Card authentication and 3D Secure

What is 3D Secure?

For extra fraud protection, 3D Secure 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. Watch our video for an example of an authenticated checkout flow.

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.

Web

iOS

Android

Step 1: The customer enters their card details.

Step 2: The customer’s bank assesses the transaction and can complete 3D Secure at this step.

Step 3: If required by their bank, the customer completes an additional authentication step.

Stripe supports 3D Secure 2. Your integration runs 3D Secure 2 when supported by the customer’s bank and falls back to 3D Secure 1 otherwise.

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 Stripe account.

Liability shift can also occur when 3D Secure 1 is required by the card network, but 3D Secure isn’t available for the card or issuer. This can happen if the issuer’s 3D Secure server is down or if the issuer does not support 3D Secure, despite the card network requiring 3D Secure support. During the payment process, the cardholder isn’t prompted to complete 3D Secure authentication, since the card is not enrolled. Although the cardholder did not complete 3D Secure authentication, liability still shifts to the issuer.

There are certain circumstances where payments that are successfully authenticated using 3D Secure do not experience a liability shift. This is rare and can happen, for example, if you have an excessive level of fraud on your account and are enrolled in a fraud monitoring program.

Although payments that have been successfully authenticated using 3D Secure cannot be disputed as fraudulent with an upfront financial chargeback, issuers may initiate a retrieval request. This type of dispute is non-financial, and is basically a request for information.

It’s important to note that responding to retrieval requests is important for any charge, but is vital when a 3D Secure-authenticated charge is involved. Although the cardholder’s bank is not allowed to file an upfront financial chargeback for fraud, they are allowed to initiate a financial chargeback if the merchant does not respond to the retrieval request, known as a no-reply chargeback. To prevent no-reply chargebacks on 3D Secure charges, be sure to submit sufficient information about the charge. You should include information about what was ordered, how it was delivered and to whom it was delivered (whether merchandise or services, etc.).

Controlling when to present the 3D Secure flow

Stripe triggers 3D Secure automatically if required by a regulatory mandate such as Strong Customer Authentication. You can also use Radar rules or the API to control when customers are prompted to complete 3D Secure authentication, making a determination for each user based on the desired parameters.

To track whether 3D Secure was attempted on a card payment, read the three_d_secure property on the card information in the Charge’s payment_method_details. Stripe populates the three_d_secure property when the customer attempts to authenticate the card—three_d_secure.succeeded indicates whether authentication succeeded.

Use Radar rules in the Dashboard

Stripe provides three default rules to dynamically request 3D Secure when creating or confirming a PaymentIntent or SetupIntent. You can configure these 3D Secure Radar rules in your Stripe Dashboard. The following screenshot depicts these Radar rules, which request additional authentication from customers when the issuer of their card requires 3D Secure:

The first rule is enabled by default, but you can choose to disable it.

If you have Radar for Fraud Teams, you can add custom 3D Secure rules using the syntax described in our Rules reference. Radar requests 3D Secure authentication for payments that match these rules. In the example below, the enabled rule requests 3D Secure authentication for payment attempts where the amount of the payment exceeds $500 USD and the risk level is not considered normal.

Manually request 3D Secure with the API

The default method to trigger 3D Secure is using Radar to dynamically request 3D Secure based on risk level and other requirements. Triggering 3D Secure manually is for advanced users integrating Stripe with their own fraud engine.

To trigger 3D Secure manually, set payment_method_options[card][request_three_d_secure] to any when creating or confirming a PaymentIntent or SetupIntent. This process is the same for one-time payments or future off-session payments. When this parameter is provided, Stripe attempts to perform 3D Secure and overrides any dynamic 3D Secure Radar rules on the PaymentIntent or SetupIntent.

When to provide this parameter depends on when your fraud engine detects risk. For example, if your fraud engine only inspects card details, you know whether to request 3D Secure before you create the PaymentIntent or SetupIntent. If your fraud engine inspects both card and transaction details, provide the parameter during confirmation—once you have more information. Then pass the resulting PaymentIntent or SetupIntent to your client to complete the process.

Explore the request_three_d_secure parameter’s usage for each case in the API reference:

• Create a PaymentIntent
• Confirm a PaymentIntent
• Create a SetupIntent
• Confirm a SetupIntent

When you set request_three_d_secure to any, Stripe requires your customer to perform authentication to complete the payment successfully if 3D Secure authentication is available for a card. If 3D Secure is not available for the given card, the payment proceeds normally.

Stripe’s SCA rules run automatically, regardless of whether you manually request 3D Secure. Any 3D Secure prompts from you are additional and not required for SCA.

Displaying the 3D Secure Flow

next_action: {
    type: 'redirect_to_url',
    redirect_to_url: {
      url: 'https://hooks.stripe.com/...',
      return_url: 'https://mysite.com'
    }
}

var action = intent.next_action;
  if (action && action.type === 'redirect_to_url') {
    window.location = action.redirect_to_url.url;
  }

stripe.confirmCardPayment(
  '{{PAYMENT_INTENT_CLIENT_SECRET}}',
  {
    payment_method: {card: cardElement},
    return_url: 'https://example.com/return_url'
  },
  // Disable the default next action handling.
  {handleActions: false}
).then(function(result) {
  // Handle result.error or result.paymentIntent
  // More details in Step 2.
});

curl https://api.stripe.com/v1/payment_intents/{{PAYMENT_INTENT_ID}}/confirm \
  -u 
sk_test_4eC39HqLyjWDarjtT1zdp7dc
: \
  -d "return_url"="https://example.com/return_url"

var iframe = document.createElement('iframe');
  iframe.src = paymentIntent.next_action.redirect_to_url.url;
  iframe.width = 600;
  iframe.height = 400;
  yourContainer.appendChild(iframe);

window.top.postMessage('3DS-authentication-complete');

function on3DSComplete() {
    // Hide the 3DS UI
    yourContainer.remove();

    // Check the PaymentIntent
    stripe.retrievePaymentIntent('{{PAYMENT_INTENT_CLIENT_SECRET}}')
      .then(function(result) {
        if (result.error) {
          // PaymentIntent client secret was invalid
        } else {
          if (result.paymentIntent.status === 'succeeded') {
            // Show your customer that the payment has succeeded
          } else if (result.paymentIntent.status === 'requires_payment_method') {
            // Authentication failed, prompt the customer to enter another payment method
          }
        }
      });
  }

  window.addEventListener('message', function(ev) {
    if (ev.data === '3DS-authentication-complete') {
      on3DSComplete();
    }
  }, false);

Testing the 3D Secure flow

Use a Stripe test card with any CVC, postal code, and future expiration date to trigger 3DS authentication challenge flows while in test mode.

When you build an integration with your test API keys, the authentication process displays a mock authentication page. In that page, you can either authorize or cancel the payment. Authorizing the payment simulates successful authentication and redirects you to the specified return URL. Clicking on the Failure button simulates an unsuccessful attempt at authentication.

All other Visa and Mastercard test cards do not require authentication from the customer’s card issuer.

You can write custom Radar rules in test mode to trigger authentication on test cards. Learn more about testing your Radar rules.