Native 3DS2 Drop-in integration

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).

When making a card payment with native 3D Secure 2 authentication:

1. Configure Drop-in to collect the cardholder name.
2. Provide additional parameters when making a payment request.
3. Submit authentication result if you receive an action object in response to your /payments or /payments/details request.
4. Handle the redirect result if the payment was routed to the 3D Secure 2 redirect flow.

Requirements

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:

1. Make sure that you have set up your back end implementation, and added Drop-in to your payments form.
2. Add the cards that you want to accept in your test Customer Area.

Show the available cards in your payment form

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 cards with Drop-in

When creating an instance of Drop-in, you can optionally specify:

You can customize your shopper's experience further 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 do not 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, because 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.

1. Pass the state.data to your server.

2. From your server, make a /payments request, specifying:

   Parameter name	Required	Description
   paymentMethod		The state.data.paymentMethod object from the onSubmit event.
   paymentMethod.holderName	Required for Visa	The cardholder's name.
   browserInfo		The state.data.browserInfo object from the onSubmit 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:// or https://. 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 the onSubmit event.
   shopperEmail	Required for Visa	The cardholder's email address. shopperEmail or a phone number is required for Visa.
   shopperIP	Required for Visa	The shopper's IP address.
   threeDS2requestData.homePhone threeDS2RequestData.workPhone threeDS2RequestData.mobilePhone	Required for Visa	A phone number for the shopper, include one of these fields. shopperEmail or a phone number is required for Visa.

Your next steps depend on whether the /payments response contains an action object.

The following example shows a /payments response with action.type: threeDS2

Submit authentication results

Drop-in handles the action after it is returned within the onSubmit event and performs the required authentication flow. If the issuer requires shopper interaction, Drop-in presents the challenge screen.

When the shopper completes the challenge, Drop-in calls the onAdditionalDetails event.

1. Get the state.data from the onAdditionalDetails event, and pass it to your server.

2. From your server, make a POST /payments/details request, specifying:

   • details: The state.data.details from the onAdditionalDetails event.

   The /payments/details response has a resultCode. You will need it to present the payment result.

3. Pass the resultCode you received in the /payments/details response to the actions.resolve() object. Depending on the result code, the onPaymentCompleted or onPaymentFailed event is triggered to complete the payment flow.

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:

Test and go live

Use our test card numbers to test how your integration handles different 3D Secure authentication scenarios.

See also