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
When is 3D Secure applied
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 a text message containing a one-time verification code.
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 it’s new value through the API or dashboard.
Cardholders without phone numbers on file won’t be enrolled in 3DS. You can add contact information to Cardholder objects in the future and we’ll auto-enroll them for you. Likewise, if you remove the phone number from your cardholder, we’ll un-enroll them from 3DS.
When a payment is authenticated with 3DS and later disputed 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, aren’t enrolled, that liability shift also applies. To prevent this from happening, you should 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.|