.png?width=365&height=122&name=BTLogo%20(1).png)
As the global borders between consumers and merchants collapse, people from around the world are ready to buy and sell from and to one another in an almost entirely unlimited way. The mechanisms for ensuring that an intended purchase is successfully completed, though, are struggling to keep up.
It’s not just that consumers in different geographies have different payment method preferences, nor that banks are more inclined to approve deals that happen within their own national borders. It’s that merchants must somehow apply all the knowledge they’ve collected about consumer behavior and the payment ecosystem at the point of sale for every single transaction.
And that is why the market developed payment orchestrators, systems that would make it easier for merchants to close the most deals they could, at the lowest cost possible. And also why, today, merchants at scale start to outgrow payment orchestration.
What is a payments orchestrator?
A payments orchestrator is a system that analyzes transactions and directs them to the optimal endpoint for processing, theoretically maximizing the chance of a successful approval, while minimizing the total processing fees to be paid. Additionally, payment orchestration platforms (POPs) often offer a shortened path to adding new payment service provider (PSP) accounts, effectively shortening the lead time to getting new offerings off the ground.
At its most basic level, the orchestrator will read an inbound payment request, discern its key characteristics, then use a decisioning engine to dictate the PSP partner to which it should be submitted.
For instance, if a merchant had relationships with one PSP in the United States and another in Canada, the orchestrator would likely start by ensuring transactions were directed to the provider that matched the customer’s location. On the other hand, if the merchant was contracted with two PSPs with different processing rates for different payment methods, with all else being equal, the orchestrator would direct the transaction to the lowest-cost provider.
What are the downsides to payment orchestrators?
While the impact of payment orchestration can be immediate and quite profound—literally putting money back to the bottom line by eliminating excessive processing fees—that doesn’t mean there aren’t some potential drawbacks. These include:
- Security: Not all orchestrators are able to offer the highest level of security, meaning that for merchants operating internationally (especially in the EU), purchase paths may need to be extended or adjusted to ensure customer data is properly protected. This can introduce friction to the buying process, which can suppress conversion rates from purchase pages.
- Settlement: Although working with an orchestrator makes it easier to get signed up with, and to process through, new PSPs, gaining access to settled funds can be tricky when the relationship is indirect.
- Routing Rules You Don’t Control: While POPs are good at sorting between PSPs based on transaction success rates and processing fees, they may struggle to support more merchant-specific considerations, such as volume discounts or annual transaction guarantees. Businesses that have complex agreements with their PSP partners can quickly run into a brick wall trying to configure their orchestrator properly.
This is not to say that the concept of the orchestrator is flawed. It is, in fact, a fundamental requirement for optimizing any payment system. The challenge for most merchants is to recognize when they have outgrown third-party payment orchestration.
How do you know if you are outgrowing an orchestrator?
There are fundamentally three reasons why a merchant may decide that their business has outgrown their existing payment orchestration provider:
- Arbitrage Balance: At a certain volume of transactions and partners, the cost of the orchestrator will exceed the savings that could be captured by using an in-house decisioning engine. When the fee approaches what you’d spend staffing an engineer, the math has shifted.
- System Resilience: At a certain point, a merchant cannot risk having a third-party-caused event and must therefore build redundancies for when their external partners are unavailable, including their orchestrator. But once an engine is in place to route around the orchestrator if need be, it makes sense to use that engine for all decisioning and bypass the orchestrator entirely.
- Security and User Experience: Merchants are always focused on delivering low-friction buying experiences, which increase and protect their conversion rates on sales pages. They are also necessarily careful to maintain the security of their customers’ personally identifiable information (PII). At the slightest hint that an orchestrator may not be able to emulate the merchant’s required security posture, it may be time to move the decisioning in-house.
An orchestrator is normally offered by a POP, which takes full responsibility for building, developing, and managing the software; a merchant simply signs up for and uses the service, paying whatever fees are currently charged.
Moving on From a Third-Party Orchestrator
Recognizing that you have outgrown your payment orchestration platform is a meaningful step, but only raises harder questions. Building an in-house decisioning engine gives you the routing control and logic your business actually needs, but it only delivers its full value when the payment credentials are stored somewhere portable, secure, and processor-agnostic.
That’s where the programmable payments vault comes in. With Basis Theory, a merchant can keep sensitive card data out of its systems, while still having the control to route it to a PSP without touching PCI scope.
More importantly, it removes any single point of failure. The decisioning engine routes, the vault holds the credentials, and no outage with a processor or orchestrator anywhere in that chain can take down your payments.
It may well be time to accept that the business has outgrown its orchestrator, and to move on to an in-house decisioning engine, supported by a token vault.
