Cardholder authentication using 3D Secure

Learn about 3D Secure, an additional layer of authentication used by merchants to ensure a purchase is from a legitimate cardholder.

A growing number of online merchants worldwide use 3D Secure 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 are 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

3D Secure is only used for online transactions, and only if the merchant supports it. When a 3D Secure authentication request comes through for your cardholder, Stripe will send a text message containing a one-time passcode to them for verification.

To enable us to best secure you and your cardholders, Stripe recommends keeping up-to-date phone numbers and email addresses for cardholders. This will enable us to reach out to them during authentication. You can update your cardholders information by setting the field you want to update to it’s new value through the API or dashboard.

Cardholders without phone numbers on file will not be enrolled in 3D Secure. You can add contact information to Cardholder objects in the future and we will auto-enroll them for you. Likewise, if you remove the phone number from your cardholder, we will un-enroll them from 3DS.

Liability shift

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

If the merchant is enrolled in 3DS but you, or your cardholder, are not enrolled in 3DS, that liability shift also applies. To prevent this from happening, you should enroll in 3DS and reject authorizations that were not properly authenticated. By rejecting these authorization attempts, the purchases will not 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 how best to action an incoming authorization.

Result Meaning Suggested action
attempt_acknowledged The merchant attempted to authenticate the authorization, but the cardholder is not enrolled or was unable to reach Stripe. There is insufficient evidence to determine if the authorization is fraudulent or not.
authenticated The shopper was successfully verified as the cardholder as they entered the correct verification code sent to their phone. Online purchase was legitimate and not fraudulent. Approve transaction.
failed The cardholder was not authenticated as the shopper which could mean the cardholder is not the actor making the purchase. Decline transaction.

Note: When verification_data.three_d_secure is not present, 3D Secure was not attempted by the merchant on an authorization.

Was this page helpful?
Questions? Contact us.
Developer tutorials on YouTube.
You can unsubscribe at any time. Read our privacy policy.