In the Core Specification, Device Information is defined to allow rich device data collection on App-based transactions. The EMV® EMV 3-D Secure—SDK Device Information specification defines common and operating system-specific device elements to be captured by the 3DS SDK during an Authentication Request (AReq). This rich device data set assists in assessing transaction risk. In addition, it may provide information on the capabilities of the device to inform presentation of authentication methods during a challenge request.
Device Information is applicable to all App-based implementations, including the Default-SDK and the Split-SDK (and its variants). Some examples of device information may include:
The Device Information data is collected by the 3DS SDK using the built-in operating system APIs. The data is then encrypted by the 3DS SDK using the DS public key and sent to the 3DS Server for forwarding on the Authentication Request (AReq) as SDK Encrypted Data (sdkEncData). Once received by the DS, the SDK Encrypted Data will be decrypted and the Device Information will be sent to the ACS for use in risk assessment and/or Cardholder verification.
The decrypted Device Information will include one of the following groups of data elements ;
Within the OS-specific Device Parameters, there are varying degrees of data elements available, ranging from probabilistic device identifiers to user profile metadata on the device. These data elements are captured in JSON name/value pairs, using an Identifier name key:
This format allows for flexibility in the capturing of the Device Information as the operating systems continually evolve. With operating systems typically releasing at least one major version per year, the Identifier name key and the format definition of the data elements in the Device Information specification can be adapted quickly when certain data elements are modified or restricted by the OS platform providers.
The SDK Device Information specification has received multiple publications, each incrementing the version of the Device Information object (name/value pairs). All 3DS components are expected to support the latest Device Information version to maintain compatibility with each OS platform provider.
The SDK Device Information specification enables secure transfer of data to the ACS by encrypting the device data in transit from the 3DS SDK using the DS public key. This prevents the 3DS Requestor or any unauthorised party from accessing or modifying device-level data during an Authentication Request.
The DS public key must be obtained from each supported network and the process is subject to network program rules (i.e., requires a valid EMVCo Letter of Approval). The connection between the 3DS SDK and the DS is required to be secured via the DS public key, even though the 3DS Server is facilitating the connectivity. This preserves the privacy of the Cardholder and upholds the security model established via the EMV 3DS protocol. Similar to the 3DS Method URL, all device information is accessed only by the ACS.
In line with regional regulations and/or operating system provider policy, the 3DS Requestor is required to provide prominent disclosure of the use of data in the application at the time of submission to the operating system provider. This includes specifying which data elements may be collected and used as part of a 3DS authentication.
At the time of installation, the 3DS Requestor App must prominently disclose to the user that:
When use of sensitive user data is invoked for a 3DS authentication, the 3DS SDK must verify user consent and permission prior to requesting any sensitive user data from the 3DS Requestor App. This shall be implemented in accordance with the Permission designation provided in the SDK Device Information specification.
Note: The 3DS SDK shall never prompt for user consent or permission to any data within a 3DS authentication.
EMV 3-D Secure—SDK Specification
Core Specification [Req 1–25]
Table 2.1: 3DS Data Elements Related to Device Information for the App-Based Flow
Data Element | Description | Version |
---|---|---|
SDK Encrypted Data | Device information gathered by the 3DS SDK from a Consumer Device. This is JSON name/value pairs that as a whole is Base64url-encoded. This will be populated by the DS as unencrypted data to the ACS obtained from SDK Encrypted Data. | 2.3.1 2.2 |
SDK Encrypted Data | JWE Object (represented as a string) as defined in Section 6.2.2.1 containing data encrypted by the 3DS SDK for the DS to decrypt. | 2.3.1 2.2 |
For each Browser-based transaction, the 3DS Server populates a set of Browser-specific data as follows:
In addition to this data, the 3DS Method URL is a mechanism defined in the 3DS protocol that allows the ACS to gather detailed device and browser information during the checkout process, prior to authentication, enhancing risk-based decisioning during a 3DS authentication.
Executing the 3DS Method URL early in the checkout process maximises the likelihood that the Issuer has the necessary information for risk assessment before authentication, potentially improving authentication success rates and reducing customer abandonment. This involves loading a URL in a hidden iframe to execute JavaScript for browser fingerprinting, gathering data such as browser device characteristics.
Merchants must run the 3DS Method URL if requested by the Issuer, as failure to do so can result in higher step-up rates and increased authentication failures. The collected data helps Issuers to make informed risk decisions based on the device used by the Cardholder for the transaction and accurately assess the transaction contexts. The process is asynchronous and transparent to consumers, typically completing within 5 seconds. If the 3DS Method URL does not complete within 5 seconds, the process fails, but the Merchant can proceed with the Authentication Request (AReq) message.
Refer to Section 5.8.1 in the Core Specification for the requirements related to the execution of the 3DS Method URL.
Table 2.2: 3DS Data Elements Related to Device Information for the Browser-Based Flow
Data Element | Description | Version |
---|---|---|
Browser Accept Headers | Exact content of the HTTP accept headers as sent to the 3DS Requestor from the Cardholder Browser. | 2.3.1 2.2 |
Browser IP Address | IP address of the Browser as returned by the HTTP headers to the 3DS Requestor. | 2.3.1 2.2 |
Browser Java Enabled | Boolean that represents the ability of the Cardholder Browser to execute Java. | 2.3.1 2.2 |
Browser JavaScript Enabled | Boolean that represents the ability of the Cardholder Browser to execute JavaScript. | 2.3.1 2.2 |
Browser Language | Value representing the Browser language as defined in IETF BCP47. | 2.3.1 2.2 |
Browser Screen Color Depth | Value representing the bit depth of the colour palette for displaying images, in bits per pixel. | 2.3.1 2.2 |
Browser Screen Height | Total height of the Cardholder’s screen in pixels. | 2.3.1 2.2 |
Browser Screen Width | Total width of the Cardholder’s screen in pixels. | 2.3.1 2.2 |
Browser Time Zone | Time zone offset in minutes between UTC and the Cardholder Browser local time. | 2.3.1 2.2 |
Browser User-Agent | Exact content of the HTTP user-agent header. | 2.3.1 2.2 |
3DS Method Completion Indicator | Indicates whether the 3DS Method successfully completed. | 2.3.1 2.2 |
3DS Method ID | Contains the 3DS Server Transaction ID used during the previous execution of the 3DS Method. | 2.3.1 2.2 |
Card Range Data | Card range data from the DS indicating the most recent Protocol Versions supported by the ACS, and, optionally, the DS that hosts that range, and, if configured, the ACS URL for the 3DS Method. | 2.3.1 2.2 |
3DS Method Notification URL | The URL that will receive the notification of 3DS Method completion from the ACS. This is sent in the initial request to the ACS from the 3DS Requestor executing the 3DS Method. | 2.3.1 2.2 |
ACS Protocol Versions | Array of objects containing the list of Protocol Versions supported by the ACS for the card range, with their associated ACS Information Indicator, the 3DS Method URL and the list of Supported Message Extension.
| 2.3.1 2.2 |
3DS Method URL | The ACS URL that will be used by the 3DS Method for a particular Protocol Version. The 3DS Method URL data element may be omitted if not supported by the ACS for this specific card range. | 2.3.1 2.2 |
The importance of Cardholder Information in 3DS Authentication is critical for enhancing transaction security and ensuring successful ACS processing. Cardholder information comprises various data types sourced from multiple origins. Key data points include:
This information is essential for establishing trust and assessing risk. The richer data exchange in 3DS authentication enables businesses to send detailed, transaction-specific, and contextual data to the ACS. The Merchant or 3DS Server should provide all available information as accurately as possible. When the ACS trusts and validates this data, the transaction can proceed seamlessly; otherwise, it may enter a challenge flow for additional verification.
The Merchant provides the 3DS Server with two main sets of data related to the Cardholder:
The Merchant should provide the most accurate and complete information possible, as this directly impacts the ACS’s ability to authenticate the transaction. Incomplete or incorrect information (such as dummy values) that does not accurately represent the Cardholder or the context of the transaction can lead to increased challenges or, in the worst case, declined authentication.
Table 2.3: 3DS Data Elements Related to Cardholder Information
Data Element | Description | Version |
---|---|---|
Address Match Indicator | Indicates whether the Cardholder Shipping Address and Cardholder Billing Address are the same. | 2.3.1 2.2 |
Cardholder Account Identifier | Additional information about the account optionally provided by the 3DS Requestor. | 2.3.1 2.2 |
Cardholder Billing Address City | The city of the Cardholder billing address associated with the card used for this purchase. | 2.3.1 2.2 |
Cardholder Billing Address Country | The country of the Cardholder billing address associated with the card used for this purchase. | 2.3.1 2.2 |
Cardholder Billing Address Line 1 | First line of the street address or equivalent local portion of the Cardholder billing address associated with the card used for this purchase. | 2.3.1 2.2 |
Cardholder Billing Address Line 2 | Second line of the street address or equivalent local portion of the Cardholder billing address associated with the card used for this purchase. | 2.3.1 2.2 |
Cardholder Billing Address Line 3 | Third line of the street address or equivalent local portion of the Cardholder billing address associated with the card used for this purchase. | 2.3.1 2.2 |
Cardholder Billing Address Postal Code | ZIP or other postal code of the Cardholder billing address associated with the card used for this purchase. | 2.3.1 2.2 |
Cardholder Billing Address State | The state or province of the Cardholder billing address associated with the card used for this purchase. | 2.3.1 2.2 |
Cardholder Email Address | The email address associated with the account that is either entered by the Cardholder or is on file with the 3DS Requestor. | 2.3.1 2.2 |
Cardholder Home Phone Number | The home phone number provided by the Cardholder. | 2.3.1 2.2 |
Cardholder Mobile Phone Number | The mobile phone number provided by the Cardholder. | 2.3.1 2.2 |
Cardholder Name | Name of the Cardholder. | 2.3.1 2.2 |
Cardholder Shipping Address City | City portion of the shipping address requested by the Cardholder. | 2.3.1 2.2 |
Cardholder Shipping Address Country | Country of the shipping address requested by the Cardholder. | 2.3.1 2.2 |
Cardholder Shipping Address Line 1 | First line of the street address or equivalent local portion of the shipping address requested by the Cardholder. | 2.3.1 2.2 |
Cardholder Shipping Address Line 2 | The second line of the street address or equivalent local portion of the shipping address requested by the Cardholder. | 2.3.1 2.2 |
Cardholder Shipping Address Line 3 | The third line of the street address or equivalent local portion of the shipping address requested by the Cardholder. | 2.3.1 2.2 |
Cardholder Shipping Address Postal Code | The ZIP or other postal code of the shipping address requested by the Cardholder. | 2.3.1 2.2 |
Cardholder Shipping Address State | The state or province of the shipping address associated with the card being used for this purchase. | 2.3.1 2.2 |
Cardholder Work Phone Number | The work phone number provided by the Cardholder. | 2.3.1 2.2 |
Tax ID | Cardholder’s tax identification. | 2.3.1 2.2 |
Note: The Address Match Indicator allows the 3DS Requestor to indicate to the ACS whether the Cardholder’s billing and shipping address are the same.
3DS Requestors can use the Address Match Indicator to identify that the Cardholder selected a checkbox indicating that the shipping address is the same as the billing address. This could be helpful in regions with privacy mandates that prohibit providing billing and shipping address details.
3DS Requestors should still provide billing and shipping address information (assuming no privacy mandates exist in the region), even when the Address Match Indicator has been provided.
Some 3DS Requestors always provide this indicator as part of their checkout process, even if it may not be meaningful – for example, in the case of digital goods for which the shipping address is irrelevant.
Table 2.4: 3DS Data Elements Related to the Cardholder’s Relationship
with the Merchant
Data Element | Description | Version |
---|---|---|
Cardholder Account Information | Additional information about the Cardholder’s account provided by the 3DS Requestor. | 2.3.1 2.2 |
3DS Requestor Authentication Information | Information about how the 3DS Requestor authenticated the Cardholder before or during the transaction. | 2.3.1 2.2 |
3DS Requestor Prior Transaction Authentication | Information about how the 3DS Requestor authenticated the Cardholder as part of a previous 3DS transaction. | 2.3.1 2.2 |
The Issuer/ACS offers the Cardholder the option to add their preferred or trusted Merchant to their trust list during a 3DS challenge when in direct communication with the Cardholder. The Issuer controls the selection of merchants proposed in the Trust List (for example, only offering the Trust List service for low-risk merchants). The Issuer will consider the risk associated with the merchant type and market, as well as the Cardholder’s transaction history.
The 3DS Trust List feature may be used for the trusted beneficiary exemption in countries in scope of the Revised Payment Services Directive (PSD2).
The 3DS Specification does not prevent issuers from providing alternative channels to cardholders to manage the trusted beneficiaries list (for example, e-banking).
An alternative use case is the Trust List managed by the DS as described in Alternative Use Case – Trust List Managed by the DS.
The ACS has a Trust List Management System and can display the Trust List prompt/screen to the Cardholder during a 3DS challenge.
Optional: The ACS indicates support of the Trust List in the Card Range Data (ACS Information Indicator – 04 = Trust List Supported).
Note: The ACS uses some or all of the merchant information (Merchant Name, 3DS Requestor Name, 3DS Requestor ID) to manage the Trust List. Therefore, it is essential that the Merchant and/or the 3DS Server provide consistent merchant information across the Trust List enrolment and subsequent transactions.
The Cardholder enrols a Merchant on their Trust List that is managed by the Issuer/ACS.
In a subsequent transaction with the same Cardholder and Merchant:
The table below lists the data elements that may be provided in relation to the Trust List.
Table 2.5: 3DS Data Elements Related to the Trust List
Data Element | Description | Version |
---|---|---|
3DS Requestor Challenge Indicator | Indicates whether a challenge is requested for this transaction. | 2.3.1 2.2 |
3RI Indicator | Indicates the type of 3RI request. This data element provides additional information to the ACS to determine the best approach for handling a 3RI request. A value of 10 indicates a Trust List Status check. | 2.3.1 2.2 |
ACS Information Indicator | Provides additional information for a particular Protocol Version to the 3DS Server. The element lists all applicable values for the card range. | 2.3.1 2.2 |
Card Range Data | Card range data from the DS indicating the most recent Protocol Versions supported by the ACS, and, optionally, the DS that hosts that range, and, if configured, the ACS URL for the 3DS Method. Additionally, it identifies the 3DS features supported by the ACS in the ACS Information Indicator, such as Trust List or Decoupled Authentication. Trust List indicators are defined in the ACS Information Indicator:
| 2.3.1 2.2 |
Toggle Position Indicator | Indicates if the Trust List and/or Device Binding prompt should be presented below or above the action buttons. | 2.3.1 |
Transaction Challenge Exemption | Exemption applied by the ACS to authenticate the transaction without requesting a challenge. | 2.3.1 2.2 + Bridging Message Extension |
Trust List Data Entry | Indicator provided by the 3DS SDK to the ACS to confirm whether the Cardholder gives consent to the Trust List. | 2.3.1 2.2 |
Trust List Information Text | Text provided by the ACS to the Cardholder during a Trust List transaction. | 2.3.1 2.2 |
Trust List Status | Enables the communication of Trust List Status between the ACS, the DS and the 3DS Requestor. | 2.3.1 2.2 |
Trust List Status Source | This data element will be populated by the system setting Trust List Status. | 2.3.1 2.2 |
Note: The term “Trust List” is used in version 2.3.1 of the 3DS Specification, replacing the terms “Whitelist” and “Whitelisting” used in version 2.2.
Note: Checkbox, radio button or any relevant user interface may be used to offer the Trust List and Device Binding options.
The DS has a Trust List Management System and an agreement with the ACS to manage the Trust List on its behalf.
The ACS is able to display the Trust List prompt/screen to the Cardholder during the 3DS challenge.
Optional: The ACS or DS indicates support of the Trust List in the Card Range Data (ACS Information Indicator – 04 = Trust List Supported)
The Cardholder enrols a Merchant on their Trust List that is managed by the DS.
In a subsequent transaction with the same Cardholder and Merchant:
In this White Paper, Device Binding is understood to denote the process to link the Consumer Device used for a transaction to the Cardholder Account.
Device Binding may be managed by any 3DS component (refer to the different use cases in this section).
The ACS, the DS or the 3DS Server may be the source of the Device Binding Status information.
The ACS offers the Cardholder the option to link the device used for the transaction to the Cardholder Account Number during a 3DS challenge. The Device Binding Status provides to the ACS additional information that could be used for transaction risk assessment.
The 3DS Specification does not prevent issuers from providing alternative channels to cardholders to manage the Device Binding information (for example, e-banking).
The 3DS Specification does not define how the ACS identifies the Consumer Device.
The ACS has a Device Binding management system and is able to display the Device Binding prompt/screen to the Cardholder during the 3DS challenge.
The ACS is able to identify the Consumer Device.
Note: How the ACS identifies the Consumer Device is outside the scope of the Core Specification
The Cardholder accepts the Device Binding option that is managed by the ACS.
In a subsequent transaction with the same Cardholder and Merchant:
The table below lists the data elements that may be provided in relation to Device Binding.
Table 2.6: 3DS Data Elements Related to Device Binding
Data Element | Description | Version |
---|---|---|
3DS Requestor Challenge Indicator | Indicates whether a challenge is requested for this transaction. | 2.3.1 |
3RI Indicator | Indicates the type of 3RI request. This data element provides additional information to the ACS to determine the best approach for handling a 3RI request. A value of 10 indicates a Trust List Status check. | 2.3.1 |
ACS Information Indicator | Provides additional information for a particular Protocol Version to the 3DS Server. The element lists all applicable values for the card range. | 2.3.1 |
Card Range Data | Card range data from the DS indicating the most recent Protocol Versions supported by the ACS, and, optionally, the DS that hosts that range, and, if configured, the ACS URL for the 3DS Method. Additionally, it identifies the 3DS features supported by the ACS, such as Trust List or Decoupled Authentication. The Device Binding indicator is defined in the ACS Information Indicator:
| 2.3.1 |
Device Binding Data Entry | Indicator provided by the 3DS SDK to the ACS to confirm whether the Cardholder gives consent to bind the device. | 2.3.1 |
Device Binding Information Text | Text provided by the ACS to the Cardholder during the Device Binding process. | 2.3.1 |
Device Binding Status | Enables the communication of Device Binding Status between the ACS, the DS and the 3DS Requestor. For bound devices (value = 11–14), Device Binding Status also conveys the type of binding that was performed. | 2.3.1 |
Device Binding Status Source | This data element will be populated by the system setting Device Binding Status. | 2.3.1 |
Toggle Position Indicator | Indicates if the Trust List and/or Device Binding prompt should be presented below or above the action buttons. | 2.3.1 |
Note: Checkbox, radio button or any relevant user interface may be used to offer the Trust List and Device Binding options.
The 3DS Server (and/or 3DS Requestor) has a Device Binding management system.
The 3DS Server (and/or 3DS Requestor) is able to identify the Device used by the Cardholder.
The Cardholder accepts the Device Binding option that is managed by the 3DS Server/3DS Requestor.
The DS has a Device Binding management system, and is able to identify the Consumer Device.
Note: How the DS identifies the Consumer Device is outside the scope of the 3DS Specification.
The DS and ACS have an agreement for the management of the Device Binding information.
The ACS is able to display the Device Binding prompt/screen to the Cardholder during the 3DS challenge.
The Cardholder accepts the Device Binding option that is managed by the DS.
In a subsequent transaction with the same Cardholder and Merchant:
Delegated authentication enhances the shopping experience for Cardholders, Merchants, and Issuers, ensuring a seamless Cardholder authentication process. EMV 3DS is designed to encourage frictionless authentication, which can be achieved by Merchants providing specific information. Delegated authentication can increase the likelihood of a frictionless authentication.
In delegated authentication, Issuers transfer the responsibility of Cardholder authentication to a third party, which may be the Merchant or an authorised representative. This arrangement allows the third party to handle the authentication process.
Upon authenticating the Cardholder, the Merchant relays the authentication confirmation to the ACS. The ACS then assesses the Cardholder’s authentication details as part of its transaction risk analysis. It will confirm the authentication unless the risk is deemed excessive, or the information provided is insufficient. In such instances, the ACS retains the option to challenge the Cardholder.
Furthermore, the regulations (such as PSD2) support delegated authentication by Merchants or third parties, provided that the Merchant adheres to the Strong Customer Authentication (SCA) requirements. This regulatory framework ensures that the authentication process remains secure while allowing flexibility in how it is conducted. For this to work effectively, Merchants and Issuers must establish agreements regarding the authentication methods, either through bilateral contracts or services offered by payment systems, which are outside the scope of the Core Specification.
The Merchant has an agreement with the Issuer/ACS for delegated authentication, for example as defined in PSD2. The Merchant has an authentication process that meets the Issuer’s requirements or preferences.
When the Cardholder creates an account or makes a purchase with the Merchant, the Cardholder goes through a secure registration process that complies with agreed ACS requirements (such as a FIDO-based authentication).
During the checkout process, the Cardholder is prompted to authenticate using the method established during the registration. The Merchant’s system then verifies the authentication data to validate the Cardholder.
After the successful Cardholder authentication, the Merchant communicates this information using the 3DS Requestor Authentication Method and 3DS Requestor Authentication Data in the AReq message to the ACS.
The ACS receives the confirmation of the Cardholder authentication, it can approve the transaction, allowing the transaction to be processed. This streamlined process reduces the need for additional authentication steps providing a frictionless checkout experience for the Cardholder.
Table 2.7: 3DS Data Elements Related to 3DS Requestor Authentication Information
Data Element | Description | Version |
---|---|---|
3DS Requestor Authentication Data | Data that documents and supports a specific authentication process.
For 3DS Requestor Authentication Method = 06 or 07, refer to the EMV® 3-D Secure White Paper – Use of FIDO® Data in 3-D Secure Messages for the 3DS Requestor Authentication Data content and format. | 2.3.1 2.2 |
3DS Requestor Authentication Method | Length: 2 characters
| 2.3.1 2.2 |
3DS Requestor Authentication Timestamp | Date and time of the Cardholder authentication converted into UTC. | 2.3.1 2.2 |
DS Authentication Information Verification Indicator | Supplied by the DS, the value that represents the signature verification performed by the DS on the mechanism (e.g., FIDO) used by the Cardholder to authenticate to the 3DS Requestor.
| 2.3.1 2.2 |
Some markets require Issuers to validate all e-commerce transactions with the Cardholder (i.e., PSD2 – Strong Customer Authentication (SCA) requirements). However, the regulations may allow certain exemptions from the SCA requirements.
One of such exemptions is the Transaction Risk Analysis exemption. Merchants or their acquiring banks assess the risk associated with the transaction. If the transaction risk is low (below a certain threshold), the Merchants can request an SCA exemption.
Other exemptions include:
Merchants can request exemptions for qualifying transactions. If the exemptions are accepted (granted) by the Issuer, they allow for a frictionless checkout, reducing the risk of abandonment linked to the challenge.
The Merchant or 3DS Server is able to evaluate the context of the transaction and its risk, and request an exemption.
The ACS is able to manage the challenge exemption.
Optional: The ACS indicates the supported exemption in the Card Range Data (ACS Information Indicator – 08, 09, 10 or 11)
During the checkout process, the 3DS Server may:
The ACS evaluates the risk associated with the transaction, taking into account the request for an exemption (if present). If an exemption is applicable, the ACS may provide this information in the Transaction Challenge Exemption in the ARes message.
Note: The Core Specification supports the exchange of information related to the exemption between the 3DS Server and the ACS. The presence and use of this information is optional, and depends on the regulations applicable in the relevant market.
Table 2.8: 3DS Data Elements Related to Exemptions
Data Element | Description | Version |
---|---|---|
3DS Requestor Challenge Indicator | Indicates whether a challenge is requested for this transaction.
| 2.3.1 |
Transaction Challenge Exemption | Exemption applied by the ACS to authenticate the transaction without requesting a challenge.
| 2.3.1 |
ACS Information Indicator | Provides additional information for a particular Protocol Version to the 3DS Server. The element lists all applicable values for the card range.
| 2.3.1 |
The transaction value is below a predefined threshold, so the Merchant and/or 3DS Server can request an SCA exemption.
Before sending an Authentication Request with 3DS Requestor Challenge Indicator = 10 (No challenge requested – use low value exemption), the 3DS Server may check that the ACS supports the Low-Value Exemption using ACS Information Indicator (10 = Low Value Exemption Supported).
The ACS verifies that the transaction value is below the threshold, determines that a Cardholder challenge is not necessary, and applies the Low Value Exemption. It may return Transaction Challenge Exemption = 10 (Low Value exemption) with its response.
Merchant/3DS Server | Issuer / ACS |
---|---|
Low Value Exemption threshold = 50 € (example) Transaction data elements
| Transaction data elements
|
The Merchant or their acquiring bank assesses the risk associated with the transaction. If the transaction risk is low (below a certain threshold), the Merchant and/or 3DS Server can request an SCA exemption.
Before sending an Authentication Request with 3DS Requestor Challenge Indicator 05 = No challenge requested – transactional risk analysis is already performed), the 3DS Server may check that the ACS supports the Transaction Risk Analysis Exemption using ACS Information Indicator (08 = Transaction Risk Analysis Exemption Supported).
The ACS determines that the Merchant/Acquirer performed the transaction risk analysis and that a Cardholder challenge is not necessary, it applies the Transaction Risk Analysis exemption. It may return Transaction Challenge Exemption = 05 (Transaction Risk Analysis exemption) with its response.
Merchant/Acquirer | Issuer |
---|---|
The Merchant assesses that the transaction risk is low. Transaction data elements
| Transaction data elements
|
The Merchant or the 3DS Server knows that the Merchant is listed on the Cardholder’s Trust List (refer to Section 2.2.4 for more information on the Trust List), the Merchant and/or 3DS Server can request an SCA exemption.
Before sending an Authentication Request with 3DS Requestor Challenge Indicator = 08 (No challenge requested – use Trust List exemption if no challenge required), the 3DS Server may check that the ACS supports the Trust List Exemption using ACS Information Indicator = 09 (Trust List Exemption supported).
The ACS verifies that the Merchant is on the Cardholder’s Trust List, determines that a Cardholder challenge is not necessary, and applies the Trust List exemption. It may return Transaction Challenge Exemption = 08 (Trust List exemption) with its response.
Merchant/Acquirer | Issuer |
---|---|
The Merchant knows that it is on the Cardholder’s Trust List. Transaction data elements
| Transaction data elements
|
The Merchant or the 3DS Server knows that the card used for the transaction is a corporate payment card (i.e., card used for business expenditures or card account used for business-to-business payments), the Merchant and/or 3DS Server can request an SCA exemption.
Before sending an authentication request with 3DS Requestor Challenge Indicator = 11 (No challenge requested – Secure corporate payment exemption), the 3DS Server may check that the ACS supports the Secure Corporate Payments Exemption using ACS Information Indicator = 11 (Secure Corporate Payments Exemption Supported).
The ACS verifies that the type of card used for the transaction, determines that a Cardholder challenge is not necessary, and applies the Secure Corporate Payments exemption. It may return Transaction.
Merchant/Acquirer | Issuer |
---|---|
The Merchant knows that the card used for the transaction is a corporate card. Transaction data elements
| Transaction data elements
|
Last Updated: April 17, 2020
Welcome to EMVCo. By accessing or using the EMVCo website at www.emvco.com (“Site“) or any Site Materials, whether or not you obtained them via the Site, you agree to the following Terms of Use on behalf of yourself individually and the company or organization for which you are using the Site or Site Materials (“Organization“). If you do not agree to the following Terms of Use, do not use the Site or other Site Materials.
In these Terms of Use, “Site Materials” means all email messages sent to you by EMVCo in connection with your registration on the Site or participation in an EMVCo participation program, and all content, files and other materials that are available for viewing or download on the Site, including the EMV® Specifications, requirements, guidelines, white papers or other documents, APIs, SDKs, software, scripts, code, trademarks, videos, text, graphics, pictures, information, and other materials.
You represent that either (a) you are an authorized representative of your Organization with authority to bind your Organization to these Terms of Use, in which case the term “you” refers collectively to both you individually and your Organization, or (b) you are not authorized to bind any Organization to these Terms of Use and are using the Site or Site Materials solely in your personal capacity, in which case the term “you” refers to you individually. EMVCo, LLC (“EMVCo“) reserves the right to modify or replace these Terms of Use at any time and in EMVCo’s sole discretion.
EMVCo will indicate at the top of these Terms of Use the date such document was last updated. Any changes will be effective immediately upon posting the revised version on the Site (or such later effective date as may be indicated at the top of the revised Terms of Use). Your continued use of the Site or Site Materials following the posting of any changes to these Terms of Use will constitute your acceptance of such changes. If you do not agree to the changes, you must stop using the Site and Site Materials. In addition, EMVCo may provide other methods by which you may accept or receive notice of these Terms of Use or changes to these Terms of Use.
In these Terms of Use, “EMV Products” means products or services that are designed to comply with the EMV Specifications. The foregoing license applies retroactively to include activities prior to the date you agreed to these Terms of Use, but is granted solely under the intellectual property rights that EMVCo owns or has the right to license. To the extent the foregoing license includes rights to a third party’s patents, the license is limited to those patents or patent claims that would be necessarily infringed by an entity implementing the mandatory or optional requirements of the EMV Specifications.
And after the cover page of each copy of a translation, the following (or a substantially similar notice) must be printed:
Notwithstanding the foregoing, the Public Documents may be subject to a separate agreement you may have with EMVCo or to supplemental terms and conditions that are included in or accompany Public Documents, in which case you agree that such separate agreement or supplemental terms and conditions will apply to your use of the Public Documents. Any use of the Site or Site Materials other than as specifically authorized herein (or in such separate agreement or supplemental terms and conditions) is strictly prohibited and will automatically terminate the foregoing license without notice.
EMVCo's new website and Participant Dashboard are now live. To access your account for the first time on our new website you'll need to carry out a password reset here. You will then be sent an email to reset your password.
EMVCo Associates, Subscribers and public users of emvco.com can create accounts to manage their engagement and participation with EMVCo. Using your EMVCo account, you can create your own watchlist of EMV technologies documents, monitor queries and responses, and manage your profile.