Merchant Payment Infrastructure Guide: Building a Stack That Scales

Most merchants buy a payment gateway and call it infrastructure. Then volume grows, a second market opens, a provider degrades during peak trading, and the gaps appear all at once: no ledger of record, no reconciliation, no failover, no way to answer a simple question like "how much did we actually earn last Tuesday in Bangladesh".

Payment infrastructure is the set of systems around your provider that make money movement observable, recoverable and expandable. This guide describes how to build it properly, in the order that matters.

Layer one: the ledger of record

Before checkout design, before routing, build a ledger you own.

Why your provider's dashboard is not a ledger

Provider dashboards show their view of your money — their fees, their cycles, their statuses, their retention window. They do not show your view: gross revenue by product, refunds by reason, provider cost by route, FX effects, reserves receivable, or unmatched credits. When you have two providers, the dashboard problem becomes unsolvable.

What the ledger should record

Each payment attempt should be recorded with your internal order ID, customer reference, requested amount and currency, method, route or provider, provider transaction reference, status transitions with timestamps, fee breakdown, settlement currency amount, FX rate at transaction and settlement, and links to any refund or dispute.

Immutability and auditability

Never overwrite states. Append transitions. When an auditor, a bank or a compliance reviewer asks what happened to a transaction eighteen months ago, an append-only history answers instantly. Overwritten records do not.

Layer two: checkout and method presentation

Local methods as first-class citizens

In South Asia, checkout conversion is determined by whether customers see their own payment method with its own branding. Display bKash, Nagad, UPI, JazzCash, Easypaisa, eSewa and Khalti as named, logo-bearing options ordered by local popularity. Generic "mobile wallet" buttons underperform consistently.

Amount, currency and language

Show local currency with local formatting. Avoid surprise conversions. Where possible, present the payment page in the customer's language. Small localisation gaps cause measurable abandonment.

State clarity for the customer

Wallet and UPI flows involve customer confirmation outside your page. Your interface must handle three outcomes gracefully: confirmed, failed, and genuinely unknown. Tell customers exactly what to do in each case, and never leave a pending payment with no messaging — that is what generates support tickets and duplicate payments.

Layer three: routing

Why routing exists

No single route performs best for every method, ticket size, hour and market. Routing is the logic that selects the best available path for each transaction and moves away from degraded paths automatically.

Routing dimensions

Route by market, method, ticket band, customer segment, provider health and cost. Start simple — one primary and one fallback per method — and add sophistication only when you have data to justify it.

Health-based failover

Track rolling success rates per route in short windows. When a route drops below a defined threshold, shift traffic automatically and alert operations. Manual failover during an incident is always too slow.

Retry logic

Retries recover real revenue but must be idempotent and bounded. Never retry without an idempotency key, never retry a terminal decline, and never retry so aggressively that you trigger provider rate limits or duplicate charges.

Layer four: the API integration

The technical contract with your provider determines how much operational pain you inherit. The behaviours that matter are covered in detail in how payment APIs work, but the infrastructure essentials are:

• Idempotency keys on every creation call, stored with the order.
• Signed webhooks verified on receipt, with replay protection and idempotent handlers.
• Explicit terminal states and a defined timeout policy for anything that never terminates.
• A reconciliation endpoint or file that can be diffed programmatically.
• Sandbox fidelity that reproduces failures, timeouts and edge cases, not just happy paths.

Layer five: reconciliation

Daily, automated, non-negotiable

Every day, match provider settlement data against your ledger. Categorise breaks: missing in ledger, missing in provider report, amount mismatch, fee mismatch, currency mismatch, duplicate. Assign each category an owner and a resolution target.

Reserve and settlement tracking

Track held reserves as a receivable with expected release dates. Track settlements as they arrive against the amounts you expected. Providers make mistakes; merchants who reconcile find them, and merchants who do not simply absorb them.

Refunds, payouts and returns

Outbound flows are where silent losses concentrate. Reconcile refunds, payouts and returned payouts with the same rigour as collections.

Layer six: monitoring and alerting

Instrument these metrics per route and per method: attempt volume, authorisation rate, completion rate, average latency, timeout rate, refund rate, dispute ratio, settlement timeliness and unmatched-credit count.

Alert on deviation from baseline, not just on zero. A route that falls from ninety-four percent to eighty-one percent is an incident even though it is still processing. Route your alerts to a channel a human actually watches, with a defined on-call owner.

Layer seven: redundancy

The single-provider trap

Every merchant that has lost a week of revenue to a provider issue swore afterwards they would add redundancy. Do it before the incident.

What real redundancy requires

A second provider that is contracted, integrated, compliance-approved, receiving live traffic at low volume, and reconciled in the same ledger. A provider you integrated once and never used will not work when you need it — credentials expire, APIs change, limits are unset.

Switch mechanics

Define the trigger conditions, the authoriser, the technical steps and the customer communication in a runbook. Rehearse it. The target is minutes, not days.

Layer eight: compliance and controls

Payment infrastructure includes the controls that keep you bankable.

• Customer KYC proportionate to your vertical, with records retained and retrievable.
• Sanctions and watchlist screening where required, with documented match handling.
• Transaction monitoring with defined thresholds, escalation and case records.
• Access control — least privilege on payment systems, with audit logs on privileged actions.
• Secrets management — API keys in a managed secret store, rotated on a schedule, never in source control.
• Data protection — minimise stored payment data, encrypt in transit and at rest, define retention.

These controls are also commercial leverage: providers price supervision risk, and merchants who demonstrably manage their own risk negotiate better terms. The underwriting perspective is explained in how high-risk payment processing works.

Layer nine: reporting the business can use

Finance needs revenue net of fees, refunds and FX by market and product. Operations needs conversion and failure analysis by method. Compliance needs auditable transaction and case records. Leadership needs cost per successful order and provider concentration.

Build these from the ledger, not from provider exports. When a provider changes its report format — and it will — your reporting should not break.

A phased implementation plan

Phase one, weeks one to two. Ledger schema, idempotency, signed webhook handling, basic method coverage, manual daily reconciliation.

Phase two, weeks three to six. Automated reconciliation, monitoring and alerting, refund and dispute workflows, settlement and reserve tracking.

Phase three, weeks seven to twelve. Secondary provider integration, health-based routing and failover, runbooks, rehearsed switch test.

Phase four, ongoing. Multi-market expansion, FX analytics, cohort-level conversion optimisation, periodic provider performance review and renegotiation.

Multi-market expansion in South Asia

Expanding from one market to four multiplies methods, currencies, settlement cycles, compliance relationships and reconciliation surfaces. Two decisions reduce that cost dramatically: keep one internal ledger with market as a dimension rather than separate systems, and prefer a provider that covers multiple markets on one integration where the economics allow. The trade-offs are covered in the cross-border payment guide for South Asia, with market detail in Bangladesh, India, Pakistan and Nepal.

How PayEurasia supports merchant infrastructure

PayEurasia provides one integration across four South Asian markets with signed webhooks, idempotent APIs, method-level performance reporting and reconcilable settlement files — the inputs a real ledger needs. Merchants can see routing, balances and settlement data directly rather than reverse-engineering them from statements.

See the payment infrastructure overview or talk to our team.

Frequently asked questions

What is merchant payment infrastructure?

It is the set of systems a merchant owns around its payment providers: an internal ledger, checkout and method presentation, routing and failover, webhook and reconciliation pipelines, monitoring, compliance controls and reporting. The provider moves money; the infrastructure makes it observable and recoverable.

Do I need my own ledger if my provider has a dashboard?

Yes. A provider dashboard reflects one provider's view of your money with their fees, statuses and retention limits. An internal ledger unifies multiple providers, records your own economics and FX, and survives provider changes and audit requests.

How many payment providers should a merchant use?

At least two for any critical market. The secondary should be contracted, integrated, compliance-approved and receiving a small share of live traffic so it is proven to work when you need to shift volume.

What should I reconcile and how often?

Reconcile collections, refunds, payouts, returns, fees, FX and reserves against provider settlement data daily, with categorised break handling and a resolution owner. Month-end-only reconciliation finds problems far too late.

How do I reduce failed payments?

Present local methods natively, route intelligently by method and ticket size, implement bounded idempotent retries, handle pending states explicitly, and monitor per-method success rates so degradation is detected and rerouted quickly.

What compliance controls should be built into payment systems?

Customer KYC proportionate to the vertical, sanctions screening where applicable, transaction monitoring with documented escalation, least-privilege access with audit logging, managed secret rotation and defined data retention.