The Technical Face of Payments as a Service
How can technology make payment processing easier? Let me give you 4 ways, and a litmus test.
Sometimes, the change is so expensive it no longer makes business sense.
One massive headache for companies is often the mismatch between the evolution of the business needs and the maintenance and operating costs derived from enabling those needs. Customers demand something, but the implementation is so expensive, it doesn’t make sense to pursue it.
This is what technical debt is all about.
When choosing a PSP, there’s always a decision maker who brings up the “buy vs build” dilemma. This is because payments are no longer something that can be handled by paper pushers alone. It demands a modicum of technical expertise, and to choose whether to build that expertise in-house or outsource it to an external company is one critical aspect of choosing a PSP.
What are the equivalent of MoRs and PayFacs from the technical point of view?
Well, we may say they are Gateways and Orchestrators. But the answer, just like it was in the previous article, isn’t as clear cut as it looks like.
This is The Payments Engineer Playbook. In this 2 part series, we’re setting the record straight. There is a lot of confusion about what PSPs really are, and I’m sick and tired of people on LinkedIn reposting infograms that are plainly wrong.
Last week, we discussed what Payment Service Providers (PSPs) are from the point of view of regulation. In this second part, we’re looking at how PSPs are distributed over the spectrum of technology.
Let’s dive in.
Your convenience is my complexity
A PSP is a gateway when its key differentiator isn’t technical.
There are many, many providers out there that offer the absolute minimum required for you to use it. Their website is clunky, full of meaningless images of people in suits shaking hands, or holding a credit card in front of their laptop. Their docs is a PDF, not available online. And they tend to support card payments only.
This doesn’t cut it anymore.
Do you always pay with card? A lot of people don’t. It is an insecure protocol, after all. But, most importantly, it is not as convenient as reading a QR from your phone, or staring at your screen for a FaceID test.
For a growing chunk of the population, using non-card and irreverently local payment methods (PIX, UPI, Blik, iDEAL, …) is the preferred option. In other words: if you’re only accepting card payments, you’re missing out.
This is where orchestration comes in.
We’ve talked before about the 4 categories on which every payment method, card or non-card, can be in.
But the truth is that no matter how consistent the payment system’s design is, you’re going to have to build integrations for all those payment methods.
Take, for example, PIX. Brazil is a country where card payments is extremely fragmented and complex. Alongside Visa and Mastercard, a significant share of the cards are issued by local schemes like ELO and Hipercard. But Brazil is also a country where card penetration and bank account ownership has historically been pretty low, compared to the EU or the US.
PIX filled the void by allowing everyone to send and accept payments, even those without recourse to a credit card.
If you’re doing business in Brazil, accepting payments is a daunting task:
You have to accept card payments from multiple schemes (not just Visa and Mastercard)
You have to incorporate PIX payments into the mix, or admit the likelihood that the customer won’t convert right at the checkout page
You have to reconcile payments from both kinds of payment methods
And only then you can do precisely what your business is really about
Most companies, especially those that are small, would rather do only 4., and leave 1., 2., and 3. to a specialized Payments as a Service firm. Not only because the burden of regulation is already too much, but also because keeping the payments technology stack up to date is already enough work for a medium size company.
So let me present you 4 ways in which Payments as a Service companies can help businesses reduce the technological footprint and maintenance burden of processing payments: Localized, Composable, Simplicity and Data Orchestration.
Localized Orchestration
At the very minimum, an Orchestrator must give you a single API to accept payments in different payment methods.
That’s probably why most orchestrators find themselves in a race to integrate as many payment methods as possible, from all regions on Earth, and for all customers.
This is unsustainable. Eventually, “all-out” orchestration platforms are stretching themselves too thin, because very few companies are offering hundreds of payment methods for a global audience.
If anything, the trend is towards localized expertise. dLocal is already devouring the market for orchestration in Latin America, and I wouldn’t be surprised to see orchestrators in Europe (Ixopay), North America (Spreedly) , Africa (Kora) or Asia (Juspay) narrow down or even specialize in their regions.
Composable Orchestration
A parallel trend in orchestration is giving businesses the ability to integrate with the tools they want, but in an way that makes holistic processes (like reconciliation) way easier and less manual.
Take, for instance, tokenization.
Believe me: you don’t want to tokenize cards in-house.
What you want is to have some third party handling this for you, just like you have Google or Microsoft handle authentication via their OAuth system. Doing this in-house is just too much.
Which means that you have two choices:
Use the tokenization services of your PSP
Stitch together your tokenization of choice with your existing PSP
The first one is bad, because you don’t want all your payment needs running through a single platform that could suddenly raise prices on you.
But the second is complex. Very complex.
And that’s where Composable Orchestration comes in. You integrate with Basis Theory or VGS, and you can still use your payment provider without having to commit to their tokenization services, opening the door to valid retries across providers, who don’t recognize tokens issued by other PSPs but do allow for network tokens to be used on their platforms.
Simplicity Orchestration
You’re using a single PSP already, so why do anything?
That’s the mindset many PSP that aren’t properly Orchestrators are counting on. Businesses unwillingness to build have created a multi-million dollar market.
On the last Sessions conference, Stripe announced an Orchestration product.
If you work for a company that calls itself an Orchestrator, the demo was, to put it mildly, risible. Stripe is no real competition to the established players.
But that isn’t the end game.
Stripe will not capture any of the orchestration industry’s current market share.
Just like Instagram releasing Stories to prevent users from moving to Snapchat, Stripe is incorporating a good enough router into its stack, so that their current users aren’t tempted to rip out its API.
That is the Simplicity Orchestration: sometimes, what you want isn’t to conquer the world, but to move on with your life.
Data Orchestration
Statistics are only meaningful when you have enough data.
And fraudulent data is especially difficult to come by. For payment engineers, this might sound ridiculous, but for the wider population, fraud is a very significant event in their lives.
Fraud, for most, is traumatic. Which speaks to its rarity.
As a result, being able to analyze fraud in a way that is statistically significant is difficult at very low scale. What you need is the insights that come from pooling transactions from more companies, so that the results can be actionable.
And that’s where Orchestration may come handy.
Data Orchestration helps small businesess gather the kind of insights that are available beyond the scale their currently in, with the appropriate anonymization of the data gathered. This is not only technically difficult, but also a regulatory nightmare if you don’t know what you’re doing.
For that reason, this is incredibly useful for small businesses, but not so for big ones. Advances in AI have made this aspect of orchestration less interesting for large scale companies, which means that most Data Orchestrators are focused on the long tail of small companies, together with localized expertise.
Orchestration’s Litmus Test
Localized, Composable, Simplicity and Data are the technical faces of Payment as a Service.
However, the litmus test for a PSP to be considered an orchestration platform is having the ability to say, genuinely, “there’s someone else better at what we do than us”.
Orchestration is a trust-based business. The key features aren’t really technical, or regulatory.
The key features are transparency and honesty. “Will it remain neutral?” and “who will pay for the revenue directed to other PSPs?” are key questions.
If you want to learn more about orchestration, Simon Skinner and Samantha Gordon from Glenbrook Partners put together a three part series on Payment Orchestration last year that is well worth reading.
Or you can read two articles from The Playbook on Orchestration, and be on your way.
If you liked this article, make sure you share it with someone who might benefit, or bookmark it as future reference.
This has been The Payments Engineer Playbook. I’ll see you next week.