Evaluating payment orchestration approaches

At some point, most companies think about payment orchestration beyond the most basic level. As payment volume grows, relying on a single payment service provider (PSP) can limit acceptance rates, increase costs, and become a reliability risk. Payment orchestration addresses these issues by enabling you to route transactions to other providers.

When you start evaluating how to implement payment orchestration, you’re inevitably faced with deciding whether to use a payment orchestration platform, or to build your own orchestration layer. This post outlines why businesses care about payment orchestration, and then walks through the tradeoffs of the two main options and how to decide which one is right for you.

Why payment orchestration is valuable

Payment orchestration is essentially about increasing revenue through various means. We’ll cover these elements specifically:

• Increasing acceptance rates
• Reducing processing costs and lowering fees
• Automating payment processes
• Improving customer experience
• Increasing reliability

Increasing acceptance rates

Your acceptance rate is the percentage of payment attempts that succeed compared to the total number of attempts. The higher the number, the better. Orchestration helps increase this value because it allows you to use information about a transaction so that you can route it through the channels that are most likely to succeed.

For example, let’s say you work with two PSPs. One might have high acceptance rates in the US but low acceptance rates in the EU, while the other has the inverse. When a customer enters their card information, you can set up orchestration logic that evaluates where that customer is purchasing from or what country their card was issued in, and based on that information, route the transaction to the PSP with the higher acceptance rate for that location.

Reducing processing costs and lowering fees

Digital transactions almost always have extra costs and fees applied to them on top of the core purchase amount. These can come from card networks, PSPs, and others. Building on the previous example, one PSP might charge lower fees for US-based transactions and higher rates for EU transactions, while the other has the inverse. Again, you can use information about the customer and their card to route the transaction to the PSP with the lowest costs. This logic for determining where to send a transaction can be automated, which leads us into our next point.

Automating payment processes

The example we’ve been using is what’s called pre-authorization routing. You use information like the transaction amount, the stock keeping unit (SKU), card information, customer information, etc. to determine which PSP to route each transaction to. The decision is largely based on comparing each PSP’s acceptance rates and processing costs. You take all that information to determine which PSP is going to have the best chance for a successful transaction at the lowest cost.

This approach for determining which PSP to send transactions to is often configured in a champion-challenger format. You establish a default PSP and monitor its performance. If performance changes, you can start routing payments to a different PSP with better acceptance rates or lower fees, so the configuration isn’t static. Some companies even monitor latency across PSPs to figure out which one processes payments faster.

Retrying payments is another process you can automate. Payments can fail for a lot of different reasons: cards get soft declined, PSPs have outages, etc., and you can retry these payments with other PSPs. The process happens in milliseconds, so the customer generally doesn’t know the initial attempt failed because the payment is retried before showing them a receipt page or purchase summary.

Improving customer experience

Solid checkout experiences are as low friction as possible while remaining secure and trustworthy. Payment orchestration provides several ways of improving customer experience, which can help with conversion and building trust with customers. If you know the customer’s location, you might display prices in the primary currency for that location, as well as local payment methods. Or maybe you know a customer usually pays with a Mastercard issued in Ireland, so you route their transactions through your Ireland-based PSP because you know they’ll have the best rates and the highest chance for a successful payment.

Increasing reliability

We mentioned PSP outages previously but there are other systems involved in payment processing. If you’re locked into an individual PSP and they go down, or if one of their downstream dependencies is down, you might not be able to accept payments. This can result in lost revenue of course, but it can also damage the trust your customers have in your business. Working with multiple PSPs and being able to route transactions instantly across them increases your reliability, but it also provides peace of mind.

PSPs monitor your chargeback rate and other metrics. If you cross certain thresholds, they may stop processing payments for you. With a multi-PSP setup, you can route traffic to an alternate provider while you address issues with the PSP that’s blocking your transactions.

The pros of payment orchestration platforms

Payment orchestration platforms are ideal for companies that don’t have many (or any) engineering resources. They can be easy to get started with, and offer UI-based tooling for less technical users. They also consolidate a lot of payment-related functionality like reporting and reconciliation.

When you integrate with an orchestration platform, you use their UI components to collect card information. That information is then stored and tokenized on their end so you don’t have raw card data in your systems, which helps reduce Payment Card Industry Data Security Standard (PCI DSS) scope. To charge a customer, you use the token with the orchestrator and they share card details with the PSP for processing.

These platforms offer UI-based tooling for payment orchestration. This usually takes the form of decision trees and “if-this-then-that” logic you build using their dashboard. You can configure flows like sending USD payments to Stripe and EUR payments to Adyen, or running 3D Secure (3DS) in some locations but not others. This routing is more straightforward but it carries a lot of efficiency gains with relatively little effort. Hypothetically, if the goal is to reach 100% efficiency (likely impossible in reality due to numerous reasons), a payment orchestrator can arguably get you 80% of the way there.

With orchestration platforms, you don’t have to integrate with multiple PSPs to get access to them. The platforms already have integrations with PSPs so you just choose from their available providers when you create your orchestration flows. And because you’re only integrating with the orchestration platform, the UI that customers interact with is consistent regardless of the PSP the payment eventually gets routed to.

The cons of payment orchestration platforms

There are a few things to be aware of before you decide on a provider:

• Their UI elements may not have the level of customization you require.
• Their orchestration logic might not support fine-tuning.
• They might not support all of the PSPs and payment methods you need.
• They have limited proxying capabilities.

Starting with UI elements, many providers have theme and branding options that you can set for the collection form. Some elements aren’t customizable, or require that you select from preset values. Gr4vy for example allows you to set values outlined in the image, but you can’t apply your own CSS styles to them.

Customizable values in a Gr4vy payments form

Support for custom fields varies (either in their availability or limits on the number or types of fields), and not every provider allows you to change the order in which fields appear. These limitations can become a problem if you have strict brand requirements around custom fonts, or if you want to add fields for non-payment related information (e.g., allowing customers to enter a gift message or asking for feedback).

For orchestration logic, you’re limited to the actions (what to do with a payment) and variables (currency, transaction amount, etc.) that the platform allows. They might support something like this:

1. Send USD payments to Stripe
2. If the transaction fails with Stripe, retry the payment with Adyen

But you can’t configure logic like this:

1. After the customer submits the payment, use the bank identification number (BIN) to look up the card type and issuing bank
2. If the acceptance rate for previous purchases with that BIN is less than 85% with Stripe, route the payment to Adyen

This might seem convoluted but acceptance rates and transaction fees are varied and dynamic. You can retain more revenue by intelligently routing to PSPs with better rates or lower fees based on transaction amounts, customer location, and your own metadata. For example, if you’re a game distribution platform, you might want different routing for specific titles or publishers. The prebuilt decision tree logic from payment orchestrators makes creating routing logic across different entities either impossible, or difficult to execute.

When evaluating payment orchestrators, make sure they support the payment methods and PSPs you want to use. Validate this at the product level too because some products, like Primer.io’s Drop-in checkout, don’t support all their payment methods. We’ve had numerous conversations with users that moved off of a payment orchestrator because they either didn’t have an integration with a certain PSP, or the timeline for building the integration was too long. In some cases, the integration was deprioritized completely without any timeline for when it might be completed. These are huge issues if you’re a global business and need access to less popular or region-specific PSPs.

Payment orchestrators share card data with PSPs for processing, but they often can’t transform the data or proxy it to other third parties. For businesses like online travel agencies (OTAs), that’s a major blocker. OTAs not only need to share card information with their partners (airlines, global distribution systems, etc.), they sometimes have to transform the data itself before sharing it. Simple proxies can only share data in the format it’s collected in, they can’t reformat it. As an example, primary account numbers (PANs) might be collected like this 1234-1234-1234-1234, but a downstream supplier might require them without the dashes (1234123412341234). That seems like a small thing, but if OTAs handle raw card information themselves so they can do the transformation, it introduces a ton of compliance implications.

All of these limitations are what bar you from pushing beyond the base level efficiency gains you get with an orchestrator. If you operate on thin margins, or if something like a 1% increase in acceptance rates would make a meaningful impact on your revenue, self-orchestration is something to consider.

The pros of self-orchestration

When you build your own orchestration layer, you integrate with PSPs directly, rather than gaining access to them through a platform. You build orchestration logic at the code level, which gives you more flexibility. If payment orchestrators get you to that hypothetical 80% efficiency, self-orchestration enables you to hit that and beyond. This remaining 20% is where you really get to build logic that fits your business.

Because all the logic lives within your own systems, you can essentially route payments however you want. You can use internal data, live monitoring (e.g., track PSP performance with a multi-armed bandit configuration), and machine learning to make routing decisions, and you can do pre-authorization checks like BIN lookups. This allows you to collect more context on a customer and a transaction before routing the payment, so you can send it to the PSP with the best rates or lowest fees. Our Tebex case study is a concrete example of self-orchestration if you want to see what it looks like in practice.

With self-orchestration, we’re assuming you’d use Evervault or another solution that allows you to collect card information separately from individual PSPs. This keeps the customer experience consistent (using the UI element from each PSP you integrate with would be messy and look visually different) and allows you to integrate with just about any PSP you want. It also maintains a reduced PCI DSS scope while providing more routing flexibility.

A subtle but important benefit is that changes to orchestration logic are done through code. This means changes are tracked and reviewed before they’re enabled. While the UI tools that orchestration platforms provide are easy to use, the barrier is also low for anyone to make a change, or to accidentally implement something they shouldn’t have.

The cons of self-orchestration

The biggest downside to self-orchestration is that it’s generally more upfront work than using a payment orchestrator. Routing logic isn’t always that complex, but it still requires engineering time. And because you’re integrating with multiple PSPs directly, it can take longer to go live.

The maintenance effort depends a bit on your logic, but it’s also something you likely don’t want to make changes to very often (changing how payments are routed obviously needs to be done with care). If your logic is straightforward, maintenance effort should be minimal. If you have more complex routing requirements, you might have more maintenance or monitoring to do but that’s not always the case. Ideally you’d automate flows for rerouting payments as-needed. For example, you might automatically switch to a backup PSP when your primary PSP’s acceptance rates get too low or their fees too high.

Depending on the solution, there might be some limitations on the checkout form UI in terms of visuals, adding custom fields, etc. Evervault provides a fully-customizable form, and you can edit values at the CSS level. You can even design entire themes or extend prebuilt ones provided by Evervault. Both orchestration platforms and solutions like Evervault require some level of design work, so there might not be a significant difference in the time or effort it takes to build your checkout form. It depends on what you need your checkout form to look like.

Real companies that built their own orchestration layers

Tebex is one of our customers that decided to self-orchestrate their payments. Their use-case was such a solid model that we paired on a case study. In short, they tried a payment orchestration platform but it didn’t provide all the payment methods they needed, or the routing flexibility they required. Tebex is a global business and local payment methods are a must-have, not just secondary options. On top of that, they wanted to route payments at the individual content creator, game genre, and payment method level (they’re a gaming monetization platform). This kind of routing wasn’t possible with payment orchestration platforms.

PayNext is another of our customers and they took self-orchestration to a level we hadn’t quite seen before. Their business focuses a lot on recurring payments and subscriptions. Payment orchestrators can support these types of payments, but PayNext needed more control over dunning. They built their own machine learning platform in-house that handles payment recovery and determines when to retry individual payments.

Deciding between an orchestration platform and self-orchestrating

The choice between an orchestration platform and self-orchestrating is a company-specific decision. For many businesses, orchestration platforms work great and they have long-term relationships with their provider. For other businesses, their requirements are such that they need more flexibility so they build their own logic. It’s not a “What’s better?” question, it’s a “What’s best for my business?” question.

If you aren’t sure which way to go or how to start the conversation at your company, here are some things to think about.

• What kind of logic do we need? How complex is it?
  • List or map out the flows you want to support
  • List the PSPs, payment methods, and currencies you want to use
• Do we have engineering resources that can help build orchestration logic?
  • If you don’t have engineering resources, self-orchestration could be tough and a payment orchestrator might be a better fit
• Do you have a hard deadline for implementing orchestration logic?
• If you’re already accepting payments and have access to the data, analyze cart abandonment and failed transactions to see where payment orchestration might help.
  • If customers are adding items to their carts but not making purchases, maybe their preferred payment method isn’t available during checkout
  • Find out which transactions succeed, which are failing, and why
  • Check for failure patterns across locations, card brands, currencies, etc.

With this information, you can start evaluating both approaches to see what’s feasible. If you decide to go the self-orchestration route, Evervault has several products to help with card collection and working with multiple PSPs.