3D Secure

For extra fraud protection, 3D Secure (3DS) requires customers to complete an additional verification step with the card issuer when paying. Typically, you direct the customer to an authentication page on their bank’s website, and they enter a password associated with the card or a code sent to their phone. This process is familiar to customers through the card networks’ brand names, such as Visa Secure and Mastercard Identity Check.

Disputed payments and liability shift

Payments that have been successfully authenticated using 3D Secure are covered by a liability shift. Should a 3D Secure payment be disputed as fraudulent by the cardholder, the liability shifts from you to the card issuer. These types of disputes are handled internally, do not appear in the Dashboard, and do not result in funds being withdrawn from your account.

Liability shift can also occur when the card network requires 3DS, but it isn’t available for the card or issuer. This can happen if the issuer’s 3DS server is down or if the issuer doesn’t support it, despite the card network requiring support. During the payment process, the cardholder isn’t prompted to complete 3DS authentication, because the card isn’t enrolled. Although the cardholder didn’t complete 3DS authentication, liability still shifts to the issuer.

Sometimes payments that are successfully authenticated using 3DS don’t experience a liability shift. This is rare and can happen. There are also some industries that certain networks have exempted from liability shift—for example, Visa doesn’t support liability shift with businesses engaging in wire transfer or money orders, non-financial institutions offering foreign or non-fiat currency, or stored-value card purchase or load.

Although cardholders can’t dispute payments that have been successfully authenticated using 3DS as fraudulent with an upfront financial chargeback, issuers might initiate a dispute inquiry. This type of dispute is non-financial and is a request for information.

Responding to inquiries is important for any charge, but is vital when it involves a 3D-Secure-authenticated charge. Although the cardholder’s bank isn’t allowed to file an upfront financial chargeback for fraud, they can initiate a financial chargeback if the merchant doesn’t respond to the inquiry, known as a no-reply chargeback. To prevent no-reply chargebacks on 3DS charges, be sure to submit sufficient information about the charge. Include information about what was ordered, how it was delivered, and to whom it was delivered (whether it was physical or electronic goods or services).

How to present the 3D Secure flow?

When you run 3D Secure, DCDial displays the authentication UI in a pop-up modal when the customer clicks 'Confirm Payment'.

DCDial collects basic device information during 3D Secure 2 authentication and sends it to the issuing bank for risk analysis.

If a card doesn’t support 3DS or an error occurs during the authentication process, the payment proceeds normally. When this occurs, liability doesn’t generally shift to the issuer, as a successful 3DS authentication hasn’t taken place.

In a typical payment flow that triggers 3D Secure:

1. The customer enters their payment information.
2. DCDial assesses if the transaction requires 3D Secure based on pre-configured rules, manual requests, and other criteria.
3. If 3D Secure is:

• Not required – DCDial attempts the charge. If required by the bank, the customer completes an additional authentication step for the charge to succeed.
• Required – DCDial starts the 3D Secure authentication flow by contacting the card issuer’s 3D Secure server and creating a 3D Secure source.

• Successful – After the customer completes the 3D Secure authentication step, DCDial attempts the charge, and the payment transitions to a status of processing.
• Unsuccessful – DCDial makes a final attempt to complete the payment without authentication. The payment transitions to one of the following statuses, depending on the outcome of the payment succeeded, requires capture, or requires payment method.

Frictionless Authentication

3D Secure 2 allows businesses and their payment provider to send more data elements on each transaction to the cardholder’s bank. This includes payment-specific data like the shipping address, as well as contextual data, such as the customer’s device ID or previous transaction history.

The cardholder’s bank can use this information to assess the risk level of the transaction and select an appropriate response:

• If the data is enough for the bank to trust that the real cardholder is making the purchase, the transaction goes through the “frictionless” flow, and the authentication is completed without any additional input from the cardholder.
• If the bank decides it needs further proof, the transaction is sent through the “challenge” flow and the customer is asked to provide additional input to authenticate the payment.

Although a limited form of risk-based authentication was already supported with 3D Secure 1, the ability to share more data using 3D Secure 2 aims to increase the number of transactions that can be authenticated without further customer input.

Even if a transaction follows the frictionless flow, your business will benefit from the same liability shift that it does for transactions that pass through the challenge flow.