Daniel's been thinking about that moment at the checkout — not the part where you tap your card or type in the sixteen digits, but the part where the screen flickers, some URL you've never seen flashes past, and suddenly your phone buzzes with a code you have sixty seconds to type in before the whole transaction self-destructs. He wants to know what that middleware layer actually is, how it fits into the payments pipeline, and why it seems to cause more chaos than it prevents. He mentions a friend who got locked out of their card trying to buy medication because an SMS code didn't arrive in time. So the question is: who are these security gatekeepers sitting between the merchant and the card network, and what's actually happening during those redirects?
The short answer is it's a protocol called 3D Secure. The version most people are encountering now is 3D Secure 2, or 3DS2. And the entity you're seeing flash across the screen during that redirect is the ACS — the Access Control Server. That's the piece of infrastructure operated by the card issuer, or more often by a third party on behalf of the issuer, that decides whether you need to jump through an authentication hoop.
So the bank isn't running this themselves. They're outsourcing the gatekeeping to someone else.
Almost always. The big players are companies like CardinalCommerce, which Visa acquired, and CA Technologies, which Broadcom now owns. There's also a company called Arcot that was early in this space. When your transaction triggers a 3D Secure challenge, your browser is being handed off to one of these ACS providers. They're the ones generating the SMS, or in the better implementations, the push notification to your banking app.
Which explains why the domain name in the URL bar looks like it belongs to neither your bank nor the store you're buying from.
And that's the first thing Daniel's right to flag as a security awareness problem. You're taught never to enter credentials on a page you don't recognize, and then the payments system trains you to do exactly that — hand over a one-time code to a domain called something like acs dot cardinalcommerce dot com. The protocol is designed so this is cryptographically safe, but the user experience is teaching the opposite lesson.
Walk me through the actual sequence. I'm buying something, I hit pay, what fires off first?
The merchant sends an authorization request to their payment gateway, which routes it to the card network — Visa, Mastercard, whatever. The network checks with the issuing bank whether this card is enrolled in 3D Secure. If it is, the network sends back a response that basically says, "Hold on, we need to authenticate this one." That triggers the redirect. Your browser gets sent to the ACS, which evaluates the transaction using something they call risk-based authentication.
Risk-based authentication meaning they're scoring me in real time without me knowing.
Right. And this is where 3DS2 is genuinely different from the original 3D Secure, which everyone hated. The old version — 3DS1 — was what gave us those awful static password prompts where you had to remember some secret phrase you set up three years ago and immediately forgot. 3DS2 collects a much richer set of data. The merchant passes along something like a hundred and fifty data points about the transaction — device fingerprinting, browser language, screen resolution, time zone, shipping address, whether the email address is new to the merchant, how long you spent on the page before clicking buy.
So before I even see a challenge, the system has already profiled my device and my behavior.
And in most cases, that's enough. The statistic that gets cited is that around ninety-five percent of 3DS2 transactions are frictionless — meaning the ACS evaluates all that data, decides the risk is low, and approves the transaction silently. You never see a redirect, never get an SMS. The whole thing adds maybe half a second to the authorization.
But Daniel's story — and I think the experience most people remember — is the five percent where it fails.
And that five percent is still millions of transactions a day. When the ACS flags something as high risk, it triggers what they call a challenge flow. The most common challenge is the SMS one-time passcode, which is the worst possible option from a security standpoint and the most frustrating from a user standpoint.
Why is SMS the worst? I thought the whole point was that it's a second factor.
SMS is vulnerable to SIM swapping, SS7 interception, and it's completely unencrypted. The phone network was not designed as an authentication channel. But the real problem Daniel's pointing at isn't even the security weakness — it's the reliability. SMS delivery is not guaranteed. Carriers throttle messages, they get delayed, they get filtered. And 3D Secure challenges have a timeout, typically five to ten minutes for the overall session but often sixty seconds or less for the code entry screen. If the SMS arrives at minute four, you might already be timed out. And here's the nasty part: some issuer configurations will increment a fraud counter on a failed challenge, and after two or three failures, the card gets blocked.
So you're at the pharmacy, the SMS doesn't arrive, you try again, still nothing, and now your card is dead. For buying medication.
And the merchant has no visibility into why. They just see a declined transaction. The pharmacy clerk doesn't know it's an authentication failure versus insufficient funds versus a stolen card. The whole pipeline is opaque to the person who's actually facing the customer.
Let's back up to something you said. The ACS is scoring me based on a hundred and fifty data points. What kind of things actually trigger a challenge?
The exact models are proprietary, but the broad categories are well understood. A mismatch between the shipping address and the billing address. A device that's never been associated with that card before. An IP address geolocated far from the billing address. A transaction amount that's unusually high for that merchant category or for that cardholder's history. A merchant that has a high chargeback rate. A card that was just used in a different country an hour ago. Any combination of those can push the risk score over the threshold.
So it's not one red flag, it's a cumulative model.
And the thresholds are set by the issuer, not by Visa or Mastercard. Each bank decides how aggressive they want to be. Some banks challenge almost nothing. Others challenge anything that looks even slightly unusual. And the cardholder has no way to know which bank does what until they're standing at the register with a frozen card.
Daniel mentioned seeing API names and URLs flash during the redirect. What's actually happening in the browser during those milliseconds?
The redirect is a series of HTTP POST requests with form-encoded data, or sometimes a JavaScript SDK that creates an iframe. The merchant's checkout page sends the transaction data to the ACS URL, the ACS processes it and returns a challenge page or a completion message, and then the ACS sends the result back to the merchant via the browser using a signed response. The browser is basically a relay. The cryptographic part is that the ACS signs the authentication result with a key that the card network can verify, so the merchant can't forge a successful authentication and the ACS can't deny one it issued.
So the merchant never sees my actual authentication code. They just get a token that says "yes, this person passed" or "no, they didn't."
Correct. The code you type in goes directly to the ACS. The merchant gets back a cryptogram — they call it the CAVV, Cardholder Authentication Verification Value — which they include in the authorization request. The issuer checks that the CAVV matches what their ACS generated, and if it does, they know the authentication was genuine.
And if someone intercepts that redirect and swaps in a fake ACS page?
That's the man-in-the-middle scenario Daniel's worried about, and it's a legitimate concern. The protocol relies on the browser correctly validating TLS certificates for the ACS domain. But if a user is on a compromised network, or if there's a phishing page that mimics the ACS challenge, they could capture the SMS code and replay it. 3DS2 has some protections against replay attacks — the codes are single-use and time-bound — but the window exists.
Which brings us back to the user training problem. The system says "never trust an unfamiliar login page," then presents you with an unfamiliar login page and expects you to comply.
And the merchants hate this too. Every additional step in checkout increases cart abandonment. The industry number that gets thrown around is that every second of added friction costs about one percent conversion. A full 3DS challenge flow can add fifteen to thirty seconds. For a merchant doing millions in online sales, that's real money. But here's the counterweight: 3D Secure shifts liability.
Explain the liability shift.
In a standard card-not-present transaction without 3D Secure, if the cardholder disputes the charge as fraud, the merchant eats the loss. That's just how the card network rules work. But if the transaction went through a successful 3D Secure authentication, the liability for fraud shifts to the issuer. The merchant is off the hook. So for a merchant, the calculus is: lose some conversions to friction, or lose money to chargebacks. For high-risk categories — electronics, luxury goods, anything resellable — the chargeback savings usually outweigh the conversion loss.
Which means the merchant is actually incentivized to push transactions through 3D Secure even when it might hassle legitimate customers.
And the issuer is incentivized to make the authentication as frictionless as possible, because they're now on the hook if fraud gets through. That tension is supposed to produce a reasonable equilibrium. In practice, it produces the experience Daniel described.
What about the alternatives to SMS? You mentioned push notifications.
3DS2 supports biometric authentication through the issuer's mobile app. The flow works like this: the challenge gets sent as a push notification, you open your banking app, authenticate with your fingerprint or face, and the app sends the signed response back to the ACS. No codes to type, no SMS delays, and it's cryptographically bound to your device. This is what the protocol was designed for. The SMS fallback exists because not everyone has their bank's app installed, and not every bank has implemented the biometric flow.
So the better version exists, and banks just aren't deploying it.
It's a slow rollout. Implementing the app-based biometric flow requires the bank to integrate the 3DS2 SDK into their mobile app, which is a development project that touches authentication infrastructure. A lot of smaller banks and credit unions just haven't done it. They rely on the ACS provider's default challenge method, which is often SMS because it works for every customer with a phone number on file.
"Works" in the technical sense. Not in the Daniel's-friend-at-the-pharmacy sense.
Right. And there's another layer here that makes this even more frustrating. The ACS providers compete on their fraud detection models, not on their user experience. The bank chooses an ACS based on how well it blocks fraud, not on how pleasant the challenge flow is. The cardholder isn't the customer. The bank is the customer. So the incentives are misaligned all the way down.
Daniel also asked about verifying legitimacy. If I see one of these redirects, how do I know it's real and not a phishing page?
The honest answer is that for most users, it's nearly impossible to distinguish in the moment. The domain will be something unfamiliar by design. The page will look vaguely like your bank's branding, but it might be a generic template from the ACS provider. The best practical advice is to look at the URL bar and verify that the domain is at least related to a known ACS provider or your bank, and that the TLS certificate is valid. But that's a lot to ask of someone just trying to buy something.
And the sixty-second timeout means you don't exactly have time to do a WHOIS lookup.
The protocol does include a mechanism that helps, though. In 3DS2, before the redirect happens, the merchant is supposed to display the name of the ACS provider and the issuer. So you might see a brief interstitial that says "You are being redirected to Visa Secure, operated by CardinalCommerce, on behalf of Chase." That's supposed to set expectations. But merchants often skip that step or implement it poorly, and the redirect happens so fast you never see it.
Let's talk about what happens when the authentication fails. You said there's a fraud counter. What does that actually look like on the issuer side?
Each issuer has their own risk rules, but a common pattern is that a failed 3DS challenge increments a velocity counter. Three failed challenges in a short window might trigger an automatic card block. Some issuers block after two. Some block after one if the transaction was already high-risk. The block is usually not communicated to the cardholder in any useful way — they just find out when their next transaction gets declined.
And unblocking it means calling the bank, waiting on hold, going through identity verification.
Which for Daniel's friend at the pharmacy is not exactly convenient. You're there to pick up medication, not to spend forty minutes on the phone with fraud prevention.
Is there any movement toward fixing this? Any regulatory pressure?
The main regulatory framework is PSD2 in Europe, which mandates strong customer authentication for electronic payments. That's actually what accelerated the 3DS2 rollout — the regulation requires two-factor authentication for most online transactions, and 3DS2 is the industry's answer to compliance. But PSD2 also includes an exemption for low-risk transactions, which is where that risk-based authentication model comes in. The regulator said "we need strong authentication," and the industry said "okay, but let us decide when it's actually needed."
So Europe mandated the thing, and then the industry built a system to mostly bypass the mandate.
In the best possible way, honestly. The alternative would be challenging every single transaction, which would be catastrophic for online commerce. The exemption framework is what allows that ninety-five percent frictionless rate. The problem is that the five percent of challenged transactions are handled so poorly.
What about the US? No PSD2 equivalent.
No federal mandate. 3D Secure adoption in the US has been driven entirely by the liability shift and by the card networks requiring it for certain merchant categories. Visa and Mastercard have both been pushing it hard, but it's still not universal. A lot of US issuers still don't require 3D Secure for every transaction.
Which means an American buying from a European merchant might suddenly encounter 3D Secure for the first time with no warning.
And that's another failure mode. The cardholder has never set up their phone number with the issuer for SMS challenges, or the number on file is outdated, and the challenge goes to a phone they no longer have. The transaction fails, and they have no idea why.
I want to go back to the technical architecture for a minute. You said the ACS signs the authentication result. What's the trust model there? Who holds the keys?
The card networks operate the root of trust. Each issuer registers their ACS with the network, and the network issues the signing keys. When the ACS signs a CAVV, the issuer can verify it because they trust the network's key infrastructure. The merchant includes the CAVV in the authorization message, the issuer validates it, and if it checks out, the liability shift applies. The merchant never holds any keys — they're just passing through a signed token.
So the merchant can't fake an authentication. But could a malicious ACS fake one?
Only if they've compromised the key infrastructure, which would be a catastrophic breach. The ACS is a regulated entity within the payments ecosystem. They have to be certified by the card networks. The certification process involves security audits, penetration testing, and ongoing monitoring. It's not perfect, but it's a meaningful barrier.
And yet the user experience makes it feel like anything could be happening behind that redirect.
That's the fundamental tension Daniel's getting at. The protocol is cryptographically sound. The infrastructure is regulated and audited. But the user-facing part — the part that actually touches human beings — is a mess. And in security, the human is always the weakest link. You can have perfect cryptography and still fail because someone got confused by an unfamiliar URL and typed their code into a phishing page.
Or because they never got the code at all and their card got blocked.
The pharmacy story is a perfect example of a system optimizing for the wrong thing. The fraud model correctly identified an anomalous transaction — maybe the pharmacy was in a different zip code, maybe the amount was unusual for that card. The challenge was triggered appropriately by the risk model. But the delivery mechanism for the challenge failed, and the consequence was disproportionate to the risk. The system protected the bank from a potential fifty-dollar fraudulent charge by preventing a legitimate fifty-dollar medication purchase and creating hours of hassle for the cardholder.
And the bank probably never even knows that happened. The blocked transaction is just a statistic.
The bank sees a declined authentication. They don't know it was a legitimate customer who needed medication. They don't know the SMS was delayed by carrier congestion. All they see is "challenge failed." The feedback loop is completely broken.
What would fix it? If you were designing the next version of this, what changes?
First, kill SMS as a challenge method. Push notifications to banking apps, biometric verification, and WebAuthn as a fallback. The technology exists. Second, give the cardholder a way to pre-authenticate trusted merchants or transaction types. If I buy from the same pharmacy every month, let me whitelist them. Third, make the failure pattern graceful. If a challenge times out, don't increment a fraud counter. Offer a retry, offer an alternative authentication method, or let the transaction proceed with a lower liability shift. Don't just block the card.
That last one seems obvious. Why isn't it done?
Because the system is designed around liability, not usability. The liability shift is binary — either the transaction was fully authenticated and the issuer takes the risk, or it wasn't and the merchant takes the risk. There's no partial liability shift for a transaction where the challenge was attempted but failed for technical reasons. The card networks would need to create a new liability category, and that would require renegotiating the entire framework.
So the legal architecture is as much the problem as the technical architecture.
More so, in some ways. The technical pieces — the cryptography, the device fingerprinting, the risk models — those are actually quite good. The protocol does what it's designed to do. But it's designed to allocate financial liability between merchants and issuers, not to serve the cardholder. The cardholder is just the object being authenticated.
And the merchant is stuck in the middle, watching customers abandon carts because of a security system they didn't choose and can't control.
The merchant chooses whether to attempt 3D Secure — it's not mandatory for every transaction — but once they opt in, they have no control over which transactions get challenged or how the challenge is delivered. That's entirely on the issuer and the ACS. The merchant just gets the pass or fail result.
Daniel mentioned seeing the redirect URL and wanting a mental model for what's legitimate. I think the model we've laid out is: there's a third party between the merchant and the card network, it's called the ACS, it's hired by the bank, and its job is to decide whether you are you. The URL you see belongs to that third party, and it's supposed to be there.
And the way to verify it, imperfect as it is, is to look for the issuer's name somewhere in the flow — either on the challenge page itself or in the brief interstitial before the redirect. If you see a challenge page that claims to be from your bank but the URL is completely unrelated to any known ACS provider or your bank's domain, that's a red flag. But the honest truth is that the system relies on the card networks' certification process to keep malicious ACS providers out of the ecosystem, not on the cardholder's ability to verify URLs.
Which is a reasonable security model for the infrastructure layer. It's just a terrible user experience.
And it's going to stay terrible until the incentives change. As long as the banks are the ACS providers' customers and the cardholders are just the raw material being authenticated, the user experience will be an afterthought. The only thing that might shift that is regulation — something like requiring issuers to report their false positive rates and making that data public, so consumers can choose banks that don't block their legitimate transactions.
If one bank figures out that a smooth authentication experience attracts customers, the others might follow.
Maybe. But banking competition is slow, and most people don't choose their credit card based on the 3D Secure experience. They don't even know what 3D Secure is until it fails on them.
On the record: within two years, at least one major US issuer will offer a whitelist feature for trusted merchants in their mobile app, and market it as a feature.
I'll go further. Within three years, SMS will be deprecated as a challenge method by at least one of the major card networks — probably Mastercard, they've been more aggressive on this — and replaced with app-based biometric authentication as the default. The SMS option will still exist as a fallback, but it won't be the primary method anymore.
I think that's optimistic on the timeline, but I hope you're right.
The pharmacy story Daniel shared is the kind of thing that eventually reaches a regulator's desk. Someone's going to ask why a card got blocked for trying to buy medication, and the answer "because an SMS didn't arrive in time" is not going to be acceptable.
The whole thing is a reminder that payments infrastructure is a stack of compromises. Every layer was added to solve a problem in the layer below, and each one creates its own problems. 3D Secure solved the problem of card-not-present fraud by adding authentication, and it created the problem of legitimate customers getting locked out. The next layer will solve that, and create something else.
And somewhere in the middle, there's a person at a pharmacy counter staring at their phone, waiting for a code that isn't coming.
Thanks to our producer Hilbert Flumingtop.
This has been My Weird Prompts.
If you've got a story like Daniel's — a moment where the payments infrastructure failed you in an interesting way — we'd love to hear it. Email the show at show at my weird prompts dot com.
We'll be back soon.
