Cashfree vs Razorpay for Indian Developers in 2026 — Which PG Should You Use?

Some links on this page are affiliate links. They cost you nothing, and I only link tools I'd mention anyway.

Both work. Both have millions of merchants. Both support UPI, cards, netbanking, wallets, and EMI. If you pick either one, you won't regret it.

So the question isn't "which one is good" — it's "which one should I use for this project, in this context." That's what this post answers.

I'll compare them across the eight dimensions that actually matter for developers building apps and AI agents in India, then give you a clear recommendation for each scenario.

The numbers upfront

On the standard headline rates the gap is 0.05 percentage points, not the 0.25 an earlier version of this post claimed. On ₹10 lakh/month of transactions that is ₹500 a month (₹6,000 a year) before GST. It only becomes material at very high volume, so the better question is which promotion and which contract terms you actually get.

Pricing deep-dive

Rates below were read on each company's own pricing page on 2026-10-09. Both are quoted before 18% GST, and both pages include conditions, so read the fine print before relying on them.

Cashfree's pricing page shows a standard platform fee of 1.95% for the payment gateway, with a festive offer of 0% on sales up to ₹20 lakh, listed as running till 31 March 2027. The offer's terms say that after the offer ends or is used up, the standard 1.95% plus taxes applies, GST is still charged on the waived fee, and some payment methods (such as subscriptions and international transactions) are excluded. Cashfree can also withdraw the offer if credit card transactions make up 60% or more of your volume.

Razorpay's pricing page shows 2% + GST as its standard rate, with a promotion showing 0% for the first 90 days on a startup plan, and custom pricing for businesses above roughly ₹5 lakh a month or funded startups. I could not verify the old claim that Razorpay drops to 1.75% on an enterprise plan, so treat any negotiated rate as something to get in writing.

Both treat UPI specially, and the rules around UPI charges have changed more than once, so check each gateway's current terms for UPI instead of assuming it is free.

For subscriptions and recurring billing, Razorpay is ahead — their Subscriptions product has more configuration options, better retry logic, and cleaner dunning workflows. If subscription revenue is your primary model, Razorpay's extra features probably justify the small rate difference.

Settlement speed

Published numbers disagree, so check your own dashboard before you rely on any of them. As of 2026-10-09:

• Cashfree advertises next-day (T+1) settlement and instant settlement on its pricing page, but the FAQ on that same page says businesses "usually" receive money in T+2 working days. Treat T+1 as something to confirm for your account, not a guaranteed default.
• Razorpay's settlement FAQ says the standard cycle is T+2 working days, while its pricing page says the net amount is settled "on a T+1 or instant settlement cycle". Instant settlement is a separate add-on with its own pricing. Razorpay's docs also say the cycle is subject to bank approval and can vary by business vertical and risk, so what you get may differ from either page.

Either way, faster settlement is worth asking about during onboarding, especially for businesses with tight cash flow. For an AI agent that's processing payments and needs to confirm availability before fulfilling an order, T+1 vs T+2 can mean the difference between shipping same-day or next-day.

API and SDK quality

Both have clean REST APIs. Both have official Python SDKs. Neither will frustrate you.

Cashfree API (POST /pg/orders):

from cashfree_pg.api_client import Cashfree
from cashfree_pg.models.create_order_request import CreateOrderRequest

cf = Cashfree(
    XEnvironment=Cashfree.PRODUCTION,
    XClientId=os.environ["CASHFREE_CLIENT_ID"],
    XClientSecret=os.environ["CASHFREE_CLIENT_SECRET"],
)
response = cf.PGCreateOrder(CreateOrderRequest(...), None, None)
session_id = response.data.to_dict()["payment_session_id"]

Razorpay API (POST /v1/orders):

import razorpay

client = razorpay.Client(
    auth=(os.environ["RAZORPAY_KEY_ID"], os.environ["RAZORPAY_KEY_SECRET"])
)
order = client.order.create({
    "amount": 249900,  # in paise — Razorpay uses paise, Cashfree uses rupees
    "currency": "INR",
    "receipt": "order_receipt_001",
})
order_id = order["id"]

One practical difference: Razorpay amounts are in paise, Cashfree amounts are in rupees. This is a constant source of bugs — I've seen ₹1 charges processed as ₹0.01 because someone forgot the conversion. Cashfree's approach is less error-prone.

Both have webhook signatures, but the format differs:

• Cashfree: HMAC-SHA256 with base64 encoding of the digest
• Razorpay: HMAC-SHA256 with hex encoding

Neither is better — just different. Make sure you're using the right encoding or your signature checks will silently fail.

Which works better for AI agents?

For agentic workflows specifically, both are viable but Cashfree has two advantages:

1. Cleaner event model for webhooks

Cashfree's webhook payload is consistent: data.order.order_id, data.payment.payment_status, data.payment.cf_payment_id. The structure is predictable, which matters when you're writing a Claude tool definition that needs to parse it reliably.

Razorpay's webhook payload structure varies by event type, and some fields are nested differently depending on whether it's a payment, refund, or subscription event. Not a dealbreaker, but more parsing logic.

2. Tool definition works better with rupee amounts

When Claude is calling a create_payment_link tool, it needs to know the amount format. With Cashfree you define "amount": 2499 for ₹2,499. With Razorpay you'd need "amount": 249900 (paise) — models consistently make mistakes here, and you need extra prompt engineering to enforce the conversion. The tool design post covers why simpler parameter schemas mean fewer agent errors.

See the Cashfree AI agent tutorial for a complete working implementation with the Claude tool definition, webhook handler, and n8n workflow.

When to choose Cashfree

• New project starting fresh — no migration cost, a promotional rate, possibly faster settlement
• Cost-sensitive while volume is small — the festive 0% offer (up to ₹20 lakh of sales, till 31 March 2027 per its page) can matter early; after that the standard rates are close
• Building agentic workflows — cleaner webhook events, rupee amounts, reliable SDK
• Need next-day settlement (confirm in writing what your account gets)
• India-only payments — Cashfree's domestic stack is excellent

When to stick with Razorpay

• Already integrated and running — migration cost and risk rarely justify switching for a working integration
• Subscription-heavy business — Razorpay Subscriptions is more mature, better retry logic
• Significant international volume (>30% of transactions) — Razorpay supports 100+ currencies vs Cashfree's 15+
• Need Razorpay's ecosystem — their Capital, Payroll, and RazorpayX products are integrated, which can matter if you're building on those

Migrating from Razorpay to Cashfree

If you're switching, here's what changes:

The core flow (create order → redirect to checkout → handle webhook) is identical. The migration is a few hours of work, not a few days.

The honest verdict

Start new projects on Cashfree. The pricing difference is now small (1.95% vs 2% standard) apart from Cashfree's time-limited offer, so the real reasons are the rupee amounts and the cleaner API. Settlement speed is worth negotiating on either side, and the API is clean enough that there's no learning curve if you're coming from Razorpay.

Don't migrate existing Razorpay integrations unless you have a specific reason — subscription billing improvements, faster settlement, or a negotiated rate that is clearly better. At the headline rates the gap is only 0.05 points, so price your own volume and get any custom rate in writing.

For AI agents: Cashfree is the better choice. Rupee amounts, clean webhook events, and a reliable SDK mean less prompt engineering and fewer edge cases in your tool definitions.