Drop-in renders the available cards in your payment form and securely collects card information, so sensitive data doesn't reach your server. It also handles the 3D Secure 2 frictionless and challenge flows, including the data exchange between your front end and the issuer's Access Control Server (ACS).
Follow the instructions on this page if your integration uses the /payments or /payments/details endpoint, and Checkout API 49 or later.
If your integration uses only the /sessions endpoint, you don't need additional configuration for 3D Secure. If you're using Checkout API 46 or earlier, follow instructions in the 3D Secure 2 integration guide for v46 or earlier.
When making a card payment with native 3D Secure 2 authentication:
- Configure Drop-in to collect the cardholder name.
- Provide additional parameters when making a payment request.
- Submit authentication result if you receive an
action
object in response to your /payments or /payments/details request. - Handle the redirect result if the payment was routed to the 3D Secure 2 redirect flow.
Before you begin
This page explains how to add cards with native 3D Secure 2 authentication to your existing Web Drop-in integration. The Web Drop-in integration works the same way for all payment methods. If you haven't done this integration yet, refer to our Drop-in integration guide.
Before starting your integration:
- Make sure that you have set up your back end implementation, and added Drop-in to your payments form.
- Add the cards that you want to accept in your test Customer Area.
Show the available cards in your payment form
For information about the supported countries and currencies for each card, refer to Payment methods.
Drop-in uses the combination of countryCode and amount.currency from your /paymentMethods request to show the available cards to your shopper.
When the shopper is entering their card details, Drop-in tries to recognize the card brand. When successful, Drop-in renders the brand icon and the corresponding input field for the card security code (CVC, CVV, or CID).
Collect additional parameters in your payment form
For higher authentication rates, we strongly recommend that you collect the cardholder name, billing address, and email address for payments with 3D Secure authentication.
Configure Drop-in
When creating an instance of Drop-in, you can optionally specify:
Field | Description | Default |
---|---|---|
hasHolderName |
Set to true to show the input field for the card holder name. | false |
holderNameRequired |
Set to true to make the card holder name a required field. To show the field, you additionally need to set hasHolderName to true. |
false |
enableStoreDetails |
Set to true to show the checkbox for saving the card details for recurring payments. | false |
name |
String that is used to display the payment method name to the shopper. | Depends on the shopperLocale specified in /paymentMethods request. |
billingAddressRequired |
Set to true to collect the shopper's billing address. | false |
const dropin = checkout
.create('dropin', {
paymentMethodsConfiguration: {
card: { // Sample Drop-in configuration for 3D Secure
hasHolderName: true,
holderNameRequired: true,
enableStoreDetails: true,
name: 'Credit or debit card',
billingAddressRequired: true
},
threeDS2: { // Web Components 4.0.0 and above: sample configuration for the threeDS2 action type
challengeWindowSize: '05'
// Set to any of the following:
// '02': ['390px', '400px'] - The default window size
// '01': ['250px', '400px']
// '03': ['500px', '600px']
// '04': ['600px', '400px']
// '05': ['100%', '100%']
},
...
}
})
.mount('#dropin');
You can also customize your shopper's experience with optional configuration parameters and specific events.
Handle Drop-in errors
When an error occurs, Drop-in calls the onError
handler.
For errors that happen during the 3D Secure 2 authentication, you don't need to stop the payment flow because the shopper can continue.
Collect shopper email in your payment form
We also recommend that you collect the shopper email in advance in your payment form. Deliver this parameter to your backend when making a payment as it is required by the card schemes.
Make a payment
When the shopper selects to pay, Drop-in calls the onSubmit
event, which contains a state.data
.
- Pass the
state.data
to your server. -
From your server, make a /payments request, specifying:
Parameter name Required Description paymentMethod
The state.data.paymentMethod
object from theonSubmit
event.browserInfo
The state.data.browserInfo
object from theonSubmit
event.authenticationData.threeDSRequestData.nativeThreeDS
Set to preferred. Indicates that your payment page can handle 3D Secure 2 transactions natively.(authenticationData object is available from Checkout API v69) channel
Set to Web. origin
The origin URL of the page where you are rendering the Drop-in. This can be a maximum of 80 characters and should not include subdirectories and a trailing slash. For example, if you are rendering the Drop-in on https://your-company.com/checkout/payment
, specify:https://your-company.com
.
To get the origin:- Open the browser console and call
window.location.origin
.
returnUrl
In case of 3D Secure 2 redirect flow, this is the URL where the shopper is redirected back to after completing authentication. The URL should include the protocol: http://
orhttps://
. For example,https://your-company.com/checkout/
. You can also include your own additional query parameters, for example, shopper ID or order reference number.billingAddress
The state.data.billingAddress
object from theonSubmit
event.shopperEmail
The cardholder's email address. shopperIP
The shopper's IP address. - Open the browser console and call
For higher authorisation rates, we recommend that you send additional parameters.
For channel
Web, we recommend including these additional parameters: billingAddress
, shopperEmail
, and shopperIP
.
Your next steps depend on whether the /payments response contains an action
object. Choose your API version:
action.type |
Description | Next steps |
---|---|---|
No action object |
The transaction was either exempted or out-of-scope for 3D Secure 2 authentication. | Use the resultCode to present the payment result to your shopper. |
threeDS2 | The payment qualifies for 3D Secure 2, and will go through the authentication flow. | 1. Pass the action object to your front end to perform the authentication flow. 2. Submit the challenge result. |
redirect | The payment is routed to the 3D Secure 2 redirect flow. |
1. Store action.paymentData on your server. 2. Pass the action object to your front end.3. Handle the redirect result. |
The following example shows a /payments response with action.type
: threeDS2
Submit authentication results
Drop-in uses dropin.handleAction(action)
to perform the required authentication flow. If the issuer requires shopper interaction, Drop-in presents the challenge screen. Drop-in then calls the onAdditionalDetails
event.
- Get the
state.data
from theonAdditionalDetails
event, and pass it to your server. -
From your server, make a POST /payments/details request, specifying:
details
: Thestate.data.details
from theonAdditionalDetails
event.
The /payments/details response has a resultCode
. You will need it to present the payment result.
Present the payment result
Use the resultCode from the /payments or /payments/details response to present the payment result to your shopper. You will also receive the outcome of the payment asynchronously in a webhook.
For card payments, you can receive the following resultCode
values:
resultCode | Description | Action to take |
---|---|---|
Authorised | The payment was successful. | Inform the shopper that the payment has been successful. If you are using manual capture, you also need to capture the payment. |
Cancelled | The shopper cancelled the payment. | Ask the shopper if they want to continue with the order, or ask them to select a different payment method. |
Error | There was an error when the payment was being processed. For more information, check the
refusalReason
field. |
Inform the shopper that there was an error processing their payment. |
Refused | The payment was refused. For more information, check the
refusalReason
field. |
Ask the shopper to try the payment again using a different payment method. |
Test and go live
Use our test card numbers to test how your integration handles different 3D Secure 2 authentication scenarios.