Payment Orchestration Architecture: Build vs Buy vs PSP-Native

Every vendor selling "payment orchestration" is actually selling some subset of six different things, and most sales conversations never separate them. Payment orchestration is the coordination layer. Smart routing is a decision function — which PSP handles this transaction — that can live inside a PSP's own product, inside a bought orchestration platform, or inside code an engineering team wrote itself. Gateway abstraction is a normalised API surface that hides PSP-specific schemas from your checkout. PSP aggregation is commercial consolidation — one vendor relationship standing in for several processor contracts. Acquiring is the licensed money-movement relationship that actually settles funds, which no orchestration layer replaces. Token vaulting is credential custody, and whether that custody is portable across PSPs or locked to one is the decision most operators make by accident.

A team can buy gateway abstraction with no routing logic at all — a common API that still requires someone to manually pick a PSP. A team can build routing logic with zero abstraction — a rules engine bolted directly onto two hardcoded integrations. A team can vault cards with an orchestration platform and still end up with PSP-locked tokens, because the vaulting path it used was a pass-through reference rather than a native re-vault. None of this is theoretical: it is the difference between a PSP migration that takes six weeks and one that takes six months, and it is decided long before anyone notices which posture they actually bought.

This piece is the framework for choosing a posture — PSP-native, bought orchestration layer, or in-house build — against the decisions that actually determine the outcome: who owns the token vault, where the routing decision function sits, what idempotency has to mean across two PSPs, what reconciliation costs once settlement fragments, and who gets paged when a routing rule misfires at 3am.

The Three Postures

PSP-native routing means your primary PSP's own smart-routing or retry product handles failover and optimisation, and you have no independent abstraction layer. Stripe's own routing intelligence, Adyen's RevenueAccelerate, and equivalent products from Checkout.com all fall here. This is the correct default for a single-PSP operator: no integration overhead, no second vault to reconcile, and the PSP has every incentive to make its own routing product good. The ceiling is structural — PSP-native routing only ever routes within that PSP's own acquiring relationships. It cannot fail over to a second processor, and it cannot escape that PSP's token format if you ever need to leave.

A bought orchestration layer — Spreedly, Primer, Gr4vy, and comparable platforms — sits above two or more PSPs, providing a vault, routing rules, and normalised reporting as a managed product. The full vendor comparison covers how the three differ; the point for this decision is narrower: buying trades ongoing engineering ownership for a recurring basis-point fee and a new vendor relationship that itself needs contract review, SLA monitoring, and an exit plan.

In-house build means the operator writes and owns the routing, failover, and vaulting logic itself, typically against two or more directly-integrated PSPs. This is a permanent engineering commitment, not a project with an end date — scheme rules change, PSP APIs version, and routing tables drift stale the moment nobody is assigned to maintain them. The multi-acquirer routing guide has the build-vs-buy economics for the routing layer specifically; this piece extends that same threshold logic to the vault, the reconciliation load, and the org design each posture actually requires.

None of the three postures is free of the underlying six decisions — they only change who makes each one and how visibly. PSP-native routing makes the vault decision by default (it's the PSP's vault, full stop). Buying an orchestration layer makes routing ownership visible in a contract. Building makes every decision explicit, which is its main advantage and its main cost.

Token Vault Ownership: The Decision Nobody Makes on Purpose

Of the six decisions, token vault ownership determines future optionality more than any other, and it is the one most often set by default rather than by choice. A card saved during a Stripe checkout is a Stripe token. A card saved through an orchestration platform's vault should be a portable token — but whether it actually is depends on how the card got there.

Spreedly's own documentation for third-party vaulting is explicit about the failure mode: when a card that already exists in a PSP's own vault is referenced through Spreedly's third-party vaulting API rather than natively re-vaulted, the resulting ThirdPartyToken "is locked to the gateway type they were created against," and using it against a different gateway returns an error. A team migrating an existing card base into Spreedly can do this correctly — using the store API to copy from the Spreedly vault into a gateway's vault, or a genuine re-vault — or incorrectly, by treating a pass-through reference as if it were a native token. Both paths are available in the same product. Only one produces the portability the team thought it was buying.

Primer's approach differs in a way worth being precise about, per Primer's own network-tokenization documentation: network tokens are stored in a Centralized Vault independent of any single processor, and when a vaulted card has been network-tokenized, Primer automatically forwards that network token to whichever processor is handling the transaction, provided that processor supports it. This is real portability, but it is portability of the network token issued by Visa or Mastercard — not a Primer-proprietary credential. The distinction matters at the edges: a processor that doesn't support network token pass-through, or a card that was never network-tokenized in the first place, falls back to whatever that processor's own vault requires. The network tokens vs PSP tokens breakdown covers when that fallback bites.

The operator-level rule, regardless of which platform: ask which of these three you actually have before assuming you have portability. A vault-native token issued by the orchestration platform itself. A network token pass-through, portable across processors that support it. Or a gateway-vaulted reference that only works at the gateway that created it. The three look identical in a dashboard. They behave completely differently the day you try to leave a PSP.

Where the Routing Decision Function Actually Lives

"Smart routing" is a function, not a place, and the same routing logic can physically execute in at least four different locations with different failure characteristics. Inside a PSP's own product, where it can only ever choose within that PSP's acquiring relationships. Inside a bought orchestration platform's rules engine — Primer's visual workflow builder is the clearest example, letting a payments manager configure "if card is Visa and country is UK, route to Adyen; on decline, fall back to Stripe" without a code deployment. Inside custom code sitting on top of directly-integrated PSPs. Or, increasingly, inside an ML model trained on historical auth data rather than static rules — the AI and ML routing piece covers when that upgrade is worth it and when it is premature.

The operational question that matters more than which of these four is technically superior: who can change a routing rule, and how fast, when a specific BIN range starts declining at 2am. If the answer requires a code deployment and an engineer on call, the routing function is effectively frozen outside business hours regardless of how sophisticated the underlying logic is. If the answer is a payments operator with dashboard access to a rules engine, the routing function stays live around the clock — at the cost of a rules engine that non-engineers can misconfigure without a pull request review catching it first.

Neither answer is universally right. A team running thin payments headcount and deep engineering bench should keep routing logic in code, reviewed like any other production change. A team with a dedicated payments operator and thin engineering bandwidth for payments specifically should buy the visual rules engine, because the alternative is routing logic that never gets tuned because no engineer has the spare cycles to prioritise it against the rest of the roadmap.

Idempotency Across Two PSPs: What "Idempotent" Has to Mean

Every major PSP implements idempotency keys, and every implementation stops at that PSP's own boundary. Stripe's idempotency layer, per Stripe's own API reference, saves the resulting status code and body of the first request against a given key and returns that same result on retry — including on a 500 error — with keys pruned after 24 hours. Adyen's implementation, per Adyen's own documentation, holds keys for a minimum of 7 days and applies only to POST requests — and Adyen states directly that idempotency keys are "not checked for duplication" across its separate regional endpoints if a merchant targets more than one simultaneously, meaning the guarantee doesn't even span one PSP's own infrastructure globally, let alone a second PSP. Checkout.com's support documentation confirms the same local scope: the key is generated by the merchant's own backend, tied to one payment request, and the entire mechanism breaks if a new key gets generated on every retry.

None of the three has any concept of a second PSP. That is the gap a multi-PSP router has to close itself, and it is the single most consequential correctness requirement in the entire architecture. A router that times out waiting on PSP A, retries PSP A with the same idempotency key — correctly protected — and then, on continued timeout, fails over the same customer intent to PSP B has just created a scenario where PSP A's idempotency guarantee and PSP B's idempotency guarantee are both individually honoured while the customer has two live authorisation attempts in flight, on two different processors, for the same purchase.

The fix is architectural, not a bigger idempotency key. A cross-PSP router needs its own application-level transaction identifier that exists before any PSP call is made, a state machine that records which PSP (if any) has confirmed the attempt, and a hard rule that a failover to PSP B only fires once PSP A's outcome is known to be a genuine failure — a hard decline, a confirmed connection refusal, or an expired retry budget — never a bare timeout with an unknown outcome. A soft timeout on PSP A can mean the authorisation succeeded and the response was lost in transit; failing over on that ambiguity is exactly how double-authorisation incidents happen. The PSP and acquirer outage failover runbook covers the detection and failover mechanics for this scenario in operational detail; this section is the architectural precondition that runbook assumes is already built.

Reconciliation and Settlement Fragmentation

This is the cost that gets priced least accurately at selection time, on any of the three postures, because it doesn't show up until the first full settlement cycle after go-live. One PSP produces one settlement file, one fee structure, one dispute flow, and one reference-ID scheme your finance team already knows how to read. Two PSPs — regardless of whether routing between them is PSP-native, bought, or built — produce two of each, in different formats, on different timing, using different identifiers for the same logical transaction.

Concretely: Stripe settlement reports and Adyen settlement reports do not share a reference-ID convention, do not batch on the same schedule, and do not classify the same fee components the same way. A three-way match — internal ledger against PSP settlement report against bank statement, the standard reconciliation discipline covered in the PSP reconciliation failure runbook — now has to run twice, with a merge step afterward to produce one source of truth for finance. That merge step is the part every operator underestimates. It is not a reporting inconvenience; it is a recurring engineering and finance workload that scales with PSP count, and it does not go away because you bought an orchestration platform instead of building.

A bought orchestration platform's unified reporting genuinely helps here — Primer's unified event stream, for instance, normalises authorisation, capture, refund, and dispute events into one schema regardless of which PSP processed the underlying transaction, which is real value most operators discover only after they've lived without it. But normalised reporting is not the same as reconciled settlement. The orchestration platform's event stream tells you what happened at the payment layer; it does not by itself close the loop against what actually landed in the bank account, because settlement timing, batch cutoffs, and fee netting still happen inside each PSP's own systems, not inside the orchestrator. Whichever posture you choose, budget the reconciliation build as its own line item, not as something the routing decision solves as a side effect.

Local Acquiring and the Orchestration Layer

Adding a local acquirer in a specific market — for authorisation-rate or interchange-economics reasons covered in the local acquiring vs cross-border reference — interacts with orchestration architecture in a way that's easy to miss during planning. A local acquirer is a new PSP relationship for routing purposes, but it often comes with narrower capability than your global processors: fewer supported card types, no network token support in that market yet, or settlement only in local currency with its own separate reconciliation stream.

An orchestration layer with a genuine capability matrix — knowing which acquirer supports which transaction type, currency, and stored-credential state before routing to it — handles this correctly. A router built without that capability gate will occasionally send a transaction to the acquirer with the best headline auth rate for that BIN, only to have it hard-decline because the local acquirer doesn't support the specific card product or recurring flow in question. That failure mode looks like a routing bug; it is actually a missing capability check, and it is the same failure mode covered in the least-cost routing guide's discussion of routing to a rail that can't actually process the transaction. Local acquiring adds real value on auth rate and cost — it also adds one more row to the capability matrix every routing decision has to check first.

Observability and Configuration Governance

Every posture eventually needs an answer to the same question: who approved this routing rule, and can you prove what the rules were at 2:14pm last Tuesday when a specific transaction declined. PSP-native routing inherits whatever change log the PSP itself provides, which is usually thin because the PSP doesn't expect you to be auditing your own routing decisions inside their product. A bought orchestration platform with a visual rules engine makes rule changes visible and often versioned, but that same accessibility is the risk — a non-technical routing change made without review can go live instantly, with no pull request, no diff, and no second reviewer. An in-house build gets whatever governance the engineering team's normal code review process already provides, which is strong on process but slow to react to a routing rule than needs correcting in minutes, not a sprint.

None of the three defaults is safe without deliberate configuration. The minimum bar, regardless of posture: every routing rule change needs a timestamp, an author, and a rollback path, and someone specific needs to own approving changes to rules that affect live payment traffic — not "the payments team" as an abstraction, but a named role. The same applies to observability: routing decisions, retry attempts, and failover events need to be logged with enough detail to reconstruct why a specific transaction went where it went, because the alternative is debugging a decline pattern by guessing at what the rules were when nobody wrote them down.

Vendor Lock-In and Latency

Buying an orchestration platform trades PSP lock-in for orchestrator lock-in, and the trade is real even though it's usually a better one. The PSP vendor lock-in mechanics — token portability, settlement format dependence, termination notice periods — apply to an orchestration platform contract just as they apply to a PSP contract, and are worth auditing with the same rigor: does the vault produce genuinely portable tokens on exit, what's the data export format and notice period, and what happens to in-flight routing rules if you migrate off the platform.

Latency is the second cost that's easy to discount. Every layer between checkout and acquirer adds round-trip time — an orchestration platform routing decision typically adds single-digit to low-double-digit milliseconds versus calling a PSP directly, which is immaterial for most checkouts but is exactly the kind of cost that compounds if the routing layer itself is degraded or under load during a peak trading event. A cloud-deployed, single-tenant model like Gr4vy's — per Gr4vy's own documentation, a dedicated instance per customer organised around one default merchant account containing that merchant's specific PSP connections and routing rules — reduces noisy-neighbour latency risk relative to shared SaaS orchestration, at the cost of the operator's own infrastructure team owning uptime for that instance. There is no posture that eliminates the added-layer latency question; there is only a choice about who is accountable for keeping it small.

Fraud and 3DS Interaction

Routing logic and fraud/authentication logic have to agree with each other, and a common gap is building them as though they don't interact. SCA exemptions are requested per PSP, using that PSP's fraud data and exemption flagging — an issuer evaluates a transaction-risk-analysis exemption based on the requesting PSP's own fraud rate, not a blended rate across every PSP an operator uses. A router that shifts volume from PSP A to PSP B without accounting for this can inadvertently degrade exemption approval rates on the newly-routed volume, because PSP B's fraud rate on that specific traffic segment hasn't been established yet.

The same applies to 3DS2 challenge and frictionless flows: frictionless-flow eligibility is influenced by issuer trust signals that build up per merchant-acquirer relationship over time. Routing a transaction to a newly-added acquirer resets some of that accumulated trust, which can show up as a higher challenge rate on freshly-routed volume even when nothing about the transaction itself changed. Neither of these is a reason to avoid multi-PSP routing — it's a reason to route fraud-sensitive and stored-credential traffic deliberately during a PSP or acquirer addition, rather than cutting volume over all at once and attributing the resulting dip in frictionless rate to the wrong cause.

Organisational Ownership

The honest answer to "who should own orchestration" is usually about team shape, not about which platform has the better connector library. A payments function with one generalist wearing the payments hat alongside three other responsibilities cannot sustain an in-house build regardless of engineering talent elsewhere in the org, because routing rules, reconciliation, and vault governance are ongoing operational work, not a project that finishes. That team should buy, and should buy the platform with the most accessible non-technical configuration surface, because the actual bottleneck is operator bandwidth, not engineering capability.

A payments function with a dedicated engineering pod, a payments operator, and a finance counterpart who owns reconciliation can sustain a build — but only if all three roles exist and are staffed specifically against payments, not borrowed from general product engineering whenever payments issues get loud enough. The tell that an organisation isn't ready to build, regardless of its stated engineering capacity: nobody can name, without checking, who currently owns the PSP relationship, who approves a routing rule change, and who reconciles settlement discrepancies past 30 days old. If those three answers require asking around, buy.

The Build-vs-Buy Decision Table

Read the table by threshold, not by row-count: an operator hitting the "buy" column on four of six rows and "build" on one specific row (say, a regulatory routing constraint no rules engine expresses) should still buy the platform and build the one non-standard rule as a customisation or pre-processing step in front of it, rather than building the entire stack to accommodate one exception.

Failure Modes

Treating a pass-through vault token as portable. Covered above — the single most common mismatch between what an operator believes it bought and what it actually has, and it only surfaces during the next PSP migration, at the worst possible time to discover it.

Failing over on an ambiguous timeout instead of a confirmed decline. The idempotency gap described earlier: a router that treats "no response yet" the same as "confirmed failure" creates double-authorisation risk that no single PSP's idempotency key can catch, because the double attempt spans two separate idempotency ledgers.

Routing rule changes with no owner and no audit trail. A visual rules engine that lets anyone with dashboard access change live routing logic, with no review step and no change log, turns configuration governance into the weakest link in an otherwise sound architecture — the technology didn't fail, the process around it did.

Reconciliation treated as a reporting feature instead of a workload. Unified event streams and normalised dashboards, whether from a bought platform or a custom build, describe what happened at the payment layer. They do not, by themselves, close the three-way match against settlement and bank statements — that work scales with PSP count regardless of posture, and budgeting it as a one-time integration cost rather than an ongoing function is how reconciliation backlogs accumulate silently for months.

Adding a PSP or local acquirer without updating the fraud and 3DS picture. New routing destinations start with no accumulated issuer trust and no established fraud rate of their own. Cutting volume to a new PSP all at once, without a ramp, conflates a routing decision with a fraud-model cold-start problem and makes both harder to diagnose.

Capability gaps that look like routing bugs. A router without a capability check will send a transaction to the cheapest or highest-auth-rate option on paper, only to hard-decline because that acquirer doesn't support the card type, currency, or recurring flow in question. The fix is a capability matrix checked before cost or auth-rate scoring, not after.

Closing

The build-vs-buy question that gets asked — "should we build orchestration or buy it" — is usually the wrong first question, because it assumes orchestration is one decision. It isn't. Gateway abstraction, routing logic, PSP aggregation, acquiring, and token vaulting are five separable decisions that a sixth layer, orchestration, happens to bundle for commercial convenience. An operator who separates them before evaluating any vendor or build proposal will find that some of the six are obvious — nobody needs to build their own acquiring relationship — and others genuinely depend on PSP count, volume, market spread, and whether payments has a permanently staffed function or a part-time owner.

The vault decision deserves the most deliberate attention of the six, precisely because it's the one most likely to be made by default. Check whether the token you have is vault-native, network-token portable, or gateway-locked before you need the answer during a migration — that is the version of this decision that costs nothing to get right now and six figures in re-capture campaigns to get wrong later.

What to read next

The postures compared here point to more specific decisions once you've picked one:

• Multi-acquirer routing — the volume and PSP-count math for when a second acquirer earns its complexity, in more depth than the summary table above.
• Spreedly vs Primer vs Gr4vy — the vendor-level comparison once you've decided to buy rather than build or stay PSP-native.
• PSP vendor lock-in and hidden costs — the exit mechanics that apply to an orchestration platform contract exactly as they apply to a PSP contract.
• PSP reconciliation failure runbook — the break types and escalation checklist for the settlement fragmentation this piece prices at selection time.