Payment Gateway Integration India: Razorpay, PayU, Cashfree

If you are adding online payments to a custom website, SaaS product or internal portal, payment gateway integration India teams need goes well beyond pasting a checkout button. The part that decides whether money and orders stay in sync is on your server: how you create the order, verify the result and handle repeats.

This guide is written for founders and product owners who need to brief a developer, and for developers who want a checklist. It compares Razorpay, PayU and Cashfree on the points that matter for your backend, then walks through a safe build order, indicative costs and common mistakes.

What does payment gateway integration involve?

Payment gateway integration is the work of connecting your application's orders to a licensed payment provider so customers can pay by UPI, card, netbanking or wallet, and your system learns the result reliably. The gateway handles card entry, OTPs and bank redirects. You handle everything before and after.

A typical flow has five stages:

1. Your server creates an order with the amount, currency and your own reference.
2. The browser or app opens the gateway's checkout using that order.
3. The customer pays, and the gateway returns a result to the browser.
4. The gateway sends a signed webhook to your server with the final status.
5. Your server marks the order paid, fulfils it and later reconciles the payout.

Steps 1 and 4 are where most bugs live, so they get most of the attention below. If you sell on Shopify instead of a custom stack, read our Shopify payment gateway guide for India, because the platform handles much of this for you.

How do Razorpay, PayU and Cashfree differ for developers?

All three give you server APIs, hosted or embedded checkout and webhooks, but they differ in how they identify and verify a payment. Check each provider's current documentation before you build, because parameters and versions change.

This is a summary, not a substitute for the docs. Razorpay documents its approach in Validate and Test Webhooks, PayU explains reverse hashing in its Generate Hash guide, and Cashfree describes its scheme in Webhook Signature Verification.

Pick on commercial and operational fit as well: approved rates, settlement cycle, refund handling and support. Our Shopify payment gateway comparison table lists the questions to ask each provider, and they apply to custom builds too.

Why must the webhook decide whether an order is paid?

The signed webhook is the only message that comes from the gateway to your server directly, so it is the safest signal for marking an order paid. The browser callback depends on a customer's device and network, and it can be skipped or forged.

Razorpay's integration guide says plainly to rely on webhooks for all fulfilment and never use the browser callback alone for order confirmation. The same principle applies to PayU and Cashfree. Use the browser result to show "payment processing" and let the webhook, or a server-side status fetch, flip the order to paid.

Keep a fallback for the rare missed webhook. If an order has been pending longer than a few minutes, call the gateway's payment status API from a scheduled job and update the order from that response. This protects users who paid but never saw a confirmation page.

How do you verify webhook signatures correctly?

You verify a webhook by recomputing the HMAC of the raw request body with your secret and comparing it to the signature header before you parse or use any field. The raw body matters because re-serialising JSON can change spacing, field order or number formatting, which breaks the match.

In Node.js this means capturing the raw bytes before your JSON middleware runs. Use a constant-time comparison for the final check, and return a 4xx status when it fails.

Three details trip teams up:

• Secret mismatch. Razorpay's webhook secret is set when you create the webhook and does not have to be your API key secret.
• Rotated secrets. Retried events may be signed with the old secret, so keep it available while old events drain.
• Decimal formatting. Cashfree notes that converting the payload to an object can turn 170.00 into 170, which changes the signature input.

Signature checks sit alongside the rest of your API hygiene, so pair this with our API security checklist for auth, rate limits and logging.

How do you handle duplicate and out-of-order events?

You handle them by recording every event ID once and by making the business action depend on current order state, not on event arrival order. Razorpay documents at-least-once delivery, so the same event can reach you several times, for example when your server accepts it but does not respond within the timeout.

A reliable pattern looks like this:

1. Verify the signature on the raw body.
2. Insert the event ID into a table with a unique constraint. If the insert fails, return 200 and stop.
3. Return 200 quickly and push the real work onto a queue.
4. In the worker, load the order and check its state. Only move forward, for example from pending to paid, never backwards.
5. Fulfil once, using a unique key such as the order ID, so two different events about the same payment cannot ship twice.

Razorpay also warns that payment.captured can arrive before payment.authorized, so do not assume a sequence. Queues and retries are covered in our post on backend scalability with caching, queues and read replicas.

What should the build checklist include?

A complete build covers more than the happy path. Use this order of work:

1. Define the order model. Store your order ID, gateway order or transaction ID, amount in paise or rupees, status and timestamps.
2. Create orders server-side only. Calculate the amount from your own price data, never from a browser field. PayU also expects a fresh transaction ID for every retry.
3. Verify the result. Check the checkout signature or reverse hash, then confirm the amount matches your order.
4. Add the webhook endpoint with raw-body signature checks, event ID storage and a queue.
5. Build refunds and failures. Handle failed payments, partial refunds and refund failure events, and show clear status to the customer.
6. Add reconciliation. Match gateway settlement reports to your orders and your bank statement.
7. Test in sandbox, including duplicate, delayed and out-of-order events and an expired UPI request.
8. Go live with small real payments, refund them and confirm the full trail.

For API shape and versioning, our REST API design best practices post covers conventions that keep payment endpoints predictable.

How much does payment gateway integration cost in India?

Cost depends on scope, not on the gateway, because the gateways themselves provide SDKs and documentation. The ranges below are indicative estimates based on typical project scopes, not quotes.

GST applies to development fees, and gateway charges are separate. Recurring billing needs extra design work, which we cover in our post on SaaS subscription billing in India. Your final estimate will depend on your existing codebase, compliance needs and the number of payment flows.

What mistakes should you avoid?

Most payment incidents come from a small set of shortcuts:

• Trusting the browser redirect and shipping before the webhook arrives.
• Taking the amount from the client, which lets a user pay ₹1 for a ₹10,000 order.
• Parsing the body before verifying, then wondering why signatures fail.
• Skipping duplicate handling, so a retry credits wallet balance or sends goods twice.
• Leaving test keys in production or live keys in a public repository.
• Not logging gateway IDs, which makes a support case slow to resolve.
• Never reconciling, so settlement gaps surface only at GST filing time.

How Arham Technology approaches payment gateway integration

Payments sit inside our backend development service, where we treat correctness and operability as the main goals rather than extra features. For a gateway project the process is:

• Domain and threat sketch: we map your order lifecycle, trust boundaries and the abuse cases that matter, such as amount tampering and replayed events.
• Contract first: we agree API contracts so your web or mobile client and the payment endpoints can be built in parallel.
• Core build: order creation, verification and webhook handling ship with automated tests around the state transitions.
• Integration reality: background workers, retries and idempotent write paths are exercised against sandbox events, including duplicates and delays.
• Runbook handover: deploy steps, secret handling and incident basics are documented for your team.

If payments are part of a larger product, our SaaS development service covers the surrounding billing, tenancy and admin features.

What should you do next?

Write down your payment flows first: one-time orders, refunds, subscriptions and payouts. Shortlist two gateways, ask for written rates and sandbox access, and decide how you will reconcile before you write code. If you want a second pair of eyes on an existing integration or a plan for a new one, review our backend development service and contact us with your order volume and stack. We will outline a pragmatic scope and test plan before you commit.