The Customer Must Never Know: The American Way of Building 3DS
3DS is the great equalizer for online payments. But in the US, it is not mandatory. This has more significance than you might expect for engineers.
Online payments have a fraud problem. But not the one you think.
Yes, fraudulent use of credit cards is still a thing. I’ve said before that online payments are kind of a miracle, so I don’t think we should be surprised that it leaks from time to time.
No. The problem is more serious than that.
To quote patio11 on this, online payments rules are “not fully descriptive”. That means that, when there’s a dispute, the cardholder’s bank, or issuer, has wiggle room to decide its outcome:
As a simplified example, issuers who focus on “premium” card users frequently make a business decision to side with their customer more frequently than, say, mass-market banks do. (They would probably entirely automate “Chargeback sustained!” if the network rules allowed them to do so, but they don’t.)
— Finality does not exist in payments, Patrick McKenzie
This is perverse. Online, merchants don’t have direct access to the card itself (they deal with what the industry call Card Not Present, or CNP, transactions). And that means that, should the payment be fraudulent, the merchant is liable.
But even when there’s overwhelming evidence proving that the payment was legit, the issuer, being the ultimate decision maker in a dispute, is strongly incentivized to side with the cardholder.
Ask any owner of an e-commerce store. They have wild stories to tell about it.
This is not fair. The issuer is happy to charge fees to the merchant. But it refuses to accept the responsibility that comes with it. Issuers charging the most are, in fact, the worst offenders.
3DS is the protocol that makes things fair. It’s the great equalizer.
But unlike Europe, where it’s mandatory, 3DS is an optional tool for US merchants. Earlier this year, Stripe analyzed how US banks treat 3DS authenticated payment and were shocked to find that American issuers perceive transactions requesting 3DS to be high-risk.
This proves what many in the payments industry have long suspected, even taken for granted. That the cultural, demographic and regulatory differences between the US and Europe towards online fraud lead to fundamental differences in the way merchants at each side of the pond deal with 3DS.
And yet, I haven’t found anything online that attacks this divide head on.
This is not good. It’s not that this information should exist already. It’s that merchants approaching 3DS the opposite way is disastrous.
I’m Alvaro Duran, and this is The Payments Engineer Playbook. Scroll for five minutes on Youtube and you’ll find tons of tutorials that show you how to pass software design interviews that use payment systems. But there’s not much that teaches you how to build this critical software for real users and real money.
The reason I know this is because I’ve built and maintained payment systems for almost ten years. I’ve been able to see all types of interesting conversations about what works and what doesn't behind closed doors.
And I thought, “you know what? It’s time we have these conversations in public”.
In The Payments Engineer Playbook, we investigate the technology that transfers money. All to help you become a smarter, more skillful and more successful payments engineer. And we do that by cutting off one sliver of it and extract tactics from it.
3DS is a protocol designed to shift the liability of an online payment from the merchant to the customer bank when the customer has verified their identity.
3DS is the process of deciding if there’s a two-factor authentication step required, called challenge. But the data clearly shows that converting a customer online becomes way more difficult by adding this extra step.
If right after you click pay, your bank asks “are you sure?”, you may very well change your mind.
The impact on conversion and the liability shift is why fraud risk, and the means to mitigate it, have become a power play between merchants and issuing banks, mediated by the payment networks.
The middle ground turned out to be collecting as much information from the customer as possible, with as minimal involvement from them.
When you read that “3DS is flexible”, they mean exactly that: merchants will try to sharpen the cardholder’s digital footprint—information they leave online simply by accessing or registering to their website—to predict fraud.
How that footprint is used is what distinguishes The American from The European Way of building 3DS.
I’ve already written an article on The European Way, where I examine how things change when regulators force merchants and issuers to always go through 3DS. In this article, I’ll be focusing on The American Way, where 3DS is an optional protocol.
Let’s begin.
American issuers don’t trust 3DS authenticated payments, and it makes total sense
That study by Stripe found that US banks go as far as declining 3DS transactions rather than putting the customer through the 3DS flow.
This is so shocking, the guys from Payments on Fire Podcast invited the author of that study for an in-depth conversation.
But look, think about it: Americans aren’t used to 3DS. Virtually no merchant in the US puts their customers through a 3DS challenge. Therefore, those customers who put up with it are clearly doing something fishy.
It is so unlike American customers to go through 3DS, issuers will be reasonably suspicious about those that do.
Merchants, however, have figured out a way around it.
But to explain what, I need to explain a little bit about the 3DS process itself.
Preparing, Authenticating, Challenging
It’s called 3 Domain Secure because there are 3 servers, each on one “domain”, involved in the protocol:
The 3DS Server, in the Acquiring domain (for merchants, PSPs, etc), responsible for collecting data from the customer. That, by the way, includes the card number, CVV and expiration date, either directly in a secure PCI environment, through a vault, via nonce (read “Google Pay or Apple Pay”), etc. PCI is a beast that I will address in some future date, but not today.
The Access Control Server, or ACS, in the Issuing domain (for issuers), responsible for making a data-driven decision on the transaction risk
The Directory Server, or DS, in the Interoperability domain (for networks like Visa and Mastercard), responsible for mediating on the decision process and communication.
What makes the protocol possible is that each server is expected to behave in predictable ways and tightly conform to the specification.
The protocol, in version 2.2, has 3 phases: Preparation, Authentication, and Challenge.
Preparation: PReq/PRes, Version negotiation, and 3DS Method
At Preparation, the 3DS Server (which used to be called MPI) has two main tasks.
One is called version negotiation. It consists of agreeing with the DS and the ACS the version of the protocol that will be used for the transaction. Banks are notoriously slow adopters of new technology, and it’s often the case that the 3DS Server has to fallback to an older version so that the authentication process can happen.
Version negotiation is carried out by a message exchange called PReq/PRes. The PReq, sent by the 3DS Server, also generates the transaction identifier, called threeDSServerTransID (which used to be called XID), and includes the callback link to which the ACS can directly communicate with the 3DS Server later on.
In the US, though, credit cards are required to have support for at least one local network (called PIN debit). In practice, this means that the PRes will contain multiple answers (one per network). But that’s about it: you just choose whichever option that suits you best, and move on.
Apart from version negotiation, the Preparation phase also includes the 3DS Method. This is a request made straight to the ACS, and contains hundreds of data points collected from the user to assess the risk of fraud, in what is called Risk-based authentication.
Something I learned very recently is that 3DS Method can happen in parallel with the PReq/PRes exchange. As a result, it’s more performant to start this message exchange as soon as the credit card number is available.
Authentication: AReq/ARes, ECI, and transStatus
The meat of 3DS happens during Authentication.
Once Preparation is done, the 3DS Server makes a request to the ACS through the DS, containing the threeDSServerTransID generated during the preparation. This request is called AReq.
The 3DServer will receive, in turn, a response called ARes, which contains three important values: the Electronic Commerce Indicator, or ECI, the transStatus, and the Cardholder Authentication Verification Value, or CAVV.
The ECI is a two digit code that indicates the outcome of the transaction:
Approved or Denied by the ACS.
Attempted, which means that the DS considers that there’s enough data to warrant a liability shift, despite what the issuer says.
This data is complemented by the transStatus, which expands and clarifies on the ECI value received (including whether a challenge is required), and the CAVV, which encodes all the necessary information to identify and validate a transaction. You can even calculate what the CAVV would look like using a calculator.
Challenge: CReq/CRes, RReq/RRes
This is what surprises people the most: even if the outcome of the Authentication phase is that the issuer is requesting a challenge, the merchant can still decide not to do it.
But let me first quickly address what happens if they do, so that we can talk about ways to avoid it.
If the ARes contains a transStatus with value C, the 3DS process won’t be completed unless the merchant presents a two-factor authentication process to the user (if the transStatus is “D”, that means that the process is decoupled from the merchant, and the challenge will be handled by the issuer).
There are differences in the way the Challenge phase is handled in the browser versus via app, which is more convoluted.
In the browser-based challenge, the user is redirected to a url specified by the ACS, where the customer will have to complete the challenge. The outcome of this process will be sent straight to the ACS in the form of a request called CReq.
Upon receiving the CReq, the ACS sends the result of the challenge to the DS with a message called RReq, which will be proxied to the 3DS Server, and acknowledged with a response message called RRes.
Once the ACS receives that response message, it will ensure that the browser has received the challenge decision by sending a message called CRes to the callback link defined during the preparation phase.
At this point, the acronym salad merits a diagram, so here it is:
Challenge Cancellation
In the land of the free, merchants have the freedom to opt out of the challenge.
3DS let merchants proactively decide to cancel a challenge when they get the ARes.
This is crucial in the US, where in practice 3DS challenges are both conversion killers and red flags for issuers.
As a result, US merchants often opt out of 3DS if the outcome of the ARes is that a challenge is requested. They’re better off trying to authorize the payment without any 3DS whatsoever.
TL;DR
Preparation, Authentication and Challenge are the three phases of 3DS.
At Preparation, the 3DS Server, mediated by the PReq/PRes message pair, and the 3DS Method, negotiates the version used, generates the 3DSServerTransID, and provides ACS with richer data to increase the odds of approval
At Authentication, the 3DS communicates through the DS to the ACS the standard AReq, and receives an ARes message that contains the ECI and the transStatus. Approved and attempted results shift the liability of a potential dispute from the merchant to the issuer; outright rejection ends the process; and challenge request initiates the next phase.
At Challenge, the browser may redirect the user as specified in the ARes message, sending a CReq to the ACS with the result, or opt out by canceling the process. Upon receiving the CReq, the ACS communicates the challenge decision to the 3DS Server with the RReq, and to the browser with the CRes.
Something has gone very wrong when we expect merchants to assess the fraud risk of online payments. It should be a task for banks!
But banks are businesses too, and they’re pressured to think that the customer is always right. Even when it’s clear that they’re not.
The American Way of doing 3DS is ingenious: merchants use it as much as they can, as long as the customer never notices it.
Building payment systems in this way brings power to merchants in this fraud tango with issuers. I suggest you bookmark this article, and come back to it any time you need.
Nailing 3DS is crucial. It’s the great equalizer. Even when it’s not required.
This has been The Payments Engineer Playbook. I’ll see you next week.
PS: I believe that building software is to computer science just like buying something is to economics: Almost unrelated.
Buying groceries is governed by dynamics studied in economics. We can use economics to figure out pricing, inventory, or financing. But it’s a stretch to say that buying groceries is doing economics.
Same with building software and computer science.
Yes, the code is going to be taken by the compiler or the interpreter and it’s going to do something that’s studied in computer science. You shouldn’t use floats to store money, and the reason can be found in computer science.
But that doesn’t mean that building software is computer science.
There was definitely a time when all this wasn’t true. When algorithms and data structures and all that was crucial. And there are definitely still times you want someone with real computer science knowledge to write your organization’s code, i.e. when the computer sciencey stuff really matters.
But it’s not true anymore. The reason is that all this obfuscates the business logic. We’re more productive if we don’t have to think about it, so that we have more room for the business stuff in our heads.
There are two important takeaways from this.
The first is that it’s wild that engineers still obsess over generic computer science stuff as part of their on-the-job learning. Most think that what got them where they are (whiteboard interviews) is going to get them where they want to be (promotions, more valuable companies, better clients).
What’s shocking is that even if their rational brain thinks that way, organizations reward the engineers that don’t obsess over generic computer science stuff.
Now you know why.
My second observation is that the hype surrounding AI is going to be deeply unsatisfying for generalists. Up until now, building software was left for the software builders. Now, it’s just a means to an end.
Which means, again, that you should focus more on the business aspects of the software you’re writing, rather than hustling on leetcode for hours.
It’s going to be a better use of your time.
That’s why newsletters like The Payments Engineer Playbook exist. You’re supposed to know about HTTP and JSON. You should understand of how the Internet protocol works.
But 3DS is the application of all that in a very particular context. And that’s more valuable, because there is a direct connection between nailing down the implementation of 3DS and your company’s revenue.
That’s something that knowing the difference between bubble sort and merge sort can’t give you.
As you probably know, this newsletter is going paid in 2025. But until then, you have a chance of becoming a paid subscriber for a discount.
You just simply have to be a subscriber, and pledge a paid subscription.
I write The Playbook in such a way that engineers building money software take more than 10x in salary increase what they pay for a subscription.
This is the first step: pledge a subscription for The Playbook now. And start learning more effectively.