In a world where merchants rely on service providers to operate their businesses, being dependent on any single provider creates risk when service is interrupted.
Consider the CrowdStrike outage as an example of what impact could happen to a merchant if their payment service provider (PSP) experiences a disruption in service. While cash can still be king at physical locations, the more PSPs and payment options a business can work with, the higher the potential volume for sales—and the greater the need is to orchestrate how payments are processed.
The term payment orchestration refers to a comprehensive approach for managing a payment process across multiple PSPs. Compared to payment routing, which is the actual process of directing payment transactions to a processor or financial institution, payment orchestration encompasses tools like fraud detection and transaction monitoring too.
Payment orchestration platforms tout several benefits of orchestrating payments,, in addition to payment routing:
- Increased approval rates: Because transactions are routed to the best processor based on real-time data, merchants will 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 in a backup processor to manage retries of failed transactions.
Many orchestration providers can also work with merchants without requiring development work.
How to Orchestrate Payments
At checkout, the payment orchestration platform filters payment options based on specific criteria, such as the customer’s country and risk score. The payment is then routed to the most suitable payment provider based on response times, transaction costs, and acceptance rates.
The acquiring bank then verifies and authorizes the payment with the issuing bank and sends the merchant an authorization response code.
Payment Orchestration Use Case
For example, a global merchant might choose to have transactions processed by providers in the buyer’s home country. In this case, payment orchestration can help solve tricky funds flows without the aid of significant supporting technologies.
- The customer enters their payment details.
- These details may be collected and stored by the merchant, sent directly to the PSP, or tokenized and stored in a third-party token vault
- The merchant sends the details to a payment service provider, or gateway.
- This may have happened automatically if the details were sent directly to the PSP. If the details are in the merchant’s control, however, there is an opportunity at this step to decide which PSP should be used for the deal.
- The gateway encrypts the customer’s payment method information and sends it to the acquiring bank and card network (or other payment processor).
- The gateway or payment orchestration platform performs a series of security checks before passing the transaction on and may, in fact, cancel it before ever passing it to the card networks. The reasons for this vary but they all come down to whether the PSP’s internal fraud detection systems clear the transaction.
- The merchant’s and customer’s banks verify and authorize the pending transaction.
- Ensuring that the payment orchestration platform here has positive and active relationships with both sides of the transaction increases the likelihood of success.
- Generally, the acquiring bank communicates the authorization response code to the payment gateway, which passes it on to the merchant.
- In the case of a failure, the failure code itself can be used by the merchant to decide what to do next. Next steps go from simply declining to close the deal to re-presenting the same information to a different PSP.
The bottom line is that the PSP, or payment gateway, generally enables a linear process of presenting cardholder details to a card network and communicating the decision of whether or not to honor the transaction by the issuing and acquiring banks. By contrast, payment orchestration represents lower-level decision-making processes, like a proprietary fraud check, selecting which PSP to use, and deciding whether to automatically attempt a second attempt in the case of a decline.
Where Payment Orchestration Falls Short
The reality for many merchants is that payment orchestration provides more than what merchants need, as this utopian plan becomes complicated and overwhelming for many merchants.
Single-Point-of-Failure Threats
Working with an orchestration provider with custom APIs simply moves the risk from one location to another. A primary reason for implementing payment routing rules is to safeguard against payment failure, account shutdown, or PSP outage. By dynamically routing payments, merchants try to reduce single-point-of-failure issues by giving payment optionality. But, should the orchestration provider have an outage, the routing rules, the connections, and the payment processing can all go down from a single outage.
Unnecessary Features
Complicated routing, logic, and advanced settings sound exciting on a pitch deck but the vast majority of merchants don’t need—and won’t use—the sophisticated features that come with payment orchestration providers. It is like buying a ticket to Disneyland just to get a churro—you likely won’t see a positive ROI leveraging such a small portion of the product (even with how good those churros happen to be!)
Inflexible Omnichannel and Partner Options
Given just how vast the payment landscape truly is, it is impossible for payment orchestration platforms to offer connections to every payment partner a merchant may want. These platforms will often prioritize the highly sought-after PSPs and any partners they may have binding contractual agreements with. The sticking point is when a merchant needs to connect with a partner not offered in the preset “marketplace” of connections.
Merchants Don't Need Complex Routing
A huge myth in payments today is that merchants require complex routing strategies to optimize fees, flows, and revenue. However, most merchants want—and honestly, benefit more from—a much simpler approach to payment optimization: the ability to integrate a backup processor.
Where to Get Started Implementing Payments Orchestration
For the more established merchants, perhaps the promises of orchestration truly resonate. They have the teams to implement a strong solution, and they want more complex routing rules for payments. What may come as a surprise, however, is the sticker shock of using orchestration platforms when processing large volumes of payments. These solutions often tout the opportunity for volume discounts but may fail to mention that more complex routing rules (often most beneficial to use at high volumes) come at an additional cost. If not through an add-on feature, then in the form of a higher-tiered plan. What was once scalable became unaffordable.
There is a class of technology solutions known as payment orchestration platforms (POPs), offering a range of services. Some payment orchestration platforms include Spreedly, Payoneer and BlueSnap.
Choosing the right PSP, whether that is a more ‘black box’ experience where they hold the payment gateway relationships or one that offers a greater depth of flexibility in subscriptions management or treasury and payables management, is based on the business's needs.
Merchants also have the option to create either simple or complex routing logic within their systems if they have the engineering team to accomplish it.
Regardless of the direction, the first step in implementing payment orchestration is to get control of the cardholder data.
This can be done by either achieving PCI Level 1 compliance and owning the cardholder data environment or by using a third-party tokenization provider like Basis Theory.
By using a tokenization provider, merchants can ensure that:
- PII and cardholder data is maintained in the tokenization provider’s secure vault, keeping their own systems out of PCI-DSS scope
- All customer-sensitive data is secure yet available for merchant use
- Customer cardholder data (CHD) can be used to process transactions across a functionally infinite range of payment methods and providers
The merchant simply uses the tokenization provider’s API to collect and store customer PII and CHD and instructs the provider to transmit that information as needed to the preferred downstream payment processors and payment gateways.
By orchestrating payments between processors and gateways, merchants increase their successful transactions, decrease their costs, and reduce the risk of centralizing too many services on a single PSP.
Rethink your payments stack and consider the benefits of multiple payment gateways.
