3D Secure benefits cardholders and merchants by providing an additional layer of authentication. During the checkout process, if the cardholder is enrolled in 3D Secure, the issuing bank will decide whether the cardholder's identity can be verified using data supplied regarding the cardholder and their device, or if an additional authentication process is necessary. If additional authentication is necessary, the Braintree SDK will begin a process provided by the issuing bank to verify the cardholder’s identity via SMS one-time passcode, the issuing bank's mobile app, biometric methods, or other means. Learn more about 3D Secure processing in our support article.
In addition to helping fight fraudulent card use, 3D Secure can shift liability for fraud-related chargebacks from the merchant to the card issuer. For example, if the issuer does not participate in 3D Secure but the card brand supports this extra protection (i.e. Visa or Mastercard), the liability for fraud-related chargebacks will shift to the issuer.
3D Secure does not shift liability for all fraudulent chargebacks. You can determine whether or not liability shift occurred by the 3D Secure status code returned for the authentication.
- the 3DS 2 protocol allows many more data elements to be collected, allowing issuing banks to perform a much more effective risk assessment decision. As a result, issuing banks will be able to allow more transactions to proceed without requiring additional authentication from the cardholder.
- the 3DS 2 protocol includes support for mobile apps and devices, allowing for native mobile authentication experiences, without redirects or webviews.
- the 3DS 2 protocol includes greatly improved support for frictionless authentication, granting the benefits of liability shift without requiring further action from the cardholder. Note that availability may be limited in regulated markets that require strong customer authentication.
3DS 2 satisfies the Strong Customer Authentication (SCA) requirements coming into effect for European merchants transacting with European customers.
On the client side:
- Generate a client token
- Render a checkout page to collect customer payment information
- Verify the credit card amount
- The customer may then be prompted to authenticate if requested by the issuing bank, or otherwise required to do so by relevant local legislation
On the server side:
- If the authentication is completed successfully or none was required, use the returned
nonceto create a transaction.