Integration Types
Other Features
Card Payments
Mobile Wallets
Alternative Payment Methods
Resources
3-Domain Secure™ (3-D Secure or 3DS) authentication is designed to protect online purchases against credit card fraud by allowing you to authenticate the payer before submitting an Authorization or Pay transaction. The eGenius Platform supports both 3DS versions — 3DS and EMV 3DS.
3DS, also known as 3DS1 in the gateway, is the original version that allows payers to authenticate at their issuer's Access Control Server (ACS) by entering a password previously registered with their card issuer. Supported authentication schemes include Mastercard SecureCode™, Verified by Visa™, American Express SafeKey™, J/Secure™, and Diners Club ProtectBuy™.
EMV 3DS, also known as 3DS2 in the gateway, is the new version designed to enhance security in online purchases while providing frictionless checkouts to payers who are considered low risk by the Access Control Server (ACS). The ACS may determine the risk using information provided by the merchant, browser fingerprinting, and/or previous interactions with the payer. The ACS subjects the payer to a challenge (for example, entering a PIN) only where additional verification is required to authenticate the payer thereby providing increased conversion rates. Supported authentication schemes include Mastercard SecureCode™, Verified by Visa™, American Express SafeKey™, Diners Club/Discover ProtectBuy, and JCB J/Secure.
While your payment service provider can configure both 3DS1 and 3DS2 on your merchant profile with the gateway, you can restrict the versions you want to accept by specifying your choice in the authentication request. If both are accepted then the gateway uses 3DS2 (if supported by the issuer and the card) and falls back to 3DS1 only where 3DS2 is not available. If both are not available, the authentication will not proceed. However, you can still proceed with the payment if the gateway recommends you to do so.
Here are some key terms that will be referenced throughout the 3DS integration documentation.
Term | Description |
---|---|
Access Control Server (ACS) | A component that operates in the issuer domain, which verifies whether authentication is available for a card number and device type, and authenticates specific transactions. |
ACS Method Call | Applies to 3DS2 authentication. It's a call that allows the ACS to gather additional data to determine the risk score for the payer. When 3DS2 is available and when the ACS call details are returned in the response after initiating the authentication, these details are passed to the payer's browser, which are submitted as a form post in a hidden iframe, so that the ACS can collect additional data. |
Frictionless Flow | An authentication flow where the payer is not required to respond to a challenge because the ACS deems the payer as low risk. |
Challenge Flow | An authentication flow where the payer is redirected to the ACS and is required to respond to a challenge to identify themselves, because the ACS does not have sufficient payer information to deem the payer as low risk. |
Payment Session | A payment session, or simply session, is a temporary container for any request fields and values of operations that reference a session. You can use it in an operation to reference the request fields and values than providing them directly in the operation request. When the gateway receives an operation that references a session, it forms the final request by combining the request fields in the session and those supplied directly in the request. For more information, see payment session. |
Session Authentication | Authentication using a payment session. This authentication allows payers to provide their payment details directly to the gateway via a client-side interaction with the gateway, either through a payer's browser or an app on the payer's mobile device. It uses basic HTTP authentication mechanism (similar to password authentication) where you must provide 'merchant.<your gateway merchant ID>' in the userid portion and the session Id in the password portion. To use this authentication type, you must first create a session by submitting a session request (see Create session [REST][NVP]) from your server to the gateway server. |
Merchant Authentication | A mechanism that allows the merchant to authenticate API requests to the gateway, for example, password/certificate/session authentication. |
Authentication API | A server-side API consisting of two operations, Initiate Authentication and Authenticate Payer, that must be submitted from your server to the gateway server. It can also be used as a client-side API using session-based authentication. |
3DS JavaScript API | A client-side JavaScript API that allows you to initiate 3DS authentication from the payer's browser using session-based authentication. |
Authentication Channel | Indicates where 3DS authentication is taking place, in the payer's browser, in an app on the payer's mobile device, or in your system with no payer present to interact. These have implications in terms of which authentication types and flows are available, for example, 3DS1 can only be supported in browser with a payer available for interaction with the ACS. |
Authentication Purpose |
|
To use gateway's 3DS authentication service:
The authentication flow for a payment differs depending on whether the card selected by the payer supports 3DS1 or 3DS2 or both.
The diagram below illustrates the authentication flow for a payment where the gateway falls back to 3DS1 authentication because 3DS2 is not available for the card. The gateway will attempt 3DS1 in other cases too, for example, where you are only enabled for 3DS1, or have restricted the authentication version to only 3DS1 in the authentication request.
The authentication flow for a successful authentication is as follows:
The diagram below illustrates the authentication flow for a payment where the payer is authenticated using 3DS2.
The authentication flow for a successful authentication is as follows:
The gateway supports the following 3DS authentication modes:
The gateway supports the following integration options for 3DS.
Integration Option | When to Use | Supported Transaction Modes |
---|---|---|
Hosted Checkout | This is the easiest integration option. With Hosted Checkout integrations version 57 and later, you must select 3-D Secure Authentication from the Payer Authentication dropdown, in the Admin > Integration Settings page of the Merchant Administrator user interface. To initiate 3DS authentication and other 3DS operations directly from the payer's browser, you must first establish the authentication channel where your merchant server must communicate with the gateway server for creating a session on the gateway. The gateway generated session Id is then included in all browser-initiated authentication requests as the password parameter (see session-based authentication) |
Authentication and Payment Transaction |
3DS JavaScript API | This is a client-side JavaScript integration if you want to initiate 3DS authentication from your website's payment page. Use this option if you want to allow the payer to submit their payment details directly to the gateway from the browser. To initiate 3DS authentication and other 3DS operations directly from the payer's browser, you must first establish the authentication channel where your merchant server must communicate with the gateway server for creating a session on the gateway. The gateway generated session Id is then included in all browser-initiated authentication requests as the password parameter (see session-based authentication). |
Authentication Only Authentication and Payment Transaction |
Authentication API | This is a server-side integration option that gives you total control over your integration but requires the highest integration effort. Use this option if you are required to customize API interactions between the payer's browser and the gateway. You must perform operations needed for managing the 3DS integration flows directly from your merchant server to the gateway server. It can be used as a client-side API using session-based authentication. |
Authentication Only Authentication and Payment Transaction. |