Payments Orchestration Layer

Can you share a bit about yourself?

I’m a consultant for the boutique firm, Retail Payments Global Consulting Group. We specialize in payments architecture and payments product management. After tossing around the terms payment switch and payment hub for much of 2018, I co-authored a white paper on Payments Orchestration in 2019.

Payments orchestration has been coming up quite a bit in recent years. Can you give an overview of what it is and why it matters?

Fundamentally payments orchestration is a function within a specific architectural layer that separates PCI concerns from the rest of the back-office or CRM. Payments orchestration as a term is new. The configurations are new. But the practices are quite old. In theory, the principles of payments orchestration provide payments folks the toolset to demonstrate and quantify their value. I’ve had a hand in defining the payments orchestration layer as meeting the four following conditions:

• One single API connection to all the required PSPs, acquirers, and payment methods as to isolate PCI burden onto one architectural quantum
• Smart Routing capabilities, whether it be retry logic, least cost routing, or any other arbitrary business logic can be coded into the platform; whether by developer, algorithm, or widget.
• Provides an end-user configurable tool so that providers and payment methods can be turned on and off without needing someone from engineering to do the maintenance work. Ideally, this tool also provides the ability to configure rules for routing or payment method presentation on the checkout screen.
• Leverages real-time ledgers to accurately track transaction statuses, costs, and revenue splits, improving liquidity management. I’ve taken a step back from this definition in the past year as many of these core requirements can be met with eventIDs and good idempotency practices. I’ve only seen one implementation of this principle in practice with payments orchestration.

Control and flexibility is at a premium. That’s what orchestration offers.

Payments can remind me of Greek mythology. There’s issuers, card brands, acquirers, merchants, and all the middlemen that can’t kill each other but are always trying to get one up on each other–for profit. That makes for a complicated and ever-fluctuating ecosystem. Control and flexibility is at a premium. That’s what orchestration offers. Upfront, it addresses some pervasive merchant payments problems in an easy to explain way.

• Outage and Latency Management—automatically and immediately switch transactions from failed or slow PSPs to alternative PSPs to avoid outages, timeouts, and the resulting customer abandonment.
• Optimized Routing provides the tools for non-technical staff to define routing criteria and rules for maximizing approval rates, minimizing payment costs, and automatically executing those rules with no manual intervention.
• Retry Declined Transactions—providing the tools for non-technical payments staff to define criteria for retrying declined transactions, establish decision trees for these retrials, and automatically executing those rules without manual intervention.
• Tokenization—providing a Token Vault, or interface with third-party Token Vaults, and additionally coordinate the tokenization/de-tokenization of payment credentials to optimize transaction routing flexibility.
• Nuisance Fee Avoidance and Interchange Optimization—automating the processes required to avoid and minimize card scheme fees (e.g., “misuse of authorization,” “floor limit” fees) or interchange downgrades.
• A/B Testing—Payments folks get the freedom to fail by trying out different payment methods or routes without investing a great deal of political or economic capital to get the necessary engineering.

When I write this, it’s December 2020. There’s a big fear that Strong Customer Authentication and 3D-Secure will lead to a dramatic dropoff in approval rates. I wonder what will happen with Transaction Risk Analysis in Europe and the 1-leg out routing strategies many companies are looking at leveraging in 2021 to achieve a frictionless flow. There are a few more strategies it would be suspect for me to mention. Regardless, none of that testing or dynamism is possible without a large dedicated engineering team or proper payments orchestration.

Assuming a dedicated engineering team, is there a telltale that it’s time for a company to consider moving from an all-in-one PSP solution to a payments orchestration architecture?

For me, the easiest rule of thumb is the following gate:

Does USD $100 million of transactions pass through your platform? Regardless of business model or whether that $100 million is gross revenue or earmarked for payouts, the economics just make too much sense at that point.

Market requirements, ticket size, and risk profile are also big factors that, for me, lower that $100 million price tag. Suppose a merchant needs access to an Indian wallet and the PSP doesn’t have it. In that case, the merchant will get another provider, so they may as well put in the proper infrastructure to grow without future headaches or PCI non-compliance.  For a merchant with a ticket size over €500, having the ability to save the transaction is already worth the premium by cascading. Why pay a %-based premium when it can be a flat fee? Transaction risk analysis just amplifies that fact even further. As for risk, Eaze and OnlyFans are two model use cases due to their business models since PSPs could choose to kill the merchant account at a moment’s notice.

It’s interesting to hear that you favor event driven implementations over real-time ledgers for financial tracking.  I’m curious if you could share an example of a system that you think used events particularly well?

The real-time ledgers I’m familiar with are in their nature event-driven architectures. They use finite state machines, dynamic acrylic graphs, or blockchains to enable the subledger functionality. The compelling value that a real-time ledger provides are:

• Split tender transactions across multiple methods
• The ability to refund or credit each funding instrument an exact amount per upstream business logic
• The ability to track revenue shares on a gross settlement basis rather than a net settlement basis
• Prequalify interchange for future reconciliation from the card brands settlement reports to the acquirers
• Financial exactitude

Those are some pretty sophisticated use cases with ROI that haven’t been well articulated to justify the investment.

Ultimately an event-driven architecture provides the foundations for payments folks to conduct granular analysis and triage. Payment transactions are already analyzed over periods of time. The way payments data objects have been built, just hasn’t always made that easy. Without an eventID to separate transaction states, users lose granularity for investigations which just adds time when conducting root cause analyses for bad authorizations or properly represent 2nd or 3rd chargebacks on a recurring transaction. Ultimately it shouldn’t matter if the analysis is being conducted in a dashboard portal or in a separate BI tool; means to slice and dice the data needs to be accessible. Using an eventID and performing duplicate checks or idempotency keys seems to be a generally understood means to solving for most of these requirements with a tolerable margin of error.

For those using a single PSP, are there any components of the payments orchestration layer you think should be prioritized?

Great question and one we bat around a lot because you’re ultimately asking: what components get me to MVP? And if a business decides to build their POL, that’s potentially as far as they’re ever going to go.

The connectors to PSP endpoints and payment methods are a commodity. Don’t get me wrong; there’s a lot of value in maintaining those connections. It’s what has driven the economic viability of the gateway market for two decades. But to perform and manage orchestration, it’s ultimately about having that configurable transaction routing UI tool. I’m not a fan of black box smart logic with no end-user tools to set the guard rails. Otherwise, we’re just back to needing engineers to perform maintenance work, which subverts the goals of payments orchestration. So, at a minimum, the configurable routing tool needs to be able to:

• manage MIDs for presentation,
• call the BIN file (a separate table vital for routing),
• dictate routing logic to the transaction handler,
• access the libraries of payment methods and payment flows,
• output the necessary data to monitoring tools for risk control.

I’m sure you can find others who will disagree with me for many reasons, but not because you can build a sufficient tool with less.

I think you’ve made a compelling case payment orchestration. Are there any resources you’d recommend for those wanting to learn more?

Shameless self-promotion time.

My partner, René and I, wrote a whitepaper on the business value for payments orchestration in 2019 without sponsorship from any provider. We simply thought the value proposition needed to be articulated and that it needed a name. It’s subservient to a larger argument, that payments are a strategic asset and need to be treated as such. You can find all those materials on our resources page: https://rpgc.com/resources/

We’ve also been looking at the players that position themselves as payment orchestration platforms and publish that report in conjunction with our partners Paladin Group in an annual Vendor Report. Many of our latest blog posts discuss how orchestration works in conjunction with other payments function responsibilities like reconciliation, payouts, and authentication.