Payment Infrastructure in India: Rails, Routing and Reconciliation

The rails underneath

India has the deepest real-time payment infrastructure in the region. UPI handles billions of transactions a month and has effectively replaced cards for everyday online spending. From an infrastructure perspective India offers UPI for instant low-value collections and IMPS, NEFT and RTGS for bank transfers. UPI carries the instant leg, and the banking system handles higher-value, slower-settling transfers.

Each rail has its own state machine. Wallet flows tend to be asynchronous: you create an intent, the customer authorises in their own app, and confirmation arrives by callback some seconds — occasionally minutes — later. Bank rails may confirm on a batch cycle. A system that assumes synchronous responses will misreport a meaningful share of real transactions.

Designing for asynchronous confirmation

Three properties make an asynchronous integration reliable:

• Idempotency. Every create call carries a client-generated key so a retry cannot produce a second charge.
• Monotonic state. A transaction moves forward only — created, pending, succeeded or failed, then optionally refunded. Late or out-of-order callbacks never move it backwards.
• Reconcilable identity. Your order reference, the gateway reference and the rail reference are all stored on the same record.

These are covered in our API documentation and explored further in how payment APIs work.

Routing and redundancy

A single upstream connection is a single point of failure. Bank-side downtime is public and predictable enough that routing logic should shift traffic away from a degraded sponsor bank automatically rather than waiting for support tickets.

A production routing layer in India should:

1. Maintain more than one connection per major method where available.
2. Score each connection on a rolling window of success rate and latency.
3. Shift traffic automatically when a score crosses a threshold.
4. Retry a failed attempt on an alternative route where the method allows it safely.
5. Log every routing decision so post-incident analysis is possible.

This is exactly what the routing and failover layer described on our payment infrastructure page is built to do.

Ledger design

The ledger is the source of truth, not the gateway dashboard. A double-entry model with immutable entries prevents the class of bug where a balance is correct on screen and wrong in reality. Minimum requirements:

• Append-only entries; corrections are new entries, never edits
• Every entry references a transaction and a counterparty
• Balances are derived, never stored as a mutable field
• Currency is explicit on every amount, with no implicit conversion

Payment methods that matter in India

Each method maps to its own set of ledger accounts, which keeps settlement differences between wallets and bank rails visible instead of blended.

• UPI — supported through PayEurasia's India acceptance stack with reference data returned on every transaction.
• IMPS — supported through PayEurasia's India acceptance stack with reference data returned on every transaction.
• NEFT — supported through PayEurasia's India acceptance stack with reference data returned on every transaction.
• RTGS — supported through PayEurasia's India acceptance stack with reference data returned on every transaction.

Bank rails are covered through dedicated collection accounts with HDFC Bank, ICICI Bank, Axis Bank and other local institutions, which is what makes larger ticket sizes practical. Coverage per market is listed on the countries hub.

Reconciliation

Reconciliation compares three records for every day: your ledger, the gateway's report, and the settlement actually received. Differences fall into predictable buckets — timing, fees, refunds, failed payouts and genuine breaks. Automating the first four leaves a small manual queue that a human can clear quickly.

Settlement in India runs on T+0 or T+1 depending on the rail and the merchant's risk profile, so the comparison window has to allow for rail timing rather than assuming same-day equivalence.

Observability

Instrument the things that predict revenue loss:

• Success rate per method, per upstream connection, per hour
• Time from create to terminal state, at median and 95th percentile
• Webhook delivery success and retry depth
• Settlement received versus expected, per day

Security

Signed webhooks with timestamp validation, credential rotation, least-privilege API keys, IP allowlisting for administrative access and complete audit logging are baseline, not optional extras. Our trust and compliance pages describe the controls we operate.

Merchant benefits

• Rail-aware infrastructure rather than a generic card-style abstraction
• Automatic routing and failover across India providers
• Immutable ledger with line-level reconciliation
• Signed, replayable webhooks with idempotency guarantees
• Monitoring built around the metrics that actually predict lost revenue

Related guides and solutions

• India Payment Gateway
• India Payment Solutions
• UPI Payment Gateway
• High Risk Payment Solution India
• Solutions overview
• Cross-Border Payment Solutions
• Payment Infrastructure
• High-Risk Merchant Payment Processing
• Countries hub

Talk to our team

If you are evaluating acceptance in India, the fastest way to get a useful answer is to share your vertical, expected monthly volume and required payout frequency. Our team can confirm which rails are available to your business, what documentation underwriting will ask for, and how quickly you can go live. Start with merchant onboarding or contact us directly.

Frequently asked questions

What payment rails are available in India?

UPI for instant low-value collections and IMPS, NEFT and RTGS for bank transfers. UPI handles the instant leg while bank rails cover larger and slower-settling transfers.

Why does idempotency matter so much?

Wallet and bank confirmations are asynchronous and networks are unreliable, so retries are normal. Without idempotency keys, a retry can create a duplicate charge that is expensive to unwind.

How should webhooks be handled?

Verify the signature, check the timestamp, respond quickly, and process the payload asynchronously. Handlers must be replay-safe because delivery is at-least-once.

What does reconciliation actually compare?

Your own ledger, the provider's transaction report and the settlement received. Timing, fees, refunds and failed payouts explain most differences; anything left is a genuine break to investigate.

Can routing failover happen automatically?

Yes. Connections are scored on rolling success rate and latency, and traffic shifts away from a degraded provider without manual intervention.