Getting Started
On this page
What is 3D Secure 2 and why should you use it
3D Secure 2 is an extra security layer defined by open_in_newEMVCoLink opens new window and major credit card schemes for CNP (card-not-present) transactions. As an e-commerce authentication protocol, it enables the secure processing of payment, non-payment, and account confirmation of card transactions.
Using 3D Secure 2, the issuer inspects over 100 data parameters to:
- verify the cardholder’s authenticity
- assess the risk level of the transaction
It acts as a protocol to authenticate a cardholder or verify an account during an e-commerce transaction:
- When the issuer determines the authentication is successful, the merchant can process the transaction without any cardholder interaction.
- If the issuer classifies the transaction as risky it challenges the customer to confirm their identity using Strong Customer Authentication (SCA) mechanisms.
High-level integration steps for developers
Use these high-level steps to guide you through the integration process.
Step 1: Review the 3D Secure solution integration options
You can use the 3D Secure 2 solution either as a standalone offering or as a feature if you are a Converge user.
To use 3DS 2 as a standalone offering, you can choose one or a combination of these options.
- Direct integration with the 3DS Server
- Web SDK
- Mobile SDK (Android) (releasing soon!)
- Mobile SDK (iOS) (releasing soon!)
See integration options and further details about using the 3DS 2 service in Converge.
Step 2: Get authentication credentials
To get authentication credentials that you would need to test the different integration options in the sandbox environment, fill in the information requested in this form.
open_in_new3D Secure 2 test credentials request formLink opens new window
We will send you the credentials by the next business day. We will also send contact details to whom you can reach out for any assistance required during the integration and testing process.
Additional resource
- How authentication works for 3DS APIs
Step 3a: Sandbox testing if integrating directly with the 3DS Server
Follow these high-level steps to test your server’s integration with the 3DS Server.
Action 1: Collect the required cardholder and transaction details.
Action 2: (Optional) To verify if the cardholder’s account number supports 3DS 2, send a /lookup
request.
Action 3: To initiate a 3DS 2 authentication check, send all required and optional (if available) cardholder and transaction details in an /authenticate
request.
Action 4: Verify the authentication response and use the information in the 3DS 2 test cards table for the next steps for the transaction status (transStatus
) you received in the response.
Additional resource
Detailed steps to follow when integrating directly with the 3DS Server. (Action 1 - 4 in Step 3a)
Test card numbers to test different authentication scenarios with various card schemes.
Step 3b: Sandbox testing if using the Web SDK
Follow these high-level steps to test your integration through the Web SDK.
Action 1: Embed the Web SDK JavaScript file to your payment page.
Action 2: Access the Web SDK functionality from the window object (window.Elavon3DSWebSDK
)
Action 3: Make a call to your server to get an authentication token that you will need to use with the Web SDK. Note that the Web SDK only supports JWT tokens for authentication.
Action 4: Create a new instance of the object and assign it to your preferred variable.
(const sdk = new window.Elavon3DSWebSDK({baseUrl: 'https://baseUrl', token: 'authentication token from Action 3'})
)
Action 5: Call the web3dsFlow
method (sdk.web3dsFlow(data)
)
This method will run the 3DS flow and display and handle any cardholder challenges if required by the issuer.
Action 6: Use authentication values received from the issuer in Action 5 to confirm the order.
You can also try the Web SDK demo application to test the different functionalities of the Web SDK.
Additional resource
Detailed steps to follow when integrating using the all-in-one workflow of the Web SDK (Action 1- 6 in Step 3b)
Test card numbers to test different authentication scenarios with various card schemes.
Step 4: Begin the onboarding process
After you have tested the different integration options, work with the Elavon representative to begin the onboarding process.
Before you go live, check for the following:
- You have the production endpoint and credentials.
- You have run different test scenarios such as frictionless, challenge, 3DS 2.2 to 2.1 fallback, and 3RI in the UAT (sandbox) environment. This step will give you the confidence to handle different scenarios in a production environment.
- You are boarded for all right card schemes. If you don’t have the required details, check with your Elavon contact.
- If you are using 3D Secure through Converge, then work with your Elavon contact to check that all required elements are enabled for your Converge environment.
Step 5: Go Live!
Action 1: Activate your production account.
Action 2: Connect your production environment to Elavon’s production server.
Action 3: Go Live!
Strong Customer Authentication (SCA)
SCA is the new requirement to make online payments secure by adding extra levels of authentication. In SCA, cardholders can verify their identity by using the following authentication mechanisms:
Something they know: password, passphrase, PIN, sequence, secret fact
Something they own: mobile device, wearable device, smart card, token, badge
Something they are: fingerprint, face recognition, voice, iris format, DNA signature
With SCA, issuers can use two or more means of authentication of their choice, thus increasing the chance of successful authentication and decreasing the cases of fraud. To know more about PSD2 and SCA compliance, see open_in_newElavon’s guide on PSD2 complianceLink opens new window.
3D Secure 2 Authentication flows
In the 3D Secure 2 authentication process, there are three authentication flows: frictionless, challenge, and 3RI. These authentication flows guide the communication (i.e. the requests and responses) among the different components - the cardholder, merchant’s website or app, the 3DS Server, the directory server (DS), and the issuer (ACS).
If the issuer verifies and authenticates a cardholder’s account details without any additional input from the cardholder, the transaction is a frictionless flow. But if the issuer needs more information from the cardholder to authenticate the transaction, the transaction is converted to a challenge flow. However, scenarios where a merchant already has the cardholder details are classified as a 3DS requestor-initiated flow.
Review the following sections for more details on these flows:
Frictionless flow
In a frictionless flow, the 3DS Server sends an authentication request to the issuer using the cardholder data sent by the merchant and receives a successful authentication response from the issuer. Based on the data received, the issuer determines that it does not need any cardholder interaction to complete the 3D Secure 2 authentication process.
Most 3D Secure 2 transactions are expected to be “frictionless.” The payments experience is improved because the cardholder is unaware that an authentication check has even taken place. Also, you don’t need to re-direct the cardholder to the issuer/Access Control Server (ACS) to enter a two-factor authentication.
Figure caption: Sample screens a cardholder might see for a frictionless flow
Challenge flow
In a challenge flow, the 3DS Server sends an authentication request to the issuer using the cardholder and shopping data the merchant sent but the authentication response sent by the issuer request extra information from the cardholder. For example, the issuer might challenge the cardholder (i.e., request for additional information) if it deems the transaction as high-risk or above a predetermined shopping value threshold.
To process the challenge, the 3DS client (Browser or SDK) sends the challenge request to the issuer. The issuer performs the challenge directly with the cardholder and responds with the challenge response after extra authentication by the cardholder is complete.
If the challenge response is successful, the issuer authenticates the transaction and returns the authentication values to the 3DS requestor. At this point, the 3DS requestor (merchant) may use the authentication values to proceed with transaction authorization.
Figure caption: Sample screens a cardholder might see for a challenge flow
3DS Requestor-initiated (3RI) flow
In a 3D requestor-initiated (3RI) or a merchant-initiated transaction, the cardholder is not present during the transaction. The merchant’s server has the cardholder’s information stored from an earlier transaction. Merchant can use this information for confirmation of account information or cardholder authentication. For example, confirmation of account validity in case of recurring transactions such as subscriptions, insurance premium payments, etc. For more details, see 3RI Overview.
Next steps
Review the integration options page to select an integration option that would work best in your environment. Use the sample use cases for guidance.
note
EMV 3-D Secure 2 is a new offering by Elavon. If you have identified any errors or gaps in the content, please contact: email#SEDevPortalSupport@elavon.com