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 Who Actually Does What in a Card Payment

Because this argument turns on some fine distinctions, it is worth spending a moment on who does what, since the vocabulary of card payments is unhelpfully opaque and the same word often means different things depending on who is using it. When you buy something online, four parties matter. There is you, the cardholder. There is the merchant you are buying from. There is the merchant’s acquirer, which is the bank or provider that handles payments on the merchant’s behalf and passes the transaction into the card networks. And there is your issuer, which is the bank that gave you the card and which ultimately decides whether to release your money. Sitting alongside the acquirer there are usually processors and payment service providers, which are the plumbing that carries messages between the merchant and the networks, and increasingly there are orchestration platforms, which sit above all of that and decide which route a given transaction should take.

Two words then do most of the heavy lifting in this article, and they are routinely confused with one another. Authentication is the process of establishing that the person attempting a purchase is the legitimate cardholder, and on the web this is usually handled by 3D Secure, generally shortened to 3DS, which is the standard behind those moments when your bank interrupts a purchase to ask you to confirm it through your banking app or a one time code. Authorization is something quite different, and it happens afterwards. It is the issuer deciding whether to approve the transaction and release the funds, based on your balance, its own risk rules, and everything it knows about the transaction. Authentication asks who you are. Authorization asks whether the money should move. Keeping those two apart is the beginning of the argument that follows, and adding a third idea to them, whether you actually intended the purchase, is the whole of it.

1.2 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 a technique known as 3DS cascading. The idea is straightforward enough once the jargon is stripped away. Ordinarily a transaction is authenticated and then sent for authorization down a single route, and if that route fails the whole thing starts again from the beginning, including a fresh interruption for the customer. Cascading separates those two steps, so that the result of a successful authentication can be carried over into a second attempt sent through a different acquirer, without the customer being asked to confirm anything a second time. Whether this is possible at all depends on scheme rules, on certification, and on what the providers involved support, and cross provider portability of this kind is not universal. 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.3 The Problem Statement Has Been Quietly Swapped

The sleight of hand at the center of this entire conversation is that a question the payment system answers well has been quietly substituted for a question it answers badly. Four distinct things are involved, and the industry routinely collapses them into one. Authentication asks whether this is the legitimate user of the card. Participation asks whether that user is actively involved right now. Intent asks whether that user approved this particular purchase. Authorization asks whether the issuer will permit the payment to proceed. EMVCo, which governs the 3DS standard, describes payer authentication in terms of verifying that the person making the purchase is the legitimate cardholder. It does not define authentication as capturing consent, and that is precisely the point worth holding onto. The industry’s mistake is not that authentication has failed at its job. Authentication has become remarkably good at its job. The mistake is that authentication is increasingly asked to stand in for something it was never designed to prove, which is conscious transaction intent. A challenge is one of the few moments in the conventional card payment journey where a system can obtain fresh evidence that the legitimate user is actively participating, which is why removing it has consequences that go beyond convenience, but even a completed challenge establishes participation rather than intent.

1.4 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 3DS standard is governed by EMVCo, the body jointly owned by the major card networks that maintains the technical specifications everyone else builds against, and it explicitly defines two paths through authentication. There is a challenge flow, where you are interrupted and asked to confirm, and there is a frictionless flow, where the issuer assesses transaction, device, and behavioral information and authenticates you without interrupting you at all. 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.5 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, and they do it explicitly enough that ignoring it is a choice rather than an oversight. When an issuer declines a transaction it does not simply say no. It returns a reason, and alongside that reason the networks attach guidance about what the merchant is permitted to do next. Mastercard publishes what it calls merchant advice codes, which include a do not try again code covering situations such as suspected fraud, and that code tells the merchant and acquirer plainly 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. The decline, in other words, arrives carrying its own instructions about whether it may be retried. 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 resubmitting it repeatedly through alternative acquiring routes in the hope of obtaining an approval 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.

1.6 Authentication Can Be Transaction Bound and Still Not Prove Intent

It would be easy to assume the problem here is that authentication floats free of the transaction it covers, and that binding it more tightly would solve everything. That assumption is wrong, and it is worth dismantling early, because the industry has already done a great deal of the binding work. When you complete a 3DS authentication, the result is not a vague note that you were verified. It is a cryptographic value passed along with the transaction, and on the Visa network that value is called the CAVV, short for Cardholder Authentication Verification Value. Version seven of the CAVV can carry authentication information relating to the specific authentication transaction, including elements such as the merchant name and the purchase amount, and Visa treats it as unique to each authentication. Visa’s rules explicitly contemplate the misuse that arises when a previously validated CAVV is reused in an authorization containing different data, such as a different amount.

In Europe the requirement goes further and has the force of law. Under PSD2, the European payment services regulation, certain transactions require what is called strong customer authentication, and the rules impose a property known as dynamic linking. This means the authentication code must be specific to the amount and to the payee, and any change to either of those must invalidate the code. You cannot authenticate a fifty euro payment to one merchant and have that authentication quietly cover a five hundred euro payment to another.

So the payment industry is not naive about binding. In many cases the authentication is already tied cryptographically to a merchant and an amount, and it cannot legitimately be stretched to cover a different transaction. This is exactly why the more obvious criticism does not hold, and why the real problem is more interesting than it first appears. A CAVV can relate cryptographically to a specific merchant, a specific amount, a specific date, and a specific authentication event, while still failing to establish that a particular human being consciously chose to spend that amount at that merchant on that day. Binding proves that the authentication belongs to this transaction. It does not prove that the person the credential belongs to made a conscious decision to enter into it. Those are different guarantees, and the gap between them is where the trouble lives.

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. Recurring mandates and what the industry calls merchant initiated transactions, meaning payments the merchant triggers later without the customer being present, 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, meaning a single use cryptographic value that cannot be lifted and replayed on a different purchase. That is a direct architectural endorsement of the distinction being drawn here, 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. It is called Secure Payment Confirmation, usually shortened to SPC, and it is worth understanding what it actually does before considering why it matters. SPC uses the authenticators already built into your device, things like Touch ID, Face ID, or Windows Hello, but the crucial part is what happens before you place your finger on the sensor. The browser displays the terms of the transaction to you, showing the merchant, the payment instrument, and the total amount, and you confirm those specific terms as part of the act of authenticating. What comes out the other side is cryptographic evidence that the cardholder accepted those particular terms. 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 something more fundamental, because it changes the question being asked. Traditional authentication asks whether you are the legitimate user. SPC asks whether you are the legitimate user and whether you are approving these specific terms, displayed to you and confirmed by you before you authenticate. SPC matters because it finally starts treating authentication and transaction intent as separate problems that must be joined cryptographically, rather than assuming that solving the first automatically solves the second. That is the architectural evolution this entire argument is describing, and the encouraging part is that the industry has already begun building it. Taken together the two examples point toward a conclusion that runs against the prevailing direction of travel. The goal is not fewer confirmations. The goal is better confirmations.

3.3 What Cardholders 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 cardholders actually want. Cardholders want very low friction, meaning they do not want to spend time repeatedly approving something they clearly intended to buy. But cardholders 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 infer 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 Authentication Answers a Security Question, Not a Human One

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 treats distinct signals as though they were interchangeable. Authentication answers a security question, namely who is present. Authorization answers a financial risk question, namely whether the issuer will release the money. Neither of them answers a human question, namely whether the cardholder wanted this to happen. The uncomfortable part is how far this holds even when everything works correctly. The device can be genuine. The credential can be genuine. The authentication can be genuine. The CAVV can be genuine, and the merchant and amount can even be cryptographically bound into it. The issuer can legitimately approve the authorization. And the cardholder can still never have wanted the transaction.

That is the intellectual heart of the matter, and cascading is best understood as the case study that exposes it rather than as the villain of the story. Routing around a technical failure is sensible engineering, and modern authentication is frequently far better bound to a transaction than critics assume. 3DS cascading is not the enemy. The mistake is treating successful authentication as proof of transaction intent, and then building orchestration on top of that assumption which is permitted to discard the meaning of a decline on the way through.

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, and it is not tighter binding alone, since binding is a problem the industry has already gone a long way toward solving. It is near zero friction evidence that a human being actually intended this, joined cryptographically to the transaction it covers. Proving who was present and proving what they meant are different problems, and the payments industry has become extraordinarily good at the first while quietly assuming it implies the second.

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.

Visa, CAVV version 7 documentation for use with EMV 3DS, covering the authentication information a CAVV can carry and its uniqueness to each authentication transaction.

Commission Delegated Regulation (EU) 2018/389, regulatory technical standards on strong customer authentication, covering the dynamic linking requirement that an authentication code be specific to the amount and the payee.

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.