Merchants face ever-expanding complexity for managing payments across geographies, channels, and use cases. Merchants want the ability to quickly adapt their payment infrastructure to embrace growth while delivering robust customer experiences. In parallel, payments technology is shifting into the cloud and opening and embedding into broader API ecosystems. As a result of both merchant demands and modern technical possibilities, a new model of payment services – orchestration, is thriving. As illustrated in Figure 1, payments orchestration introduces a many-to-many technical mindset with a product designed to ease the burden and increase the flexibility for merchants needing broad connectivity, rich data, and transaction flexibility. Within this article, we explore the rise of orchestration and discuss examples of orchestration providers and use cases.

FIGURE 1: Payments Orchestration vs. Traditional Siloed Payments

Source: Flagship market observations

Early Days of E-Commerce and the Emergence of Full-Service PSPs

In the early days of e-commerce (2000 - 2010), technical PSPs (or ‘gateways‘) were the prevailing product and operating model for payment enablement. PSPs were generally not the collectors and settlers of funds, but rather technical integrators between merchants and acquirers. This new breed of technical providers thrived in an environment in which traditional acquirers typically lacked a robust e-commerce front-end.

In the 2010-2020s, there was a broad shift towards full-stack, collecting PSPs (such as Stripe and Adyen) that could combine technical enablement with acquiring and alternative payments collecting, along with a suite of complementary services (fraud management, multi-currency, etc.). The collecting PSP model rapidly spread and today is the prevailing model for merchant payment services. The rise of collecting PSPs and the sunsetting (to some extent) of pure technical PSPs was driven by a number of forces:

1. One-stop Shop Convenience: Merchants appreciate the simplicity of using a single provider, having one point for technical integration, service, contracting, etc. This now includes enterprise merchants who prefer PSPs that can cover many needs.
2. M&A of PSPs: Merchant acquirers heavily engaged in buying PSPs to enhance gateway capabilities and technical connections.
3. Capabilities Expansion: Technical PSPs recognized the value of expanding across the payment acceptance value chain and grew their product sets to include payments collecting, which offered a more lucrative revenue pool than the technical services (i.e., earning ad-valorem fees versus small fees per API-call).
4. Payment Services Directives: In Europe, PSD opened the market for obtaining payment institution licenses, making licenses readily available with low barriers for entry to hundreds of technical PSPs.
5. Introduction of Payment Facilitation: Visa and Mastercard opened the floodgates to payment facilitation and allowed PSPs to onboard and underwrite sub-merchants on behalf of legacy providers, which further reduced the regulatory barriers to collecting models.

The Emergence and Growth of Payments Orchestration

The concept of a ‘one-stop shop‘ continues to be a winning concept within merchant payments. However, in practice, the ‘one-stop shop‘ is difficult for multi-national enterprise merchants to obtain. Geographic localization, payment inflows and outflow requirements, systems integration, reconciliation, risk management, compliance, and commerce use cases all introduce complexities that a single PSP struggles to solve. The result for merchants is a complex flywheel of multiple PSPs and value-added service providers that merchants must themselves integrate and manage.

We now see the emergence of PSPs (‘Payments Orchestrators‘) that are natively designed to simplify enterprise payments infrastructure by abstracting the complexities of managing many service providers. While still niche relative to the broader merchant payments market, these orchestrators are winning market share in North America and Europe. Figure 2 illustrates examples of payments orchestrators, many of whom are relatively new and small, but some of which are older business that have adapted to serve the demand for orchestration.

FIGURE 2: Select Payments Orchestrators

Source: Company websites and developer portals, LinkedIn

At their core, payments orchestrators enable smart routing which improves transaction success and sales conversion. Merchants are increasingly focused on optimizing conversion and supporting multiple options for processing improves results. Payments orchestrators also make switching volumes and PSPs easier, which enables the ongoing reduction of the costs arising from legacy acquirers / payments collectors.

Payments orchestrators also enable transaction abstraction, where transactions are augmented or manipulated to deliver specific use cases. For example, split payments and settlement (single pay-in to multiple sellers), partial payments (one transaction with multiple means of payments, vouchers, etc.), stand-alone authorizations or authentications. Fraud management is also optimized through a similar process by allowing merchants to aggregate multiple providers and data sources into a single decision engine.

Multinational merchants, who inevitably use many providers of payments and related services, have a clear need for centralized data. Payments orchestrators also aggregate data across providers and enable easy consumption of this data for various purposes by the merchant (risk decisioning, treasury management, marketplace support, reconciliation, etc.).

Payments orchestrators can also help merchants address complex regulatory compliance. For example, PSD2 regulations forced European marketplaces to either become licensed payment institutions or to outsource payment money flows to PSPs. Marketplaces are often multi-geographic, working with many acquirers and collecting PSPs. Payments orchestrators help to streamline the integration of seller (sub-merchant) KYC and management while still supporting many processors into a single point of managed seller payouts.

Payments orchestrators help to alleviate PCI compliance by removing sensitive data while greatly enhancing the flexibility the underlying tokens. Many traditional PSPs rely on proprietary tokens which are owned by the PSP, can only be processed by that PSP, and offer restrict the ability for merchants to change their infrastructure while maintaining the tokens. Orchestrators generally provide a much more flexible tokenization service (for example, build on V/MC ‘network ‘ tokens) that allows merchants to use the same token across many processors/collectors. Use of tokenization continues to spread for payments and other forms of data across merchant environments, so flexibility is prized.

Figure 4 (below) illustrates the different operating model focal points of traditional acquirers, technical PSPs, collecting PSPs, and payments orchestrators. While the market has moved towards full-service PSPs and more advanced in-house integrations, payments orchestrators have moved in the opposite direction. Orchestrators generally espouse collecting in favor of a dogmatic focus on technical enablement with a core value proposition centered around connectivity (to payments collectors and other), smart routing, transaction abstraction, and data aggregation.

Payments Orchestration Use Cases

Payments orchestration is most visible today in e-commerce, especially for multi-national merchants in digital verticals, but also relevant and expanding in the POS channel. Figure 3 illustrates how merchants use orchestration to simplify and enrich both e-commerce and POS commerce. As merchants expand their global footprints, the payments orchestration inputs (e.g., payment terminals and e-commerce platforms) and outputs (e.g., local PSPs and acquirers) increase while merchants benefit from having a single integration point. Beyond basic channel and geo enablement, examples of orchestration use cases include:

1. Omni-Channel Merchants: Multinational merchants supporting omni-channel commerce must support many payment methods, form factors, and means of interacting with consumers. Orchestrators help to recognize customers across channels and geos (regardless of the payments provider) and to enable complex transactional use cases such as combining an online booking in one country with a POS check-in in another country.
2. Marketplaces: Multinational marketplaces have some of the most complex set of payments requirements, supporting many buyers, many sellers, many geographies, and many transaction use cases. Orchestrators help marketplaces to support a single infrastructure for managing buyers and sellers across payments providers, for example, enabling a single pay-out infrastructure for all sellers, regardless of the geography, payment method, or payment service provider.
3. SaaS Providers Expanding Into Fintech: Software as a Service (‘SaaS’) providers are increasingly bundling payments to enrich their proposition and to expand their revenue base. Integrating payments across channels and geos presents the same challenges to SaaS providers as to merchants (if not more complex). Orchestrators can help to centralize technical integration into a broad array of payments partners, payment methods, and payments endpoints while also integrating complementary services such as tax-free shopping.
4. Acquirers and Financial Institutions: Traditional acquirers and banks also want to participate within commerce & payment ecosystems. Orchestration can provide them with a simplified means of integrating into a broad set of software and service providers. As we have witnessed with full services PSPs like Stripe and Adyen, a seamless onboarding process and connection point for ISVs / SaaS providers is a winning formula in the payment acceptance market. Payments orchestration could be the next evolution for acquirers and banks (particularly in the U.S.) looking to differentiate legacy gateway solution in favor of cloud-native, API-first technical connections.

FIGURE 3: e-Commerce and POS Orchestration Merchant Use Cases (illustrative)

Source: Flagship market observations

Payments Orchestrators vs. Technical PSPs

At a first glance, a payments orchestrator may look a lot like a traditional technical PSP: each has a fundamental purpose of connecting to acquirers and routing transactions; each is a tech-centric organization; and for each, the breadth of connectivity into acquirers and payment methods define the robustness of their service.

FIGURE 4: PSP Operating Models

Source: Flagship market observations

There are, however, a few key differences which set a payments orchestrator apart from a traditional technical PSPs (illustrated in Figure 4):

1. Orchestrators leverage modern tech stacks driven by REST APIs and are developer centric in everything that they do (rich documentation, support, etc.).
2. Orchestrators use fully cloud-based tech stacks, whereas technical PSPs often still rely on traditional on-prem data centers.
3. Orchestrators are built to add, test, update, and maintain connections, and are significantly more agile than others for constant build out of connectivity.
4. Orchestrators effectively deliver unbundled, agnostic services: data, transaction management, etc. can be delivered separately from processing itself whereas technical PSPs tend to offer a more limited, linear set of service options.
5. Orchestrators tend to have a global footprint, whereas technical PSPs are often domestically and regionally oriented.
6. Orchestrators can support hundreds of connections, while PSPs generally reach ‘only’ dozens.

In Summary

The ability to orchestrate payments and adjacent services across channels, geographies, and use cases via a single technical integration is a powerful value proposition for merchants. Orchestration specialists are rising to meet this demand and are being rewarded with rapid growth. Beyond the orchestration specialists, we expect the future of payments technology and propositions generally to be shaped by orchestration principles, which embrace the realities of complex ecosystems.

Please do not hesitate to contact Joel Van Arsdale at Joel@FlagshipAP.com or Rom Mascetti at Rom@FlagshipAP.com with comments or questions.