Choosing a Payment Orchestration Vendor: Three Architectural Positions and the Cost of Leaving

Choosing a Payment Orchestration Vendor: Three Architectural Positions and the Cost of Leaving

Once you have concluded that you need an orchestration layer — usually because several acquirers now run in parallel, you want routing based on real cost, or the pace of channel changes has outgrown in-house capacity — the question shifts from "should we" to "whose". And this is exactly where the most common mistake happens: opening three feature tables and ticking boxes.

The functional overlap is high. All three manage credentials, route transactions, chain risk and 3DS together, and ship a console. The real divergence is that they give three different answers to the same three questions: who holds the credentials, who owns operational visibility, and who carries the runtime burden. Those three answers determine where you stand three years from now.

For whether to adopt at all, and build-versus-buy, see whether you need a payment orchestration layer. This article handles only one thing: once you have decided to buy, what each of the three actually sells, and in what order you should decide.

1. The three are selling three different things

1.1 The vault type: you are buying "freedom to switch acquirers"

Spreedly describes itself as payment orchestration, but its core asset is not the routing algorithm — it is the vault. It explicitly does not acquire: it is neither an acquirer nor a PSP, and clearing still runs through the gateways, processors or acquirers the merchant has contracted.

Why that matters: once you hand card data to a gateway, the credentials are locked inside that gateway, and switching acquirers means re-enrolling every existing customer's card. That, not interface difficulty, is the real reason most teams never switch. When credentials live in a vault of your own, changing processors becomes a matter of taking the whole vault elsewhere, and only after that does the marginal cost of switching approach zero.

1.2 The operations type: you are buying "several rails that still reconcile"

Primer splits its product into three clear lines: Payments for the acquiring chain, Revenue for whether the money adds up, and Platform for operational observability. The split is itself the position — the goal is not to help you add another payment method, but to keep things reconcilable once several run at once.

It treats payment operations as a first-class citizen: failover, observability, cost insights and reconciliation, four things that are usually add-ons or third-party patches in orchestration designs, are built in here.

1.3 The infrastructure type: you are buying control, with the runtime burden attached

Gr4vy takes a less common self-positioning: IaaS. It wants to be procured as infrastructure rather than as a payment provider. The product comes in five modules: acquiring integration, checkout components, credential hosting, routing and success-rate optimisation, and data and reporting.

Its core argument is one sentence: PSPs should be stateless. The reasoning is that acquirers have an inherent incentive to steer transactions onto their own infrastructure, because that affects their marginal economics. Demoting PSPs to replaceable resources is what puts control back in the merchant's hands — at the cost of having to cash that control in with your own payment engineering.

2. How the three differ mechanically

2.1 Spreedly: the core asset is the vault, not the routing

Beyond credential sovereignty, three things deserve separate attention:

One integration, near-zero marginal cost to change processors later. It absorbs gateway differences behind one interface, so adding a rail does not require rebuilding the front end or the order logic.

Rule changes move out of the engineering backlog. Its Composer lets the payments team configure risk, routing and settlement rules themselves instead of queueing for a release. That matters in growth phases — routing policy changes far more often than software ships.

Routing is driven by live cost and approval data, deciding each transaction from real outcomes rather than a static weight table refreshed quarterly.

Its constraint is equally clear: it does not acquire. Merchant IDs, reserves, industry onboarding review and settlement cycles all stay as they are, and each rail is still contracted separately. Pricing is not published and requires negotiation, and the learning curve sits on the payment engineering side — the team must understand gateway differences, tokenisation mechanics and 3DS flows.

2.2 Primer: payment operations as a first-class citizen

Four capabilities form a chain:

Failover is built in. When one provider declines, the transaction automatically routes to the next. In a self-built setup this is usually a pile of special-case code, and when it goes wrong you get double charges or inconsistent state.

Network tokenisation lowers the cost of changing rails. Card credentials exist as network tokens, so switching rails does not mean starting over — the same direction as a vault-based position, through a different implementation path.

Reconciliation and cost insights sit on one product line. Both live under Revenue, meaning the vendor treats "does the money add up" as a product problem rather than an after-sales one. For the underlying method see reconciliation and statement download operations.

Operational observability is its own line. Platform addresses "can you see it when it breaks", which in multi-rail setups becomes a bottleneck more often than the routing algorithm does.

The hard prerequisite: it only makes sense with two or more providers. A team with a single acquirer is paying for a capability it cannot use. Nor does it replace your accounting — policy, revenue recognition and tax remain yours.

2.3 Gr4vy: PSPs should be stateless

Four capabilities:

Adding a PSP does not touch the front end. Enabling a new PSP and fraud service requires no checkout changes and no new API, which is the direct payoff of the stateless argument.

Payment method breadth. Vendor materials describe one integration covering more than 400 payment methods; the significance of that scale is avoiding re-integration each time you add local methods by country. The actual list and regional availability follow official documentation.

Recovering failed payments is quantifiable revenue. Gr4vy publishes a figure for the share of revenue recoverable from failed payments. That figure is vendor material and cannot be transplanted onto your own business, but the method holds: split failure rate into recoverable and unrecoverable, and invest only in the former. For the broader method see payment success rate optimisation.

The IaaS positioning cuts both ways. It hands you control and hands you the runtime burden with it. Without a team that understands payment engineering, that control becomes a liability.

3. Decision one: who holds the credentials

This is the most important section, because it determines whether you can change acquirers three years from now.

Credentials can live in three places: inside an acquirer or gateway, inside the orchestration vendor's vault, or inside your own vault. The difference is not technical difficulty but migration cost:

• Inside a gateway: changing gateway means re-enrolling every customer's card, effectively impossible, so you are locked to one rail.
• Inside the orchestration vault: you can take the whole vault to another gateway, but changing the orchestration layer itself remains hard.
• Inside your own vault: maximum migration freedom, but PCI scope and key management land on you.

So the first question is not "whose vault is more secure" but whose custody you are willing to trust with the freedom to switch rails. Choosing a vault-based orchestration product buys you that freedom — with the premise that you will not change the orchestration layer itself. That premise belongs in the contract term and migration clauses.

PCI scope shifts with where credentials sit; scope determination and SAQ selection are covered in PCI DSS compliance in practice.

4. Decision two: do you want to take on the runtime burden

An orchestration layer hands you control and, with it, a new class of work: multi-rail adapter maintenance, state machines and idempotency, cross-PSP reconciliation, and the differing failure semantics of every provider.

This work cannot be fully outsourced, only partly transferred. The three vendors differ in how much they transfer: the operations type (Primer) productises observability, failover and reconciliation, so you write less code but must adopt its abstraction model; the infrastructure type (Gr4vy) keeps the abstraction thinnest, preserving the most control and the most in-house work.

The test is team composition. Teams with dedicated payment engineers who treat payments as a core competency fit a thin abstraction; businesses without that team, who want stability quickly, fit a thicker product. The dividing line between building and buying is in build or buy for each payment layer.

5. Cost structure and the cost of exit

None of the three publishes pricing; all quote against transaction volume and module mix. So break total cost into four parts during procurement:

1. Platform fee: the volume-independent part, which dominates when volume is small.
2. Usage fee: per transaction or per value, with the billing basis clarified — whether authorisation, capture and refund all count.
3. Module fees: whether routing optimisation, reconciliation and observability are billed separately.
4. Exit cost: almost never on the quote sheet, and the largest single item in a four-year total.

Exit cost has at least three layers: whether credentials can be exported in full, whether the destination gateway accepts that format, and the labour and reconciliation cost of running both systems during cutover. Write the export format, turnaround and fee into the contract, and agree the data retention period after termination.

For fee and cost auditing see payment fee auditing; for how multi-rail changes your funds float see modelling reserves and funds float.

6. Acceptance and go-live checklist

For the minimum implementation of idempotency and state machines see order number design and idempotency tables and multi-rail payment callback frameworks; for migrating off an existing rail see payment gateway migration in practice.

7. When orchestration is a net loss

Four situations where adding a layer subtracts value:

1. One rail only, with no plan to add another within a year. Orchestration value comes from plurality; with a single rail it adds a hop of latency and a layer of reconciliation.
2. No payment engineering capability. The thinner the abstraction, the more adapters, state machines and reconciliation you must write yourself.
3. Very high order value, very low volume. Optimisation room there lies in manual review and settlement terms, not routing algorithms.
4. Compliance forbids handing credentials to a third party. Then only a self-owned vault works, and the vault advantage disappears.

8. Four common misjudgments

1. Treating the orchestration layer as an acquirer: none of the three provides acquiring. The merchant remains the contracting party with each provider, and merchant IDs and reserves are unchanged. For funds architecture see treasury architecture for platform businesses.
2. Expecting orchestration to raise success rates automatically: the lift comes from having a second path and routing on real data, which requires that you genuinely run multiple providers and keep calibrating policy.
3. Forgetting the orchestration layer is itself a dependency: when it is down, every rail is down, so its availability requirement cannot be lower than your critical rails'.
4. Comparing only usage rates, never exit cost: the former is visible annual spend, the latter is the hidden barrier that decides whether you can still switch four years out.

Source: 16IDC original. Product scope, payment method coverage and pricing for each platform follow official documentation and commercial contracts.