Standalone authentication

Use standalone authentication when you want to separate authentication from authorization. In the standalone authentication flow, you make a payment request that specifies only authentication. When authentication is successfully completed, you receive the 3D Secure 2 authentication data which you can use to authorize the payment with Adyen or another payment service provider (PSP).

Requirements

Before you begin, take into account the following requirements, limitations, and preparations.

How it works

With standalone authentication, you perform the 3D Secure 2 authentication independently of the payment authorization flow.

1. Make a payment request, where you use the authenticationOnly parameter to specify that the request is only for performing authentication.
2. In the /payments response, use the action object to determine the authentication flow you need to perform.
3. Perform the required authentication flow.
4. Get the 3D Secure 2 authentication data.
5. Use the authentication data to authorize the payment with Adyen, or with another PSP or acquirer.

Keep in mind that authentication data is valid for a different time period for each scheme, and you can not use it after it expires.

Make a payment request for authentication

A payment request to perform standalone authentication is similar to making a /payments request for a payment authorization with your standard 3D Secure 2 integration. You add the authenticationOnly parameter to specify that you only want to authenticate the shopper.

To perform standalone authentication:

1. In your POST /payments request, specify:

   Parameter	Required	Description
   paymentMethod		Object that contains the shopper's card information from your front end or client app. Make sure that you: Include the encrypted, or if you are fully PCI compliant, unecrypted card details. For co-badged cards, set the brand to the scheme that you want to authenticate with. For Visa and JCB transactions, include the holderName.
   channel		Specify the platform that you are using. Possible values: Web iOS Android
   authenticationOnly		Set to true to trigger the standalone authentication flow.
   nativeThreeDS		Use case: if you have a native 3D Secure integration. Set to preferred to indicate that the native flow should be triggered when available.
   browserInfo		Object that contains information about the shopper's browser. The sub-fields that you must include in browserInfo depend on your integration type: For mobile integrations ( channel: iOS/Android): the acceptHeader, and userAgent sub-fields are required to support cases where the payment is routed to 3D Secure 2 redirect. For web integrations ( channel: Web): the full object, except javaScriptEnabled, is required.
   returnUrl		The URL where the shopper is redirected back to after completing authentication to support cases where the payment is routed to the 3D Secure 2 redirect flow. See our integration guides to learn how to set this URL depending on your platform.
   origin		Use case: required for browser-based (channel: Web) transactions. The origin URL of the page where you are rendering the Drop-in/Component. When this field is not set, or set incorrectly, the 3D Secure 2 action can not be handled correctly. Format: Maximum characters: 80 Do not include subdirectories and a trailing slash. Example: If you are rendering on https://your-company.example.com/checkout/payment, set to https://your-company.example.com.
   shopperIP		Use case: required for browser-based (channel: Web) transactions. The shopper's IP address. Required for channel web.
   billingAddress		The shopper's billing address.
   shopperEmail		Use case: required for Visa and JCB transactions. The cardholder's email address. If you do not include this, you must send the telephoneNumber, or a phone number in the threeDS2RequestData object.
   telephoneNumber		Use case: required for Visa and JCB transactions if you did not include the shopperEmail field. The shopper's phone number. To be more specific, you can use the mobilePhone, homePhone, and workPhone fields in the threeDS2RequestData object. Format: The phone number must include a plus sign (+) and a country code (1-3 digits), followed by the number (4-15 digits). Example: +4912345678901 If the value you provide does not follow the guidelines, we drop the value and do not submit it for authentication.

   Required for all transactions.
   Required for particular setups, or issuers and card schemes.
   Recommended for all transactions, but not required.

   We recommend that you do the following to prevent authorization refusals:

   • Include additional acquirer-related data if you plan to authorize the payment with a different acquirer. Refusals often happen when acquirer data mismatches between the authentication and authorization requests.
   • Include additional shopper information to increase the likelihood of achieving a frictionless flow.

2. In the /payments response, check the resultCode:

   • If the result code is AuthenticationNotRequired , You can proceed to authorize the payment with Adyen by making a standard /payments request, or with another PSP or acquirer.

   • If you get a 3D Secure 2 authentication result code, proceed to perform the authentication.

     resultCode	Description	Action to take
     ChallengeShopper	The issuer requires authentication from the shopper, for example through facial recognition or entering a code received on their phone.	Initiate the challenge flow to present the challenge to the shopper, and submit the result to Adyen.
     IdentifyShopper	The issuer requires authentication from the device the shopper is using.	Initiate the frictionless flow to get the shopper's device fingerprint, and submit the result to Adyen.
     RedirectShopper	The issuer requires the shopper to provide authentication in an an external web page or app.	Redirect the shopper to complete the authentication.

Perform the authentication

1. In the /payments response, you receive action.type: ThreeDS2. Use the action.subtype object to determine your next steps. The way to handle the action object for the standalone authentication flow is the same as handling it for your native or redirect 3D Secure implementation.

2. When authentication is completed, submit the authentication result in a /payments/details request, including authenticationData.authenticationOnly: true.
   Below is an example /payments/details request:

3. In the /payments/details response, check the following fields:

   • resultCode: If the authentication process has finished, you receive AuthenticationFinished. If an error occurs during the authentication flow, and the authentication process is not completed, you receive Refused.
   • threeDS2Result: The object that contains the authentication data that you need to authorize the payment following a successful authentication.
   • threeDS2Result.transStatus: Indicates the result of the authentication. The value Y means that authentication is successful.

     If the authentication went through the redirect flow, the result of the authentication is in additionalData.threeDAuthenticatedResponse.

Get the 3D Secure 2 authentication data

After a successful authentication, you get a resultCode with the value of AuthenticationFinished in the /payments/details response. The response contains threeDS2Result object, that contains the authentication data produced by a Merchant Plug-in (MPI).

Some schemes do not provide all fields; the Applies to column shows which schemes provide each field.

Authorize the payment

Use the 3D Secure 2 authentication produced by the MPI to authorize the payment with Adyen, or with another PSP. For information on authorizing with other PSPs, refer to their documentation.

For payment authorizations, keep the following in mind:

• You cannot reuse the authentication data across PSPs. For example, if you send a request to authorize the payment using the data to a PSP and it fails, you can not pass the same data to another PSP.
• Make sure to use the authentication data before it expires.

Authorize the payment with Adyen

To authorize the payment with Adyen, make a POST  /payments request, including:

1. The standard parameters required to make a payment. Make sure to pass the scheme that authenticated the transaction in the paymentMethod.brand object for co-badged cards.
2. The authentication data you received in the threeDS2Result object of the /payments/details response. Send this data in the mpiData object. The fields you need to send in your request map to the threeDS2Result fields as shown in the table below.
3. For Cartes Bancaires, include the required additional fields from the additionalData and the threeDS2RequestData objects. It is possible that you do not receive all Cartes Bancaires fields for each transaction, these fields are only required when they are returned in the /payments/details response that contains the authentication data.

You will receive an  Authorised resultCode if the payment authorization was successful. See  Result codes for a complete list of possible responses.

Authentication data expiry

Authentication data and cryptograms expire depending on card schemes. This means that you can no longer use the authentication data after it expires.

Authentication not required reasons

You get an AuthenticationNotRequired result code in the /payments response when a transaction doesn't require 3D Secure authentication. If you get this code, you can proceed with the standard payment flow with Adyen, or another PSP.

Below is the list of possible authenticationNotRequiredReason values:

Testing

Use our Testing 3D Secure 2 authentication guide to test your integration.

In this flow, you receive an AUTHENTICATION webhook that informs you of the outcome of the authentication.

See also