🛡️Getting Started | 3D Secure
Finartz 3DS Secure is a suite of EMVCo certified 3D Secure solutions for securing online card payments. The suite includes Access Control Server, 3DS Server and Directory Server.
Should you have any questions, please reach out at 3ds@finartz.com
Overview
Access Control Server, ACS for short, is the 3D Secure component that handles the cardholder authentication. It resides in the issuer domain and can be used by card issuers. Finartz ACS is provided either as an on-premise solution or Software as a Service solution. The current version supported is v2.2.
SecureScore RBA is a rule-based tool that enables the risk analysis of a 3DS transaction to make a calculated decision to proceed without an additional cardholder challenge. SecureScore RBA is provided as part of Finartz ACS or as a standalone solution for 3rd party ACS operators.
3DS Server is the 3D Secure component that initiates the 3D Secure transaction and facilitates the communication between the merchant and the card issuer. It resides in the acquirer domain and can be used by acquirers, PSPs or merchants. Finartz 3DS Server is provided either as an on-premise solution or Software as a Service solution. The current version supported is v2.2.
Quick links
➡️ACS as a Service➡️ACS On-Premise➡️RBA as a Service➡️RBA On-Premise➡️3DS Server as a Service➡️3DS Server On-PremiseDefinitions & Abbreviations
Term | Definition |
3DS Client | The consumer-facing component allowing consumer interaction with the 3DS Requestor for initiation of the EMV 3-D Secure protocol. |
3DS Integrator | An EMV 3-D Secure participant that facilitates and integrates the 3DS Requestor Environment, and optionally facilitates integration between the Merchant and the Acquirer. |
3DS Method | A scripting call provided by the 3DS Integrator that is placed on the 3DS Requestor Website. Optionally used to obtain additional Browser information to facilitate risk-based decisioning. |
3DS Requestor | The initiator of the EMV 3-D Secure Authentication Request. For example, this may be a Merchant or a digital wallet requesting authentication within a purchase flow. |
3DS Requestor App | An 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 Environment | The 3DS Requestor-controlled components (3DS Requestor App, 3DS SDK, and 3DS Server) are typically facilitated by the 3DS Integrator. Implementation of the 3DS Requestor Environment will vary as defined by the 3DS Integrator. |
3DS Requestor Initiated (3RI) | 3-D Secure transaction initiated by the 3DS Requestor for the purposes of confirming that an account is still valid or for Cardholder authentication. The first main use case being recurring 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. |
3DS Requestor Website | Component that provides the website that requests Cardholder credentials (whether on file or entered by Cardholder). |
3DS SDK | A component that interacts with the 3DS Requestor App. The 3DS SDK performs functions related to 3-D Secure on behalf of the 3DS Server. |
3DS Server | Refers to the 3DS Integrator’s server or systems that handle online transactions and facilitates communication between the 3DS Requestor and the DS. |
3-D Secure (3DS) | An e-commerce authentication protocol that enables the secure processing of payment, non-payment and account confirmation card transactions. |
Abandon | The act of a Cardholder leaving a transaction by use of the Cancel action while in the process of a challenge. For example, using the Cancel button in the App challenge UI. |
Absent | Used in this specification to indicate that an element is absent when the name/value pair does not occur in the message. For example, element "firstName" is absent in the following JSON instance: { "lastName":"Smith" } |
Access Control Server (ACS) | A component that operates in the Issuer Domain, that verifies whether authentication is available for a card number and device type and authenticates specific Cardholders. |
Access Control Server User Interface (ACS UI) | The ACS UI is generated during a Cardholder challenge and is rendered by the ACS within a Browser challenge iframe. |
Acquirer | A financial institution that establishes a contractual service relationship with a Merchant for the purpose of accepting payment cards. In the context of 3-D Secure, in addition to the traditional role of receiving and sending authorisation and settlement messages (enters transaction into interchange), the Acquirer also determines whether a Merchant is eligible to support the Merchant’s participation in 3-D Secure. |
Acquirer Domain | Contains the systems and functions of the 3DS Requestor Environment and, optionally the Acquirer. |
App Screen Orientation | The orientation of the app screen display on the device, which may differ from the device orientation (for example, if the app supports Portrait-only or Landscape-only display, or if the device is in multi-window or split- screen mode). The orientation is considered Landscape if the display is wider than it is tall, and Portrait otherwise. |
Attempts | In this specification, used 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. |
Authentication | In the context of 3-D Secure, the process of confirming that the person making an e-commerce transaction is entitled to use the payment card. |
Authentication Request (AReq) Message | An EMV 3-D Secure message sent by the 3DS Server via the DS to the ACS to initiate the authentication process. |
Authentication Response (ARes) Message | An EMV 3-D Secure message returned by the ACS via the DS in response to an Authentication Request message. |
Authentication Value (AV) | A 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. |
Authorisation | A process by which an Issuer, or a processor on the Issuer’s behalf, approves a transaction for payment. |
Authorisation System | The systems and services through which a Payment System delivers online financial processing, authorisation, clearing, and settlement services to Issuers and Acquirers. |
Bank Identification Number (BIN) | The first six or eight digits of a payment card account number that uniquely identifies the issuing financial institution. Also referred to as Issuer Identification Number (IIN) in ISO 7812. |
Base64 | Encoding applied to the Authentication Value data element as defined in RFC 2045. |
Base64url | Encoding applied to the 3DS Method Data, Device Information, WebAuthn Credential List and the CReq/CRes messages as defined in RFC 7515. |
Browser | A Browser is a dedicated software application for accessing information on the World Wide Web, for example Chrome, Safari, Edge, Firefox. When a user requests a web page from a particular website, the Browser retrieves the necessary content from a web server and then displays the page on the consumer’s screen. In the context of 3-D Secure, the Browser is a conduit to transport messages between the Acquirer Domain and the Issuer Domain. A Browser is distinguished from a UI component for example, a WebView, or Custom Tabs, which can be used to display content within an App on a mobile device. The Browser flow is invoked by a Browser whereas the EMVCo specification does not support a UI component within an app invoking the Browser flow. |
Card | In this specification, synonymous to the account of a payment card. |
Card Range Data File | The file containing the JSON Card Range Data object. The Card Range Data provides to the 3DS Server the 3DS Protocol Versions supported by the card ranges hosted by the ACS, and other optional information (e.g. 3DS Method, Message Extension). |
Cardholder | An individual to whom a card is issued or who is authorised to use that card. |
Certificate | An electronic document that contains the public key of the certificate holder and which is attested to by a Certificate Authority (CA) and rendered not forgeable by cryptographic technology (signing with the private key of the CA). |
Certificate Authority (CA) | A trusted party that issues and revokes certificates. Refer also to DS Certificate Authority. |
Challenge | The process where the ACS is in communication with the 3DS Client to obtain additional information through Cardholder interaction. |
Challenge Flow | A 3-D Secure flow that involves Cardholder interaction as defined in Section 2.5.2. |
Challenge Request (CReq) Message | An 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 (CRes) | The 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 Device | Device used by a Cardholder such as a smartphone, laptop, or tablet that the Cardholder uses to conduct payment activities including authentication and purchase. |
Decoupled Authentication | Decoupled Authentication is an authentication method whereby authentication can occur independent from the Cardholder’s experience with the 3DS Requestor. The authentication method used for Decoupled Authentication is outside the scope of this specification. However, one method could be a push notification to a banking app that completes authentication and then sends the results to the ACS. Decoupled Authentication is applicable to all Device Channels. |
Decoupled Authentication Fallback | An additional challenge option for an ACS during the Challenge process. By returning Transaction Status = D in the RReq message, the ACS requests that the 3DS Server initiate a subsequent 3DS authentication using Decoupled Authentication. |
Device Binding | In this specification, the process to link the Consumer Device used for a transaction to the Cardholder Account and/or Cardholder. |
Device Channel | Indicates the channel from which the transaction originated. Either: · App-based (01-APP) · Browser-based (02-BRW) 3DS Requestor Initiated (03-3RI) |
Device Information | Data provided by the Consumer Device that is used in the authentication process. |
Digital signature | An asymmetric cryptographic method whereby the recipient of the data can prove the origin and integrity of data, thereby protecting the sender of the data and the recipient against modification or forgery by third parties and the sender against forgery by the recipient. |
Digital wallet | A software component that allows a user to make an electronic payment with a financial instrument (such as a credit card) while hiding the low-level details of executing the payment protocol, including such tasks as entering an account number and providing shipping information and Cardholder identifying information. |
Directory Server (DS) | A 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 Authority (DS CA) | A component that operates in the Interoperability Domain; generates and 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 ID (directoryServerID) | Registered Application Provider Identifier (RID) that is unique to the Payment System. RIDs are defined by the ISO 7816-5 standard. The Directory Server ID is a hex value encoded as a 10-character text. For example, 0x'A000000003' is encoded as 'A000000003'. |
Electronic Commerce Indicator (ECI) | Payment System-specific value provided by the ACS to indicate the results of the attempt to authenticate the Cardholder. |
Empty | An element is empty if the field name is present and the value is empty. For example, element "firstName" has no data in the following JSON instance. { "firstName":"", "lastName":"Smith" } |
EMV | A term referring to EMVCo’s specifications for global interoperability and acceptance of secure payment transactions and/or products and services complying with such specifications. |
EMV Payment Token | As defined in the EMV Tokenisation Specification, a surrogate value for a PAN that is a variable length, ISO/IEC 7812-compliant numeric issued from a designated Token BIN or Token BIN Range and flagged accordingly in all appropriate BIN tables. A Payment Token passes basic validation rules of an account number, including the Luhn check digit. Payment Tokens do not have the exact same value as or conflict with a PAN. |
EMVCo | EMVCo, LLC, a limited liability company incorporated in Delaware, USA. |
Ends 3-D Secure Processing | In the 3-D Secure processing flow, this indicates that no further processing as defined by this specification will be performed. Per Merchant preferences, an authorisation transaction may still be performed, although it will happen without a successful 3-D Secure authentication outcome. |
Ends processing | In the 3-D Secure processing flow, this indicates that an error has been found by a specific 3-D Secure component, which reports the error via the appropriate Error Message as defined in Section A.9 or RReq message as defined in Table B.8. The specific 3-D Secure component reports the error to the component from which the erroneous message was received, and may inform other components about the error and will stop further 3-D Secure processing. The subsequent 3-D Secure components in the authentication flow will still perform further execution of the received message with an Error Message to close the error situation. For an RReq message, the sending component should expect back an RRes message before stopping 3-D secure processing. |
FIDO Authenticator | An authentication entity that meets the FIDO Alliance’s requirements and which has related metadata. A FIDO Authenticator is responsible for user verification, and maintaining the cryptographic material required for the relying party authentication. For additional information, refer to: https://fidoalliance.org. |
Frictionless | The process of authentication achieved without Cardholder interaction. |
Frictionless Flow | A 3-D Secure flow that does not involve Cardholder interaction as defined in Section 2.5.1. |
Fully Qualified URL | A Fully Qualified URL contains all the information necessary to locate a web resource, and is defined as an ‘Absolute-URL string’ with scheme ‘https’, encoded in 'UTF-8' using 'url-code-points' from https://whatwg.org/ Refer to https://url.spec.whatwg.org/#absolute-url-string and to https://url.spec.whatwg.org/#url-code-points A Fully Qualified URL does not contain credentials (https://url.spec.whatwg.org/#include-credentials) Example: https://server.domainname.com/acs/auth%20(*ret |
iframe | An iframe (short for inline frame) is a frame within a frame. It is used to embed a piece of HTML content from other sources in an HTML document. Refer to: w3c: https://www.w3.org/html/wg/spec/the-iframe-element.html#the- iframe-element OR |
Information Only | Information Only is a Transaction Status value, whereby the ACS acknowledges the 3DS Requestor’s preference to not challenge on the transaction since the data sent was only for informational purposes. |
Interaction Counter | The number of interactions for each transaction is tracked by the ACS and sent with the RReq message to the Directory Server (DS). Used by the ACS to set a maximum number of Cardholder interactions as determined by the selected Challenge Flows and security requirements to allow an appropriate number of Cardholder retries without going beyond a pre-set maximum. |
Interoperability Domain | Facilitates the transfer of information between the Issuer Domain and Acquirer Domain systems. |
Issuer | A financial institution that issues payment cards, contracts with Cardholders to provide card services, determines eligibility of Cardholders to participate in 3-D Secure, and identifies for the Directory Server card number ranges eligible to participate in 3-D Secure. |
Issuer Domain | Contains the systems and functions of the Issuer and its customers (Cardholders). |
JavaScript Object Notation (JSON) | An open standard format that uses human-readable text to transmit data objects consisting of attribute-value pairs. It is typically used to transmit data between a server and web application. Refer to Table 1.1 for RFC references. |
Key | In cryptography, the value needed to encrypt and/or decrypt a value. |
Key management | The handling of cryptographic keys and other security parameters during the entire lifetime of the keys, including generation, storage, entry and use, deletion or destruction, and archiving. |
MAC | Message Authentication Code. A symmetric (secret key) cryptographic method that protects the sender and recipient against modification and forgery of data by third parties. |
Merchant | Entity that contracts with an Acquirer to accept payment cards. Manages the online shopping experience with the Cardholder, obtains card number, and then transfers control to the 3DS Server, which conducts payment authentication. |
Message Category | Indicates the category of the EMV 3-D Secure message. Either: · Payment (01-PA), or Non-Payment (02-NPA) |
Message Version | Refers to the Protocol Version that will be used by all components to process the 3-D Secure transaction. Message Version is always consistent across all 3-D Secure protocol messages for a specific transaction. |
Missing | An element is missing either if it is absent (that is the name/value pair does not occur in the message) or if the field name is present and value is empty. For example, element "firstName" has no data in both of the following JSON instances. Example of empty field name present and value empty: { "firstName":"", "lastName":"Smith" } Example of absent name/value pair: { "lastName":"Smith" } |
Name/value Pair (NVP) | A simple class encapsulating an attribute/value pair. |
Native | Refers to the original method for a device display, using its own APIs. |
Null | An element is null if the field name is present and the value is null. For example, element "firstName" has null in the following JSON instance. { "firstName":null, "lastName":"Smith" } |
One-Time Passcode (OTP) | A passcode that is valid for only one login session or transaction, on a computer system or other digital device. |
Out-of-Band (OOB) | A 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. |
OOB Authentication App | App on a Consumer Device that is used by the ACS to authenticate the Cardholder as part of the 3-D Secure flow, for example, a mobile banking app. See Section 3.2 for details of the OOB flow. |
Operation Request (OReq) Message | The OReq message sequence is created to communicate operational information serving as an alert, a reminder, report, or call to action. This message is not part of the 3-D Secure authentication message flow. |
Operation Response (ORes) Message | The ORes message acknowledges receipt of the OReq message sequence. The message is created by the recipient of the OReq message and sent to the source of the OReq message. |
Payment System | A Payment System defines the operating rules and conditions, and the requirements for card issuance and Merchant acceptance. |
Platform Provider | An entity that provides a digital ecosystem consisting of an operating system and/or hardware components, capable of uniquely identifying the consumer and their device through a user ID and a hardware-derived device ID, and sharing these IDs for the purposes of risk assessment and fraud prevention. |
Preparation Request (PReq) Message | 3-D Secure message sent from the 3DS Server to the DS to request the ACS and DS Protocol Version(s) 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 (PRes) Message | Response to the PReq message that contains the DS Card Ranges, active Protocol Versions for the ACS and DS and 3DS Method URL, or a Card Range Data File URL to download this information, so that updates can be made to the 3DS Server’s internal storage. |
Private key | Part of an asymmetric cryptographic system. The key that is kept secret and known only to an owner. |
Proof of authentication attempt | Refer to Attempts. |
Protocol Version | Defines the message interoperability between the EMV 3-D Secure components. |
Public key | Part of an asymmetric cryptographic system. The key known to all parties. |
Public key pair | Two mathematically related keys—a public key and a private key—that are used with a public key (asymmetric) cryptographic algorithm to permit the secure exchange of information without the necessity for a secure exchange of a secret. |
Registered Application Provider Identifier (RID) | Registered 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. |
Responsive Design | Responsive Design is an approach to make the web page content adjust to the dimensions of the device's screen for a better user experience. The approach is based on the use of three web techniques when designing the web pages: · Flexible grid to create the web page layout that dynamically adapt to the screen width. · Media queries to allow the page to adopt different CSS styles depending on the Browser and device screen. Flexible media to make images scalable to the size of the viewport. |
Results Request (RReq) Message | Message sent by the ACS via the DS to transmit the results of the authentication transaction to the 3DS Server. |
Results Response (RRes) Message | Message sent by the 3DS Server to the ACS via the DS to acknowledge receipt of the Results Request message. |
Secret key | A key used in a symmetric cryptographic algorithm such as DES which, if disclosed publicly, would compromise the security of the system. |
Secure Payment Confirmation | FIDO-based authentication to securely confirm payments initiated via the Payment Request API on a Browser. Refer to w3.org for additional information. |
Token Service Provider | A role within the Payment Tokenisation ecosystem that is authorised by a Token Programme to provide Payment Tokens to registered Token Requestors. Refer to the EMV® Payment Tokenisation Specification - Technical Framework. |
Transport Layer Security (TLS) | A cryptographic protocol developed by the IETF (Internet Engineering Task Force) to confidentially transmit information over open networks, such as the Internet. Refer to Table 1.1 for RFC references. |
Trust List | In this specification, the process of enabling the Cardholder to place the 3DS Requestor on their trusted beneficiaries list. |
Uniform Resource Locator (URL) | Address scheme for pages on the World Wide Web usually in the format http://www.example.com or https://www.example.com. |
Universal App Link | Operating System-registered HTTPS links for opening a specific mobile app, installed on a device. The implementation is platform-specific. · Android App Links: https://developer.android.com/training/app-links iOS Universal Links: https://developer.apple.com/ios/universal-links |
Universally Unique Identifier (UUID) | Identifier standard used in software construction. In its canonical form, a UUID is represented by 32 lowercase hexadecimal digits, displayed in five groups separated by hyphens, in the form 8-4-4-4-12 for a total of 36 characters (32 alphanumeric characters and four hyphens). Refer to Table 1.1 for RFC references. |
Validate | In this specification, the process of checking a message against the requirements for presence and format of each data element in the message as defined in Table A.1 and detailed outline in Section 5.1.6. Refer to Section 5.9 for additional information. |
Verify | In this specification, the process of checking a message cryptographically as defined in Section 6.2. Refer to Section 5.9 for additional information. |
Wallet | Refer to Digital wallet. |
WebAuthn | Defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users. Refer to https://www.w3.org/TR/webauthn-2/ |
X.509 | Certificate format as defined in RFC 4158. |
Last updated