Payment Orchestration Architecture: The Components and How a Payment Flows Through Them

A payment orchestration layer sits between a business and the payment providers it uses. The business integrates once; the layer decides which provider handles each payment, talks to that provider in its own dialect, and turns everything that comes back into one consistent model. That's the idea. The architecture is what makes it hold up under real traffic, real failures and real money.

This is a vendor-neutral reference for engineers and architects, whether you're building such a layer, evaluating one, or just want to understand what sits behind "one integration, many providers". It describes the components, how a payment flows through them, and the principles that keep the system correct when providers misbehave.

Two paths run through an orchestration layer: the request path, which creates and routes payments in real time, and the event path, which brings back what providers report later.

Each component has one job. The table summarises what goes wrong when a component is missing or weak, which is usually how teams discover they needed it.

Everything else depends on getting the data model right. A good model separates the order or intent (what the customer is paying for) from payment attempts (each try with a provider), and from refunds, disputes and settlements that attach to a successful payment. It defines one set of statuses, one error format with a category and a retryable flag, and amounts as integers in minor units with an explicit currency. Our guides to storing money in code and duplicate payments go deeper on amounts and on the order-attempt split.

Routing is usually two stages. First, hard filters remove providers that can't take this payment at all: wrong method, currency or amount range, a provider that doesn't hold the customer's saved token or mandate, or one that's currently paused. Then the remaining candidates are ranked by rules the business sets and by live signals such as success rate, response time and cost. The engine should store its decision on the payment: which providers were considered, which were excluded and why, and which rule or score won. That record is what makes routing explainable to support teams and auditors. Our guide to smart routing explains the decision logic.

A connector is an adapter for one provider. It turns the unified request into the provider's request, passes the idempotency key on where the provider supports one, calls the provider with the right credentials, and maps everything that comes back, statuses, error codes, references such as RRN or UTR, into the unified model. Connectors also verify that provider's webhook signatures and parse its settlement files. Keeping all of a provider's quirks inside its connector is the single most important boundary in the system: when a provider changes its API, one connector changes. Our guide to payment API versioning covers how to make connectors tolerant of provider changes.

If customers save cards, something has to hold the reference to them. Card data is the most sensitive data in the system and brings PCI DSS scope with it, so most architectures keep it out of the orchestration layer's general systems entirely, using provider-hosted fields and network or provider tokens. In India, RBI's card-on-file rules mean merchants can't store actual card numbers at all, and card-on-file tokens are specific to a merchant and token requestor. That has a routing consequence: a saved-card or recurring payment usually has to go to the provider that holds the token or mandate. Our guide to PCI DSS SAQ types explains how these choices affect compliance scope.

Some failures are worth retrying, on the same provider or another; many aren't. The controller classifies each failure (provider error, timeout, issuer unavailable, customer decline, risk decline), retries only recoverable categories, keeps the same idempotency key and payment reference across attempts, and never retries a payment whose outcome is unknown without first checking its status. Our guide to payment API timeouts explains why that last rule matters.

Provider webhooks arrive at the connectors, are verified, stored with their event IDs, acknowledged quickly and processed asynchronously. Processing applies each event to the payment's state machine, ignoring events that would move a payment backwards, and emits a normalised event to the business. Because providers deliver at least once and not always in order, every consumer has to be idempotent. Our guide to exactly-once payment processing covers the patterns.

Reconciliation ingests each provider's settlement reports, whatever their format, and matches them to payments, refunds and fees, then to bank credits; our reconciliation guide explains the three-way match. Observability means metrics broken down by provider and method (success rate, response time, timeouts, pending age), plus the routing decision log. Our guide to payment success rate covers measuring it without distortion.

Putting the pieces together for a single payment:

Architectures like this fail in predictable ways. These principles prevent most of them:

The components above are individually well understood. The cost is in the long tail: keeping connectors current as providers change, mapping every provider's statuses and error codes, parsing every settlement format, and operating it all around the clock. That's the trade-off our comparison of LILPE and building in-house sets out. If you're evaluating platforms, our orchestration evaluation guide lists the questions that test each component.

LILPE's platform overview describes its own capabilities against this picture, including one integration to multiple providers, the unified API and intelligent routing.