Read Client Stories
Alex Kugell
Key Takeaways
- Serious orchestration platforms all have similar features. What actually separates them turns up at runtime and on the way out.
- Token custody decides how hard it will be to leave. A platform holding your card vault can quietly rebuild the processor lock-in you bought orchestration to get away from.
- The payment orchestration platform sits in your authorization path, so its latency and uptime become yours. Judge it on p99 numbers and its actual incident record.
- An abstraction that hides too much costs you the processor-specific features you added that processor for, like 3DS step-up or a local payment method.
- Four of the seven criteria come down to a single question: when this ends, what do you walk away with? Confirm that your tokens, your routing rules, and your settlement history all export before you sign.
- Your integration pattern sets your PCI scope. The vendor’s own compliance does not.
It can be incredibly difficult to choose a payment orchestration platform. Staring at two or three platforms whose websites could have been written by the same person doesn’t give you all the information you need to guarantee the right choice.
An orchestration platform quickly becomes a dependency between your application and your money movement. It lives right inside your authorization path, so its latency turns into your latency and its uptime sets the ceiling on yours.
Once your customers’ card credentials sit in its vault, leaving gets slow and expensive. So much so that many companies don’t find it worthwhile to move to someone better.
Two platforms can look identical on features and still behave nothing alike once real traffic hits them, or once you try to walk away.
Let’s look at the seven criteria that separate the serious platforms, the questions that pull each one into the open, and the tell for when a vendor reassures you instead of answering.
If what you actually need is engineers who have shipped multi-processor payments before and can sit in the evaluation with you, we can help.
What Actually Separates These Platforms
From what we have observed, the differences that matter are usually in the integration contract and in how the platform behaves while it runs and while you leave. Seven criteria carry most of the weight, roughly in the order they’ll shape the work:
- Token custody: Who holds your card credentials.
- Abstraction depth: What the layer exposes, and what it hides.
- Latency and availability in the authorization path.
- Webhook and event normalisation.
- Data access: Raw records, or an aggregated view.
- Exit terms: What you keep if you leave.
- PCI scope.
Notice that four of those seven ask about what happens when the relationship ends.
You’re slotting a dependency between your application and your money, so it pays to work out how you’d leave before you commit to joining, even if you feel quite certain at the time that this will be your long-term vendor.
Build-vs-Buy Payment Orchestration Platforms
Orchestration isn’t just one thing you choose to buy or build. Instead, you can think of it as four layers: a token vault, routing logic, connectivity to processors, and compliance and fraud tooling.
You can own or rent each one on its own.
We recommend that you always try to own the layers that carry your switching cost and your proprietary data, which means the vault and the routing logic. You can then reduce your engineering load and costs by renting the layers that rot and demand constant certification work, like connectivity and the compliance tooling.
When it comes to abstraction, we only recommend renting it when you start expanding geographically or seeing massive growth. Before that, up to about two processors in one market, building the abstraction yourself usually costs less than renting it.
Criterion 1: Who Holds the Token Vault?
A platform holding your card credentials in its own vault ends up with the same grip your processor had. If you, at any point, decide to leave, it means re-tokenising your whole customer base.
Four broad options exist, and they trade portability against simplicity:
- Platform-held vault: Quickest to stand up, and it gives you portability across processors inside the platform. It also hands the platform the most leverage over you.
- Independent vault that the orchestrator points at: More parts for you to run and monitor, but you keep portability on both fronts, so you can swap processors or swap orchestrators.
- Network tokens, where they’re supported: The card networks issue these rather than the platform, and any acquirer wired into that network recognises them. They also refresh on their own when a card gets reissued or expires.
- Your own vault: Total control, plus the full weight of PCI scope that rides along with it. We find this is rarely worth it unless card data forms part of the product itself.
The question to ask any platform stays simple: if we leave, do we get our tokens, and in what shape?
Then the follow-up that tells a real answer from a comforting one: has a customer actually done it, and how long did it take?
Naturally, a platform that earns its money from retention has a built-in reason to make vault portability clumsy without making it impossible, so make sure to pay attention to the actual transfer mechanism.
Criterion 2: How Deep the Abstraction Runs, and What Leaks
An orchestration layer earns its keep by smoothing over the differences between processors. The trouble starts when it also flattens the ones you need.
A lowest-common-denominator interface reads clean and integrates fast, and it often can’t touch the very things that made you add a given processor: a 3DS step-up flow, a local payment method, a network-token operation, a processor-specific fraud signal.
Teams usually bring on a second or third processor for one of those exact capabilities, so a layer that buries it defeats the purpose.
Worth checking:
- Does the platform document an escape hatch for processor-specific features, or does it simply not surface them?
- When your acquirer ships something new, how long until the platform supports it? Ask for the actual history. That lag measures what the abstraction costs you better than any roadmap promise.
- Can you drop below the layer for a single flow when you have to, or does it work only as all-or-nothing?
- Whose status and error models do you end up using, yours or theirs? Take on theirs, and you’re translating a second vocabulary into your own everywhere payments touch your code.
The question to ask: show us how we’d use a processor-specific feature you don’t natively support. A platform that has wrestled with this gives you a straight answer.
We find it’s helpful to keep in mind that deciding what to normalise and what to let through when you build the layer yourself counts as an architecture problem.
Criterion 3: Latency and Availability in the Authorization Path
Your checkout only stays as fast and as available as the platform in front of it.
Structurally, that platform sits between your application and your processor, right inside the authorization flow, which means that any latency will stack on top of your own.
A lot of companies see this as a worthwhile trade for the connectivity and certification load it lifts off you, but make the trade deliberately, with numbers on the table.
What to ask for, and how to read it:
- Percentiles: A p50 flatters everyone. A p99 shows what checkout feels like under load.
- Uptime history: An SLA works as a refund policy. Ask to see the status-page history and the post-mortems from real incidents.
- Behaviour when part of the system fails: If the platform can’t reach one processor, does it drop the transaction, route around to another, or hang until it times out?
- Whether you can go around it mid-incident: A documented direct-to-processor fallback beats any availability figure, because it puts a floor under your worst day.
The question: what happens to our transactions during your next incident, and what happened during your last one?
Criteria 4: Webhook and Event Normalisation.
Consistent, reliable events keep your reconciliation and your retries sane.
Processors, though, report the same real-world occurrence at a different granularity and in different payload shapes, often at different times. So the question becomes whether the platform truly folds all that into one event model, or just forwards each processor’s webhooks wrapped in a thin layer.
Forwarding hands you back the original problem with a dependency stacked on top.
We recommend that you check the delivery guarantees, the ordering, whether you can replay events, and whether you can reconcile against the platform’s own event history after an outage.
Outages happen, and that history becomes how you climb back out cleanly. Solid fintech API security on those webhook endpoints stops being optional here too.
Criteria 5: Data Access (Raw or Aggregated)
Owning your raw data keeps you in control of both reconciliation and rate negotiations.
Reconciliation needs settlement-level data, and any routing decision worth making needs per-processor cost and approval data.
Ask whether you get the raw settlement files and full transaction records, or only the platform’s tidied-up view. Take the aggregated view, and you depend on their analysis, and you walk into an acquirer rate negotiation holding a weak hand.
This marks the point where your payment reconciliation systems and your payment ledger architecture have to match up against whatever the platform will actually hand over.
Criteria 6. Exit Terms
As we have already discussed above, what you can carry out decides how free you really are to leave.
The vault aside, we recommend that you ask what becomes of everything else you built in the platform: the processor integrations you set up, the routing rules you tuned over months, the transaction history you piled up.
Your data and your rules should walk out with you in a format you can use.
It’s a good idea to pin down notice periods, export formats, and any transition help while you’re still deciding.
Criteria 7. PCI Scope
Your integration pattern drives your PCI scope more than anything the vendor says about its own certifications.
Depending on how you wire it up, a platform either shrinks your scope by keeping card data out of your systems or widens it.
A redirect or hosted-fields pattern, where card data never lands on your servers, can hold you at the lightest self-assessment. Push card data through the platform from your own backend, and you fall into a much heavier one.
Make sure to nail down which pattern you’d actually use, what it does to your SAQ type, and get the platform’s Attestation.
The Questions That Sort Platforms Fastest
- If we leave, do we get our tokens, and has a customer actually done it?
- Show us how we’d use a processor feature you don’t natively support.
- What are your p99 latency numbers, and what happened in your last incident?
- Do we get raw settlement data, or your aggregated view?
- Do we own our routing rules in a form we can export?
- What does our integration pattern do to our PCI scope?
A platform that answers the first three concretely, without kicking you to a specialist, has fielded them before from teams like yours.
Whoever runs this evaluation should have operated multi-processor payments before, since the criteria only mean much to someone who has felt their absence.
Sometimes the exercise turns up a different answer entirely. The architecture may hold up fine, but that’s no use if you just can’t staff the integration work.
Trio places payment engineers and fintech integration engineers who have built this layer in production.
