Glossary

This page provides a list of terms relating to 3D Secure 2, some are not used elsewhere in this documentation but are included for completeness of the subject area. Familiarise yourself with them now or refer back to this page when you come across an unfamiliar word.

TermAcronymDefinition
3DS ClientThe consumer-facing component, such as a browser-based or mobile app online shopping site, which facilitates consumer interaction with the 3DS Requestor for initiation of the EMV 3-D Secure protocol.
3DS IntegratorAn EMV 3-D Secure participant that facilitates and integrates the 3DS Requestor Environment, and optionally facilitates integration between the Merchant and the Acquirer.
3DS RequestorThe initiator of the EMV 3-D Secure Authentication Request, known as the AReq message. For example, this may be a merchant or a digital wallet requesting authentication within a purchase flow.
3DS Requestor AppAn App on a Consumer Device that can process a 3-D Secure transaction through the use of a 3DS SDK. The 3DS Requestor App is enabled through integration with the 3DS SDK.
3DS Requestor EnvironmentThis describes the 3DS Requestor controlled components of the Merchant / Acquirer domain, which are typically facilitated by the 3DS Integrator. These components include the 3DS Requestor App, 3DS SDK, and 3DS Server. Implementation of the 3DS Requestor Environment will vary as defined by the 3DS Integrator.
3DS Software Development Kit3DS SDK3-D Secure Software Development Kit. A component that is incorporated into the 3DS Requestor App. The 3DS SDK performs functions related to 3-D Secure on behalf of the 3DS Server.
3DS Requestor Initiated3RI3-D Secure transaction initiated by the 3DS Requestor for the purpose of confirming an account is still valid. The main use case being recurrent transactions (TV subscriptions, utility bill payments, etc.) where the merchant wants perform a Non-Payment transaction to verify that a subscription user still has a valid form of payment.
3DS Server3DSSRefers to the 3DS Integrator's server or systems that handle online transactions and facilitate communication between the 3DS Requestor and the Directory Server.
3-D Secure3DSThree Domain Secure, an eCommerce authentication protocol that for version 2 onwards enables the secure processing of payment, non-payment and account confirmation card transactions.
Access Control ServerACSA component that operates in the Issuer Domain, which verifies whether authentication is available for a card number and device type, and authenticates specific Cardholders.
AttemptsUsed in the EMV 3DS specification to indicate the process by which proof of an authentication attempt is generated when payment authentication is not available. Support for Attempts is determined by each DS.
AuthenticationIn the context of 3-D Secure, the process of confirming that the person making an eCommerce transaction is entitled to use the payment card.
Authentication Request MessageAReqAn EMV 3-D Secure message sent by the 3DS Server, via the DS, to the ACS to initiate the authentication process.
Authentication Response MessageAResAn EMV 3-D Secure message returned by the ACS, via the DS, in response to an Authentication Request message.
Authentication ValueAVA cryptographic value generated by the ACS to provide a way, during authorisation processing, for the authorisation system to validate the integrity of the authentication result. The AV algorithm is defined by each Payment System.
AuthorisationA process by which an Issuer, or a processor on the Issuer's behalf, approves a transaction for payment.
Authorisation SystemThe systems and services through which a Payment System delivers online financial processing, authorisation, clearing, and settlement services to Issuers and Acquirers.
Bank Identification NumberBINThe first six digits of a payment card account number that uniquely identifies the issuing financial institution. Also referred to as an Issuer Identification Number (IIN) in ISO 7812.
Base64Encoding applied to the Authentication Value data element as defined in RFC 2045.
Base64 URLEncoding applied to the 3DS Method Data, Device Information and the CReq/CRes messages as defined in RFC 7515.
CardCard is synonymous with the account of a payment card, in the EMV 3-D Secure Protocol and Core Functions Specification.
Certificate AuthorityCAAn entity that issues digital certificates.
CardholderAn individual to whom a card is issued or who is authorised to use that card.
ChallengeThe process where the ACS is in communication with the 3DS Client to obtain additional information through Cardholder interaction.
Challenge FlowA 3-D Secure flow that involves Cardholder interaction as defined in the EMV 3-D Secure Protocol and Core Functions Specification.
Challenge Request MessageCReqAn EMV 3-D Secure message sent by the 3DS SDK or 3DS Server where additional information is sent from the Cardholder to the ACS to support the authentication process.
Challenge Response MessageCResThe ACS response to the CReq message. It can indicate the result of the Cardholder authentication or, in the case of an App-based model, also signal that further Cardholder interaction is required to complete the authentication.
Consumer DeviceDevice used by a Cardholder such as a smart phone, laptop, or tablet that the Cardholder uses to conduct payment activities including authentication and purchase.
Device ChannelIndicates the channel from which the transaction originated. Either: • App-based (01-APP) • Browser-based (02-BRW) • 3DS Requestor Initiated (03-3RI)
Device InformationData provided by the Consumer Device that is used in the authentication process.
Directory ServerDSA server component operated in the Interoperability Domain; it performs a number of functions that include: authenticating the 3DS Server, routing messages between the 3DS Server and the ACS, and validating the 3DS Server, the 3DS SDK, and the 3DS Requestor.
Directory Server Certificate AuthorityDS CA or CA DSA component that operates in the Interoperability Domain; generates and Certificate Authority (DS distributes selected digital certificates to components participating in 3-D Secure. Typically, the Payment System to which the DS is connected operates the CA.
Directory Server IDRegistered Application Provider Identifier (RID) that is unique to the Payment System. RIDs are defined by the ISO 7816-5 standard.
Electronic Commerce IndicatorECIPayment System-specific value provided by the ACS to indicate the results of the attempt to authenticate the Cardholder.
FrictionlessUsed to describe the authentication process when it is achieved without Cardholder interaction.
Frictionless FlowA 3-D Secure flow that does not involve Cardholder interaction as defined in EMVCo Core Spec Section 2.5.1.
Message Authentication CodeMACA symmetric (secret key) cryptographic method that protects the sender and recipient against modification and forgery of data by third parties.
MerchantEntity that contracts with an Acquirer to accept payments made using payment cards. Merchants manage the Cardholder online shopping experience by obtaining the card number and then transfers control to the 3DS Server, which conducts payment authentication.
Non-Payment AuthenticationNPA3DS authentication type with no transaction attached, used for identity verification
One-Time PasscodeOTPA passcode that is valid for one login session or transaction only, on a computer system or other digital device.
Out-of-BandOOBA Challenge activity that is completed outside of, but in parallel to, the 3-D 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. ACS authentication methods or implementations are not defined by the 3-D Secure specification.
Preparation Request MessagePReq3-D Secure message sent from the 3DS Server to the DS to request the ACS and DS Protocol Versions that correspond to the DS card ranges as well as an optional 3DS Method URL to update the 3DS Server’s internal storage information.
Preparation Response MessagePResResponse to the PReq message that contains the DS Card Ranges, active Protocol Versions for the ACS and DS and 3DS Method URL so that updates can be made to the 3DS Server’s internal storage.
Proof or authentication attemptRefer to Attempts.
Registered Application Provider IdentifierRIDRegistered Application Provider Identifier (RID) is unique to a Payment System. RIDs are defined by the ISO 7816-5 Standard and are issued by the ISO/IEC 7816-5 Registration Authority. RIDs are 5 bytes.
Results Request MessageRReqMessage sent by the ACS via the DS to transmit the results of the authentication transaction to the 3DS Server.
Results Response MessageRResMessage sent by the 3DS Server to the ACS via the DS to acknowledge receipt of the Results Request message.