Mastercard Identity Check Liability Shift: 3DS2 Explained

What is the Mastercard Identity Check liability shift with 3DS2?

Mastercard Identity Check is Mastercard's version of 3-D Secure 2, the authentication layer that lets a card issuer verify the cardholder during an online purchase. When the authentication succeeds, liability for certain fraud chargebacks moves from the merchant to the issuing bank. That movement is the liability shift.

In plain terms: you ask the issuer to confirm the buyer is who they say they are. If the issuer confirms it and you pass along the authentication result correctly, the issuer, not you, generally carries the cost if that sale is later disputed as fraud.

This matters because online card-not-present sales are where fraud disputes tend to concentrate. A merchant who accepts a stolen card number normally loses the sale, the goods, and often pays a dispute fee on top. Identity Check is designed to change who holds that risk.

For the broader picture across card brands, see our guide to the 3D Secure liability shift.

How does 3DS2 differ from the older SecureCode version?

The older version of this program was called Mastercard SecureCode and relied on 3DS1. Buyers were often redirected to a pop-up or a separate page to type a static password. Many shoppers abandoned the purchase at that step.

3DS2 is built differently. It sends much more data about the transaction and the device to the issuer at the start. The issuer can use that data to judge risk in the background. Low-risk purchases can be approved without bothering the buyer, and only higher-risk ones are asked for extra proof.

The practical differences for a merchant:

• Better mobile and app support than the old redirect flow.
• Fewer interruptions for trusted buyers.
• A richer data exchange between merchant, gateway, and issuer.
• A challenge step only when the issuer wants more assurance.

The name changed too. Identity Check is the current Mastercard branding for this program, so searches for 3DS2 and Identity Check are really about the same thing.

When does the liability shift actually apply?

The shift applies when the transaction goes through authentication and the issuer returns a result that qualifies. If the cardholder later claims they never made the purchase, the dispute is typically coded as fraud, and the issuer absorbs it instead of you.

Several conditions have to line up:

1. The transaction must be an eligible card-not-present sale.

2. Authentication must actually be requested and completed through your gateway.

3. The issuer must return a result that qualifies for protection.

4. The authorization request must carry the authentication data so the network can see it.

5. The later dispute must be a fraud-type claim.

If any link in that chain is missing, you may still be treated as liable. The most common failure is not the buyer or the issuer. It is an integration where the authentication result never makes it into the authorization message.

What is the difference between a frictionless and a challenge flow?

In a frictionless flow, the issuer reviews the data it received and approves the buyer without asking for anything. The shopper sees nothing unusual and checkout feels normal.

In a challenge flow, the issuer decides it needs more assurance and prompts the buyer, for example with a one-time code or an approval in their banking app. If the buyer completes it, the authentication succeeds.

Both can result in a qualifying authentication. What matters is the result the issuer sends back, not whether the buyer saw a prompt. You do not control which flow a given buyer gets, because the issuer's risk engine makes that decision.

This is also why you should not treat a frictionless result as weaker. A properly returned approval is the signal your gateway needs to pass forward.

What does the liability shift not cover?

The liability shift is narrower than many merchants assume. It addresses fraud-coded disputes. It does not remove every kind of chargeback.

Examples of disputes that are generally outside the protection:

• The buyer says the item never arrived.
• The buyer says the product was not as described.
• The buyer says they cancelled and were still charged.
• The buyer says they were billed twice.
• Disputes about subscription terms or unclear billing descriptors.

Those are service and fulfillment disputes. Authentication proves who was paying, not whether you delivered what was promised. You still need clear descriptions, tracking, a plain refund policy, and a billing descriptor that customers recognize.

There are also edge cases where rules differ by transaction type, region, or card product. Because those details change over time, confirm your specific situation with your processor rather than relying on a general summary.

Does your gateway have to support Identity Check?

Yes. The merchant does not run authentication alone. Your gateway or payment platform connects you to the Mastercard directory, passes data to the issuer, and returns the result.

When you review a gateway, check these points:

• Does it support 3DS2 for Mastercard, not only the older flow?
• Can you decide when to request authentication, such as for all orders or only above a risk threshold?
• Does it forward the authentication result in the authorization request?
• Does it show you the authentication outcome per transaction so you can audit it?

If you cannot see the outcome in your reports, you cannot prove protection when a dispute arrives. Ask for that visibility before you rely on the shift.

Should every online order go through 3DS2?

Not necessarily. Authentication adds protection but can also add friction, so most merchants think in terms of risk and checkout experience together.

Some questions to weigh:

• How often do you see fraud disputes today?
• Are your orders high in value or easy to resell?
• Do you ship digital goods that are delivered instantly?
• Is your buyer base mostly returning customers on trusted devices?

A merchant with a history of fraud disputes on higher-value orders may choose to authenticate more broadly. A merchant with mostly small, repeat orders may use a risk-based approach and authenticate selectively. Neither is automatically right. The best setting depends on your own dispute history and your tolerance for checkout friction.

Remember that issuers also request authentication on their own in some regions where it is mandated, so your choice is not always the only factor.

How does Identity Check fit with your chargeback process?

Think of Identity Check as prevention and your dispute file as the backup. The shift helps when a fraud claim lands on an authenticated order. Your records help on everything else.

A sensible routine:

1. Save the authentication result and transaction ID with each order.

2. Keep delivery confirmation, especially for physical goods.

3. Store customer messages and the terms shown at checkout.

4. Respond to every dispute within the deadline, even when you expect protection to apply.

5. Review dispute reasons monthly to see whether fraud or fulfillment is the bigger source.

If the dispute is fraud-coded and the transaction was authenticated, your evidence of the authentication result is what supports the shift. Without it, the issuer's side has less reason to reverse the decision.

What does this mean for your card processing costs?

Chargebacks are a cost of doing business online, but they are not the only one. Fraud losses, dispute handling time, and the way you price card payments all affect your margin.

Authentication addresses one piece: who carries fraud liability. It does not change how you price acceptance. Many merchants pair fraud controls with a clear pricing approach. MidPay offers dual pricing so the card-price and cash-price are shown separately, which keeps the cost of accepting cards visible to the buyer at checkout.

If you want to talk through how your processing setup, your gateway, and your dispute exposure fit together, you can reach MidPay at 1-855-464-3576.

What should you do first to put this to work?

Start with a short audit rather than a big project:

1. Ask your gateway whether Mastercard Identity Check with 3DS2 is enabled.

2. Confirm the authentication result is passed in each authorization.

3. Pull your last few months of disputes and separate fraud claims from fulfillment claims.

4. Decide whether to authenticate all orders or only the riskier ones.

5. Document the process so your team handles disputes the same way every time.

These steps cost little and tell you quickly whether you are already protected or only assume you are.

Ready to see your rate?

If you want clear card processing with dual pricing, the next step is simple. See your rate.

Frequently asked

Is Mastercard Identity Check the same as 3D Secure?

Identity Check is Mastercard's branded implementation of 3-D Secure. The current version uses the 3DS2 standard. Other card brands use their own names for the same underlying protocol, which is why you may see several brand names in your gateway settings.

Do I still need to respond to a chargeback if I authenticated the order?

Yes. Respond to every dispute by its deadline. Submit the authentication result along with your order records. Ignoring a dispute can lead to a loss even when the transaction was authenticated, so treat protection as support for your response, not a replacement.

Can a buyer fail authentication and still complete the order?

That depends on your gateway rules and your own settings. Many merchants decline or review orders where authentication fails. If you choose to process one anyway, you should assume the protection may not apply and weigh that risk before shipping.

Does 3DS2 slow down checkout for customers?

Usually less than the older version. Because the issuer receives rich data up front, many low-risk purchases pass without any prompt. Some buyers will still see a challenge step, such as a one-time code, when the issuer wants extra assurance.

Does the liability shift apply to recurring or subscription payments?

Rules for repeat billing differ from one-time purchases, and the initial authentication often matters most. Details vary by transaction type, so confirm with your processor how stored credentials and recurring charges are treated before assuming coverage.

How do I know my gateway is passing authentication data?

Check your transaction reports for an authentication result field on each order, and ask your gateway provider to confirm the data is included in the authorization message. If you cannot see it, request that visibility so you can prove it during a dispute.