Payment Gateway Integration in India (2026)

The choice depends on the payment mix, not on the dashboard. A business taking mostly UPI has different needs from one taking international cards, and a marketplace with payouts needs a provider that supports both collection and disbursement.

We compare fees, settlement time, payout support, subscription features and onboarding requirements on the payment gateway comparison before recommending one. Changing gateways later is a migration, so the decision deserves an hour.

A hosted checkout sends the customer to the provider's page and returns them with a signature. It is the fastest route, keeps card data out of your systems, and usually needs the least compliance work.

An embedded or direct API integration keeps the customer on your site, which converts better and costs more to build. It also expands your PCI scope, because card fields now touch your page even if they are posted directly to the provider.

For most Indian businesses taking UPI and cards, hosted checkout with a well-designed return flow is the rational choice in year one.

UPI on a phone works by handing the customer to an app and bringing them back. That handoff is where orders get stuck: the app is closed, the return never fires, and the payment completes anyway.

The defence is a webhook as the source of truth and a status page the customer can revisit. Never rely on the browser return alone to mark an order paid.

Recurring payments use a mandate: the customer authorises a maximum amount and frequency, and the provider debits within that limit. The integration has to create the mandate, store its reference, and handle the failures: insufficient funds, a revoked mandate, an amount above the cap.

Mandates expire and pre-debit notifications are required. A subscription that works in testing often fails in month three because the notification path was never built.

The provider will retry a webhook. It will also send events out of order. Without an identity per event and a handler that records it, a retry becomes a second order, a second invoice, or a second credit.

We store the provider's event identifier, apply the state change in a transaction, and make a repeat delivery a no-op. Signature verification happens before any parsing, because an unverified webhook is an open endpoint that can mark orders paid.

A refund is a new financial event, not the deletion of a payment. Partial refunds, refunds after settlement, and refunds on a cancelled order all need their own records, and the gateway reference must be stored so support can trace one.

If the business issues credit notes, the refund should be able to produce one without a spreadsheet.

Daily settlement files should be imported and matched against orders, with unmatched lines surfaced rather than hidden. The three usual gaps are charges with no order, orders with no charge, and amount mismatches after fees or currency conversion.

A reconciliation view is unglamorous and it is the difference between a finance team that trusts the platform and one that keeps a parallel spreadsheet.

If card data never touches your servers, your PCI obligations are far smaller. That is the main argument for hosted checkout and provider-hosted tokenisation.

What to avoid: storing card numbers, logging full request bodies, putting secret keys in front-end code, and skipping signature verification because it "works without it". The cost of getting this wrong is measured in incidents, not tickets.

Sandbox testing usually covers a successful payment. The value is in the rest: a declined card, a timeout after debit, a webhook arriving before the return redirect, a duplicate webhook, a refund larger than the original, a mandate that fails on the second debit.

We run those deliberately before launch and record the expected behaviour, so support knows what "stuck" looks like.

Production keys, KYC approval, domain allowlists, webhook endpoints over HTTPS, and a monitoring alert on payment success rate. Launch week needs someone watching failures, not just the deploy.

A drop in success rate is the earliest signal of an integration problem, and it usually appears before any customer complains.

We start with the failure log and the reconciliation gap, then trace one payment end to end: order, gateway request, return, webhook, settlement. The break is usually between two of those, and it is almost never in the gateway.

Read next: payment gateway integration cost for the pricing breakdown, or the gateway comparison if the provider is still undecided.