By Ivan Vukelikj, Product Manager Payment and Identity, G+D Netcetera
The acquiring business has never been easy. But for most of the last decade, the core technology decisions were relatively stable: support the card networks, implement 3-D Secure, manage chargebacks, keep fraud low. That chapter has now come to an end.
Three forces are reshaping the acquiring landscape at the same time: the rise of AI-native platforms that are changing legacy authentication infrastructure, the gradual maturation of open banking and A2A payment rails as a genuine alternative to card-based flows, and the standardization of new checkout experiences like Click to Pay across major schemes. For acquirers and PSPs, the question is no longer whether to modernize. It’s how to do it without breaking what already works.
The 3DS layer is more strategic than most acquirers treat it
3-D Secure is often treated as a compliance checkbox. In practice, it’s one of the most consequential levers acquirers have for conversion and fraud outcomes. It directly influences approval rates, fraud exposure, liability, issuer confidence, exemption handling, and customer friction, while increasingly determining how well tokenized credentials and low-friction checkout journeys perform in real-world conditions. This makes 3DS far more than a protocol layer: It becomes a true a decision layer.
What’s driving this further now is AI. Machine learning models are beginning to replace rule-based fraud scoring in authentication flows, and the data richness of 3DS2 message categories gives them something to work with. Acquirers who treat their 3DS infrastructure as a commodity are leaving performance on the table. Those who invest in real-time analytics, exemption management, and adaptive flows are seeing the difference in their approval-rate benchmarks.
The practical implication: the 3DS layer deserves the same architectural attention as the core switching and settlement stack. It’s no longer appropriate to treat it as a peripheral compliance module.
Click to Pay is not optional for much longer
Click to Pay – built on the EMVCo Secure Remote Commerce (SRC) standard – has moved from pilot to scale faster than many acquirers anticipated.
With Visa, Mastercard, Amex, and Discover all live, and major PSPs racing to certify merchant bases, the window for deliberation is effectively closed. The question is implementation sequencing, not buy-in.
The merchant case is clear: Click to Pay eliminates guest checkout friction, reduces manual card entry, and ties tokenized credentials to strong authentication. Abandonment rates drop. Return customers have a faster path. For acquirers serving merchants who compete on conversion rates, not being able to offer Click to Pay readiness is increasingly a commercial disadvantage.
What makes this technically non-trivial is the integration requirement. SRC implementation sits at the intersection of tokenization, authentication, and merchant-side checkout SDK changes. Acquirers need to be able to offer their merchant base a clear migration path without disrupting existing flows during the transition. Modular deployment architecture matters here – the ability to layer new authentication and tokenization capabilities onto an existing platform without a full-stack rebuild is what separates acquirers who can move at market pace from those who are always six months behind.
A2A rails are real – and they change the authentication question
Account-to-account payments, powered by open banking APIs and domestic real-time payment schemes, are not a distant threat to card-based acquiring. The Netherlands, Poland, and the Nordics already see A2A at significant online transaction share. PSD3 will extend the regulatory foundation further, and the infrastructure supporting A2A-based commerce is maturing faster than most acquiring roadmaps assume.
For acquirers, the implication is not that cards go away. They won’t, at least not at any meaningful scale within the next five years. What changes instead is the role of the payment stack, which needs to support multiple rails intelligently: merchants will want routing optionality, consumers will expect payment method parity on checkout pages, and the authentication layer – historically built around card credentials and 3DS flows –must extend to securely support account-based payment initiation.
This is where identity infrastructure becomes a differentiating factor. Strong Customer Authentication under PSD2 was designed with card-like flows in mind, but A2A payments require SCA that maps to bank account access and payment consent, not card PAN verification. Acquirers who are building or sourcing authentication capabilities now need to think about credential types, consent models, and identity verification in a way that covers multiple rails, not just EMVCo-standard card flows.
What staying competitive actually requires
Efficient payment processing is the floor, not the ceiling. The most resilient acquirers will be those that build their value around authentication, tokenization, and orchestration as core capability of the merchant operating model.
Acquirers who are navigating this well share a few characteristics. Their authentication infrastructure is modular and configurable, not hardwired to a single vendor or protocol version. They have real-time visibility into their approval rates, decline reasons, and fraud patterns, not just end-of-day reporting. And they are making technology decisions with a multi-rail, multi-credential future in mind, rather than optimising purely for card-present and card-not-present use cases as they exist today.
The path from a traditional payment stack toward one that can support tokenization, modern authentication, Click to Pay, A2A flows, and AI-driven decisioning is not simple. But it does not require a full rebuild if the underlying architecture is modular and extensible. That is the real strategic bet for acquirers today: not trying to predict which rail or interface will dominate, but building infrastructure that can support multiple models securely, adapt to change, and avoid forcing merchants into a single path.
