Mastercard Identity Check: Authentication, Liability Shift, and Chargeback Evidence

Mastercard Identity Check is Mastercard's brand for EMV 3-D Secure (3DS), the authentication step that verifies a cardholder's identity during checkout and determines who is liable if the order is later disputed as fraud.

For merchants, the protocol details matter less than the outcome: a successfully authenticated transaction generally shifts fraud chargeback liability to the card issuer, but that shift only covers fraud-coded disputes, only applies when you can prove authentication happened, and only holds if you actually keep that proof once the dispute lands.

What Identity Check Replaced, and What Didn't Change

Mastercard Identity Check runs on EMV 3-D Secure 2.x, the specification EMVCo published in October 2016 to replace the original 3-D Secure 1.0.2 protocol. Mastercard SecureCode was the brand name for that older 3DS 1.0.2 implementation, and it lost network support once card networks retired the 1.0.2 protocol industry-wide (Visa's own discontinuation took effect October 15, 2022). If your integration, a processor contract, or an older support article still references "SecureCode," see the Mastercard SecureCode to Identity Check transition guide for what that means for your setup.

What didn't change is the underlying purpose: verify the cardholder, then decide who eats the risk if the order turns into a chargeback. What has changed is how much cardholder data Mastercard expects with each request. Through 2026, processor guidance points to stricter Identity Check data requirements, the cardholder's name, billing address line 1, at least one contact method, and device data, with requests missing these fields more likely to be challenged or declined, which pushes more legitimate orders into step-up friction.

The Authentication Flow and Its Outcomes

Every Identity Check attempt resolves into one of three outcomes, and the outcome is what your processor records in the transaction's ECI (Electronic Commerce Indicator) value:

• Frictionless authentication: the issuer assesses risk silently using the data sent with the request and approves without prompting the cardholder.
• Challenge flow: the issuer isn't confident enough to approve silently, so the cardholder is prompted for a one-time passcode or biometric step before the order proceeds.
• Not authenticated: the issuer's system is unavailable, the cardholder isn't enrolled, or authentication is never attempted.

Liability Shift and When It Doesn't Apply

The reason Identity Check matters to merchants is the fraud liability shift, but it isn't unconditional. Who requested the authentication path changes who holds the risk:

In other words: requesting your own exemption to skip a step-up prompt keeps the fraud risk on your books. That trade only makes sense for low-risk, low-value, or trusted-customer orders where the conversion lift outweighs the retained liability.

Which Disputes Stay Merchant-Liable After Authentication

The liability shift covers one thing: fraud-coded chargebacks where a cardholder claims they never authorized the transaction. It does not cover friendly fraud, where a real, authenticated cardholder disputes a charge they actually made, and it does not cover non-fraud reason codes like item-not-received, not-as-described, or processing errors. Those disputes still land on the merchant regardless of how the transaction was authenticated, which is why authentication has to sit inside a broader chargeback reason code response strategy rather than stand in for one.

This is also where card-not-present fraud and authenticated friendly fraud start to look similar from the merchant's side: both arrive as a dispute you have to answer with evidence, not with an ECI value alone.

What to Retain as Evidence After Every Authenticated Order

An ECI value on its own rarely wins a dispute. Issuers and networks want to see the underlying record. Keep, for every transaction:

• The ECI value returned by the authentication request.
• The CAVV or AAV cryptogram generated during authentication.
• The 3DS transaction ID and a timestamp of the authentication event.
• The cardholder data Mastercard's 2026 authentication requirements call for: cardholder name, billing address line 1, the contact method used, and device data.
• Whether the flow was frictionless or challenge-based, and if challenged, the method used (OTP, biometric, or app-based approval).

This is exactly the kind of record compelling evidence is built from, and it's far easier to assemble automatically at the time of sale than to reconstruct after a dispute notice arrives.

Weighing Step-Up Friction Against What It Actually Recovers

A challenge prompt costs you a small amount of conversion on every order it touches. The liability shift only pays that cost back on the subset of orders that would otherwise have become fraud chargebacks. That asymmetry is why a blanket "authenticate everything" policy usually costs more than it saves: risk-based authentication that reserves challenges for higher-risk or higher-value orders, while requesting exemptions for low-risk repeat customers, keeps friction where it earns its keep.

The same tradeoff is starting to show up in a newer context: as AI shopping agents begin completing checkout on a cardholder's behalf, authentication and liability rules built around a human answering a step-up prompt are being tested in ways the original 3DS design didn't anticipate. Merchants selling into agentic commerce channels should expect AI agent chargeback liability questions to follow the same evidence logic as any other authenticated order, proof of what was verified and when, not just a pass or fail flag.

Either way, authentication decisions work best paired with tools built for what happens after: chargeback prevention alerts catch disputes before they escalate, and automated evidence responses handle the ones that don't shift no matter how the order was authenticated.

Preguntas frecuentes

¿Qué es Mastercard Identity Check?

Mastercard Identity Check is Mastercard's brand for EMV 3-D Secure (3DS2), the authentication layer that verifies a shopper's identity during checkout, usually through a risk-based silent check or a one-time passcode or biometric step-up. It replaced the older Mastercard SecureCode, which ran on the retired 3DS 1.0.2 protocol.

¿El Mastercard Identity Check evita Contracargos?

It shifts liability for fraud-coded chargebacks to the issuer once a transaction is fully authenticated. It does not stop friendly fraud or non-fraud disputes like item-not-received claims, which still require merchant-submitted evidence regardless of authentication result.

What data should merchants keep as proof of authentication?

At minimum, the ECI value, the CAVV or AAV cryptogram, the 3DS transaction ID and timestamp, and the cardholder data Mastercard's 2026 authentication requirements call for: cardholder name, billing address line 1, a contact method, and device data.

Does using Identity Check on every order hurt conversion?

Challenging every transaction adds friction to orders that would never have disputed. Risk-based, frictionless authentication limits step-up prompts to higher-risk orders, which is why most processors recommend it over a blanket challenge policy.

Are merchants required to use Mastercard Identity Check?

Regions with strong customer authentication mandates, such as the EU under PSD2, effectively require it for most online card payments. Elsewhere it's optional, but skipping it means keeping full fraud liability on higher-risk or higher-value orders.

See how Chargeflow turns your authentication data into automated dispute evidence and pairs it with chargeback prevention for the disputes 3DS never touches.