Payment Gateway Integration in India: A Practical Guide

How a payment gateway actually works

When a customer clicks Pay, your server first creates an order with the gateway, specifying the amount and your own reference number. The customer then completes payment on the gateway's checkout: approving a UPI collect request or intent in their app, entering card details and an OTP, or logging in to net banking. The gateway talks to the card network, NPCI or the bank, and returns a result.

That result arrives in two ways: a redirect or callback to the customer's browser, and a server-to-server webhook. The browser callback is convenient for showing a success page, but it can be lost if the customer closes the tab or the network drops. The webhook, and a status check from your server, are what you should treat as the truth. Funds then move from the gateway to your bank in a settlement batch, usually a day or more later, net of fees and taxes.

• Create order on your server, never in the browser
• Customer pays on the gateway's checkout
• Verify the signature returned to the browser, then confirm status server-side
• Receive webhook and update the order idempotently
• Match the settlement report against your orders

Choosing a provider: Razorpay, Cashfree, PayU, PhonePe PG, Stripe

All the major Indian gateways support UPI, cards, net banking and popular wallets, so the choice usually comes down to onboarding speed, the features you need beyond basic payments, and how pleasant the API is to work with. Fees vary by payment method, business category and negotiated volume, and they change, so request a current quote from each provider rather than relying on published rates or blog comparisons.

Onboarding requires KYC for every provider: PAN, GST registration where applicable, bank account proof, business registration documents and a website or app with clear terms, refund and privacy policies and visible pricing. Some business categories are restricted or need extra review. International card acceptance is usually a separate activation with additional checks, and export businesses should ask specifically how foreign payments are settled and documented.

Stripe is worth a note. Its APIs and documentation are among the best anywhere, and it remains strong for businesses selling mainly to overseas customers, but it has restricted onboarding of new Indian businesses in recent years, at times to invitation only. Check its current position before planning around it, and do not assume an integration built for Stripe elsewhere can simply be reused for Indian domestic payments.

Hosted checkout vs custom checkout

A hosted or standard checkout is the gateway's own payment page or pop-up. You pass an order ID, it handles payment method selection, OTP pages and retries, and returns a result. It is the fastest to build, keeps card data entirely off your servers, which keeps your PCI DSS obligations light, and it gets UPI and card flow updates from the gateway automatically.

A custom checkout means building your own payment method screens and calling the gateway's APIs directly, for example showing a UPI app picker or saved-card list inside your own design. It can reduce drop-off for high-volume apps, but it is more code to maintain, and handling raw card data directly brings much heavier PCI DSS compliance. Most small and mid-sized businesses should use the hosted or embedded checkout and spend the effort on order handling and reconciliation instead.

Webhooks and reconciliation: where integrations fail

Webhooks are HTTP calls from the gateway to your server when something changes: payment captured, payment failed, refund processed, subscription charged. Always verify the webhook signature using your webhook secret before trusting the payload. Expect the same event more than once and out of order, so update orders idempotently: look up the order, check whether this event has already been applied, and only then change state.

Some payments end in a pending state, especially UPI, where the bank's final status can take minutes. Build a scheduled job that queries the gateway for any order still pending after a set time, and never mark an order failed purely because the browser redirect said so. Many "customer paid but order not created" complaints come from exactly this gap.

Reconciliation is the accounting side. Download settlement reports regularly, or pull them through the gateway's settlement API, and match each settlement line to your order and payment IDs, including fees, GST on fees, refunds and chargebacks deducted. Doing this daily with a script is far easier than untangling a month of mismatches, and it gives your accountant clean entries for the books.

Card tokenisation, saved cards and recurring payments

Under RBI's card-on-file rules, merchants and their payment aggregators must not store customers' full card numbers. If you want a "save card" feature, the card is converted into a network or issuer token with the customer's consent, and you store only the token reference provided by your gateway. In practice this means you should never write card numbers to your database, logs or analytics tools, even temporarily. Use the gateway's saved-card or tokenisation feature instead.

Recurring payments follow RBI's e-mandate framework. The customer registers a mandate with authentication, you must send a pre-debit notification before each charge, and debits above a set limit need fresh authentication. UPI Autopay, card mandates and e-NACH each have different limits and customer experiences. Limits and rules have been revised over time, so confirm the current ones with your provider when designing a subscription product.

• Never log request bodies from payment pages; they may contain card data
• Store gateway payment IDs, order IDs and token references only
• Show clear consent text when saving cards or creating mandates
• Handle mandate cancellation and failed renewals in your billing logic

Refunds, chargebacks and failed payments

Refunds should be triggered from your system through the gateway API, not manually from the dashboard, so that your records and the gateway's stay in step. Support partial refunds if you sell multiple items per order, store the refund ID, and listen for refund webhooks because refunds are also asynchronous. Tell customers realistic timelines: UPI refunds are often quick, while card refunds depend on the issuing bank.

Chargebacks, or disputes, happen when a cardholder contests a payment with their bank. The gateway notifies you and asks for evidence such as invoices, delivery proof or service logs, within a deadline. Keeping order, delivery and communication records linked to the payment ID makes disputes much easier to win. Watch your dispute rate; persistently high rates can lead to reserves or restrictions on your account.

Testing checklist before you go live

Every major gateway provides a test mode with test keys, test cards and simulated UPI flows. Use it to run through the unhappy paths as carefully as the happy ones, because those are what generate support calls after launch. Then do a small number of real low-value transactions in live mode with your own cards and UPI apps before you open to customers.

• Successful payment by UPI, card, net banking and wallet
• Failed payment, cancelled payment and customer closing the tab mid-payment
• Pending UPI payment that succeeds later; order must update via webhook or status check
• Duplicate webhook delivery; order must not be double-fulfilled
• Invalid webhook signature; request must be rejected
• Amount tampering in the browser; server must use its own order amount
• Full and partial refunds, and refund webhooks
• Live keys in production only, test keys never shipped to live, secrets kept out of front-end code
• Settlement report matches your orders for the first few days of live traffic

Common failure cases and how to avoid them

Most incidents in payment integrations fall into a short list of mistakes, and nearly all of them are about state management rather than the gateway itself. Each one below looks harmless in testing, where networks are fast and nobody closes the tab halfway, and becomes expensive in production, where customers are on patchy mobile data and switch between apps to approve UPI payments.

• Marking orders paid based only on the browser redirect, without server verification
• Creating orders with an amount sent from the client, allowing price tampering
• No handling for pending status, so late UPI successes are never fulfilled
• Webhook endpoint behind a login or firewall, so events never arrive
• Not handling duplicate events, leading to double shipments or double credits
• Secret keys committed to a code repository or exposed in a mobile app
• Currency or rounding bugs, since amounts are usually sent in paise, the smallest unit
• No reconciliation, so fee deductions and chargebacks go unnoticed for months

Getting help with your integration

A basic hosted checkout on a standard website can be done in a few days. Subscriptions, marketplace splits, custom checkouts and reconciliation with accounting software take longer and deserve careful design. RED SAG Fintech Solutions builds payment gateway integrations, billing and fintech software from Tiruppur, and can review an existing integration against the checklist above if you would rather have a second pair of eyes.