Merchant Risk Council Webinar: The Payments Ecosystem Beyond 2025
The Merchant Risk Council (MRC) hosts various events to connect payment decision-makers with each other and showcase expertise, brands, and best practices. In November of 2024, Basis Theory CEO Colin Luce was the featured speaker during an MRC webinar as part of MRC’s weekly Webinar on Wednesdays.
Luce explained what he’s calling “payments 3.0” for merchants and the new paradigm in payments, particularly B2B payments.
“We’ve reached full deconstruction of a single PSP,” Luce said. “Gone are the days of relying on just one. The new payments stacks are custom, distributed, and open by default.”
The presentation was just over 30 minutes long. Here are our takeaways:
Macro Industry Trends in Fintech & Payments
CL: When I say payments 3.0, what I mean is reaching full deconstruction of what a legacy PSP looks like. Relying on a single PSP is something most merchants and software platforms are moving away from. What we are seeing is a desire and actual implementation by merchants to build a custom payment stack from scratch. Distributed, custom, and fit for each unique business.
We’re sitting at this really interesting point in time where we’re in this technological cycle of bundling and unbundling. Today, these two concurrent but divergent trends are happening. On the B2C fintech application side, we are moving into the rebundling phase and the rise of the Super App. But for the past ten or so years, B2C fintech was about unbundling products and services from financial institutions. It was very siloed, and now we see this rebundling into a single application.
From a B2B fintech infrastructure perspective, a lot of the announcements are about unbundling of the payments stack and decoupling various services. Those trends are happening at the same time and what’s interesting is, there’s a new requirement for a faster, better way to think about data security, compliance, and rebundling at the application layer or within an organization.
Payments 3.0
CL: Despite this being an oversimplification of the payments world, it helps frame the discussion for payments 3.0 and this new paradigm.
In the early internet days, there was a primary banking institution that was set up for online payments. Merchants chose the PSP, signed a massive contract commitment and hoped for the best. There were trends happening, a shift to mobile, the emergence of marketplaces and ride hailing came into the world, these required a different approach to payments. Different services were needed domestically, compared to Europe or Latin America.
And now, with Payments 3.0, individual companies are going after every component of the payments stack. And this is where a merchant starts to build their own custom payments stack. It all starts with the vault, from there you can connect to different PSPs, fraud providers, data analytics, and orchestration platforms. You as a merchant now have the ability to pick and choose the best provider for each component of the payments stack. That’s what we are talking about with payments 3.0.
Lessons from Crypto & DeFI
CL: One of the biggest takeaways from this world is that, with the whole promise of blockchain and defi was about decentralization. But who was the biggest company to emerge? It was a centralized wallet service. And the reason for that, is that even in a decentralized world, centralization matters and is important.
We’d say that you need to go centralized to enable decentralization. The analogy isn’t perfect but there are a lot of parallels that can be drawn. This nuanced perspective on the importance of looking at a decentralized world, from a centralized perspective, that’s going to be really important. And the nuances to that, think about this from a custodial perspective. You don’t want to store PANs on your own servers with all the complexities of PCI compliance, legal and security concerns that come from that.
But you want to, at any point, be able to have an escape hatch where, and going back to the crypto example, you may have that centralized wallet service to hold crypto but at any point you can eject out and interact with a specific blockchain. In this world, being able to help store these credentials, but then being able to branch out and connect with a PSP or other third party, that’s the right balance of control, security, compliance, and ownership.
Token Management for Recurring Payments
CL: As we start to see alternative payment methods be supported in a “pull” context, what we will see is that anything that can be stored and enabled for a recurring payment, can be tokenized. So you as a merchant or you as a platform are going to have a more comprehensive, intentional approach to token management and recurring payments. There’s a lot of desire from merchants for the new rails like FedNow or RTP (Real Time Payments) to support pull functionality, as opposed to push functionality in the United States.
There have also been multiple attempts by either the PSPs or the networks to build the one token to rule them all—and what we are starting to find is taking a comprehensive approach. There is no magic bullet, it’s that you need to leverage all of these as tools. Whether it’s a universal token, merchant specific token, but the base token can be the PAN and you build this parent-child relationship between the PAN and associating that with multiple PSP tokens. Once you have all of those associations and reconciliations, you are able to much more intelligently think about, for this individual transaction, on this time of day, from this geo with this user, I’m either pushing a raw PAN through my vault to a PSP. Or I’m using a PSP directly with my integration to the PSP. Or I’m routing a network token to a PSP.
This allows you to get a lot more granular in how you think about payment optimization. But the macro trends being around more payment methods supporting recurring use-cases will require a more intentional approach to token management.
Payload Optimization
CL: As we think about the “so what” aspect of this, whether it’s payment optimization, payment orchestration, or this broad trend of building a custom stack. It all comes down to what is the impact to your business, and to your customers? What gets lost in the conversation is that there is an assumption that payment optimization or payment orchestration is about least cost routing.
And what we see is that is not the case. Cost is always important. But in this particular context, we tend to see it be the third or fourth most important thing. Ultimately, the number one thing we see folks solve for here is conversion, authorization, growth, and experience. Then, you optimize for cost.
A great part of this decoupling is enabling merchants to be more truly data-driven. All other aspects of the business are data-driven, except for business. This can be intelligently driven by data, and we are starting to see that. Because if you take this approach, you can do basic routing with little effort. Every time a customer comes in and inputs their credit card, on the back end you should see in real-time all of the associated BIN data with that card. Plus, geographic data to the user, should all be tied so that for this transaction, you can dynamically determine how you route that payment.
One of the most interesting strategies for this type of routing has been, deciding where to route the transaction purely based on who will give me a frictionless 3DS flow. It’s important for merchants but how can we optimize for a frictionless 3DS flow. That’s been an interesting way to think about this.
In this new world where no two payment stacks are the same, I think that is a result of no two merchants being the same. The uniqueness required to thrive in this global world is important to continue pulling through. In order to be competitive on a global scale, you need to be truly unique in offering something nobody else is offering. That could be products, services, experience, whatever. And what that means is it becomes difficult to rely on a one-size-fits-all all, rigid integration into any number of PSPs.
Payload optimization is a very technical way to think about this. Merchants say they need to go multi-processor, but I push them to say, have you fully optimized your current PSP? Many times, that type of collaboration can have meaningful results. An example would be, the current PSP sees your auth rates and they think they can get them up by a certain amount of basis points if we can send an additional data field.
In particular, in your core markets where the vast majority of volume is happening, it’s really important and arguably critical to own your integrations. This will help you strategically partner with your PSP, optimize your payload, integration, and dynamically adopt.