If you accept card payments online, 3D Secure (3DS) shapes your business more than you might think. Authentication is often treated as a compliance box to tick, but the way it is set up has a direct effect on how many shoppers complete checkout and who carries the cost when fraud slips through. In this post we explain how 3DS works, why frictionless authentication matters, and how upcoming changes such as PSD3 and agentic commerce will raise the stakes. We also explain why the biggest conversion gains come not from authentication alone, but from how authentication and authorization work together.
At Rootline, authentication and authorization are not two separate steps handled by two separate systems. Our risk engine decides for every payment whether to request an exemption, or whether to actively request a challenge, and the same platform then submits the authorization and acts on the issuer’s response. Owning the authentication layer is what makes this possible. Our 3DS server is fully certified to the latest standards by EMVCo as well as the major card schemes: Visa, Mastercard and American Express. This allows us to directly communicate with the directory servers of these schemes without any third party dependencies in between. It is fully embedded in our Checkout SDK allowing for a seamless payment experience. But to understand why that matters, we first need to look why 3DS has the reputation it has, and whether it deserves it.
3DS, a necessary evil?
For a technology designed to protect merchants, 3DS has earned a remarkably bad reputation among them. Traditionally (and perhaps still today), 3DS is known as a conversion killer, a step where shoppers abandon their shopping basket because there is too much friction. Too many redirects, forgotten passcodes or missed one-time passwords causing shoppers to drop-off and costing you not only the sale but also the acquisition spend of getting these shoppers to the checkout page in the first place.
With the rollout of 3DS2 starting in 2018 and its subsequent versions all the way up to 2.3.1 a lot has improved in terms of conversion. Still, due to the strong customer authentication (SCA) mandate via PSD2 and soon the refinement of exemption handling and fraud prevention rules within PSD3, the number of transactions that have to go through 3DS2 has only gone up. So achieving frictionless 3DS authentications is more important than ever.
That said, 3DS is not only a cost and just a necessary evil. A successfully authenticated transaction shifts the liability for fraud chargebacks from the merchant to the cardholder’s bank (the issuer). For merchants in segments with higher fraud exposure this protection is worth a lot, as long as the authentication itself does not become a burden for genuine shoppers. That is exactly the balance a good 3DS setup should strike, and therefore being in control of that setup can be an advantage.
Optimized for conversion
So what do we mean when we speak about frictionless 3DS authentications? The biggest difference between 3DS1 and 3DS2 is the number of data points that are shared between the 3DS Requestor and Server (the merchant and Rootline) and the Directory Server (the major card schemes) and the Access Control Server (ACS) managed on the issuer side. Based on all these data points the ACS can make a decision whether to grant a frictionless authentication or request the cardholder to complete a challenge to verify their identity. Frictionless means the cardholder does not need to take any additional steps to confirm the payment: all messaging and checks happen in the background. It is the best of both worlds for conversion and fraud prevention. Your shoppers experience no extra friction at checkout, and because the transaction was authenticated, liability for fraud-related chargebacks shifts to the issuer.
However, not every 3DS solution provider is optimized for this. They might not run on the latest protocol, require redirects to collect additional data points or simply do not have full transparency about what happens behind the scenes. The result is that shoppers get lost mid flight, wait on pages that never load, or complete the authentication only for the result to be lost on the way back.
Avoiding these failure points is one of the reasons we built and certified our own 3DS server. It gives us full control and visibility over every step of the cardholder's authentication journey, so when something breaks we see it and can fix it rather than waiting on a third party. The other reason is that a 3DS server only delivers on conversion when it works hand in hand with the checkout itself, which is where our Checkout Components come in.
With Checkout Components you embed PCI compliant payment fields directly in your own pages that your shoppers know and trust. The scripts the cardholder's bank uses to collect data points run behind the scenes, without your shoppers ever leaving the page. And when an issuer does require a challenge, the challenge window is embedded within your checkout page as well.
The impact is significant on the overall 3DS conversion. We see on average 3 to 4% successful conversion uplift compared to redirect-based 3DS flows at merchants where 3DS is fully embedded in the checkout flow without the need to redirect the shopper. For a merchant processing 1 million EUR per month in card volume through 3DS, that comes down to roughly 30,000 to 40,000 EUR in additional revenue from payments per month that would otherwise not have been completed.
Not every transaction needs 3DS
PSD2 not only mandates SCA , it also defines when you are allowed to skip it. Low value transactions and transactions covered by transaction risk analysis (TRA) can be exempted from authentication, and merchant initiated transactions such as subscriptions fall outside the SCA requirement altogether. Because Rootline operates both the authentication and authorization processing, we can make this decision per transaction and request exemptions both through the authentication as well as the authorization flows. PSD3 will refine these exemption rules further, and with our own 3DS server we can adapt the exemption strategy the moment the rules change.
Having both the authentication and authorization layers under the same roof allows us to optimize for conversion. If an issuer disagrees with an exemption request, we catch it. Issuers can return a so-called soft decline, and we can automatically retry the transaction with 3DS, without the shopper noticing anything more than a short additional check, handled cleanly within the checkout page. This means no unnecessary failed payments, no ‘please try again’, and most importantly no lost baskets and revenue.
Knowing when to use an exemption requires knowing the risk of every single transaction. Rootline has built its own risk product, Signals, which through its Identity Graph can recognize underlying fraud networks and bots and distinguish these from trusted recurring shoppers and agents. In combination with its Dynamic 3DS module we know when 3DS is required by regulation, when it is warranted by risk appetite, and when it is best avoided altogether. Authentication is applied where it adds protection and skipped where it would only add friction.
Infrastructure that is ready for the future
Owning the infrastructure pays off in the day-to-day. We see exactly how each issuer’s ACS behaves: which ones respond slowly, which ones challenge more often than others, and where authentication breaks down. The visibility allows us to tune what we send per issuer and to spot problems before they show up in your conversion numbers. And when EMVCo publishes a new protocol version, we can adopt it as soon as issuers do, instead of waiting on a third party’s roadmap.
The ability to launch fast becomes critical as the way purchases are made evolves. Merchants are adding entirely new checkout channels through agentic commerce. The industry is moving towards conversational checkouts hosted on your own webpage or third-party AI tools like ChatGPT, Claude or Gemini. In some cases the purchases will be fully managed by AI agents themselves that act based on the cardholder’s consent and either act within a controlled or protocol-driven domain, or scrape your checkout with the cardholder’s credentials to complete the purchase.
This raises an entirely new authentication question: how does an issuer verify a cardholder who is not sitting behind the checkout at all? A one-time password over SMS does not work when an agent completes the purchase on your behalf. Many of the answers the industry is working on run over the 3DS rails.
The most visible innovation is payment passkeys. Visa and Mastercard are rolling these out so that a cardholder can approve a payment with the same fingerprint or face unlock they use to open their phone, instead of retyping a one-time code from a text message. Recent 3DS protocol versions support this through device binding and browser-native authentication, which is what makes the challenge step fast enough to stop hurting conversion.
The second innovation is less visible but matters more for agentic commerce: decoupled authentication. Here the cardholder approves the payment outside the checkout altogether, for example through a push notification from their banking app. The 3DS flow does not need the shopper to be present in the browser or app where the payment is initiated. That is exactly the situation an AI agent creates. The cardholder delegates trust to the agent once, the agent transacts within the limits it has been given, and when the issuer wants confirmation, the cardholder approves it on their own device without the agent ever handling their credentials. The emerging agentic payment standards build on this foundation rather than replacing it.
Both capabilities depend on the 3DS server being current with the protocol and on issuers having switched them on. Because we run our own server, we can enable them as soon as the schemes release them and issuer adoption is there, so merchants on Rootline get the benefit without changing their integration.
Live today
Our 3DS server is live today, and handles the authentication traffic for our partners and clients processing with us. If you process with Rootline there is nothing to integrate or migrate as our authentications already run over our own infrastructure. It is embedded in your checkout when you use Checkout Components, or when you use our hosted checkout page.
If you want to see how this works, you can book a demo here or leave us a ‘payment’ message at rootline.cafe to book a coffee appointment with us.
