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.
If you are a US user, cards created will not automatically be enrolled in 3DS. Please reach out to support to enroll in 3DS.
Example of a 3D Secure flow
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.
To comply with the Strong Customer Authentication regulations, any cardholders who create EU or UK cards must have a
phone_number on file.
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.
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.
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
The following table serves as a guide to help you determine what action to take on an incoming authorization.
|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. The online purchase was legitimate and not fraudulent.||Approve the transaction.|
|failed||The cardholder wasn’t authenticated as the shopper which could mean the cardholder is not the actor making the purchase.||Decline the transaction.|
|required||The authorization was declined because regulatory requirements mandated an authentication for this transaction but it wasn’t submitted correctly by the merchant, and they didn’t claim an applicable exemption.||Decline the transaction.|
If the card is enrolled in 3DS, when
verification_data.three_d_secure isn’t present, 3D Secure wasn’t attempted by the merchant on an authorization.
However, if the card isn’t enrolled in 3DS and the merchant attempts 3D Secure, the payment can be declined, and
verification_data.three_d_secure won’t be present. Please reach out to support to enroll in 3DS.