Cardholder authentication using 3D Secure

A growing number of online merchants worldwide use 3DS at checkout to match the identity of the shopper with the cardholder.

The additional 3D Secure step at checkout typically involves showing the cardholder an authentication page on their bank’s website, where they’re prompted to enter a verification code sent to their phone or email. This process is familiar to cardholders through the card networks’ brand names, such as Visa Secure and Mastercard Identity Check.

Example of a 3D Secure flow

Step 1: The customer enters their card details.

Step 2: The customer’s bank assesses the request and can complete 3D Secure at this step.

Step 3: If required by their bank, the customer completes an additional authentication step.

When is 3D Secure applied

The Strong Customer Authentication regulation in Europe requires the use of 3D Secure for card payments. 3D Secure is optional in other regions but can still be used as a tool to reduce fraud.

3DS is only used for online transactions, and only if the merchant supports it. When a 3DS authentication request comes through for your cardholder, Stripe sends them either a text message or an email containing a one-time verification code.

The method of authentication depends on the contact information provided for the cardholder. For EU and UK, cardholders must have a phone number on file to authenticate with a one-time text message verification code. For other regions, if cardholders provide both an email and phone number, they can generally pick which method to use at the time of the transaction. Otherwise, the authentication request defaults to using whichever contact info is available.

To enable us to best secure you and your cardholders, we recommend keeping up-to-date phone numbers and email addresses for cardholders. This enables us to contact them during authentication. You can update your cardholders information by changing the field to its new value through the API or dashboard.

Cardholders without a phone number or email on file won’t be enrolled in 3DS. You can come back and add contact information to Cardholder objects later, and we’ll auto-enroll them for you. Likewise, if you remove the contact info from your cardholder, we’ll un-enroll them from 3DS.

Cardholders may also see an additional security question. The cardholder is presented with a list of transactions on the card, from which the cardholder selects the transaction they recognize. If the cardholder is using the card for the first time, they should select the option indicating they don’t recognize any of the presented transactions.

The list of transactions the cardholder is presented with.

How is the 3D Secure language chosen?

The display language of the 3D Secure flow is determined by the preferred_locales field of the Cardholder object. If this field is not set, the 3D Secure language defaults to English.

Liability shift

When a payment is authenticated with 3DS and the cardholder later disputes it as fraud, the issuer might be liable for losses. This is called a liability shift. If the cardholder disputes the payments for any other reason (for example, other) then the standard dispute process applies.

If the merchant is enrolled in 3DS but you, or your cardholder, aren’t enrolled, that liability shift also applies. To prevent this from happening, enroll in 3DS and reject authorizations that weren’t properly authenticated. By rejecting these authorization attempts, the purchases won’t go through, so your cardholders won’t need to file fraud disputes on them in the future.

How to prevent fraud and reduce losses

On the Authorization, the three_d_secure hash on the verification_data hash will help you determine if an authorization was successfully authenticated.

The following table serves as a guide to help you determine what action to take on an incoming authorization.