Rental Platform Development: Search, Booking, Payments
Developing a rental platform is not just about listing layouts and a booking form. The key challenge is the logic of availability, payments, and synchronization. If two booking requests arrive for the same property at the same time, without proper locking both will succeed — the host gets double overpayment, and the guest gets a cancellation. We design transactional systems where race conditions are eliminated at the DBMS level. For example, in a project for a network of apartments in Minsk, we handle over 500 bookings per day without a single conflict over more than 2 years of operation. The solution is on Laravel + PostgreSQL with SELECT FOR UPDATE and a state machine for statuses. Below is the specific architecture of the key modules.
Beyond data correctness, performance is critical. Core Web Vitals — LCP, CLS, INP — directly affect conversion. We achieve LCP < 1.5s with server-side rendering (Next.js), image optimization, and CDN. For complex maps with clustering, we use vector tiles and lazy loading.
Why the Availability Model Is the Core of Any Rental Platform?
No available: boolean on a property works. You need a separate table of periods with block types — booked, owner_blocked, maintenance, external_ical. Only then can you correctly check availability for date overlaps. The difference between PostGIS and MySQL Spatial is a 3x performance gain within a 50 km radius thanks to GiST indexes.
CREATE TABLE availability_blocks (
id BIGSERIAL PRIMARY KEY,
listing_id BIGINT NOT NULL REFERENCES listings(id),
start_date DATE NOT NULL,
end_date DATE NOT NULL,
block_type VARCHAR(20) NOT NULL,
booking_id BIGINT REFERENCES bookings(id),
CHECK (end_date > start_date)
);
CREATE INDEX idx_availability_listing_dates
ON availability_blocks (listing_id, start_date, end_date);
The availability check query under SELECT FOR UPDATE locking is mandatory — otherwise concurrent requests on the same property cause a race condition.
Search with Geo-Filtering: PostGIS vs MySQL Spatial
For geo-search, PostGIS is 3x faster than MySQL Spatial: support for SRID 4326, functions ST_DWithin and ST_Distance with geography types, GiST indexes. On the frontend we use Mapbox GL JS — vector tiles provide the best UX.
| Parameter | PostGIS (GiST index) | MySQL Spatial (R-tree) |
|---|---|---|
| Execution time (50 km radius, 1M points) | 120ms | 380ms |
| Geography type support | Yes | No |
| Functions for distance in meters | ST_DWithin, ST_Distance | ST_Distance_Sphere (slower) |
| Indexing | GiST (fast for intersections) | R-tree (less efficient) |
SELECT
l.id,
l.title,
l.price_per_night,
ST_Distance(l.location, ST_MakePoint($1, $2)::geography) AS distance_meters
FROM listings l
WHERE ST_DWithin(
l.location,
ST_MakePoint($1, $2)::geography,
$3
)
AND l.guests_max >= $4
AND l.bedrooms >= $5
AND NOT EXISTS (
SELECT 1 FROM availability_blocks ab
WHERE ab.listing_id = l.id
AND ab.block_type IN ('booked', 'owner_blocked')
AND ab.start_date < $7
AND ab.end_date > $6
)
ORDER BY distance_meters
LIMIT 50;
Booking System: State Machine on Laravel
| Status | Allowed Transitions |
|---|---|
| pending_payment | confirmed, cancelled |
| confirmed | cancelled_by_host, cancelled_by_guest, active |
| active | completed, disputed |
class Booking extends Model
{
public function confirm(): void
{
if ($this->status !== BookingStatus::PendingPayment) {
throw new InvalidBookingTransitionException(
"Cannot confirm booking in status: {$this->status->value}"
);
}
DB::transaction(function () {
$this->update(['status' => BookingStatus::Confirmed]);
AvailabilityBlock::create([
'listing_id' => $this->listing_id,
'start_date' => $this->check_in,
'end_date' => $this->check_out,
'block_type' => 'booked',
'booking_id' => $this->id,
]);
event(new BookingConfirmed($this));
});
}
}
Payments and Fund Holding: Stripe Connect
A key feature of rentals: funds are held at booking and disbursed to the host after check-in (or checkout). Stripe Connect with capture_method: manual allows later capture. Scheduled jobs handle payouts and refunds. An error in payout logic can cost up to 15% of turnover due to fees and refunds — so we manually test every scenario. Stripe recommends using capture_method: manual for platforms holding funds until service delivery. Savings on fees with a custom platform can reach 10–15% of turnover — at 1,000 bookings per month with an average check of $200, that's $24,000–36,000 per year.
How to Avoid Conflicts When Syncing with Airbnb and Booking?
We connect iCal (RFC 5545): the host provides a calendar URL, the system imports external blocks. Export works the opposite way. Laravel Scheduler runs sync every 15–30 minutes. This prevents double booking across platforms.
iCal sync details
Import parses the ICS file, extracts VEVENT events, and creates blocks of type external_ical. Export generates an ICS string with blocks from internal bookings. To avoid duplicates, we store external_event_uid and update only changed records.
Two-Way Anonymity Review System
Reviews are published only after both parties have left a review or 14 days after checkout. This eliminates pressure and builds trust. Implementation with published_at and a scheduled job.
What Are Core Web Vitals and Why Do They Matter for Rental Platforms?
Google ranks sites on LCP, CLS, INP metrics. For a rental platform, critical are: listing page load speed (LCP), layout stability when images load (CLS), and filter responsiveness (INP). We achieve LCP < 1.5s with server-side rendering (Next.js), image optimization, and CDN. For complex maps with clustering, we use vector tiles and lazy loading.
How We Implement the Payment System: Step by Step
- Design payment schema: choose Stripe Connect, configure
capture_method: manual - Build endpoints for creating PaymentIntent and confirmation
- Handle webhooks (payment_intent.succeeded, charge.disputed)
- Scheduled jobs for host payouts (with delay after check-in)
- Test all cases: successful payment, cancellation, refund, dispute
What Is Included in the Work
- Database architecture, API design, payment schema
- Listings, search, booking, chat development
- Integration with Stripe Connect, iCal, email notifications
- Deployment on client infrastructure (VPS, Docker)
- Documentation, admin training, 6-month warranty
Development Timeline
Basic version (search, booking, Stripe, dashboards): 10–12 weeks. With iCal, reviews, clustered map: 14–18 weeks. Full feature set (moderation, verification, dispute resolution, analytics): 20–24 weeks. Testing edge cases with payouts is the longest phase — each bug either loses money or creates legal risk.
Contact us for a consultation — we'll analyze your project and propose an architecture. Get an estimate within a day. Reach out to discuss the details.