In This New Era of Software-Led Payments, Where Do Banks and Processors Fit In?

By Michael Bradley, Senior Vice President of Growth, Infinicept

By now, it’s clear that we’ve entered a new era, where merchants are increasingly accepting payments through their software and technology providers. This new age of embedded payments is a massive $75 billion opportunity; embedding payments offers software providers new revenue streams and a host of other benefits.

In contrast, the often tech-stagnant trifecta model of yesterday – ISO / processor / acquiring bank – is under threat in the world of merchant processing.

It’s not surprising that there is a lot of talk about how the shift to software providers is replacing the traditional approaches to payments. Here at Infinicept, we’ve posed the question, “are ISOs dead?” ourselves. Look carefully and you’ll see that the more progressive and innovative ISOs have themselves become more like software companies; those less inclined or able to adapt face a difficult future.

So, what does this evolutionary change mean for acquirer banks and processors? Do legacy acquirer banks and processors risk irrelevance? Or at best, do they face long-term marginalization?

Before we write the obituary of these traditional merchant services stakeholders, let’s dig a little deeper into how the merchant services model has changed and what that really means.

The fundamental axiom at the heart of all this is that the needs of merchants are changing dramatically. And this changes how merchant services are sold and delivered. Merchants – from small retailer to global omnichannel organization – are beholden to software platforms that run their day-to-day operations. And yes, payments are now being delivered through these software platforms.

This new model means that a few new principles apply to payments acceptance, no matter who is dealing directly with the merchant:

1. Disjointed and clunky customer experiences are no longer defensible. Merchants have options, and their number one focus is a streamlined experience for their customers.
2. This means payments have to be in context. There’s no longer any reason to treat payments as separate from other business processes.
3. And providers need a tech stack to interface with those in-context expectations. Today’s payments enablers have to have a tech-forward approach to the market.

But tech-forwardness and integration of the payments value chain does not necessarily mean that traditional providers do not have a role to play. On the contrary, the shift to software-led payments opens significant, game-changing opportunities for banks and processors as well.

With these expectations, here’s what banks and processors can – and need to – do:

1. Leverage your core processing and regulatory infrastructure assets for merchant services, but with a design that supports a continuum of risk management in exchange for economics.
2. Build go-to-market (GTM) programs around three principal software-led payment models:
   • Payfac® lite (aka managed Payfac or Payfac-as-a-Service)
   • Shared risk model
   • Payment facilitator sponsorship
3. Provide a fresh tech stack to support the needs of software / ISV partners as your primary channel partners (the acronym ISV, which stands for “independent software vendor,” is often used for software providers). Often you don’t need a full swap-out of technology platforms –newer innovations can plug gaps in legacy systems and bring organizations to market competitiveness.
4. Plan for “In-context” as a strategy for other financial services and products. Get payments right, and in-context financial services (treasury services, financing, card products, etc.) quickly follow. Embedded payments is the foundation for embedded finance.

The long-term opportunity for those who support this wave is enormous. Software-led payments are only the beginning of this strategic shift. What’s already happened in payments is now beginning to accelerate for other financial services.

Happy evolving.

® PAYFAC is a trademark of FIS and its subsidiaries. Used with permission.