Hire by Technology
SERVICES
Contents
Share this article
Key Takeaways
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.
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:
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.
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.
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:
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.
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:
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.
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:
The question: what happens to our transactions during your next incident, and what happened during your last one?
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.
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.
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.
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.
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.
Expertise
Subscribe to our newsletter
Related
Content
Continue Reading
