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.
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.
Why a takeover purchase can pass frictionlessly
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.
Which EMV 3DS fields carry takeover signals
The EMVCo specification defines merchant-supplied data elements for exactly this kind of context:
|
What the merchant sees |
EMV 3DS data element |
Why it matters to the issuer |
|
How the customer logged in this session, and when |
3DS Requestor Authentication Information (login method and timestamp) |
A guest checkout or a weak login carries different risk from a passkey sign-in |
|
A recent password change or reset |
Cardholder account information: password change date and indicator |
Password resets often precede takeover purchases |
|
Recent changes to email, phone or address on the account |
Cardholder account information: account change date and indicator |
Attackers change contact details to block alerts |
|
A shipping address used for the first time |
Cardholder account information: shipping address usage indicator |
New delivery addresses are a common takeover signal |
|
Shipping name different from the account name |
Cardholder account information: shipping name indicator |
Another signal of goods being redirected |
|
Suspicious activity already observed on the account |
Cardholder account information: suspicious account activity |
Directly tells the issuer the merchant has concerns |
|
How this card was last authenticated with the merchant |
3DS Requestor Prior Transaction Authentication Information |
Shows whether the card was previously challenged or authenticated frictionlessly |
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 covers format requirements.
When to ask for a challenge
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 explains each value.
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.
Customer-initiated and merchant-initiated payments
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). An attacker who takes over an account and changes a subscription will show up in account-change signals rather than in a renewal authentication.
What 3DS does not replace
- Strong login, ideally with passkeys, so that taking over the account is harder in the first place.
- Step-up verification on account changes such as email, phone or password.
- Notifications to the customer’s previous contact details when those details change.
- Holding or reviewing high-value orders to new addresses after recent account changes.
Frequently asked questions
Do network tokens protect against account takeover?
No. A network token protects the card number from theft and reuse elsewhere. In a takeover, the attacker uses the merchant’s own stored credential, token or not.
Will sending a suspicious-activity flag cause more declines?
It may cause more challenges, which is the purpose. A genuine customer can complete a challenge; an attacker usually cannot. Declines depend on the issuer’s own assessment.
Should every stored-card payment go through 3D Secure?
Not necessarily. Many merchants authenticate stored-card payments selectively, based on risk and market rules. Takeover signals are a strong reason to authenticate and to request a challenge.
Who carries liability if a takeover purchase is authenticated frictionlessly?
Liability follows the authentication outcome and card scheme rules. A fully authenticated transaction normally carries the protection of authentication even if the issuer did not challenge. Confirm current rules with your acquirer.
Which signal matters most?
There is no single answer, but recent password and contact-detail changes combined with a new delivery address are among the clearest. Measure which combinations precede fraud in your own data.
Sending the right signals
GPayments’ ActiveServer is a 3DS Server used by acquirers, payment gateways, PSPs and merchants. To review which account signals your authentication requests carry, speak with a GPayments 3DS specialist.