Card Payment Authentication and the Intent Problem: Why Identity, Consent and Authorization Are Not the Same Thing
3DS cascading retries a declined transaction with a different provider using the same authentication credential, without asking the cardholder to confirm again. The article argues this solves provider decline rates rather than genuine consent, because authentication exists to verify the cardholder wants this specific transaction. Skipping that confirmation, as in shared device scenarios where a child buys on a parent's unlocked session, defeats fraud prevention.
1. Card Payment Authentication, Consent and Authorization Are Three Different Things
1.1 The Payments Industry Has a Habit of Solving the Wrong Problem
The payments industry has a habit of solving the wrong problem in a way that looks, on the surface, like genuine progress. Nowhere is this more visible than in the current enthusiasm for reducing authentication friction through techniques such as 3DS cascading, where certain orchestration architectures separate 3DS authentication from authorization, allowing authentication results to be carried into alternate authorization routes where scheme rules, certification, and provider support permit it. Cross provider portability of this kind is not universal, and it is worth being precise about that, since some providers state plainly that authentication data from one authorization attempt cannot be reused across payment service providers, while others deliberately architect around the constraint by decoupling authentication from the processor entirely. The pitch sounds entirely reasonable when you first hear it, because nobody enjoys being asked to authenticate twice, and conversion rates matter enormously to the businesses building these systems. The objection worth making is not that cascading is wrong, because in many cases it is straightforwardly sensible. The objection is that the industry has started treating authentication, cardholder intent, and issuer authorization as interchangeable signals, and once those three things are collapsed into one, a system can satisfy all of its internal definitions of success while entirely failing to establish the only thing that actually matters, which is whether the cardholder wanted this specific purchase to happen.
1.2 The Problem Statement Has Been Quietly Swapped
The sleight of hand at the center of this entire conversation is that the problem authentication exists to solve has been quietly replaced with a different and much easier problem. Authentication, transaction intent, and authorization are related to one another, but they are not the same thing, and the industry has a habit of collapsing them into a single word. Authentication asks how confident an issuer can be that the person initiating a transaction is the legitimate card user. Authorization asks whether the issuer should permit that transaction to proceed. Underneath both of those sits a third and more fundamental question, which is whether the human being actually intended this specific purchase, and it is that third question, transaction intent, that the industry keeps quietly substituting away in favor of the much easier question of how to get a transaction approved with the least possible resistance. A challenge is one of the few moments in the conventional card payment journey where the issuer can obtain fresh evidence that the legitimate user is actively participating in this specific transaction, and that moment of deliberate confirmation is a large part of the reason authentication exists at all, rather than being an unfortunate obstacle that a well designed system should try to engineer away.
1.3 Frictionless Authentication Is Still Authentication
There is an important wrinkle that any honest version of this argument has to concede, because the industry has a ready made rebuttal otherwise. The EMVCo standard that governs 3DS explicitly defines two paths, a frictionless flow and a challenge flow, and in the frictionless flow the issuer still authenticates the cardholder, assessing transaction, device, and behavioral information without ever interrupting them with a challenge. So it would be inaccurate to describe frictionless authentication as an absence of authentication, and doing so hands the industry an easy way to dismiss the whole argument by saying, correctly, that authentication is still happening even when nothing is challenged. The real problem is not frictionless authentication itself. The real problem is treating inferred identity, built from device signals and historical patterns, as though it were equivalent to freshly confirmed transaction intent obtained in the moment. Identity is not intent. A system can be extremely confident about who a device belongs to while having no genuine signal at all about whether the person currently holding that device wants this specific purchase to happen right now. That distinction, rather than a blanket objection to frictionless flows, is the argument worth making.
1.4 The Customer Never Consented to a Processor
Here is where the argument needs to be careful, because there is an obvious and correct objection to the way cascading is usually criticized. The cardholder never consented to Processor A in the first place. What they consented to was something much closer to paying a particular merchant, a particular amount, using a particular card. The acquirer and processor routing sitting underneath that transaction is infrastructure, and the customer neither sees it nor has any opinion about it. So when a payment orchestration platform performs 3DS independently, obtains the resulting authentication artifacts, and passes those into an authorization routed through a different acquirer, it is not automatically circumventing anything the customer cared about. It may simply be routing around a broken or badly performing pipe, and objecting to that on consent grounds would be confused.
The distinction that actually matters is between the type of decline being routed around, and it can be stated as a single principle: the semantic meaning of a decline must survive orchestration. A timeout can be rerouted. A processor outage can be rerouted. A genuinely retryable issuer response can be retried. But a decline that carries an explicit instruction not to try again must not quietly become retryable merely because another route happens to exist. Card networks formalize exactly this difference. Mastercard publishes merchant advice codes, including a do not try again code covering situations such as suspected fraud, which tells the merchant and acquirer that the authorization should not be resubmitted. Visa similarly divides declines into categories with different retry semantics, where one category prohibits reattempting the authorization altogether while others permit a limited number of retries. Routing around a technical failure is ordinary resilience and nobody should object to it. Retrying a response the network has marked as retryable is recovery. But taking a decline that the issuer meant as a substantive risk judgment and trying alternate routes until the response comes back differently is decline shopping, and the harm is not that a second attempt was made. The harm is that the meaning of the original decision was discarded on the way through the orchestration layer. The problem is therefore not cascading as a technique. The problem is blind cascading, which treats a considered risk judgment and a dropped connection as though they were the same kind of failure.
2. Payment Fraud Prevention and the Real World Scenario the Industry Keeps Ignoring
2.1 The Shared Device Problem
Consider an entirely ordinary domestic situation that happens in households everywhere on a regular basis. A child picks up a parent’s laptop or phone while it is still unlocked, finds a browser session that is still logged into a retailer, and either completes a one click purchase or adds a subscription without the parent’s knowledge. The card is technically present in the sense that it is genuinely linked to that account, and the session is technically authenticated because someone had previously logged in on that device, so by almost every signal a card provider is able to observe, this looks exactly like a legitimate transaction carried out by the actual cardholder. It is nothing of the sort. The cardholder never decided to make that purchase, and although no card was stolen and no number was leaked, the money still left the account without the cardholder ever having consented to the transaction. The issuer authorized it, in the technical sense that it approved the request and released the funds, which is precisely what makes the example so uncomfortable. Every system in the chain performed correctly according to its own definition of correct. This is a class of unauthorized transaction that identity centric fraud models are inherently poorly equipped to distinguish, because it does not resemble the stolen card number template those models were built around. The situation exposes a simple equation that most identity based risk models miss entirely: a legitimate device, plus a legitimate merchant account, plus a legitimate stored card, plus a legitimate browser session, does not add up to a legitimate transaction intent. Every one of those signals can check out perfectly while the one thing that actually matters, whether the account holder wanted this specific purchase, is entirely absent. Situations like a shared device, a curious child, a family member with access, or simply a moment of inattention are not exotic hypotheticals, and they are exactly the situations in which a fresh, per transaction confirmation of intent matters the most, rather than being the moment where the industry has decided that friction should be minimized.
2.2 Optimizing Against the Very Thing That Would Have Helped
If the underlying goal of a payments system is to reduce as far as possible how often a real human being has to explicitly confirm a transaction, then that system is quietly optimizing against the very mechanism that would have prevented exactly the kind of scenario described above. Every time a system finds a clever way to avoid asking the cardholder directly, it also removes an opportunity for the cardholder to say no to something they never intended to buy. The industry tends to describe this as removing unnecessary friction, but what it is actually removing is a checkpoint that exists specifically to catch the moments when the person in physical possession of a device or a card is not the person making the financial decision. Framing that checkpoint purely as friction to be minimized, rather than as a safeguard to be preserved, is the fundamental error running through most of the current thinking on authentication.
2.3 Consent Is Durable, Intent Is Contextual
There is a distinction worth drawing carefully here, because consent and intent are not the same thing and the difference matters enormously once recurring payments enter the picture. Consent, particularly in its contractual and regulatory sense, can be durable. A customer can agree today to a subscription or a mandate that legitimately authorizes transactions months into the future, and it would be absurd to demand a fresh biometric gesture for every renewal of a service the customer knowingly signed up for. Intent, by contrast, is contextual. It is a fresh signal that a human being consciously wants these specific transaction terms right now.
Recognizing that difference is what keeps this argument from collapsing into a demand that everything be challenged constantly. Merchant initiated transactions and recurring mandates are not a problem in themselves. The architectural property that matters is that a later authorization remains genuinely constrained by the terms the customer originally consented to, in amount, in merchant, and in scope. A durable consent that has been given for one thing should not quietly expand to cover something else, and an authentication result obtained in one context should not be treated as a general purpose credential valid for whatever comes next. The failure mode in both cases is identical, which is confirmation that has been detached from the specific thing it was given for.
3. What Apple Pay Authentication Actually Proves About Payment Security
3.1 Low Friction and High Security Are Not a Trade Off
The distinction the industry keeps collapsing is the difference between low friction and no friction. Low friction means the legitimate cardholder can confirm a transaction quickly, often in a couple of seconds, using something like a fingerprint or a face scan, and then move on with their day without any real interruption. No friction means the system tries to make the confirmation step disappear altogether, inferring consent from context, from device signals, or from a previously used credential, rather than asking the person directly whether they want this specific thing to happen. Apple Pay is the clearest existing proof that these two goals are not the same thing and do not need to be traded off against each other. Apple has explicitly built intent into the security architecture itself, rather than treating it as an afterthought. Apple’s own documentation states that a payment requires the system to verify both that the user confirmed their intent to pay and that the user authenticated themselves, and the transaction then generates a payment cryptogram unique to that payment. That is a direct architectural endorsement of the distinction this article is drawing, since Apple treats confirming intent and verifying identity as two separate conditions that must both be satisfied rather than as one combined check. What Apple Pay proves, then, is a specific and important thing: explicit intent can be made very nearly frictionless. The system does not skip the moment of confirmation in the name of speed. It makes that moment almost instantaneous by tying it to biometrics and a trusted, personally owned device, while still requiring, in the ordinary case, that the user do something deliberate to signal they want this payment to happen.
3.2 Secure Payment Confirmation and What Better Confirmation Looks Like
There is a second architectural example that proves something Apple Pay does not, and it comes from the standards body that governs 3DS itself. Secure Payment Confirmation, or SPC, uses device authenticators such as Touch ID, Face ID, or Windows Hello to produce cryptographic evidence that the cardholder accepted the specific terms of a transaction, including the merchant, the payment instrument, and the total amount. That last detail is the whole point. The confirmation is not a general assertion that a legitimate person was present somewhere in the flow. It is bound cryptographically to this merchant, this instrument, and this amount, which means it cannot later be reinterpreted as agreement to something else.
The two examples therefore do different work, and it is worth keeping them apart. Apple Pay demonstrates that explicit intent can be nearly frictionless. SPC demonstrates that intent can be cryptographically bound to the details of a specific transaction. Taken together they point toward a conclusion that runs directly against the current industry direction. The goal is not fewer confirmations. The goal is better confirmations. A biometric confirmation bound to the merchant, the instrument, and the amount is very nearly invisible to the customer while being enormously more meaningful than a risk score assembled from device history, and the industry is already building the primitive that would make this possible.
3.3 What Clients Actually Want
Card providers frequently describe their customers as wanting frictionless approvals, and use that assumption to justify pushing authentication further into the background. This misreads what clients actually want. Clients want very low friction, meaning they do not want to spend minutes or weeks approving something they clearly intended to buy. But clients also want to remain in control of their own money, which means they want to know when a new subscription is added, they want to be asked when an unfamiliar transaction is attempted, and they want the ability to say yes quickly rather than having that decision quietly made for them by a system trying to guess their intent. Low friction and full control can coexist, and Apple Pay demonstrates exactly how. The goal was never to remove the human from the loop. The goal was to make the human’s involvement as fast and as effortless as possible, while keeping it real.
4. Solving the Actual Problem in Card Authentication
4.1 Identity Is Not Intent Is Not Authorization
The problem statement that matters is not how to reduce the number of times a cardholder is asked to confirm a transaction. It is that the industry increasingly treats three distinct signals as though they were interchangeable. Authentication tells us who is present. Issuer authorization tells us the issuer is prepared to release the money. Neither of those, on its own or together, tells us that the cardholder consciously approved this specific transaction. Identity is not intent, and an approved authorization is not proof of consent. The shared device scenario described earlier is the cleanest demonstration of the gap, because it is not fraud in the way a stolen card number is fraud, and yet money moved that the account holder never agreed to spend.
Once those three signals are held apart properly, the real fault line becomes visible, and it is not cascading. Routing around a technical failure is sensible engineering. What causes the damage is confirmation that has not been bound to anything specific, so that evidence obtained for one merchant, one amount, and one moment can be stretched to cover attempts the cardholder never contemplated, and so that a decline carrying a clear instruction can lose that instruction on its way through an orchestration layer. 3DS cascading is not the enemy. Unbound confirmation is.
4.2 The Path Forward
The path forward is therefore not authentication free payments, and it is not a blanket rejection of orchestration or frictionless flows. It is confirmation that is nearly invisible to the customer while being cryptographically bound to the specific transaction it covers, in the way that Secure Payment Confirmation binds a biometric gesture to a particular merchant, instrument, and amount, combined with the lesson Apple Pay already demonstrates, which is that requiring a deliberate signal of intent need not cost the customer anything noticeable in time or effort. The right goal for the payments industry is not zero friction. It is near zero friction proof of intent, bound tightly enough to the transaction that it cannot quietly be reused for something else. Those are not the same target, even though the current conversation about frictionless payments consistently treats them as interchangeable.
5. References
EMVCo, 3-D Secure specifications and supporting documentation, covering payer authentication and the definition of the frictionless and challenge flows.
EMVCo, Secure Payment Confirmation documentation, covering cryptographic evidence that the cardholder accepted transaction terms including merchant, payment instrument and amount.
W3C, Secure Payment Confirmation working draft, covering cryptographic evidence that the user confirmed transaction details.
Apple, Apple Platform Security guide, covering the requirement that the system verify both confirmation of intent to pay and user authentication before a payment proceeds, and the generation of a per transaction payment cryptogram.
Mastercard, merchant advice codes documentation, covering the do not try again code and the conditions under which an authorization should not be resubmitted.
Visa, decline response and reattempt category documentation, covering the categories in which reattempting an authorization is prohibited and those in which limited retries are permitted.