Payment Gateway Integration Guide for Indian Businesses

Take a subscription nutrition brand. It sells directly to consumers, with one-time and recurring payments online, so the integration is far more than a payment button and spans several teams. The order is created, the customer is handed to the gateway, the payment succeeds, fails or stays pending, and the brand’s system must then hear that outcome reliably. Month end adds a fourth step. The money that reached the bank is reconciled against the orders marked paid, and any mismatch is chased back to a specific order and a specific payment.

Build it as one flow. Four separate pieces built independently produce the commonest failure: an order marked paid in the brand’s system when the money never settled. The reverse happens too. A customer is charged, the confirmation never reaches the system, and the order sits unpaid until the customer writes in to ask where the parcel is.

Indian gateways support several methods. Cards, UPI, net banking and wallets are typical, but the exact mix, settlement timelines and onboarding requirements vary by provider and must be checked with the gateway. Onboarding takes real time. It covers business documents, KYC and a wait for approval before live payments are switched on, so start it while the checkout is still being built.

Recurring payments are a separate feature. For a subscription business, recurring support is not the same as one-time checkout, and not every account tier or payment method supports automatic recurring charges in the same way. Confirm it in writing. A plan that works for single orders can still fail on the first renewal, which is the moment a subscriber is least forgiving.

Never touch raw card numbers. Most small businesses should not see or store a customer’s card number, and gateways offer hosted checkout pages and tokenised flows for exactly this reason. Card data goes straight to the gateway’s own PCI compliant systems, and the brand’s servers only ever see a token or a transaction reference.

A custom card form is rarely needed. One that passes card details through your own server carries a heavier compliance burden, more audit work and a larger target for attackers. Hosted wins for most. The hosted or tokenised route covers nearly every legitimate use, and the saved effort is better spent on webhook handling and reconciliation, which are where real orders go wrong.

A success page proves nothing. A customer landing on a payment successful page has not shown that the payment went through, because the page can be reached by a back button or by tampering. Only a server-to-server webhook counts. The gateway sends it from its own servers to the brand’s backend, and it states whether the charge was confirmed, failed or is still pending.

Razorpay is one widely used example. It signs each webhook with an HMAC-SHA256 hash sent in an X-Razorpay-Signature header, computed from the webhook secret set in the merchant dashboard. The receiving server must recompute that signature from the raw request body and confirm the match before it trusts the payload at all. Other gateways differ in detail. Most major ones use a broadly similar signed pattern, so confirm the exact header name and algorithm for whichever gateway you choose before writing the verification code.

Pending is a real state. UPI and net banking confirmations can take longer than a card charge, so give pending payments an explicit state and do not force them into paid or failed. Webhooks also arrive twice. The same event can be delivered more than once, so the integration must check a unique event ID before it processes a payment confirmation a second time.

Refunds deserve their own test pass. Run a full refund and a partial refund, then check how each appears in the gateway dashboard and in the brand’s own order records and customer emails. Refund handling is often an afterthought that gets tested far less than checkout, so it needs deliberate attention before launch rather than a scramble after the first complaint.

Settlement needs a check too. In the test environment, compare what the gateway pays into the bank account, usually after deducting its fee, with what the system recorded as paid for the same period. A gap found now is cheap. The same gap discovered during the first real month end close can cost days of manual matching across the bank statement, the gateway report and the order list.