Payment Gateway Integration: What to Settle on Security, Fees, Testing and Reconciliation

Most payment gateway integration projects are scoped as a checkout task: pick a provider, drop in an SDK, ship. The trouble usually surfaces weeks later — a finance team that cannot match settlements to orders, a security review that flags stored card data, or a support queue full of "amount debited, order not confirmed" tickets. A gateway is not a UI component. It is the point where your product, your regulatory obligations and your cash flow meet.

This article lays out what Indian teams should settle before the first line of integration code is written, organised around the four areas that generate the most rework: security, fees, testing and reconciliation.

Decide the money flow before the SDK

Start with questions that have nothing to do with code. Who is the merchant of record on the customer's card statement? Is your provider an RBI-authorised payment aggregator, or are you operating under someone else's licence through a platform arrangement? What is the settlement cycle and cut-off time, and do weekends and holidays shift it? Is there a rolling reserve, and for how long? Which account does money settle into, and is it a nodal or escrow structure you need to understand for accounting purposes?

Also decide whether you will run a single gateway or a primary with a fallback. Failover sounds like an infrastructure decision but it changes your reconciliation, your refund paths and your support scripts. If you want dynamic routing across providers, confirm whether that is a native feature or something you must build and operate yourself.

Security: what you can and cannot outsource

Using a hosted checkout page shifts a large part of the card-data burden to the provider, but it does not make security someone else's problem. Before integration, establish which PCI DSS self-assessment questionnaire applies to your setup — broadly, the lighter SAQ A when card data is entirely captured inside the provider's hosted page or iframe, and a heavier questionnaire once your own page can influence the security of the payment flow. Ask your provider and your acquirer to confirm in writing rather than assuming.

Tokenisation and stored credentials

RBI's card-on-file tokenisation rules mean merchants no longer store actual card numbers; you hold tokens issued through the card networks. Design your data model around tokens from day one, because retrofitting it after you have built a saved-cards feature is painful. If you support recurring payments or subscriptions, your flows must respect RBI's additional-factor-of-authentication requirement for e-mandates above the prescribed threshold, including the pre-transaction notification step. Read the current circulars rather than a blog summary, since thresholds and exemptions have been revised more than once.

Webhooks and callbacks are the trust boundary

Never treat the browser redirect back to your site as proof of payment. Verify the order status server-side with the provider's API before you fulfil. For webhooks, verify the signature using the shared secret, check the timestamp to block replay, and make your handler idempotent so a duplicate delivery does not create a second order or a duplicate ledger entry. Webhooks can arrive out of order; a refund event may land before the capture event. Handle unknown states gracefully and reconcile later rather than rejecting events.

Application-level hygiene

Compute the amount on the server, never from a client-supplied value. Keep API keys in a secrets manager, with separate credentials for test and production, and rotate them on a schedule. Strip card numbers, CVVs and raw provider payloads containing sensitive fields from application logs; store the raw webhook body in an encrypted, access-controlled bucket if you need it for disputes. Give refund and settlement-configuration actions their own permission set and an audit trail — refund fraud is usually an insider problem, not a hacker one.

Fees: read the schedule line by line

The headline MDR is rarely the full cost. Ask for the complete schedule: per-instrument MDR (cards, netbanking, wallets, EMI, UPI), any platform or per-transaction fee on top, onboarding and annual charges, instant-settlement charges, chargeback handling fees, and whether MDR is returned on refunds. UPI and RuPay debit transactions carry zero MDR for merchants under current RBI/NPCI rules, but gateways may still levy a platform fee, so separate the two in your model.

Then add GST on the gateway's fees, and note that the tax invoice matters if you want to claim input credit. TDS treatment depends on how your provider is classified and is worth a short conversation with your chartered accountant rather than a guess. Finally, build a per-rupee-collected model that includes failed-payment retries, refunds and chargeback drag. A marginally higher MDR with a materially better success rate often beats a cheaper gateway, because a failed payment is lost revenue, not a saved cost.

Testing beyond the happy path

Sandbox success is table stakes. Build your UAT plan around the states that actually break in production: pending payments where the customer abandons after bank authentication, timeouts where the debit succeeds but your callback never arrives, duplicate webhooks, out-of-order events, partial refunds, multiple partial captures, and currency rounding. Test the three-D Secure challenge and frictionless paths separately, on a real mid-range Android device, with a slow network.

Then test the failure modes of the provider itself. Simulate a gateway outage and confirm your fallback and your error messaging behave. Run a load test that reflects your peak sale traffic, and write a runbook with an escalation contact at the provider before you need it at 11 pm on a festival sale night.

Reconciliation is a product feature, not a spreadsheet

Reconciliation is the discipline that catches everything the webhook missed. Aim for a daily three-way match: your order ledger, your payment records, and the provider's settlement report plus bank credit. Map each settlement line to your order ID and the bank UTR or RRN. Expect timing mismatches — refunds netted off, fees deducted at source, weekend cut-offs — and design your ledger so these are explainable rather than mysterious.

Pull settlement and dispute data through APIs into your own store rather than relying on portal downloads. Alert on open items older than a defined number of days, and give finance a view of chargebacks with the evidence you will need to contest them. Assign one owner for the daily match and one for the monthly close, with GST invoices from the gateway archived alongside.

A short pre-integration checklist

• Confirm the aggregator's RBI authorisation status and your merchant-of-record position.
• Get the settlement cycle, reserves and cut-off timings in writing.
• Document which PCI DSS SAQ applies and who owns each control.
• Design token-based storage and idempotent webhook handling up front.
• Model total cost of collection, not just MDR.
• Write UAT scenarios for pending, duplicate and out-of-order states.
• Build the daily reconciliation job before launch, not after the first mismatch.

None of this is exotic, but it is easy to defer under delivery pressure. Teams that do this groundwork usually ship a checkout in the same timeframe as everyone else — they simply spend the following quarter improving conversion instead of explaining a settlement gap.