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.
Keep reading with a 7-day free trial
Subscribe to The Payments Engineer Playbook to keep reading this post and get 7 days of free access to the full post archives.