🎛️ Payment orchestration

Why merchants stop relying on a single provider

A multi-provider setup means a merchant contracts with several acquirers to process sales from the same catalog. It shows up as soon as the business crosses its second border. A seller that stays in one country can collect everything through a single provider. The first reason to add providers is coverage, meaning the set of payment methods a provider can actually process. No acquirer connects equally deeply to Pix in Brazil, UPI in India, QRIS in Indonesia, BLIK in Poland, and M-PESA in Kenya. A catalog advertising 200 payment methods covers many of them through resale agreements with third parties, not through a direct connection to the rail.

Three other reasons follow, in this order. The approval rate varies from one provider to the next on identical traffic, because the issuer sees a different presenter and different data. Cost varies because domestic acquiring avoids cross-border fees and currency conversion. Resilience comes last, and it is the only one of the four that can be measured only after an incident. Until a route actually goes down, the merchant has no measure of how its backup setup behaves.

Anatomy of an orchestration layer

An orchestration layer is a software intermediary between the merchant's checkout and its payment providers. It gives the merchant a single interface and translates each request for the selected rail. Routing is only one of its six functions. Its core deliverable is the abstraction contract it offers the merchant: a single payment object, a single life cycle, and a single set of statuses, whatever rail sits underneath. Every other function flows from that promise, which is hard to keep because each rail has its own life cycle.

• Method catalog: what exists, where, in which currency, through which connector, and what is unavailable at the moment of display;
• Credential vault: encrypted cards, network tokens, direct debit mandates, wallet aliases, all held outside the providers;
• Rules engine: routing, cascading, exemption requests, per-method limits, all editable without redeploying the application;
• Normalization: an object model and a status taxonomy shared by every rail, with the original code always attached;
• Observability: a log of every route considered, not just the one selected;
• Reconciliation: aggregating heterogeneous settlement files and matching them all the way to the bank payout received.

Routing by cost and by approval rate

Routing picks, for each transaction, the combination of provider and parameters that maximizes an objective function the merchant defines. That function is expected net margin: the probability of approval times the order amount, minus the cost of the route and the expected fraud loss. Approval rate is only one of its three terms. Two routes with a 92% approval rate do not produce the same margin if one costs 30 basis points more than the other. A route whose approval rate climbs two points because it lets fraud through destroys value, since dispute fees come on top of the lost order amount. Managing to approval rate alone leads to bad decisions.

# E[margin] = P(approval | route, bin, amount) x (order_amount - route_cost)
#           - P(net fraud | route, signals) x (order_amount + dispute_fees)

candidates = []
for route in eligible_routes(method, currency, issuer_country):
    if not route.health_ok:             # circuit breaker: technical errors
        continue                        # above threshold over 5 min -> route removed

    p_ok  = model.approval_probability(route, bin, amount, local_hour)
    cost  = route.interchange + route.scheme_fees + route.markup + route.fx
    p_frd = model.fraud_probability(route, device_signals, account_signals)

    score = p_ok * (order_amount - cost) - p_frd * (order_amount + dispute_fees)
    candidates.append((score, route))

chosen = max(candidates)[1]
log(candidates)                         # ALL routes, not just the chosen one

# Without a log of the discarded routes and their scores, no counterfactual
# can be computed later: you will never know what the other path would have
# returned, and the routing model can never be honestly re-evaluated.

Three configuration decisions deliver most of the gain, before any statistical model comes into play. The first is to acquire in the country where the card was issued. The second is to settle in the cardholder's currency. The third is to present the domestic brand when the card carries one. All three are matters of contract and configuration, not machine learning. A model only comes in afterward to break ties between routes that are already comparable: it fine-tunes a decision made elsewhere and is not a first-order lever.

Failover, cascading, and deferred retries

Failover, cascading, and deferred retries sound alike but are three distinct responses to a failed payment attempt. Failover responds to an unavailable route and switches the attempt to a backup route. Cascading responds to an issuer decline and immediately re-presents the transaction through a second provider. A deferred retry responds to a decline with an economic cause, such as insufficient funds: the next attempt is scheduled for a later date, since the cause may go away once the account is funded. Mixing them up leads to two mirror-image mistakes. The merchant either abandons sales that would have gone through after a wait, or piles up attempts that trigger the card networks' penalties.

• Count attempts per card and per merchant, across all providers: network limits apply across acquirers, never acquirer by acquirer. Visa caps attempts at 15 per card over a rolling 30 days;
• Read Mastercard's Merchant Advice Code before deciding: 01 means updated account information is available, 02 allows a later retry, and 03 and 21 prohibit one;
• Log the reason for every attempt, not just its outcome; otherwise no retry rule can ever be evaluated after the fact;
• Limit cascading to one retry. Beyond that, the added latency and authorization fees exceed the amount recovered;
• Separate technical retries from commercial dunning: a failed subscription payment calls for a re-presentment schedule, not an immediate retry.

Normalizing decline codes

Decline code normalization maps the failure reasons each rail returns onto a single reference set inside the orchestration layer. It exists because the vocabularies in use have nothing in common. Cards respond with two characters in the DE39 field of an ISO 8583 message, while European direct debits are rejected with a four-character ISO 20022 code such as AM04 or AC06. UPI returns NPCI response codes; Pix returns reason codes carried in ISO 20022 messages overseen by the Banco Central do Brasil; an Asian wallet returns its own proprietary labels. None of these vocabularies maps exactly onto another.

Normalization maps all these codes onto a small and stable set of statuses. Small, because product teams will never apply a 40-status taxonomy correctly. Stable, because retry rules, dashboards, and service-level commitments will depend on it for years. The original code is always kept.

RETRY_NOW        The route failed, not the transaction.
                 card 91 / 96 | ISO 20022 technical reject | UPI switch failure
                 -> immediate failover to another route, with idempotency

RETRY_LATER      Economic decline that can clear over time.
                 card 51 | SEPA AM04 | insufficient mobile money balance
                 -> re-presentment schedule, never an immediate retry

NEED_AUTH        Authentication required; transaction can be replayed as is.
                 card 65 (Mastercard) / 1A (Visa) | A2A PIN or biometrics redone
                 -> replay with 3-D Secure, on the same route

NEED_CREDENTIAL  The instrument must change before any new attempt.
                 card 54 | SEPA AC04 | wallet account deactivated
                 -> Account Updater, or ask the customer for a new payment method

TERMINAL         Never replay, whatever the route.
                 card 41 / 43 / 59 | Merchant Advice Code 03 and 21 | SEPA AC06, AG01
                 -> flag the credential, stop the retry cycle

UNKNOWN          Unmapped. Technical debt, not a working category.
                 -> measure its share per connector; above a few percent,
                    the layer is flattening codes, not normalizing them

Fields kept alongside the canonical status, without exception:
  raw_code, raw_network, raw_message, raw_advice_code, route_id, attempt_id

Alongside the decline code, the card networks send two pieces of information that carry an instruction rather than a verdict. Mastercard's Merchant Advice Code says whether to retry the transaction now, retry it later, or never try again. Credential update services (Visa Account Updater, Mastercard Automatic Billing Updater) answer a different question: does the cardholder now have a different card? An orchestration layer that ignores these two channels bases its retry rules on the decline code alone, even though the networks have already supplied the answer.

Orchestration vendors

The orchestration market took shape in four waves, the first of which predates the term itself. The 2000s saw the rise of gateways of gateways, before the category had a name. In the late 2010s, PSPs absorbed the first independents. A third generation was founded between 2020 and 2022 by former executives of PayPal, Braintree, Rappi, and Delivery Hero. The fourth wave, now under way, comes from the PSPs themselves, which are building optimization into their own stacks.

Inside or outside the flow of funds: the question that decides regulatory status

An orchestration layer's legal status depends on a single question: does it take possession of the funds? A layer outside the flow routes messages without ever holding money. Funds move from the payer to the acquirer, then from the acquirer to the merchant, and the layer remains a technical service provider. A layer inside the flow collects on the merchant's behalf, holds the funds temporarily, and then pays them out. From that point on, it falls under the rules for regulated institutions, country by country.

The switch from one regime to the other often happens without an explicit decision. A merchant asks for a consolidated payout, a marketplace asks for funds to be split among sellers, a jurisdiction requires collection through a local entity. A layer that agrees to any of these requests ends up receiving funds, and that changes its business: it goes from technical service provider to regulated institution. In several markets, exchange controls force this shift. Payments there are collected in local currency by an in-country entity, while repatriation in hard currency falls under an entirely separate contract.

• Credential ownership: under whose Token Requestor ID are the network tokens provisioned, the merchant's or the provider's? The answer determines how reversible the setup really is;
• Export: the format, turnaround time, and cost of a full vault extraction, tested once before you need it;
• Bypass route: the contractual and technical ability to call a provider directly, without going through the layer;
• Logs: access to raw codes, discarded routes, and their scores, exportable without relying on the vendor's interface;
• Subcontracting: a list of hosting providers and sub-processors, with a right to object and advance notice;
• Exit: length of the transition period, migration support, and what happens to the data after termination, tokens included.

The hidden cost of one more layer

An orchestration layer costs you in three distinct ways. The first is money, charged on every transaction presented, whatever the outcome. The second is latency added to the payment's critical path, since every extra call lengthens authorization time. The third is a new dependency: the layer becomes the single gateway to the very providers the merchant added to reduce its exposure.

The first cost is in the contract and can be negotiated. The other two only show up in use, and fixing them means redoing the integration. An orchestration program that only measures invoiced amounts is managing the least important of the three variables, and leaves latency and dependency out of view.

• Measure the layer's cost against authorized revenue, not call volume: declined transactions incur fees too;
• Measure added latency at the 95th percentile, by hosting region, before and after go-live;
• Track the share of credentials held under the merchant's own Token Requestor ID: it is the direct measure of reversibility;
• Name an owner for the routing rules, date every review, and delete rules no one can explain anymore;
• Run the bypass in production at least twice a year, log the result, and fix whatever failed.