The merchants need for payments orchestration

For merchants, payments do not exist for their own sake but to support their business goals. The payment itself is an intimate moment between the buyer and seller that needs to be executed in a frictionless way, with safety, and with accuracy. Otherwise, the merchant risks losing the purchase; or worse, the customer.

Moreover, merchants do not add new payment methods for their own sake, but to support market growth. While cards are popular in the US and Commonwealth countries, bank transfers are the preferred method of payment throughout Europe (in one flavour or another). ‘Push’ payments such as Boletos in Brazil or inbound cash payments accepted at convenience stores in Japan are very popular. And demand continues to grow for e-wallets (eg PayPal, AliPay, Apple Pay, Google Pay) and instalments (eg Affirm or Klarna).

But even when accepting card payments, there are challenges. The introduction of chip cards in the US has caused fraud to move from the card present environment to the card not present (CNP) environment. Because of this, many card issuers have tightened their authorisation criteria, which, in turn, has increased the number of declines, translated into the loss of hundreds of billions of dollars. Upsetting good customers because of card declines increases friction and is a good way to also losing the client’s purchase.

So we work from this premise: Customers need to be offered the ability to use the payment methods and currencies they want and when they pay, the authorisation needs to succeed. Not meeting this premise means there has been an undercapitalisation of the efforts from marketing, operations, sales, product, engineering and finance

Sample Orchestration Layer Architecture for the US Merchant

Why can’t a single Payment Service Provider (PSP) service all of a merchant’s needs? To support local payment methods and maximise approval rates, merchants need to connect to local PSPs. But some PSPs will not connect to other PSPs for competitive reasons. Retry logic varies between every PSP, and in many cases, the generic logic may not be optimised for a merchant’s specific business. Plus, with the growing number of publicised PSP outages and latency spikes, no single PSP can provide every desired payment method, currency or can maximise approval rates in every geography.
In order to manage such an environment, merchants need their own Payments Orchestration Layer that allows non-engineers to:

Easily add or subtract payment methods per business case;

Setup and customise transaction workflows;

Reconcile transaction information across multiple providers.

The connectors (payment methods, acquirers/PSPs, risk management services etc.) are actually commodities that can be deployed in 2–6 weeks by an experienced payments engineering team. The current industry gap resides in merchants lacking the non-coder tools to easily orchestrate these connectors as demonstrated in Figure 2.

Sample Orchestration Layer Transaction Flow

The Payment Orchestration Layer’s most important function is the workflow management of transactions. If each box in Figure 2 represents a microservice, then the layer needs to provide the tools to arrange these services in a manner best suited to the merchant’s needs. The Layer’s value is in being flexible enough to accommodate all of the different payment flows (pull or push, batch or real-time, instalment or anticipation etc.) without requiring major repair to the platform.

The Layer provides routing and retry logic that interacts with token vaults, BIN tables, risk management, and foreign exchange systems, while remaining compliant with the many card scheme regulations (eg reversals, credit authorisations etc). Plus, the tools should be able to allow merchants to easily activate or deactivate payment methods by business case or business unit.

To be clear, some of this functionality is currently available within specific PSP environments, but because a PSP assumes financial ownership of a transaction, they are not incentivised to provide merchants the necessary tools to orchestrate transactions outside of that specific PSP environment. Merchants with deep product and engineering resources have been able to build their own layers, but that strategy isn’t viable for most merchants. The table below lists the functionality, tools and reporting that enterprise merchants need to sufficiently manage every cent of revenue.

Given that there are few locations within a merchant’s stack where all transactions pass through, a layer that reports on all providers and fees that pass through its system saves merchants from manual time-consuming reconciliation efforts. A Payments Orchestration Layer also allows merchants to conduct A/B tests quickly without impacting reconciliation.

Good payments orchestration tools help business users to penetrate new markets and pursue growth initiatives otherwise left behind. Payments becomes an asset when merchants can quickly deploy new payment methods and determine the business impact to best service strategic markets with minimal demand on their scarce engineering resources.

This editorial was first published in our Payment Methods Report 2019 – Innovations in the Way We Pay, which provides a comprehensive overview of the up-to-the-minute trends, updates, and innovations in the payments space worldwide, depicting the key developments in the way people pay.

About René Pelegero

René was the first payments person at Amazon.com, growing operations to 160 countries. At PayPal, he managed industry relations, and created the PayPal payments education curriculum. He directs consulting efforts for leading merchants such as Google, Upwork, Priceline.com, and T-Mobile.

About Retail Payments Global Consulting Group

Retail Payments Global Consulting Group provides merchants advisory services in payments strategy, education, RFP management, and architecture design for functionality. RPGC Group believes that merchants need to retain control of their payments data in order to fully support their business objectives.