Razorpay Escrow vs. Payment Links vs. Route — Which for Your Marketplace?

Every two-sided marketplace eventually hits the same question: who holds the money between the buyer paying and the seller delivering? Get this wrong and you either lose seller trust (money arrives before work is done, creating a chargeback nightmare) or buyer trust (money leaves before delivery is confirmed, and there's no recourse). Razorpay gives you three ways to handle this — payment links, Escrow, and Route — and they solve genuinely different problems. Here's how to pick.

Payment Links — when not to use them for a marketplace

Razorpay Payment Links are the fastest way to collect money. Generate a link, share it, get paid. For a marketplace, they seem tempting because they're zero-integration-effort. They're also wrong for the job in almost every case.

The problem: money goes directly to your platform account the moment the buyer pays. You're now holding funds on behalf of a seller, which in India has specific RBI implications (you're acting as a payment aggregator), and you have to manually trigger a payout to the seller after delivery. Manual is the key word — your ops team is now a bank, processing transfers one by one. At 10 transactions a day this is annoying. At 100 it breaks.

Razorpay Escrow — the trust layer for service marketplaces

Razorpay Escrow holds a payment in a neutral account until a condition is met — typically, the buyer confirming that the work was done. Only then does it release to the seller. This is the right model for any marketplace where the service happens offline and there's a trust gap between buyer and seller.

We built this for LocalUncle. A seeker books a plumber, pays into escrow, the plumber shows up and does the work, and the seeker confirms with a Twilio OTP. That OTP triggers the escrow release. The seeker can only dispute before confirming — once they've entered the OTP, the funds are on their way to the provider. The trust gap that makes cash-first local services so friction-heavy closes almost entirely.

The integration is more involved than Payment Links — you're creating escrow accounts, managing release conditions, and handling dispute webhooks — but the user experience it produces is completely different from "pay and hope."

# On OTP verification success
def release_escrow_payment(booking_id: str, otp: str):
    booking = Booking.objects.get(id=booking_id)

    if not verify_otp(booking.seeker.phone, otp):
        raise OTPVerificationError("Invalid OTP")

    # Trigger Razorpay escrow release
    razorpay_client.payment.release_escrow(
        booking.escrow_payment_id,
        {"amount": booking.amount}
    )

    booking.status = "completed"
    booking.save()
    notify_provider_payment_released(booking)

Razorpay Route — for split payouts in rental and e-commerce

Route solves a different problem: you know exactly how to split every payment upfront. Platform takes 10%, seller gets 90%. Or 15/85. Or a fixed fee plus a percentage. Route handles this automatically — the buyer pays once, Route splits it per your rules, and the seller's bank account receives their share on the settlement cycle you configure.

We used this for BookmeDrive. Every vehicle rental goes 90% to the host's verified bank account (after penny-drop verification during onboarding) and 10% to BookmeDrive. Route also handles the bank verification — hosts enter their account number, IFSC, and account holder name, and Razorpay does a small debit/credit to confirm the account exists and belongs to them before any real payout ever happens.

• Route is the right tool when your split ratio is fixed and known at payment time.
• Escrow is the right tool when the split is conditional — delivery first, then release.
• You can combine them: collect via Route, hold a portion in an Escrow-style hold until delivery, release on confirmation.

The decision matrix

• Service marketplace (plumber, tutor, cleaner) where delivery happens offline → Escrow + OTP release
• Rental platform (vehicle, equipment, space) with fixed owner split → Razorpay Route
• E-commerce marketplace with multiple sellers per cart → Razorpay Route with linked accounts
• Freelance/gig platform with milestone payments → Escrow per milestone, released on client approval
• Direct B2C business with no sellers → Payment Links or standard Razorpay checkout

DPDPA 2023 and what it means for your payment flows

India's Digital Personal Data Protection Act affects how you store and process user payment data. For a marketplace, three things matter immediately: you cannot store card numbers or UPI IDs without explicit consent for a specific purpose, your payment processor (Razorpay) acts as a data processor on your behalf and needs to be named in your privacy policy, and any cross-border data transfer of payment data requires additional safeguards.

BookmeDrive's WhatsApp-first flow was partly a DPDPA decision — booking confirmations over WhatsApp Business API (where Meta processes the message, not us) keeps sensitive booking data off our own servers and in an already-consented channel. It's lighter infrastructure and cleaner compliance at the same time.