| 3D Secure (3DS) | An e-commerce authentication protocol that enables the secure processing of payment, non-payment, and account confirmation card transactions. |
| 3DS Client | The consumer-facing component that allows the cardholder to interact with other components and vice versa. |
| 3DS Method | A scripting call provided by the 3DS Integrator that is placed on the 3DS Requestor website. It allows for additional browser information to be gathered by an ACS before receipt of the AReq message to help facilitate the transaction risk assessment. The use of the 3DS Method by an ACS is optional. |
| 3DS Requestor | Initiator of the 3DS authentication request. |
| 3DS Requestor App | An App on a consumer device that can process a 3D Secure transaction through the use of Elavon’s Mobile SDKs (iOS or Android). |
| 3DS Server | Elavon’s server that handles online transactions and facilitates communication between the 3DS Requestor and the DS. |
| 3DS Integrator | Also referred to as ‘Integrator’ in Elavon’s 3DS documentation. An EMV 3D Secure participant that facilitates and integrates the 3DS Requestor Environment, and optionally facilitates integration between the Merchant and the Acquirer. |
| 3DS Requestor Initiated (3RI) | 3D Secure transaction initiated by the 3DS Requestor to confirm that an account is still valid or for Cardholder authentication. The main use case of a 3RI transaction is recurrent transactions (TV subscriptions, utility bill payments, etc.) where the merchant wants to perform a payment transaction to receive authentication data for each bill or a non-payment transaction to verify that a subscription user still has a valid form of payment. The second main use case is when the 3DS Requestor requests Decoupled Authentication as a method to authenticate the Cardholder. |
| Access Control Server (ACS) | A component of the Issuer Domain that verifies whether authentication is available for a card number and device type, and authenticates specific Cardholders. |
| Authentication request (AReq) | Message requesting authentication of the cardholder. Might contain cardholder, payment, and device details used in the transaction. |
| Authentication response (ARes) | ACS’s response if the transaction has been authenticated or needs further interaction to complete the authentication. |
| Authorisation | A process by which an Issuer, or a processor on the Issuer’s behalf, approves a transaction for payment. |
| Challenge flow | A 3D Secure flow that requires further cardholder authentication to process the transaction. |
| Challenge request (CReq) | Initiates cardholder interaction in a challenge flow. Sent by the SDK in an app-based scenario and sent by 3DS Server in a browser-based scenario. |
| Challenge response (CRes) | ACS response to indicate the result of cardholder authentication. In an app-based scenario, the CRes has the necessary elements to generate and display the UI for the challenge. |
| Decoupled Authentication | Decoupled Authentication is an authentication method whereby authentication can occur independently from the cardholder’s experience with the 3DS Requestor (browser/SDK). For example, a push notification to a banking app that completes authentication and then sends the results to the ACS (issuer). |
| Device Information | Data provided by the Consumer Device that is used in the authentication process. |
| Directory Server (DS) | A server that performs several functions that include: authenticating the 3DS Server, routing messages between the 3DS Server and the ACS, and validating the 3DS Server, the Mobile SDK, and the 3DS Requestor. |
| Frictionless flow | ACS authenticates the transaction without a challenge. |
| Mobile SDK (Releasing soon) | Software Development Kits (SDK) for iOS and Android. You must integrate the SDK into the merchant app so that it can be used for the 3D Secure (3DS) transaction authentication process. This SDK supports both EMV 3D Secure 2.1 and 2.2. |
| Integrator | An integrator can be an MSP (merchant services provider), a PSP (payment service provider), or other partners who use the 3DS 2 solution by Elavon and handle the payment relationship directly with the merchant. |
| Merchant | Entity that contracts with Elavon as an acquirer to accept payment cards. Manages the online shopping experience with the Cardholder, obtains the card number, and then transfers control to the 3DS Server, which conducts payment authentication. |
| Merchant alias | An alias for the merchantId of the service provider merchant. The integrator can use the merchant alias and their API key (the integrator’s API key) to retrieve the authentication token and send 3DS 2 related API requests on behalf of the merchant. |
| Message Category | Indicates the category of the EMV 3D Secure message. Either: Payment (01-PA) or Non-Payment (02-NPA) |
| Out-of-Band (OOB) | A Challenge activity that is completed outside of, but in parallel to, the 3D Secure flow. The final Challenge Request is not used to carry the data to be checked by the ACS but signals only that the authentication has been completed. |
| Result request (RReq) | Communicates the authentication or verification result sent by the ACS to the 3DS Server. The ACS sends this message only in a challenge flow. |
| Result response (RRes) | Receipt acknowledgment of the RReq message from the 3DS Server to the ACS. Present only in a challenge flow. |
| Service provider merchant | Merchant who does not process with Elavon and wants to use 3D Secure solution by Elavon. Such merchants get registered in Elavon’s database through an integrator, who could be their acquirer. |
| Whitelisting | In this specification, the process of an ACS enabling the cardholder to place the 3DS Requestor on their trusted beneficiaries list. |
