Sdaete: web development, payments and rental security
How I worked on the web part of a peer-to-peer rental service: the user journey, acquiring, data protection and testing the full deal cycle.
The task and my role
Sdaete (“you’re renting out”) is a service for renting things: one person posts a listing, another picks an item and books it for the dates they need. The project started as a P2P model in which the platform connects the parties and supports the deal.
I joined at the end of March 2026. My area covered the website, code quality, security and testing. The work turned out to be wider than a standalone audit: I improved user scenarios, the payment integration and the running of the web part of an existing team product.
A deal as a sequence of states
A rental has several connected stages: listing → booking → confirming terms → payment → handing over the item → completion. Each stage affects which actions are available to the parties and what should happen next.
| Stage | What the web part has to keep consistent |
|---|---|
| Search and booking | The listing, the rental period and the price calculation |
| Rental terms | Participant confirmation and consent before payment |
| Payment | Payment state and whether actions can be repeated |
| Handover and completion | Confirmations from both parties, the charge and the deposit return |
So I checked fixes against the whole scenario. For example, after payment the interface has to show the current booking state, and coming back to the page has to restore the steps already completed.
This path changed while I worked on it. An early version used uploads of signed contracts. In the June version that mandatory step was removed, and consent to the user agreement and privacy policy remained before payment. The old signing states are still in the code for earlier requests.
What the product connected
| Section | Participant scenario |
|---|---|
| Catalogue and search | Category, city, daily price, sorting and an item card |
| Listing | A wizard: title, description, category, price, photos and address |
| Favourites | Save an item and return to it later |
| Booking | Choose dates, check availability and get a price calculation |
| Terms and verification | Confirm the participant and accept the rental terms |
| Payment | Hold, deposit, charge confirmation, cancellation and refund |
| Handover | Confirmations from both sides, condition photos and the start of the rental |
| Chat | A conversation tied to a listing or a specific booking |
| Profile | Listings, requests, notifications, history and referrals |
| Completion | Return of the item and deposit, settlement with the owner, a review and the archive |
| Administration | Listing moderation, verification, users and payment disputes |
The web part and code quality
Listing wizard: from a description to a clear price
Creating a listing is split into six steps: title, description, category and condition, price, photos, address. Moving on depends on the current step being filled in. An empty title or description does not let the user through, the price has to be positive, and at least one photo is required before leaving the photo step. The form accepts up to ten photos and shows which one will be the main image.
On the price step the owner enters a daily rate and immediately sees the commission and the amount they will receive. The percentage is loaded for the account type, so the calculation depends on the user’s data. In an example with a price of 600 ₽ and a 10% commission, the form shows 60 ₽ commission and 540 ₽ for the owner.
The request: period, calculation and the next step
Once an item is chosen, the deal gets its own page. It shows the counterparty, the period, the number of days, the daily price, the rental cost, the deposit and the total. The view depends on the role: the owner can accept or decline a new request, while the renter sees that a decision is pending. After approval the renter gets a consent form and access to payment.
Dates are counted inclusively: 20 to 22 October is three days. At 600 ₽ a day the rental comes to 1,800 ₽. The payment state is stored separately from the request state, because approval by the owner does not by itself mean the money has been paid.
I worked on the catalogue, the home page, requests and booking. I fixed listing loading, state display, price calculation and repeated actions in forms. Styling and matching the interface to the mock-ups were a separate part of the work.
In the code I removed debug messages and outdated sections and brought authorisation handling to one common approach. This reduced the number of places where the same user step could be handled differently.
The web application uses Next.js and React, the API is NestJS, data lives in PostgreSQL via Prisma, and files go to S3 object storage. In an existing product, changes had to stay consistent across the interface, the API and the data model.
In booking, what matters is the chosen period, the available dates and the request state. Chat ties a conversation to an item and a deal, and the rental screen brings together terms, payment and handover. Completion includes condition photos, confirmations from the parties and a review. My checks went through these transitions, where a state error could block the next step.
Payments and completing a rental
I worked on the acquiring integration and two-stage payment: first the funds are held, then the payment is captured at the right moment of the deal. I also improved price calculation, the deposit and how payment status is displayed.
For this it was important to separate the rental state from the payment state. Confirming one step must not accidentally repeat another. I also went through settlement terms and owner payouts after a rental with the bank’s support team.
Settlements with the owner and payout conditions needed separate agreement with the bank, so I tested the integration by individual operations and deal states.
Security and data
I checked access control, personal data handling, sessions and user input protection. I improved encryption of sensitive fields, reduced how much data reached the logs, and separated file storage between environments.
The audit closed 43 findings: 24 from code review, 10 from the first red team round and 9 from the second.
How I tested changes
I tested the full user journey: creating a listing, booking, confirming terms, payment and the start of a rental. In the early scenario I also checked the contract step. I checked as well that operations the user should not be able to perform were refused.
The repository keeps separate E2E tests for authorisation, listings, booking, verification and admin access. A set like this helps verify the links between parts of the product after each change.
Result
My contribution combined fullstack development, payment integration and AppSec. Interface improvements went along with changes to state handling, data protection and user journey testing.
The main thing I took from this project is supporting an existing product as a whole: understanding how a change on one screen affects the API, the contract, the payment and what the parties can do next.