Mastercard 3DS Mandate, the four required fields and How Visa’s rules differ

Mastercard has a new data requirement for online card payments. Since 1 July 2026, every 3D Secure (3DS) authentication request your checkout sends must carry four specific pieces of cardholder and device data.

The new rule is not the same as the one Visa introduced two years ago, and that is where merchants are getting confused. Visa’s rule, enforced from 12 August 2024, requires three fields. Those are:

1. The cardholder’s name
2. A contact method 
3. A browser or device IP address. 

Mastercard asks for those same three, plus billing address line 1. So if you did the Visa work in 2024 and assumed Mastercard wanted the same thing, you are one field short. This guide covers what to send, why billing address is the hardest of the four to get right, and why a filled-in field is not necessarily a correct one.

What is the Mastercard 3DS data mandate?

The Mastercard 3DS data mandate is a card scheme rule. It requires every 3D Secure authentication request to carry a set list of cardholder and device details, and it has applied since 1 July 2026. The rule sits within Mastercard Identity Check, which is Mastercard’s name for its EMV 3D Secure programme.

What changed on 1 April 2026

Mastercard published the updated requirements on 1 April 2026 and gave merchants and payment providers three months to adopt them. The change itself is small. Several fields that used to be required only in certain situations must now be sent on every request, according to Datatrans 3D Secure integration documentation updated on 31 July 2026.

The reason is data quality. EMV 3D Secure already lets the card issuer, meaning the bank that issued your customer’s card, approve an online purchase without asking the shopper to prove who they are. It only does so when the request carries enough information for the issuer’s risk engine, the automated system that scores each payment, to make that call. When a request carries too little, the issuer asks the shopper for extra proof instead, but every extra step loses some customers.

Who has to comply?

The mandate is a card scheme rule rather than a regional regulation, so it applies to any merchant using Mastercard Identity Check for card-not-present payments, meaning purchases where the card is not physically swiped or tapped. There is no European carve-out and no exemption for smaller merchants. If you accept Mastercard online and you use 3DS, these field requirements apply to you.

What are the four required 3DS fields from 1 July 2026?

Four pieces of data must reach the issuer on every authentication request. They’re listed below, along with what’s required and who supplies it.

Which fields to check first

Start with the contact method. You need at least one of the four options, and an email address or a mobile number gives the issuer more to work with than a landline does. Sending both an email address and a mobile number is always better than sending only one.

The device identifier usually needs nothing from your side. Most gateways already collect the browser IP address, device ID, screen size, language and time zone through their own 3DS script. But you should ask your provider to confirm this rather than assuming it, because gateway documentation does not always list the device identifier as a merchant obligation.

Optional fields worth sending anyway

Gateway documentation separates the required fields from a second group recommended strongly, and this group holds most of the remaining approval-rate improvement. You should send these whenever you have them. These are:

1. The rest of the billing address: Postal code, city, state and country. Only line 1 is required, but the issuer matches against the full address.
2. Shipping address line 1: Expected whenever you ship physical goods.
3. Browser details: Screen height and width, language and time zone, normally handled by your gateway.

How does the 3DS frictionless flow work?

A 3DS frictionless flow is a payment the issuer approves from the submitted data alone, with no passcode, no app prompt, and no redirect. Every field in the mandate exists to make this outcome more likely, and you need to keep track of the number of payments that are cleared this way.

When the payment clears without a challenge

EMV 3D Secure 2.0, which is the version of the protocol that replaced the old static password page, sends a large set of details to the issuer in the background before the shopper takes any action. Those details are the cardholder data requirements that the 3DS depends on. The issuer’s risk engine reads them, scores the payment, and returns an answer in seconds, and from the shopper’s side, the purchase simply completes in a matter of seconds.

When the shopper gets challenged

A challenge happens when the risk engine cannot approve the payment from the data alone. When it happens, the shopper is asked for extra proof, usually a one-time passcode by SMS or a fingerprint or face check in their banking app. These steps add more friction, and fewer shoppers finish a purchase when they’re presented with a challenge than without one. An incomplete authentication request therefore costs you sales long before anyone flags it as a compliance problem.

How does the Mastercard mandate differ from the Visa 3DS data mandate?

The two are close but not the same, so it is worth comparing them field by field.

Visa does not require a billing address

Visa’s own documentation lists three required data fields. They are the cardholder name, a contact method, and a browser or device IP address. Billing address is not one of them. Visa had originally proposed a longer list of twelve fields before cutting it to three ahead of the August 2024 enforcement date.

What is the difference between 3DS fields being present and being verified?

Present means the field has something in it. Verified means the contents have been checked against a trusted record.

The mandate only asks whether the field is filled in, not whether what you put in it is true. The issuer checks that for itself, because the issuer is the one deciding whether to approve the payment. So you can meet the mandate in full and still lose sales to inaccurate data.

Why wrong data hurts more than missing data

A billing address that is out of date, mistyped or autofilled with a delivery address still counts as present, so it satisfies the mandate. It can still damage the outcome. The issuer compares what you send against the address it holds on file, finds the two do not match, and treats that mismatch as a reason for caution. The payment may still be authenticated, but the risk engine trusts the request less and is more likely to ask for a challenge, which increases friction, which leads to users not completing the process.

Wrong data produces no error message and no alert. It reduces your approval rate slowly, one payment at a time, so it is worth checking your data quality now instead of waiting for someone to tell you your numbers are wrong.

Why billing addresses end up wrong

Three causes account for most of them.

1. Autofill: The browser drops a saved shipping address into the billing field, and the issuer holds no record of that address for this cardholder.
2. Format differences: Street written as St., flat written as apartment, or a postal code entered in another country’s format.
3. Old records: An address captured when the customer signed up years ago and never checked against the card since.

None of these look like fraud and none of them produce a visible failure, but all three quietly reduce the number of payments that clear without a challenge.

How Shufti helps merchants send verified cardholder data

If you sell in several countries, the hard part of this mandate is not collecting a billing address. It is making sure the address you send is in the right format for that country and matches what the issuer holds, because a wrong value damages the request more than a missing one does.

Shufti’s address verification checks an address against live global databases and splits free-form text into separate street, unit, city, region and postal code fields before that data reaches your authentication request. Its fuzzy matching handles the Street versus St. type of difference, so genuine cardholders are not turned away over formatting. Shufti actively processes addresses across 240+ countries and territories, which is where merchants selling internationally usually find the gap.