.png?width=365&height=122&name=BTLogo%20(1).png)
In a world that relies on service providers to operate a business, dependence on any single provider creates risk if that service is ever interrupted.
Consider an outage the canonical example of the critical impact on an organization when their one and only payment service provider (PSP) experiences a service disruption. Perhaps the only more devastating blow that can be sustained is when Stripe shuts them down.
While cash can still be king at physical locations, the more PSPs a business can work with, the higher the potential volume for sales - and the greater the need is to have redundancies in place for how payments are processed. This is known as having a multi-PSP approach.
Payment orchestration is associated with a multi-PSP strategy. Payment orchestration is a set of rules that runs on top of a vault holding tokens, programmatically delivering transactions to the most beneficial downstream PSP. This arbitrages processing fees (keeping costs down), and optimizes success rates (increasing the raw number of deals closed) - so the question isn’t whether you should orchestrate, but rather whose vault the orchestration logic should be locked into?
Orchestration refers to managing an entire payment lifecycle through a single merchant platform that uses multiple connections to PSPs, fraud providers, billing platforms, and various other services. Rather than establish multiple self-contained PSP relationships, a payment orchestration platform has dynamic connections that merchants can use to control how transactions are routed, authorized, and settled.
Orchestration happens across multiple processors, geographies, and payment methods, and delivers significant economies that can boost bottom lines. Third-party orchestrators bundle this and sell you their prebuilt rules.
Compared to payment routing, which is the process of directing transactions from point A to point B to a processor or financial institution, payment orchestration encompasses multiple tools and services.
Payment orchestration platforms deliver several benefits beyond payment routing:
- Increased approval rates: Because transactions are routed to the best processor based on real-time data, merchants should see an increase in approval rates.
- Decreased transaction costs: Specific types of transactions can be routed to the processor with lower fees.
- Freedom to manage multiple connections: Easy-to-use interfaces provide a single location for managing connections.
- Redundancy: Building a backup processor to manage retries of failed transactions, and to protect against downstream system outages.
Basis Theory gives you the vault and lets you build the rules yourself, or with a partner. The main difference? Control stays with you.
What’s the difference between payment orchestration and a payment vault?
A payment vault stores and secures cardholder data independent from any PSP. Payment orchestration then decides which processor to send a transaction to, when to retry a decline, how to route by card type or geography, and so forth.
The vault is infrastructure. Orchestration is a set of rules that run on top of that infrastructure.
Every orchestration platform needs a vault underneath it to hold tokens. The difference between vendors is who owns that vault and who controls the rules running on it.
You can run into trouble when orchestration and vaulting are treated as one purchase decision. A third-party orchestration platform bundles both the vault, and prebuilt routing rules. A vault-first approach separates the two, ensuring you are the owner of the vault and the data within it, and can then decide the routing logic and add rules as you need them.
Neither approach is wrong, but the question you start with needs to change.
Don’t ask, “Do I need orchestration” and start asking, “Whose foundation is my logic sitting on, and what happens if I want to change it?”
Do I have to choose between orchestration and vaulting?
This is not an either/or scenario. Vaulting should be treated as the foundation of any payment stack. The orchestration is what you build on it.
Most orchestration platforms present this as all or nothing. That framing exists because it’s how they sell, not because vaulting and orchestration are locked together. In practice, a vault-first approach can give you more paths:
- Use your vault with no orchestration at all. Plenty of merchants just need cardholder data secured and portable across a couple of processors. No routing rules required.
- Build your own orchestration logic on top of your vault. Set rules for card type, geography, or fallback processors, and change them whenever your business changes, since the rules are just configuration on infrastructure you already own.
- Bring in an orchestration partner while keeping your own vault. You get the routing logic without giving up ownership of the data underneath it.
The reason this matters is what happens when your needs begin to change. If the vault and orchestration rules come from the same vendor, making a change to one requires a potential renegotiation of both. If they’re separate, swapping out logic, adding a processor, or building a rule set can happen on your own timeline.
This separation is why the “prebuilt” pitch by orchestration platforms deserves scrutiny. Prebuilt routing rules are usually designed around a large customer’s transaction mix, then packaged for everyone else. You end up paying for the whole platform to use a fraction of it—like buying a ticket to Disneyland just to get a churro (even with how good those churros happen to be!)
Owning the vault means not being stuck with someone else’s assumptions about your traffic.
Felix, a fintech serving Central and South American immigrants across the United States and Latin America, ran into this exact bundling problem. Their orchestrator was failing and it was impossible to isolate the specific problem. Outages were coming from either the processor, orchestrator, or an internal system without any clear signal pointing to the cause.
They didn’t drop orchestration; they built their own and moved it onto a vault they control.
“We own the tokens, so we can just go ahead and integrate directly with a PSP API,” explains Emilio Muñoz, Software Engineering Manager at Felix. “We don’t have to rely on the orchestrator.”
Migrating their existing tokens from the orchestrator onto Basis Theory’s vault took under eight weeks. As a result of removing the middleman, payment latency dropped by 50%.
“Because we have one less hop with the network, I knew we’d improve,” Muñoz says. “But I did not expect to improve that much.”
What should I ask a payment orchestrator?
Ask these before you sign anything—including if you’re evaluating Basis Theory.
Can you route a token created on one processor to a different processor?
Some platforms tokenize in a way that ties the token to whichever processor first touched it. If you can't move that same token to a second processor without a new integration, you're not as independent as the pitch deck suggests.
What happens to your routing rules if the platform goes down?
Orchestration is supposed to reduce any single point of failure risk. Ask directly, what happens if the orchestrator or vault has an outage? Will routing rules, connections, and payment processing go down too?
Is pricing flat, or does every lifecycle event generate a charge?
Provisioning, refreshes, validation, retries—some platforms bill for each one separately. A model that looks affordable at your current volume can get expensive fast once you scale, especially if complex routing rules sit behind a higher-tier plan or an add-on fee.
Ask this plainly. A per-transaction cut compounds at volume in a way a flat fee doesn't.
Who owns the routing logic, and how hard is it to change?
If the rules running your payments were built for someone else's business and packaged for yours, ask how much control you actually have to rewrite them versus just toggling settings inside their framework.
None of these questions have a "wrong" answer that rules a vendor out. But if you can't get a straight answer, that's worth knowing before you're dependent on the platform.
How do I start a POC with a payment vault?
Committing to a full orchestration rebuild isn’t necessary to determine whether a vault-first approach fits. A useful proof of concept that starts small won’t put transactions at risk.
Starting with the vault gets cardholder data into an environment you control. This becomes the foundation everything else can sit on. Run this in parallel with what you have existing today.
New transactions can flow through the vault, alongside your current setup. This means no cutover, no downtime, and nothing to roll back if something doesn’t fit. Prove one rule before building the rest.
Give yourself a real but short window. Two to three weeks is typically enough to know whether the setup fits your stack, without dragging the decision out into an open-ended evaluation. At the end of the window, you'll know whether to build out further, bring in an orchestration partner on top of the vault, or turn it off entirely. Because nothing about your existing processor relationships changed during the test, there's no unwinding required either way.
The point of a POC is to prove the foundation is solid before you build anything on top of it. Get started with a vault-first approach using Basis Theory’s documentation and your favorite AI coding agent.
Get a vault running alongside your existing setup in weeks, not months.
