Card authentication and 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. Watch our video for an example of an authenticated checkout flow.

The Strong Customer Authentication regulation as part of PSD2 in Europe and similar regulations in the UK, India and Australia may require the use of 3DS for card payments. 3DS is optional in other regions but you can still use it 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.

Controlling when to present the 3D Secure flow

Stripe triggers 3DS automatically if required by a regulatory mandate such as Strong Customer Authentication or requested by an issuer with the soft decline code authentication_required.

You can also use Radar rules or the API to control when to prompt your end users to complete 3DS authentication, making a determination for each user based on the desired parameters. However, not all transactions support 3D Secure, for example wallets or off-session payments.

When 3D Secure is triggered, Stripe requires your end user to perform authentication to complete the payment if 3DS authentication is available for a card. Depending on what frontend you use this might require you to display the 3DS Flow.

In a typical Payment Intent API flow that triggers 3D Secure:

1. The end user enters their payment information, which confirms a PaymentIntent, SetupIntent, or attaches a PaymentMethod to a Customer.
2. Stripe assesses if the transaction supports and requires 3D Secure based on regulatory mandates, Radar rules, manual API requests, issuer soft declines, and other criteria.
3. If 3D Secure is:
   • Not required–For instance due to an exemption, Stripe attempts the charge. The PaymentIntent transitions to a status of processing. If requested by the issuer with a soft decline, we automatically reattempt and continue as if required.
   • Not supported–The PaymentIntent transitions to a status of requires_payment_method. Depending on the reason 3D Secure was triggered it may be permissible to continue to authorization for the charge. In that case, the PaymentIntent transitions to a status of processing.
   • Required–Stripe starts the 3D Secure authentication flow by contacting the card issuer’s 3D Secure Access Control Server (ACS) and starting the 3D Secure flow.
4. When Stripe receives 3D Secure flow information from the issuer, we attempt authentication. The PaymentIntent transitions to a status of requires_action:
   • See below how to display the 3DS action that is required. Issuers may request different 3D Secure flow action types, which might not always result in visibly displaying a 3D Secure challenge (e.g. a frictionless flow).
   • If the issuer does not support 3DS at all or has an outage, Stripe may attempt to complete the payment without authentication if permissible.
5. Depending on the 3D Secure authentication result:
   • Authenticated–Stripe attempts the charge and the PaymentIntent transitions to a status of processing.
   • Failure–The PaymentIntent transitions to a status of requires_payment_method, indicating a different payment method has to be tried, or 3D Secure can be retried by reconfirming.
   • Other scenarios–Depending on the reason 3D Secure was triggered it may be permissible to continue to authorization for the charge in edge cases. For example, a result of attempt_acknowledged leads to a charge and the PaymentIntent transitions to a status of processing.
6. The PaymentIntent transitions to one of the following statuses, depending on the outcome of the payment: succeeded, requires_capture, or requires_payment_method.

To track whether 3DS was supported and 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.result indicates the authentication outcome.

Use Radar rules in the Dashboard

Stripe provides default Radar rules to dynamically request 3DS when creating or confirming a PaymentIntent or SetupIntent. You can configure these rules in your Dashboard.

If you have Radar for Fraud Teams, you can add custom 3DS rules.

Manually request 3D Secure with the API

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

To trigger 3DS 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 you provide this parameter, Stripe attempts to perform 3DS 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 3DS before you create the PaymentIntent or SetupIntent. If your fraud engine inspects both card and transaction details, provide the parameter during confirmation—when 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 3DS authentication is available for a card. If it’s not available for the given card, the payment proceeds normally.

Stripe’s SCA rules run automatically, regardless of whether or not you manually request 3DS. Any 3DS 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
:" \
  --data-urlencode 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. On 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 the Failure button simulates an unsuccessful attempt at authentication.

All other Visa and Mastercard test cards don’t 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.

Disputed payments and liability shift

The liability shift rule applies to payments that are successfully authenticated using 3D Secure or an equivalent cryptogram such as Apple Pay or Google Pay in some cases. If a cardholder disputes a 3D Secure payment as fraudulent, the liability should shift from you to the card issuer.

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 practice this means you shouldn’t receive disputes marked as fraudulent if the payment was covered by the liability shift rule, but you’ll still receive an Early Fraud Warning. It’s still possible that you might receive a low percentage of fraudulent disputes, and we list a few cases below where the liability shift rule might not apply.

You might receive a dispute inquiry on a successfully authenticated payment using 3DS. This type of dispute doesn’t precipitate a chargeback because it’s basically a request for information.

If you receive an inquiry for a 3D-Secure-authenticated charge, it’s vital you respond because if you don’t, the cardholder’s bank can initiate a financial chargeback known as a no-reply chargeback that could invalidate the liability shift. 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 whom it was delivered to (whether it was physical or electronic goods, or services).

Liability shift might 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 can still shift to the issuer.

Sometimes payments that are successfully authenticated using 3DS don’t fall under 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. Certain networks have also exempted some industries from liability shift. For example, Visa doesn’t support liability shift for businesses engaging in wire transfer or money orders, non-financial institutions offering foreign or non-fiat currency, or stored-value card purchase or load.

In very rare cases, liability shift might get downgraded post-authorization, or the card networks’ dispute rejection system may fail to catch liability shift for a transaction. In these cases, if you choose to counter the dispute, Stripe automatically adds the outcome of the payment’s 3DS authentication to your evidence details, but we encourage you to include additional details to improve your odds of winning the dispute.

Custom Radar rules for 3D Secure and liability shift

If you have Radar for Fraud Teams, you can customize your rules to control when to request 3D Secure and how to handle each specific authentication outcome and liability shift. Stripe’s Strong Customer Authentication (SCA) rules run automatically and independently of custom Radar rules, and will block unauthenticated payments unless exempted.

Alternative 3DS implementations

See Import 3DS results for details on how to incorporate 3DS performed externally into your Stripe transaction.