The Need for a Payments-Orchestration Panel

Payment complexity, combined with a scarcity of engineering talent, makes a new functionality layer all the more urgent for merchants’ payment flows.

“Orchestration” refers to software platforms and services that automate … business processes to help streamline and simplify operations management. By automating the configuration, management, and interoperability of disparate computer systems, applications, and services, orchestration can free IT from the burden of managing a variety of mission-critical but often complex tasks and processes.

–Forrest Stroud, Webopedia

The payments “stack” is deceptively simple: An authorization process is followed by a settlement process, with ancillary- reporting and exception-handling processes. Upon closer inspection, the deceptiveness of this simplicity becomes apparent.

There are many functions, sub-functions, components, and elements required to accept payments in the card-not-present (CNP) space. For merchants, authorizations in particular have become very complicated due to the growth of cross-border sales, the need to improve approval rates, and the desire to reduce operational costs while remaining compliant with card schemes’ rules and minimizing fraud exposures.

Many CNP merchants have built and successfully operate their own authorization gateways. Others have leveraged provider-agnostic payment gateways. Most of these environments were built to solve for immediate needs.

Among our clients, we find a staggering amount of technical debt that prevents payment operations from rapidly deploying services or optimizations to capitalize on potential market opportunities. These deficiencies will continue to exist as long as there is demand to support additional requirements (for example, “honor all wallets,” network tokens, and so on).

The dearth of available payments-product managers and engineers makes the burden of maintaining platform functionality an ever-growing problem.

At this point, we are often asked, “Why not just use a payment-service provider (PSP) that manages all of this functionality for me?” For many merchants, this is a good solution as those merchants do not need to solve for the complexity of managing several different providers (and token types) across several different sales channels, currencies, geographies, product types, and billing arrangements with their own different partner-commission structures.

That is to say nothing about supporting multi-acquiring redundancies in each strategic market, as has been highlighted by the rising number of acquirer outages.

For a merchant to truly control its own environment, its service- level agreements, and most important, its data, a new functionality layer is required: the payments- orchestration panel, or POP.

Flexible Mechanisms

As its name implies, the POP layer orchestrates all of the activities that could be associated with processing a transaction authorization to optimize the value of every transaction.

The consolidation of all the logic currently employed to handle authorizations with a number of proposed features into this single functionality layer stands in contrast to the fragmented functionality currently in the merchant marketplace across order-entry systems, billing engines, and fulfillment platforms.

The functionality of a well-architected POP allows merchants to turn payments into a truly valuable asset for the entire company.

For example, global merchants need connectivity to multiple acquirers, processors, and payment service providers (PSPs) around the world. In many cases, the connectivity requirement goes beyond cards to include other payment forms such as bank transfers or cash payments. Traditionally, each new payment method requires a new integration effort, placing demand on merchants’ scarce technical resources.

Through a single application programming interface, by contrast, POPs would have connectivity to lots of endpoints—acquirers, processors, PSPs, other gateways, banks and clearing houses, as well as cash-accepting schemes (for example, OXXO in Mexico).

Because it is best practice to denominate a transaction in the buyer’s currency, POPs must have flexible mechanisms to handle transactions in currencies other than the merchant’s native settlement currency. This may mean an interface to a foreign-exchange engine and a tax engine to price transactions at checkout time, if that is the pricing option that merchants may have chosen.

Properly engineered POPs will track these rates for every transaction so that, in the case of refunds, POPs can ensure buyers get the same amount they paid, without burdening accounting systems with these calculations.

Risk Management

POPs can also help merchants lower their operational costs by minimizing exposure and expenses related to the Payment Card Industry data- security standard. They would do this by providing a fully certified PCI/DSS level 1 token vault or be able to interface to an equally certified third-party token vault.

If offering its own token vault, the POP would support PCI tokens and EMVCo payment tokens, payment-account reference (PAR) numbers, API-based de-tokenization tools, and multiple token formats. Regardless of each disparate token format, a POP would pass a standardized token format back to the merchant. At a minimum, the POP must be able to pass the first six and last four digits back to merchants.

POPs could also offer their own management tool for risk and fraud, or—the most likely circumstance—interface to third-party engines. POPs must orchestrate the routing of transactions based on the score or response code from the fraud engine.

Because risk-management engines reply with different codes, and because merchants will likely want different routing options, POPs must offer flexible tools to allow merchants to create their own routing-orchestration rules, allowing changes to these rules without re­quiring any software development.

Transaction Routing

The most important requirement for POPs is the ability to smartly route transactions. This label encompasses multiple capabilities. Let’s explore some of these.

Some large merchants have implemented dual-acquirer strategies to immediately switch traffic between acquirers when one of them has an outage. POPs, therefore, must be able to detect availability so they can immediately and automatically re-route transactions to the available acquirer.

Further, POPs could also act as load balancers by monitoring acquirers’ response times and shifting volume to the faster acquirer to provide good online response times and prevent checkout abandonment.

By leveraging smart routing, some of our clients have saved between 20% and 30% of “do not honor” declined transactions when they are retried via an alternative acquirer. For large merchants, this can represent an additional 1% to 3% in top-line sales.

This benefit alone would justify an investment in the POP. Smart routing leverages historical information to route authorizations based on bank-identification numbers, time of day, day of week, transaction types, cost, and other factors to improve approval rates or to lower costs.

Well-thought-out POPs can deliver other financial benefits, such as lower operational costs due to reduced PCI/DSS compliance burdens, least-cost routing (for tiered pricing or credit vs. PINless debit), and reduced development costs and faster time to market when introducing a new payment method or entering a new geography.

Thus, POPs must offer flexible tools to allow merchants to develop their own routing decision trees and allow changes to these routing rules without any software development required.

Presently, state-of-the-art tools require merchants to do these analytics offline. Looking down the road, POPs themselves could be equipped with machine-learning technology to make these decisions in real time.

Rules Management

POPs can also be engineered to help merchants support the many new rules that the card schemes (for example, Visa and Mastercard) have recently introduced to the authorization process.

For example, since the rule regarding card verification replacing $1 authorizations has not been consistently implemented globally, merchants need to know when to do one or the other. This is important because issuers might decline a card verification when they only support a $1 authorization, or vice versa.

POPs with access to such information can optimize this process without burdening merchants’ systems with this logic, while at the same time optimizing approvals for new customers.

Similarly, card schemes have introduced penalties for authorizations not performed according to their rules. Examples of these penalties include Visa’s Misuse of Authorization Fee, Zero Floor Limit Fee, and Transaction Integrity Fee, as well as Mastercard’s Processing Integrity Fees in all their different varieties.

Automated exception processing using a POP should be technologically easy by automatically initiating reversals when authorizations are about to expire or initiating authorizations for settled transactions when a previous authorization cannot be identified.

Upcoming Visa and Mastercard regulations mandate that all merchants in the U.S. and Canada “must process a purchase return authorization for each return” (that is, a credit authorization for each refund). Once again, POPs should be able to initiate these authorizations without requiring any changes to merchants’ systems that were built to issue only a refund and not to do prior authorizations.

The same logic can be employed to justify POPs supporting other requirements imposed by the card schemes, such Credentials on File, 3-D Secure 2.0, or other Secure Customer Authentication protocols.

Reporting

Because the POP passes transaction data to acquirers, PSPs, banks, and other entities, it should also be able to consume that data to generate consolidated reports. In addition, that data can also feed panels and dashboards that merchants can use to manage the business of payments in real time.

Marketplace platforms or payment facilitators should also enjoy the POP’s ability to segment transaction reporting by business unit or sub-merchant on their platforms.

There are many other capabilities that POPs can provide to ease the workload of technical staff who support order entry, billing, and fulfillment systems.

Build Or Buy?

If merchants agree that they are better off consolidating this functionality into a single POP layer, the question becomes whether to build or buy.

There are many merchants with the technical capability and payments-industry know-how to build a payments-orchestration panel. We plan to release a white paper in late spring detailing all of the requirements for an optimized authorization environment based on inputs and requirements we have been hearing about from many merchants.

For those merchants interested in buying, there are a few things to consider. There are a number of PSPs that support some of the routing capabilities described in this article. In essence, these PSPs manage their own POPs, switches, or gateways.

But, to be clear, a PSP acquires the transaction or assumes financial ownership of the transaction (that is, the PSP is paying the merchant). A POP does not. The POP is merely the technological layer that enables connectivity.

Some PSPs have great reach in terms of connectivity and alternative-payments coverage. However, such vendors charge merchants for the success of “saved” declines, eroding some of the economic benefits from a POP.

Further, these PSPs might be using the same acquirers that merchants use, defeating the fail-safe purpose of multi-acquirer strategies. Still, a PSP is a good alternative for merchants that have stable connectivity requirements and authorization approval rates.

On the other hand, there are a number of vendors that offer connectivity and tools to orchestrate transaction workflows without assuming financial responsibility for the transaction. Sometimes these vendors are called switches or payment gateways.

RPGC Group, under the sponsorship of the Merchant Risk Council (MRC), has recently surveyed the landscape for these vendors. The Paladin Payment Systems Vendor Report is available through the MRC and highlights the capabilities of selected vendors in the space.

To be clear, none of the vendors in the report meet all of the requirements envisioned for a full-fledged payment-orchestration panel. But we believe that a few of them are good candidates to evolve into a true POP as described here. Merchants will find our report useful to identify capabilities available from the different vendors.

Whether built or bought, the payment-orchestration panel is a crucial architecture component for any forward-looking merchant.

—René Pelegero is principal and founder of Retail Payments Global Consulting Group LLC, Kirkland, Wash.