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

Mastercard Identity Check is Mastercard's brand for EMV 3-D Secure (3DS), a checkout authentication service whose result can help establish eligibility for fraud liability shift. See Mastercard’s Identity Check overview.

Successful authentication can support liability shift for eligible fraud-coded disputes, but neither authentication nor ECI guarantees the outcome of a particular payment or dispute. Network rules, the authorization data and the actual dispute reason control. Stripe’s processor guidance describes this qualification and the need to respond to any applicable inquiry.

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.

Identity Check exchanges cardholder and device data so the issuer can assess the authentication request. Worldline’s processor guidance, referencing Mastercard’s May 2026 guide, describes expanded data requirements beyond a short four-field checklist. Check your gateway’s current requirements, including contact, billing/shipping and device fields. Worldline advises attempting authentication even if the new fields are missing rather than automatically stopping the process.

The Authentication Flow and Its Outcomes

The table summarizes common Identity Check 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

Liability shift applies to eligible fraud reason codes under the applicable network rules. The label friendly fraud does not by itself determine coverage: a first-party claim can still arrive under a fraud code. Non-fraud disputes such as item-not-received, not-as-described or processing errors follow their own evidence requirements, so authentication belongs inside a broader chargeback reason code response strategy.

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 is relevant to eligibility, but it does not guarantee liability shift or a dispute win. Issuers and networks want to see the underlying record. Keep, for every transaction:

• The ECI value returned by the authentication request.
• The processor’s authentication value; Mastercard uses AAV/UCAF, as described in Cybersource’s Identity Check guidance.
• The 3DS transaction ID and a timestamp of the authentication event.
• Relevant authentication-request and authorization records, with the cardholder, contact, billing/shipping and device data required by your current gateway integration.
• 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.

Perguntas frequentes

O que é o 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.

A verificação de identidade da Mastercard impede o uso do “ chargebacks ”?

Identity Check authentication can support liability shift for eligible fraud-coded disputes, subject to network and transaction conditions; it does not guarantee protection for every dispute. A “friendly fraud” label does not decide eligibility. Non-fraud disputes, such as item-not-received claims, follow their normal evidence process.

What data should merchants keep as proof of authentication?

Keep the ECI, processor authentication value, 3DS transaction ID and timestamp, plus the relevant request/authorization records. Follow the complete current field list for your gateway, including applicable contact, billing/shipping and device data; a short checklist does not establish every Mastercard requirement.

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 Chargeflow Prevent for the disputes 3DS never touches.