Paving the way for payment innovation

Looking at what’s next in payments

By Filip Dames & Max Brückner

Innovation across the payments stack has been a massive value driver for a host of disruptive companies in recent years. A number of fintechs have already fundamentally changed the way global companies — be it B2B or consumer — process and organize transactions. Stripe, Adyen, Checkout.com, Primer, PPRO, and Spreedly are a few obvious ones that come to mind.

But, today, the industry is facing fresh calls to take payments even further and, in turn, better enable the next generation of emerging business models and respond to new complexities. Some of these complexities include:

So, let’s jump in. Looking at a few main areas — like payment service providers and payment orchestration — we break down why payments, in particular, is an area ripe for more disruption in the larger fintech landscape.

PSPs are eating the payments world

Twenty years ago, one of today’s largest payment service providers, PayPal, went public via IPO with stocks climbing up 50% on its first day of trading. Today, the company’s market cap is around $100 billion, making it one of the five largest publicly traded fintech companies in the US. Fast forward eight years later, the Collison brothers built Stripe. Now, the company’s value is anywhere between $74 billion to $95 billion, depending on the valuation standards applied. Another prominent PSP that evolved roughly parallel to Stripe is not only one of the biggest Dutch but also one of the greatest European tech success stories, Adyen. Adyen has since IPO’d and holds a current market cap of around €40 billion.

No one could have anticipated twenty years ago exactly how much value these e-commerce enablers would create. But shifting from market cap to actual payments volume, these three players only partially illustrate the worth that has been created within the digital payment infrastructure. Adyen, PayPal, and Stripe alone processed a payment volume of ~$2.4 trillion in 20216, 7, 8 representing one slice of the overall payment processing space. Competitors like Mollie, Checkout.com, Klarna, and others are just some others in this shark tank, all with slightly different approaches and customer focuses.

So, what is a PSP’s main job? At its core, PSPs help a company’s customers accept online payments and ensure customers’ money gets from A to B. But, in reality, it’s not so simple anymore.

Looking at Stripe and Adyen, what exactly is in it for their customers? Stripe operates on unseen product velocity finetuning its services with outstanding platform product approaches, such as Stripe Connect or Stripe Atlas. Adyen serves its customers with its own processing services or partners all around the globe. These aspects shorten new businesses’ time-to-market, allow customers to grow into the product suite, and help companies choose a payment service provider with which they could potentially scale globally.

Long story short, PSPs now go well beyond A-to-B transactions. They’re now a whole product suite and it remains to be seen if they’ll go after embedded finance offerings which would then truly make the definition we know as PSPs outdated.

Aligned with their product depth and strength, PSP giants want their customers to only use their suite of services and not be served in any way by competitors. This has had detrimental effects on customers using additional finance products, such as modules of PSPs not harmonizing on a data layer logic with outside services. Data inputs, however, are relevant for a customer’s backend when operating with varying services. For example, a Stripe token vault helping to track the payment to a single customer does not match Adyen’s token vault logic. This scenario can occur if customers want to operate with different PSPs in different geographies but have the same data warehousing setups and backends across countries. Those companies can either use only one PSP or, in case they want to work with more than one player, need to find internal technical workarounds to harmonize incoming dataflows. This, obviously, extracts focus time away from product and development teams on the core business.

Orchestration and greater need for flexibility

Other players like Primer, PPRO, or Spreedly are building their businesses on top of a different narrative: putting payment processes within product focus plus adding customer-fronting services. Such orchestration services typically sit on top of PSPs or other payment services and help their customers easily integrate a broad range of payment-related services into their products. Their offerings allow product teams to seamlessly integrate various external payment services — such as payment processors, payment methods, open banking providers, accounting services, and more — and offer payment-related add-on services like loyalty programs and return processes.

This narrative plays into increasing customer demand for more flexibility and to use of various rails of providers. Quick commerce businesses, for example, have great interest in rerouting payments within checkout processes in case of single processing declines with one provider. This is to ensure that their promise of ultra fast deliveries and the related consumer wish to order, pay, and receive goods within minutes. The risk of churn should not lie within the hands of only one external payment processing provider.

Orchestration approaches, however, typically face two main challenges. First, their services still face complications when serving complex vertical business models involving various stakeholders along payment streams. Second, there is still an existing lack of services for core payment infrastructure demands such as escrow accounts and FX amongst these providers. The latter would require licenses and complex integration into external services within the orchestrator’s network. The former is currently tackled by new players such as Payrails or Payaut who are focusing on creating seamless operating systems for very specific business models with complex orchestration streams among involved stakeholders and customers’ backends.

If a company decides to go with the services of a payment orchestration company, they obviously need to pay for such services. This means two times the cost: for the orchestrator and (indirectly) for the underlying payment services such as PSPs, KYC, etc. Using orchestration services can also prevent them from enjoying volume pricing with large PSPs or other payment services. The cost issue can also be observed within “embedded fintech” demonstrating a counterintuitive effect: using services adds additional cost to the users’ P&L while the customer’s intention often is to tap into new TAM for increasing own margins.

In addition to that, there is a trend that companies want to have more flexibility to maintain the actual code of an underlying service (ex: with a PSP) and pack those services with very specific and individual features built in-house. This granular customization is simply not possible with most mere payment orchestration services.

Risk of applying for licenses

The caveat with features built in-house is that you might run into the risk of offering services yourself that demand complex regulatory licensing processes.

There is by now a broad field of necessary licenses that companies have to apply for if they want to build and ultimately offer payment services in-house. The most prominent one with the largest scope of application is the EMI license. An EMI has two major benefits if you obtain it:

• You may issue and redeem electronic money
• You can provide a wide range of payment services such as payment transactions in the form of direct debits, credit transfers, and through payment cards

However, depending on a company’s strategy and product feature-set there are other forms of licenses allowing it to operate payment-related services. Still, as applications for licenses are cumbersome and complex processes, most companies shy away from obtaining these and are willing to pay for external providers shielding them from regulatory burdens.

A famous example of a payment service provider shielding its customers from regulation is one of Stripe’s answers to PSD2, Stripe Connect. In a standard marketplace setup where the marketplace is a mere intermediary without selling a product itself, receiving payments that are owed to sellers hence storing them before a payout occurs requires a payment license. Stripe Connect takes that burden of the marketplace by collecting and facilitating on behalf of the marketplace, thus allowing its customers seamlessly facilitate payments indirectly via their platforms but being shielded from the requirement of obtaining payment licenses.

What’s next?

There are several problems with existing payment service offerings and payment-related software.

• First, PSPs have something close to product monopolies not willing to harmonize their data input with other players for their customers’ backends.
• Second, payment orchestration companies and other embedded fintech offerings add additional costs to their customer’s P&L (potentially)
• Thirdly, payment orchestration companies add flexibility to product setups but these flexibilities do not yet go all the way.
• Lastly, companies willing to use regulated services without someone shielding them from regulatory burdens or building payment services in-house subject to licensing need to go through cumbersome licensing processes with regulators.

So, what’s next?

One potential answer could be to modularize things by breaking up PSP monoliths. Customers could choose to only pick one or the other service from such a modularized provider that is ready to be combined with competing offerings from other PSPs. Such an offering needs to be added by an additional software layer that is converting incoming payment relevant data from other providers into the same warehousing data logic used by such modularized PSP. Customers are shielded from regulatory burdens, decrease operational costs for using both PSPs and orchestration companies, and would have harmonized data digestible for their tech backends.

Another way to go could be to offer a fairly complex infrastructural service: regulatory-shield-as-a-service. This is based on the following idea. A company could build a holistic platform that can connect to all relevant payment (related) providers (orchestrators, PSPs, embedded fintech plays, lending, KYC, BaaS, etc). The platform needs to harmonize all incoming data and make them digestible for backends and warehouses without further need of building data cleaning layers in-house. If such a platform was to obtain a broad payment service license it could have similar effects as Stripe Connect but with a broader variety of usable external services. Still, such a proposition would not yet address the problem of additional cost for their users. This could be mitigated over time by putting price pressure on external providers with the leverage of re-routing demand to a different supplier available under such a regulatory umbrella.

These are exciting times for payments. A lot of changes are potentially in store. The next phase will, we hope, bring new payment products that are much more tailored to the needs of new and evolving business models. At the same time, we are confident that payment products and technologies will continue to be a massive value driver for all sorts of companies.