Looking for a payment orchestration alternative
Orchestration is sold on approval rates and cost savings, and both are real — above a certain scale, with more than one acquirer. Below that, the layer adds a fee, a dependency, and an extra hop for no routing gain. The honest evaluation starts by working out which side of that line you're on.
Six questions before you add a layer.
How many providers do you actually run?
One acquirer means there is nothing to route between. The gains on offer all assume several relationships you have a reason to keep.
What is a point of approval rate worth to you?
Multiply it out against your annual volume, then compare it to the layer's fee plus the engineering to run it. At smaller volumes the arithmetic rarely survives contact.
Is your decline problem actually routing?
A lot of what looks like a routing problem is method coverage, a checkout that loses people before authorization, or a 3-D Secure policy set too aggressively.
Who settles the money?
An orchestrator normally doesn't — settlement stays with whichever provider took the payment, which means your reconciliation still spans several providers unless the layer solves that too.
What happens to your reporting?
Normalising reporting across providers that disagree is often the real value on offer. Ask to see it against your own provider mix rather than a demo dataset.
What does the layer cost you in dependency?
You add a system in the path of every payment. Ask what happens when it's degraded, and whether you can fail past it to a provider directly.
When orchestration is genuinely the answer
When you already hold several acquiring relationships because no single one covers your markets, your risk profile, or your rates — and your volume is large enough that a fraction of a percent is real money. At that point, routing by issuer and corridor, cascading a soft decline to a second acquirer, and one reporting model across providers stop being nice ideas and become a line in the P&L. The prerequisite never changes: multiple providers you have a reason to keep.
- [ 01 ]Several acquirers, kept for coverage, redundancy, or rates
- [ 02 ]Volume where a point of approval outweighs the layer's fee
- [ 03 ]Failover between providers as a business requirement
- [ 04 ]One reporting model across providers that disagree
When it's the wrong purchase
When you have one provider, or when the problem you're solving is upstream of routing. Adding a layer above a single gateway buys a fee and an extra hop. And if payments are failing because a customer's preferred method isn't on the page, because the checkout loses people before authorization, or because 3-D Secure is challenging traffic it doesn't need to, no amount of routing recovers that — the fix is in the checkout, not above it.
- [ 01 ]One provider — nothing to orchestrate
- [ 02 ]The loss happens before authorization, not at it
- [ 03 ]Method coverage, not routing, is the actual gap
- [ 04 ]The fee exceeds the routing gain at your volume
Where Protocore Gateway fits
We're the layer underneath — a gateway that takes the payment and settles the money — with the parts of orchestration that matter to a single-provider business built in rather than sold above it: a routing policy written in terms you recognise, a retry on an alternative route before the customer sees a failure, and decline reasons an operator can act on. If you genuinely reach multi-acquirer scale, the whitelabel platform connects your own acquirers alongside ours. Most businesses asking this question need a better gateway, not a layer above the one they have.
- [ 01 ]Routing policy and retry included, with no layer fee
- [ 02 ]A gateway that actually settles, in one currency
- [ 03 ]Your own acquirers connected on the whitelabel platform
- [ 04 ]Cards, wallets, transfer, and USDC on one page and one reference
Questions worth asking anyone.
No. Every gain orchestration sells — routing, cascading, rate arbitrage — assumes several providers. Above one gateway, the layer is a fee and an extra hop with nothing to decide between.
It can, if your declines are genuinely routing-shaped and you have alternative routes to send them to. If the losses happen before authorization — wrong methods, a heavy checkout, an over-aggressive 3-D Secure policy — routing has nothing to work with.
Usually not. Settlement stays with whichever underlying provider took the payment, so your reconciliation still spans those providers unless the platform explicitly solves that as well. Worth confirming early — it surprises people.
Yes, if your gateway includes it. Routing policy, retries on soft declines, and readable decline reasons don't require a separate platform when they're part of the gateway taking the payment.
Work out which layer your problem lives in.
Tell us how many providers you run and where payments are failing. We'll say plainly whether the fix is routing, the checkout, or neither — including when the answer isn't us.
Talk to us