{"id":3209,"date":"2026-10-16T15:31:31","date_gmt":"2026-10-16T05:31:31","guid":{"rendered":"https:\/\/www.gpayments.com\/blog\/?p=3209"},"modified":"2026-10-16T15:31:32","modified_gmt":"2026-10-16T05:31:32","slug":"3ds-stored-card-account-takeover","status":"publish","type":"post","link":"https:\/\/www.gpayments.com\/blog\/article\/3ds-stored-card-account-takeover\/","title":{"rendered":"How to Authenticate Stored-Card Payments When Account Takeover Is Suspected"},"content":{"rendered":"\n

Stored cards make checkout quick for genuine customers and for anyone who gets into their account. An attacker who takes over a customer account does not need the card number, and often does not need the security code either. The payment looks like any other purchase by a returning customer.<\/p>\n

The merchant is often the only party that can see the takeover happening. EMV 3D Secure (EMV 3DS) gives it a way to pass that knowledge to the issuer, but only if the authentication request carries it.<\/p>\n

Why a takeover purchase can pass frictionlessly<\/h2>\n

An issuer’s Access Control Server (ACS) decides whether to challenge based on what it can see: the card’s history, the device, and the data the merchant sends. In a takeover, the card and merchant relationship are genuine and the account is long-standing. If the merchant sends the same data it would send for the real customer, the issuer has little reason to challenge. The signals that something has changed sit in the merchant’s own systems.<\/p>\n

Which EMV 3DS fields carry takeover signals<\/h2>\n

The EMVCo specification defines merchant-supplied data elements for exactly this kind of context:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
\n

What the merchant sees<\/strong><\/p>\n<\/td>\n

\n

EMV 3DS data element<\/strong><\/p>\n<\/td>\n

\n

Why it matters to the issuer<\/strong><\/p>\n<\/td>\n<\/tr>\n<\/thead>\n

\n

How the customer logged in this session, and when<\/p>\n<\/td>\n

\n

3DS Requestor Authentication Information (login method and timestamp)<\/p>\n<\/td>\n

\n

A guest checkout or a weak login carries different risk from a passkey sign-in<\/p>\n<\/td>\n<\/tr>\n

\n

A recent password change or reset<\/p>\n<\/td>\n

\n

Cardholder account information: password change date and indicator<\/p>\n<\/td>\n

\n

Password resets often precede takeover purchases<\/p>\n<\/td>\n<\/tr>\n

\n

Recent changes to email, phone or address on the account<\/p>\n<\/td>\n

\n

Cardholder account information: account change date and indicator<\/p>\n<\/td>\n

\n

Attackers change contact details to block alerts<\/p>\n<\/td>\n<\/tr>\n

\n

A shipping address used for the first time<\/p>\n<\/td>\n

\n

Cardholder account information: shipping address usage indicator<\/p>\n<\/td>\n

\n

New delivery addresses are a common takeover signal<\/p>\n<\/td>\n<\/tr>\n

\n

Shipping name different from the account name<\/p>\n<\/td>\n

\n

Cardholder account information: shipping name indicator<\/p>\n<\/td>\n

\n

Another signal of goods being redirected<\/p>\n<\/td>\n<\/tr>\n

\n

Suspicious activity already observed on the account<\/p>\n<\/td>\n

\n

Cardholder account information: suspicious account activity<\/p>\n<\/td>\n

\n

Directly tells the issuer the merchant has concerns<\/p>\n<\/td>\n<\/tr>\n

\n

How this card was last authenticated with the merchant<\/p>\n<\/td>\n

\n

3DS Requestor Prior Transaction Authentication Information<\/p>\n<\/td>\n

\n

Shows whether the card was previously challenged or authenticated frictionlessly<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

\u00a0<\/p>\n

Some merchants hold these values back for fear of triggering more challenges. In a takeover scenario, that is precisely the outcome they need. Sending accurate data in both directions also helps genuine customers: an account with a stable history and a strong login gives the issuer reasons not to challenge. Our article on the field-level rules behind requestor data quality<\/a> covers format requirements.<\/p>\n

When to ask for a challenge<\/h2>\n

When takeover signals are present, the merchant can also set the challenge indicator to 03, challenge requested at the merchant’s preference. That tells the issuer the merchant wants step-up for this transaction, whatever its own risk view. The issuer still decides, but it now has both the data and the merchant’s explicit request. Our article on the challenge indicator<\/a> explains each value.<\/p>\n

A workable rule of thumb is to request a challenge on a stored-card payment when two or more takeover signals appear together, for example a password reset in the last day combined with a first-time delivery address, and to tune that threshold against your fraud and abandonment data.<\/p>\n

Customer-initiated and merchant-initiated payments<\/h2>\n

This applies to payments the customer starts with a stored card. Merchant-initiated payments, such as subscription renewals, are not authenticated each time; they rely on the authentication of the original agreement (what happens after the first authentication<\/a>). An attacker who takes over an account and changes a subscription will show up in account-change signals rather than in a renewal authentication.<\/p>\n

What 3DS does not replace<\/h2>\n