Payment Gateway Integration Guide for Indian Businesses

Imagine a subscription nutrition brand selling directly to consumers, taking both one-time and recurring payments online. The integration isn't just 'add a payment button' — it's a full sequence: the order is created, the customer is handed off to the payment gateway, the payment either succeeds, fails or stays pending, the business's system needs to hear about that outcome reliably, and at month-end, the money that actually landed in the bank account needs to be reconciled against the orders marked paid.

Treating this as one connected flow, rather than four separate pieces built independently, is what avoids the most common failure: an order marked 'paid' in the business's own system when the money never actually settled, or the reverse — a customer charged but the order never updated.

Indian payment gateways typically support cards, UPI, net banking and wallets, but the exact mix, settlement timelines and merchant onboarding requirements — business documentation, KYC, the time to get approved for live transactions — vary by provider and should be checked directly against the gateway being evaluated rather than assumed to be identical across all of them.

For a subscription business specifically, recurring payment support is a separate feature from one-time checkout and needs to be confirmed explicitly, since not every account tier or every method supports auto-recurring charges in the same way.

The overwhelming majority of SMBs should never see or store a customer's raw card number. Payment gateways offer hosted checkout pages or tokenised flows specifically so the sensitive card data goes directly to the gateway's own PCI-compliant systems, and the business's own servers only ever see a token or a transaction reference back.

Building a custom card-entry form that passes card details through your own server is both a heavier compliance burden and rarely necessary for a typical SMB checkout — the hosted or tokenised route covers the vast majority of legitimate use cases with far less risk.

A customer landing on a 'payment successful' page in their browser is not, by itself, reliable proof that the payment actually went through — that page can be reached through a browser back button, a slow network, or in rare cases direct manipulation, and it says nothing about whether the gateway itself confirmed the charge. The only trustworthy signal is a server-to-server webhook sent directly from the gateway to the business's backend.

Razorpay, as one widely used example, 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 has to recompute that signature from the raw request body and confirm it matches before trusting the payload at all (razorpay.com, checked 2026-09-08). Most major Indian gateways use a broadly similar signed-webhook pattern, though the exact header name and algorithm should be confirmed against whichever gateway is actually chosen.

Pending payments — common with UPI and net banking, where confirmation can take longer than a card charge — need an explicit 'pending' state in the business's own system rather than being forced into paid or failed prematurely. And because webhooks can occasionally be delivered more than once for the same event, the integration should check a unique event ID before processing a payment confirmation a second time.

Before going live, refunds deserve their own test pass — a full refund, a partial refund, and how each shows up in both the gateway's dashboard and the business's own order records — since refund handling is often built as an afterthought and tested far less than the original checkout.

Settlement reporting — matching what the gateway pays out to the bank account, typically after its fee, against what was recorded as paid in the business's system — should be checked in the test environment before launch, not discovered as a gap during the first real month-end close.