Every founder comparing Indian payment gateways starts by putting the pricing pages side by side. It's the obvious move, and it's close to useless.
The headline rates are nearly identical. They're all clustered within a rounding error of each other, they're all negotiable once you have volume, and they're all quoted in a way that obscures what you'll actually pay.
Meanwhile the things that genuinely differ — payment success rate, settlement speed, what happens when a customer disputes a charge, whether you can pay money out as easily as you take it in — barely get discussed, and those are where the money is.
We've integrated all three for clients. Here's what actually matters.
First, the thing that changes the whole calculation
UPI carries zero MDR. Merchant discount rate on UPI person-to-merchant transactions is nil — that's a government mandate, not a gateway promotion. Nobody can charge you a percentage on a UPI payment.
For most Indian consumer businesses, UPI is now the overwhelming majority of transaction count. So if you're modelling costs off a 2% card rate applied to all revenue, your model is wrong — often by a lot.
What this means practically:
- Your blended cost of payments is far lower than any rate card suggests, and it's driven almost entirely by your payment mix, not your negotiated rate.
- Gateways make little or nothing on your UPI volume. They make money on cards, netbanking, EMI, international, and increasingly on payouts and adjacent products.
- A gateway that pushes you toward cards is not necessarily acting in your interest.
Before comparing anyone, pull your actual or expected payment mix. If you're 85% UPI, the difference between a 1.9% and 2.1% card rate is close to noise, and you should be optimising for something else entirely.
The three, honestly
All three are RBI-authorised payment aggregators, all three do the core job competently, and all three will process your payments reliably. The differences are in shape, not quality.
Razorpay
The broadest product surface of the three, and the best developer experience in the Indian market — clear documentation, sane API design, good test mode, mature SDKs across languages.
Where it earns its place is everything around the gateway: business banking, vendor payouts, split settlements to marketplace sellers, subscription billing, payment links, invoicing. If you need any of that, it's usually already there.
The trade-off is that it's a large company with a large customer base, and the support experience reflects that. On a standard plan you're in a queue. At scale, with an account manager, that changes.
Best fit: the default choice for most startups, and the strongest option if you need the surrounding financial products or your team values developer experience.
Cashfree
Historically the strongest of the three on payouts — sending money out, in bulk, programmatically. If your business disburses funds (marketplace seller settlements, refunds at scale, salary or vendor payments, insurance claims, lending disbursals), this is where Cashfree tends to be picked.
Also a solid verification suite — bank account validation, UPI handle checks — which pairs naturally with payouts, since you want to confirm an account exists before sending money to it.
Collections are perfectly competent; the payouts side is the differentiator.
Best fit: two-sided marketplaces, lending, insurance, and anything where money moving out is as important as money coming in.
PhonePe Payment Gateway
The newest of the three as a merchant gateway, and its advantage is structural: PhonePe is one of the largest UPI apps in India. That proximity to UPI rails can show up as better success rates on UPI transactions, which is a bigger deal than it sounds.
The product surface is narrower than Razorpay's. You're buying a payment gateway, not a financial-operations suite.
Best fit: consumer businesses that are overwhelmingly UPI-driven and want the tightest possible UPI experience without needing payouts, subscriptions, or banking products.
Verify current rates and terms directly. Rate cards, settlement timelines and product features change, and everything is negotiable above a certain volume. Take the numbers from each provider in writing, for your expected mix, before deciding. The comparison below is about structure — the parts that don't change month to month.
What actually differs, in order of what it'll cost you
1. Payment success rate
This is the one that dwarfs everything else, and almost nobody evaluates it.
If gateway A converts 94% of attempted payments and gateway B converts 91%, that 3-point gap is revenue you never see. On ₹1 crore of monthly attempted transactions, three points is ₹3 lakh a month walking away — vastly more than any plausible MDR difference on the same volume.
Success rate varies by gateway, by payment method, by issuing bank, and by time of day. It depends on routing intelligence, retry logic, and how many acquiring bank relationships sit behind the scenes.
How to actually evaluate it: ask each provider for success rates on your specific payment mix, and treat vague answers as an answer. Better still, run a genuine A/B — split live traffic between two gateways for a month and measure. It's more work than reading a pricing page and it's worth more than everything else on this list combined.
2. Settlement cycle
When does money actually reach your bank account? Standard is typically T+2 business days, with faster settlement available at a fee, and slower cycles common for new or high-risk merchants.
The cost here is working capital. If you're doing ₹50 lakh a month, every extra day of settlement delay is roughly ₹1.7 lakh of your cash sitting with the gateway instead of paying your suppliers. For a thin-margin, inventory-heavy business, settlement speed can matter more than MDR.
Ask specifically: what's the standard cycle, what does faster cost, what triggers a rolling reserve, and how are weekends and bank holidays handled? That last one surprises people — "T+2 business days" over a long weekend is a week.
3. Payouts
Taking money in is a solved problem everywhere. Paying money out is where gateways diverge sharply — in per-transaction cost, in bulk capability, in supported rails, and in how good the API is.
If your model involves disbursing funds, evaluate this as a first-class requirement rather than an afterthought, because it's a much bigger differentiator than collections.
4. Onboarding and underwriting
How long from signup to live? It varies from days to weeks, driven by KYC review, business category, and documentation.
Some categories get scrutinised heavily or declined outright — anything resembling gambling, crypto, certain healthcare and financial services, dropshipping, and high-chargeback verticals. If you're in a category anyone might consider borderline, ask before you build. Discovering your business type is unsupported after integration is a genuinely expensive surprise.
Have GST registration, PAN, bank proof, incorporation documents and a live website with visible policy pages ready. Missing policy pages — refund, shipping, terms, privacy — is one of the most common onboarding rejections and one of the easiest to pre-empt.
5. Support, when something is actually wrong
Every gateway's support is fine when nothing is wrong. What matters is the day payments are failing and you don't know why.
Ask: is there a phone number or only tickets? What's the escalation path? Is there a status page, and is it honest? Do you get an account manager, and at what volume?
Talk to another merchant of roughly your size on the same provider. That single conversation will tell you more than any sales call.
What you must build regardless of who you pick
These are your responsibility, not the gateway's.
Never trust the client. The browser tells you a payment succeeded. That's a claim, not a fact. Always verify server-side — either by calling the gateway's order-status API or by validating the signature on the callback — before you mark an order paid. Trusting a client-side success redirect is the most common and most expensive payment bug we see.
Webhooks are the source of truth, and they must be idempotent. Gateways retry. You will receive the same event more than once. If a duplicate webhook can double-credit a wallet or ship an order twice, you have a real problem waiting to happen. Deduplicate on the gateway's event ID.
Handle the pending state properly. Payments are not binary. UPI transactions sit in pending, sometimes for minutes. Your data model needs a genuine pending state with reconciliation, not an optimistic guess. Never ship goods on pending.
Reconcile daily, automatically. Compare gateway settlement reports against your own order records every day. Mismatches happen — failed-but-charged, refunds that didn't process, settlement short by a fee you didn't model. Catching these at a day old is routine; catching them at three months old is forensics.
Don't store card data. RBI's tokenisation regime means raw card details don't live in your systems. Use the gateway's tokenisation. Storing card data yourself pulls you into PCI-DSS scope you almost certainly don't want.
Abstract the gateway behind your own interface. Do not scatter gateway-specific calls across your codebase. Put them behind a payment interface of your own design. You will change or add a provider eventually — for better rates, for redundancy, or because a category decision forced it — and the difference between a two-week job and a two-day job is entirely whether you did this at the start.
That last point matters more than choosing correctly. Many mature Indian businesses run two gateways and route between them for redundancy and success-rate optimisation. That's only practical if the abstraction exists.
How to actually decide
Mostly UPI, straightforward consumer collections. Any of the three works. Pick on developer experience and support. Razorpay for the ecosystem, PhonePe if you want the tightest UPI path.
You need payouts. Cashfree deserves a serious look. Evaluate payouts as the primary requirement.
You need subscriptions, split settlements, or business banking. Razorpay's breadth is hard to match without stitching several vendors together.
High volume, thin margins. Optimise for success rate and settlement speed, negotiate hard, and plan for two gateways with routing between them.
Regulated or unusual category. Talk to underwriting before you write any code. This constraint outranks every other consideration.
And the meta-advice: don't spend three weeks on this decision. All three are competent. Abstract the integration properly, launch, measure your real success rate, and change providers later if the data says so. The abstraction is worth more than the choice.
Need this integrated properly?
We build payment integrations for Indian businesses — gateway integration, payouts, subscriptions, reconciliation, and the provider-agnostic abstraction that makes switching cheap. Including the unglamorous parts: idempotent webhooks, pending-state handling, and daily reconciliation that catches problems while they're still small.
Bengaluru-based, working with clients across India and globally.
Get in touch · See our API integration work · WhatsApp: +91 9677749648