Payment orchestration

A platform that grows past its first market or its first volume tier runs into the same wall twice. The first time it is availability: the provider has an incident, and every payment fails because there is nowhere else to send it. The second time it is economics: the provider's pricing or approval rate is no longer competitive in a market, and the cost of switching is a rewrite of the checkout.

Payment orchestration is the answer to both. It is a layer that sits above the providers, holds the payment logic itself, and treats each acquirer or PSP as an interchangeable route rather than as the platform's payment system.

It is not a product you buy so much as a boundary you design. Done well, adding the next provider is configuration. Done badly, it is a second integration wearing an abstraction.

The interesting decisions in orchestration are commercial. Which provider gets this card scheme in this market. When a decline is worth retrying elsewhere and when the retry is just a second cost. Whether an extra basis point of approval rate justifies a more expensive route.

Those decisions change far more often than software does, and they belong to the people who own the payment economics - not to a release cycle. So we build routing as an explicit, inspectable rule set with a change history, and we make the effect of a rule measurable before it is switched on.

The same principle applies on the billing side, where pricing policy has an identical habit of ending up buried in code. We have written about that at billing software development.

A cascade - retrying a failed payment at a second provider - is the most attractive feature of orchestration and the easiest one to get wrong. Retry the wrong declines and you pay twice for a payment that was never going to succeed, annoy the issuer, and in some scheme rules invite a penalty.

The discipline is in the decline codes. A soft decline, a technical failure or a provider timeout is worth another route. A hard decline - stolen card, closed account, do not honour - is a definitive answer and retrying it is noise that costs money.

So we build the cascade around the response taxonomy, with per-scheme retry rules, an idempotency model that guarantees one payment cannot be captured twice across two providers, and reporting that shows what the cascade actually recovered against what it cost.

Most platforms discover their real lock-in at the moment they try to leave a provider. The integration is replaceable in weeks; the stored cards are not. If card-on-file lives in the provider's vault, switching means either a migration the provider has to agree to, or asking every customer to re-enter their card.

If you intend to run more than one provider, the vault has to be a decision rather than a default. That can mean network tokenisation, a provider-independent vault, or a negotiated migration path agreed before you sign - but it has to be decided while you still have leverage.

We design the vault as a narrow, isolated service with its own access control and audit trail, so the freedom to route does not come at the cost of spreading card data through the platform. The PCI DSS considerations are the same ones we describe on payment gateway integration.

The drivers are the number of providers and methods in scope, whether tokens have to migrate, whether cascading and dynamic routing are in scope or only failover, and how much of your existing payment logic is currently welded to one provider's SDK.

The last one is usually the real driver, and it is the one nobody scopes. Extracting payment logic out of a checkout that was written against a single provider is the bulk of the work; the second provider is comparatively easy once the boundary exists.

We will tell you on the first call whether you are ready for orchestration or whether the honest answer is to do the first integration properly and revisit this in a year.