{"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
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
\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
\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
\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
\n
A shipping address used for the first time<\/p>\n<\/td>\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