Mastercard SecureCode to Identity Check: What Merchants Need to Know About Dispute Liability

Mastercard SecureCode was the brand name for Mastercard's original 3-D Secure authentication service, built on the 3DS 1.0.2 protocol. Mastercard has since moved that program to Identity Check, its brand for EMV 3-D Secure 2.x, and the 1.0.2 protocol SecureCode ran on lost network support industry-wide once card networks retired it (Visa's own discontinuation took effect October 15, 2022).

If you're still seeing "SecureCode" in an older integration, a processor contract, or a support article, this page covers what actually changed, what to check on your side, and how liability and evidence work now that the underlying technology is EMV 3DS.

Why the Name Changed

SecureCode authenticated a cardholder with a static password entered on a redirect page, using roughly 15 data elements per transaction. EMVCo published the EMV 3-D Secure specification in October 2016 to replace that model with a richer exchange, over 150 data elements, that lets issuers assess risk silently in most cases instead of interrupting checkout by default. Mastercard rebranded its implementation of the new protocol as Identity Check to separate it from the older, static-password SecureCode experience.

What to Check If Your Setup Still References SecureCode

• Confirm your payment service provider or acquirer is passing EMV 3DS 2.x requests, not a legacy 3DS 1.0.2 fallback that may silently fail authentication.
• Update any checkout copy, help-center articles, or internal documentation still labeled "SecureCode" so support staff and customers aren't chasing a retired term.
• Check that your integration sends Mastercard's four mandatory data fields as of July 1, 2026: cardholder name, billing address line 1, a contact method, and a device identifier. Missing fields increase the odds of a challenge or decline.
• If you process across card networks, confirm your Visa flows are on current EMV 3DS as well, since Visa's 3DS 1.0.2 sunset landed on the same October 2022 timeline.

How Liability and Evidence Work Now

The mechanics didn't change with the rebrand, only the protocol did. A fully authenticated transaction still generally shifts liability for a fraud chargeback to the issuer; requesting your own exemption to skip a challenge (for low-value or trusted-customer orders, for example) keeps that liability with you. Either way, the shift only covers fraud-coded disputes. Friendly fraud and non-fraud reason codes like item-not-received are never covered by the authentication result, authenticated or not. For the full breakdown of exemption categories and ECI outcomes, see the Mastercard Identity Check liability guide.

What you retain matters as much as what happened during checkout. Keep the ECI value, the CAVV or AAV cryptogram, the transaction timestamp, and the four mandated data fields for every authenticated order. That record is the foundation of compelling evidence when a dispute arrives, and it applies the same way to card-not-present fraud claims as it does to authenticated friendly fraud.

Reason codes are also worth checking against your acquirer's current documentation rather than assuming they match what you remember from the SecureCode era; networks retire and reassign chargeback reason codes over time, and citing a stale code in a dispute response weakens the response.

Conversion Friction Hasn't Changed Either, Only the Tools to Manage It

A step-up challenge still costs conversion on every order it interrupts, and the liability shift only pays that cost back on the orders that would otherwise have disputed as fraud. That tradeoff is why risk-based authentication, reserving challenges for higher-risk orders and requesting exemptions for trusted, low-risk ones, still outperforms a blanket challenge policy under Identity Check the same way it did under SecureCode. Pair that authentication strategy with chargeback prevention alerts to catch disputes before they escalate, and automated evidence responses for the disputes authentication was never going to stop.

Preguntas frecuentes

Is Mastercard SecureCode still used?

No new integration should be built against SecureCode. The 3DS 1.0.2 protocol it ran on lost network support industry-wide once card networks retired it, and any current Mastercard authentication runs on EMV 3DS 2.x under the Identity Check name.

What is the difference between Mastercard SecureCode and Identity Check?

SecureCode used a static password on a 3DS 1.0.2 redirect page. Identity Check runs on EMV 3DS 2.x, exchanging far more data so issuers can approve most transactions silently and reserve one-time-passcode or biometric challenges for higher-risk orders.

Do I need to change anything if my old documentation still says SecureCode?

Confirm your gateway or acquirer is actually sending EMV 3DS 2.x requests rather than a legacy fallback, update any internal references to the current name, and check that your integration includes Mastercard's mandatory 2026 data fields.

Does switching from SecureCode to Identity Check change chargeback liability?

The liability rules are the same: full authentication generally shifts fraud chargeback liability to the issuer, merchant-requested exemptions keep it with the merchant, and neither covers friendly fraud or non-fraud disputes.

Where can I find the full liability shift and exemption breakdown?

The Mastercard Identity Check liability guide linked above covers the full exemption table and authentication outcome breakdown in detail.

Chargeflow turns your authentication and evidence records into automated dispute responses, connected to chargeback prevention for everything a challenge prompt never touches.