Brand Specific Guidelines
Details that are specific to each card brand's implementation of the EMVCo 3DS Specification
This section provides descriptions of the validation variations for specific payment brands. Outlined below are the high-level required configurations for each payment brand. If additional information is needed, please contact TokenEx Support. If a brand does not have any specific guidance outlined below, the standard guidance applies: more valid data included in an authentications request decreases the risk of a challenge being presented to the presumed cardholder.
Mastercard - Identity Check
Supported Versions Response
The Mastercard Identity Check Program has incorporated the 80 to 99 Reserved-for-Directory-Server-Use values to inform the 3DS Servers/Merchants of value-added services or transaction processing attributes that apply to account ranges present in the Supported Versions response.
threeDSecureResponse.acsInfoInd | Description |
---|---|
01 | Authentication Available at ACS |
02 | Attempts Supported by ACS or DS |
03 | Decoupled Authentication Supported |
04 | Whitelisting Supported |
80 | Card Range is enrolled is Smart Authentication Stand-In Service |
81 | Card Range is enrolled in Smart Authentication Direct |
84 | Card Range supports payment transactions |
86 | Card Range supports the app channel |
85 | Card Range supports non-payment transactions |
87 | Card Range supports the browser channel |
88 | Card Range supports app-based ACS/Issuer Challenge Capabilities |
89 | Card Range supports browser-based ACS/Issuer Challenge Capabilities |
90 | Card Range is Enrolled in Identity Check Express |
91 | Card range supports Authentication Express Merchant Delegation for Identity Check Express (Type I) |
92 | Card range supports Authentication Express Low Fraud Merchant (Type II) |
93 | Card Range participates in Authentication Express Wallet Delegation |
94 | Card Range participates in Authentication Express Device Delegation |
Authentications Request
Rules and Validations
Request Parameter | Applicability | Description |
---|---|---|
MerchantDetails.AcquirerMerchantId | Required: message category PA Optional: message category NPA | Must match 3DS Enrollment data |
AcquirerBin | Required: message category PA Optional: message category NPA | Must match 3DS Enrollment data |
MerchantDetails.Name | Required: message category PA Optional: message category NPA | Must match 3DS enrollment data. In use cases where the transaction is initiated by a different merchant, like in the case of a travel aggregator site managing booking for airlines or hotels, the name must follow the following format: “Travel aggregator name_merchant (hotel or airline) name” example: aggregatorName_merchantName |
MessageCategory | Required | 1 (PA) or 2 (NPA) or 80 (IDCI, see section below). |
Liability Shift
The below table outlines what to expect for liability shifts.
transStatus | Meaning | Message Category | Authentication Value present | ECI | Version | Liability Holder | Comment |
---|---|---|---|---|---|---|---|
Y | Fully Authenticated | PA | Yes | 02 | 2.1.0 and 2.2.0 | Issuer | Successful authentication by the ACS (including whitelisting exemption and decoupled authentication) |
Y | Fully Authenticated | PA | Yes | 07 | 2.1.0 and 2.2.0 | Issuer | Recurring Transaction, successfully authenticated by the ACS (including 3RI recurring transactions applicable for v2.2.0, which is for the subsequent authentications after the initial transaction). |
Y | Fully Authenticated | PA | No | 02 | 2.1.0 and 2.2.0 | Issuer | Successful Frictionless authentication of low-risk transaction by Mastercard Stand-In RBA service (including recurring transaction) |
A | Attempted Authentication | PA | No | 01 | 2.1.0 and 2.2.0 | Issuer | Successful Frictionless authentication of non low-risk transaction by Mastercard Stand In RBA service (including recurring transaction) |
A | Attempted Authentication | PA | No | 01 | 2.1.0 and 2.2.0 | Issuer | Merchant only authenticated. Attempts: Transaction could not be authenticated by either the ACS or Mastercard RBA (including recurring transaction) |
N | Not Authenticated | PA | No | 00 | 2.1.0 and 2.2.0 | Acquirer | Not Authenticated: Transaction could not be authenticated, and Attempts doesn’t apply |
R | Rejected | PA | No | 00 | 2.1.0and 2.2.0 | N/A | Payment Transaction rejected by Issuer. Authorization should not be attempted. |
I | Information only | PA | Yes | 06 | 2.2.0 | Acquirer | Information only flow. Transaction was not authenticated by either ACS or Mastercard, based on Acquirer exemption for SCA or SCA performed by merchant or because it was data only flow(challenge indicator 05 or 07 or 06) |
Y | Fully Authenticated | PA | Yes | 02 | 2.1.0 and 2.2.0 | Issuer | Successful authentication by the Mastercard Identity Check Express (IDCX) Service |
U | Identity Check Insights | PA | Yes | 04 | 2.1.0 and 2.2.0 | Acquirer | Identity Check Insights transaction |
U | Identity Check Insights | PA | Yes | 04 | 2.2.0 | Acquirer | Identity Check Insights transaction on 3RI Device Channel |
Y | Fully Authenticated | NPA | No | N2 | 2.1.0 and 2.2.0 | N/A | Authenticated: Frictionless Transaction, Authenticated by ACS |
Y | Fully Authenticated | NPA | Yes | N2 | 2.1.0 and 2.2.0 | N/A | Authenticated: Challenge Transaction, Authenticated by ACS |
N | Not Authenticated | NPA | No | N0 | 2.1.0 and 2.2.0 | N/A | Not Authenticated: Transaction could not be authenticated, and Attempts doesn’t apply. |
R | Rejected | NPA | No | N0 | 2.1.0 and 2.2.0 | N/A | Transaction rejected by Issuer. Authorization should not be attempted. |
I | Information only | NPA | No | N0 | 2.2.0 | N/A | Information only flow. Transaction was not authenticated by either ACS or Mastercard, based on Acquirer exemption for SCA (challenge indicator = 05) |
The below table provides details of the specific reason codes defined by the Mastercard DS.
Transaction Status Reason, transStatusReason | Applicability | Applicable Scenario |
---|---|---|
80 | 2.1.0 and 2.2.0 | Sent by the Mastercard DS to indicate that the authentication was processed through Identity Check Insights. |
81 | 2.1.0 | Sent by the ACS with a transaction status of N in the authentications response, indicating a successful authentication of an Acquirer SCA exemption transaction. |
82 | 2.1.0 and 2.2.0 | Sent by the Mastercard DS when a transaction is not eligible for Smart Authentication Stand-In because the authentication request's Challenge Indicator was set to “challenge requested: mandate” (threeDSRequestorChallengeInd = 04). In such cases, Mastercard DS will not invoke Smart Authentication Stand-In and will instead respond with an authentication response having a Transaction Status of N (transStatus = N) and Transaction Status Reason of 82 (transStatusReason = 82) meaning “Challenge Mandate requested but could not be performed”. In case of challenge results, a Transaction Status of N and Transaction Status Reason of 82 will be sent along with Authentication Type of 92 (authenticationType = 92) meaning “Challenge Mandate requested but could not be performed”. |
83 | 2.1.0 and 2.2.0 | Sent by the Mastercard DS when the DS drops the reason code received from the ACS because the one sent by the ACS did not make sense with a transaction status of N or R. Transaction Status Reason = 83 will mean - DS dropped reason code received from ACS. In the instance where the Mastercard DS replaces the transaction status in challenge results to N, Authentication Type will be populated with a value of 83 (DS altered transaction status). |
84 | 2.1.0 and 2.2.0 | Sent by the Mastercard DS to indicate that the transaction was not processed by Smart Authentication due to challenge cancellation. |
87 | 2.1.0 and 2.2.0 | Sent by the Mastercard DS to indicate that the request was not routed to Smart Authentication Stand-In due to the Device Channel being 3RI. |
88 | 2.1.0 and 2.2.0 | Sent by the ACS to indicate that 3DS Requestor Prior Transaction Authentication Data was provided in the request, but either the ACS could not find the 3DS Requestor Prior Transaction Authentication Data or it was expired. |
Recurring Payments
A recurring payment should be indicated by the merchant in the authentications request parameter AuthenticationIndicator
and a value of 02
.
The Mastercard Directory Server (DS) will check the presence and format of the PriorAuthenticationInformation.Data
and PriorAuthenticationInformation.Timestamp
fields for payment transactions (Message Category PA, 01) when the Device Channel is 3RI. If the fields are not present, the DS will error the transaction with error code 201. If the fields are present but in the incorrect format, the DS will return error code 203.
Strong Customer Authentication (SCA) is highly recommended for the following scenarios:
- For the first transaction of the recurring payments. The ChallengeIndicator field should contain the value of 03 or 04.
- After the Recurring Payment, if the Expiry date is reached and the next set of recurring payments need to be initiated, the maximum limit before another SCA is needed (recurring expiry) needs to be confirmed between merchant and cardholder and should be typically made before the authentication screens are shown.
Best Practice Recommendation
- Ideally, Merchants should have a recurring expiry associated with all recurring transactions after which SCA should be initiated, but in cases like subscriptions where there is no established expiry or end date of recurring transactions, merchants should indicate the value of “99991231” (YYYYMMDD format) in the
PurchaseDetails.RecurringExpiry
field. - Recurring payments with a variable frequency can set the
PurchaseDetails.RecurringFrequency
field to01
to indicate that the frequency of payments is not set.
Variations based on EMV 3DS Version and Regulations
2.1.0
In EMV 3DS version 2.1.0, all subsequent transaction that are part of a recurring payment go straight to authorization and do not go through authentication as the cardholder is not in session and the 3RI payment flow is not supported. Note: liability for such transactions will be with the merchant.
Refer to the authentications request and response snippets and table below for more details of the recurring payment scenario in EMVC 3DS version 2.1.0
Authentication parameters for an initial/first recurring transaction
Request Param | Value and Details |
---|---|
MessageCategory | 1 - Payment Authentication |
DeviceChannel | 1 - App, 2 - Browser |
AuthenticationIndicator | 2 - Recurring Transaction |
ChallengeIndicator | "03" - Challenge requested because merchant preference "04" - Challenge requested because of a mandate |
ThreeDSecureResponse Param | Value and Details |
---|---|
transStatus | Y - Fully Authenticated |
eci | 02 or 07 (see table below) |
ECI's impact on the authentication value's prefix
These authentication value prefixes were added specifically for recurring payments and is recommended to ACS operators for use, though their usage is at the discretion of their ACS operator and should not be expected to be present for every initial recurring transaction's authentication.
ECI Value | Authentication Flow | Authentication Value Prefix |
---|---|---|
02 | Frictionless | kA |
02 | Challenged | kB |
07 | Frictionless | kO |
07 | Challenged | kP |
Request and Response snippet examples
{
"DeviceChannel": 2, // Browser
"MessageCategory": 1, // Payment Authentication
"AuthenticationIndicator": 2, // Recurring
"ChallengeIndicator": "03", // A challenge is requested due to merchant preference
// remainder of request
}
{
"threeDSecureResponse": {
"transStatus": "Y",
"eci": "02",
"authenticationValue": "kB..." // ellipses in lieu of suffix
// remainder of response
}
2.2.0
The request parameters described above for 2.1.0 are the same for version 2.2.0, though in 2.2.0 - all subsequent transactions that are part of a recurring payment should be sent as a 3RI transaction and include the below authentications request parameters.
Authentication parameters for a subsequent recurring transaction
Request Param | Value and Details |
---|---|
MessageCategory | 1 - Payment Authentication |
DeviceChannel | 3 - 3RI |
ThreeRIIndicator | 1 - Recurring Transaction |
PriorAuthenticationInformation.Data | DS Transaction ID of the initial or the first recurring payment transaction |
ThreeDSecureResponse Param | Value and Details |
---|---|
transStatus | Y - Fully Authenticated |
eci | 07 (see authentication value details below) |
authenticationValue | The ECI 07 and authentication value prefixes were introduced for usage in recurring payments. Authentication values are prefixed by kO if the authentication was frictionless, and by kP if the authentication was challenged. In contrast with 2.1.0, ACS Operators are mandated to use these prefixes in 2.2.0 for 3RI payment transactions. |
Request and Response snippet examples
{
"MessageCategory": 1, // Payment Authentication
"DeviceChannel": 3, // 3RI
"ThreeRIIndicator": 1, // Recurring Transaction
"PriorAuthenticationInformation": {
"Data":"64d76f6d-e512-4aba-ae29-f7af0dc7db09" // DS Transaction ID of the initial or first recurring payment transaction
}
// remainder of request
}
{
"threeDSecureResponse": {
"transStatus": "Y",
"eci": "07",
"authenticationValue": "kO..." // ellipses in lieu of suffix
// remainder of response
}
EU Specific Guidelines
According to the Article 14 in EEA, an authentication is required for the first transaction of the recurring payments with the below mentioned guidelines.
Authentication Request Param | Value and Details |
---|---|
ChallengeIndicator | "04" - Challenge is requested due to mandate |
PriorAuthenticationInformation.Data | “999999999999999999999999999999999999”. This field must contain the number 9, repeating for a character count of 36. |
Identity Check Insights (IDCI)
IDCI is a Mastercard program built on top the EMV 3DS specification's framework, but is not included in the specification.
For merchants who have concerns regarding the latency of transactions and are willing to maintain the liability of the transaction, there is an option to submit the subsequent transactions as 3RI Identity Check Insights transactions (in version EMV 3DS 2.2.0). This will allow them to take advantage of DTIs that are generated for the IDCI 3RI transaction with the potential for higher approval rates in the authorization.
Refer to the below tables for more details of such recurring payment scenario.
Authentications
Request Param | Value and Details |
---|---|
MessageCategory | 80 - IDCI |
DeviceChannel | 3 - 3RI |
ThreeRIIndicator | 1 - Recurring Transaction |
PriorAuthenticationInformation.Data | DS Transaction ID of the Initial or the first recurring payment transaction. Note: This field is a requirement for 3RI Identity Check Insights transactions for recurring payments. |
ThreeDSecureResponse param | Value and Details |
---|---|
transStatus | U - Authentication could not be performed. This transStatus is applicable to every IDCI transaction. |
eci | 04 |
authenticationValue | An authentication value is not present in IDCI transaction responses. |
Request and Response snippet examples
{
"MessageCategory": 80, // IDCI
"DeviceChannel": 3, // 3RI
"ThreeRIIndicator": 1, // Recurring Transaction
"PriorAuthenticationInformation": {
"Data":"64d76f6d-e512-4aba-ae29-f7af0dc7db09" // DS Transaction ID of the initial or first recurring payment transaction
}
// remainder of request
}
{
"threeDSecureResponse": {
"transStatus": "U",
"eci": "04",
// remainder of response
}
For unregulated markets where there are no regulations regarding Strong Customer Authentication, the IDCI message category - used with APP or BRW device channels - can be used for recurring payments initial or first transaction and use 3RI IDCI with subsequent transactions.
Refer to the below table for more details of such recurring payment scenario:
Authentication parameters for an initial/first recurring transaction
Request Param | Value and Details |
---|---|
MessageCategory | 80 - IDCI |
DeviceChannel | 1 - App, 2 - Browser |
AuthenticationIndicator | 2 - Recurring Transaction |
ChallengeIndicator | "03" - Challenge requested because merchant preference "04" - Challenge requested because of a mandate |
ThreeDSecureResponse Param | Value and Details |
---|---|
transStatus | U - Authentication could not be performed. This transStatus is applicable to every IDCI transaction. |
eci | 04 |
authenticationValue | An authentication value is not present in IDCI transaction responses. |
Authentication parameters for a subsequent recurring transaction
Request Param | Value and Details |
---|---|
MessageCategory | 80 - IDCI |
DeviceChannel | 3 - 3RI |
ThreeRIIndicator | 1 - Recurring Transaction |
PriorAuthenticationInformation.Data | DS Transaction ID of the initial or the first recurring payment transaction. Note: This field is a requirement for 3RI Identity Check Insights transactions for recurring payments. |
ThreeDSecureResponse Param | Value and Details |
---|---|
transStatus | U - Authentication could not be performed. This transStatus is applicable to every IDCI transaction. |
eci | 04 |
authenticationValue | An authentication value is not present in IDCI transaction responses. |
Visa - Secure
To successfully submit authentication requests in compliance with Visa’s 3-D Secure Authentication program, specific validations as specified by the Visa Secure Program Guide documentation applies.
Supported Versions Response
threeDSecureResponse.acsInfoInd | Description |
---|---|
01 | Authentication Available at ACS |
02 | Attempts Supported by ACS or DS |
80 | TRA Supported by issuer |
81 | Data-only Supported by issuer |
82 | Delegated Authentication Supported by issuer |
Authentications Request
Rules and Validations
Request Parameter | Applicability | Description |
---|---|---|
CardDetails.CardExpiryDate | Required | YYMM |
TransactionType | Required | 1 - Goods/Service Purchase 3 - Check Acceptance 10 - Account Funding 11 - Quasi–Cash Transaction 28 - Prepaid Activation and Load |
ThreeDSecureRequestorAuthenticationInformation.Method | Required for device channels APP and BRW. | Cardholder authentication method used by merchant. Not applicable to 3RI. "01" = No 3DS Requestor authentication occurred (i.e., cardholder “logged in” as guest) "02" = Log into the cardholder account at the 3DS Requestor system using 3DS Requestor’s own credentials "03" = Log into the cardholder account at the 3DS Requestor system using federated ID "04" = Log into the cardholder account at the 3DS Requestor system using issuer credentials "05" = Log into the cardholder account at the 3DS Requestor system using third–party authentication "06" = Log into the cardholder account at the 3DS Requestor system using FIDO® Authenticator "07" = Log into the cardholder account at the 3DS Requestor system using FIDO® Authenticator (FIDO® assurance data signed) "08" = SRC Assurance Data |
ThreeRIIndicator | Required for device channel 3RI | 1 = Recurring transaction 2 = Instalment transaction 3 = Add card 4 = Maintain card information 5 = Account verification 6 = Split/delayed shipment 7 = Top–up 8 = Mail Order 9 = Telephone Order 10 = Whitelist status check 11 = Other payment 12 = Billing Agreement 13–79 = Reserved for EMVCo future use (values invalid until defined by EMVCo) 80–99 = Reserved for DS use Note: values 1-5 are applicable to both 2.1.0 and 2.2.0. Values 6-12 were introduced in version 2.2.0. Edge Case: When the transaction uses message version 2.1.0, message category 2 (NPA), device channel 3 (3RI), and the value for this parameter is 80, the ACS will apply PA validations instead of NPA. This means that all message category 1 (PA) fields become required. |
AcquirerBin | Required | Visa requires this field for both Message Categories PA and NPA. |
These are additional challenge indicator values applicable to the Visa DS
ChallengeIndicator | Description |
---|---|
81 | Visa-specific Data-only transaction. This will only be applicable for 2.2.0. |
82 | NO CHALLENGE REQUESTED. The merchant is requesting to utilize Secure Corporate Exemption as applicable. |
83 | NO CHALLENGE REQUESTED. The merchant is requesting to utilize TRA Exemption This will only be applicable for 2.1.0. |
Liability Shift
The below table outlines what to expect for liability shifts.
transStatus | Meaning | Authentication Value present | ECI | Version | Liability Holder | Comment |
---|---|---|---|---|---|---|
Y | Fully Authenticated | Yes | 05 | 2.1.0 and 2.2.0 | Issuer | Successful authentication. |
A | Attempted Authentication | No | 06 | 2.1.0 and 2.2.0 | Acquirer | Authentication attempted but no CAVV provided by issuer. |
N | Not Authenticated | No | 07 | 2.1.0 and 2.2.0 | Acquirer | Transaction could not be authenticated and Attempts does not apply. |
R | Rejected | No | 07 | 2.1.0 and 2.2.0 | Acquirer | Payment Transaction rejected by Issuer. Authorization should not be attempted. |
Y | Fully Authenticated with TRA exemption | Yes | 07 | 2.2.0 | Acquirer | Applicable when the merchant populated the request's exemption indicator. |
Y | Fully Authenticated with TRA exemption | Yes | 05 | 2.2.0 | Issuer | Applicable when the merchant did not populate the request's exemption indicator. |
Y | Fully Authenticated with low value | Yes | 05 | 2.1.0 and 2.2.0 | Issuer | Issuer applied the low value exemption. |
Y | Fully Authenticated for Secure Corp Payment | Yes | 07 | 2.1.0 and 2.2.0 | Acquirer | Applicable when the merchant populated the request's exemption indicator. |
Y | Fully Authenticated for Secure Corp Payment | Yes | 05 | 2.1.0 and 2.2.0 | Issuer | Applicable when the merchant did not populate the request's exemption indicator. |
Y | Fully Authenticated for Trusted Beneficiaries | Yes | 05 | 2.2.0 | Issuer | Applicable when the merchant populated the request's exemption indicator. |
Y | Fully Authenticated | Yes | 07 | 2.2.0 | Acquirer | Fully authenticated via the Visa Delegated auth program. |
I | Information Only | Yes | 07 | 2.2.0 | Acquirer | Information only flow. Transaction was not authenticated by ACS, merchant challenge preference acknowledged. |
U | Unable to Authenticate | Yes | 07 | 2.1.0 and 2.2.0 | Acquirer | Authentication Could Not Be Performed, Technical or Other Problem |
The below table provides details for additional reason codes defined by the Visa DS.
Transaction Status Reason Code | Transaction Status Reason | ECI | Authentication Value present |
---|---|---|---|
80 | Error Connecting to the ACS | 07 | No |
81 | ACS Timed Out | 07 | No |
82 | Invalid Response from ACS | 07 | No |
83 | System Error Response from ACS | 07 | No |
84 | Internal error while generating authentication value | 07 | No |
85 | Visa Merchant ID not eligible for requested program | 07 | No |
86 | Version not supported by ACS | 07 | No |
87 | Transaction excluded from Attempts processing | 07 | No |
88 | Requested program not supported by ACS | 07 | No |
89 | CAVV is included in response. Note: This is applicable for version 2.1.0 in scenarios such as the Secure Corporate Payment Exemption. | 07 | Yes |
Recurring Payments
The following are generic guidelines for the Visa Secure program.
First Authentication Transaction - For merchants to receive Dispute protection, the first transaction in the series needs to be authenticated and must follow the associated authorization rules for an authenticated transaction, i.e., the authorization is submitted with the appropriate ECI and authentication value for the Visa Secure transaction.
Authentications Request Parameters - The Recurring Payment Data (PurchaseDetails.Amount
) field, Recurring Frequency (PurchaseDetails.RecurringFrequency
) field, and Recurring Expiry (PurchaseDetails.RecurringFrequency
) field in the authentications request are required when the merchant and cardholder have agreed to recurring payments and the Recurring Expiry field must contain a date no later than the original authentication date.
Dispute Protection - If the first transaction was conducted as a Visa Secure authenticated or attempted authentication, Dispute protection applies to the original e-commerce transaction. But for all subsequent Recurring Transactions, Dispute provisions applicable for Recurring Transactions will apply and Visa Secure Dispute protection won’t be applicable.
Discover - ProtectBuy
To successfully submit authentication requests in compliance with American Express SafeKey Authentication program, specific validations as specified by SafeKey 2-0 Protocol Specification and SafeKey 2-0 Acquirer Merchant Implementation Guide are applied.
Authentications Request
Rules and Validations
Request Param | Applicability | Description |
---|---|---|
CardDetails.CardExpiryDate | Required | YYMM |
Liability Shift
transStatus | Meaning | ECI | Version | Liability Holder | Comments |
---|---|---|---|---|---|
Y | Fully Authenticated | 05 | 2.1.0 and 2.2.0 | Issuer | Successful Authentication |
A | Attempted Authentication | 06 | 2.1.0 and 2.2.0 | Issuer | Attempts server responds that EMV 3DS is not supported or Issuer Unavailable. |
N | Not Authenticated | 07 | 2.1.0 and 2.2.0 | Acquirer | Not Authenticated. Transaction could not be authenticated and Attempts do not apply. |
Amex - Safekey
Authentications Request
Rules and Validations
Request Param | Applicability | Comments |
---|---|---|
AuthenticationIndicator | Required | Additional values accepted: 80 - Membership Rewards transaction (01-PA) or Membership Rewards balance inquiry (02-NPA) 81 - Add EMV Token and perform Card Member verification as part of EMV Token ID&V (Issuer must not send AV) 82 - Maintain EMV Token information and perform Card Member verification as part of EMV Token ID&V (Issuer must not send AV). |
ChallengeIndicator | Optional: 2.2.0 | If the Challenge Indicator data element contains a value of 05, 06, or 07, the Amex DS will amend this to 02 = No challenge requested. |
AcquirerMerchantId | Required for message category PA. Optional for message category NPA. | TokenEx fills the 3DS Requestor role of an aggregator (AGG). The Amex value for the AcquirerMerchantId through our 3DS solution is 10 characters long. |
ShippingAddress fields | Conditional based on ShippingIndicator value | If ShippingIndicator is 1, 2, 3, or 4 - then the ShippingAddress fields become required. |
PurchaseDetails.Currency | Required for message category PA. Conditional for message category NPA. | The 3DS Server will validate that Purchase currency is provided for 02-NPA if requestor Authentication Indicator = 02, 03, or 80. |
Authentications and Challenge Results Response
threeDSecureResponse Param | Comments |
---|---|
authenticationType | This field could include the value of 80 - Information or Value-Added interaction. |
authenticationValue | This field will also be returned for message category NPA if the request's AuthenticationIndicator was set to either 83 or 84 and the response's transStatus is Y . |
dsTransID | This value also may be referred to as an XID by the Amex Safekey program. |
transStatus | The value A is only applicable to message category PA. The value I is not used by Amex SafeKey. |
transStatusReason | Additional values that may be present 80 - PAN/Token is not eligible for Amex SafeKey. 81 - Message version number not supported by ACS for PAN/Token. |
Liability Shift
The below table outlines what to expect for liability shifts.
transStatus | Meaning | Authentication Value Present | ECI | Version | Liability Holder | Comments |
---|---|---|---|---|---|---|
Y | Fully Authenticated | Yes | 05 | 2.1.0 and 2.2.0 | Issuer | Successful Authentication |
A | Attempted Authentication | Yes | 06 | 2.1.0and 2.2.0 | Issuer | Attempts response from Issuer ACS |
N | Not Authenticated | No | N/A | 2.1.0 and 2.2.0 | Acquirer | Not Authenticated. Transaction could not be authenticated and Authorization should not be attempted. |
R | Rejected | No | N/A | 2.1.0 and 2.2.0 | Acquirer | Payment Transaction rejected by Issuer. Authorization should not be attempted. |
U | Unable to Authenticate | No | 07 | 2.1.0 and 2.2.0 | Acquirer | Merchant obtained and conveyed Card Member information, but authentication was not performed by ACS. |
U | Unable to Authenticate | No | 07 | 2.1.0 and 2.2.0 | Acquirer | PAN or Token is not eligible for SafeKey. TransStatusReason - 80. |
I | N/A | N/A | N/A | N/A | N/A | Not Supported by Amex |
JCB - J/Secure
Authentications Request
Rules and Validations
Request Param | Applicability | Comments |
---|---|---|
RequestorId | Required | JCB requires a unique 3DS Requestor ID (threeDSRequestorID), and 3DS Requestor Name (threeDSREquestorName) be assigned to each merchant and sent in the Authentication Request (AReq). The format for this value is as follows: AcquirerBin + MCT + AcquirerMerchantId. That's 8 digits + MCT + 15 digits, for an example value of 12345678MCT123456789123456 . |
RequestorName | Required | JCB requires a unique 3DS Requestor ID (threeDSRequestorID), and 3DS Requestor Name (threeDSREquestorName) be assigned to each merchant and sent in the Authentication Request (AReq). This value is the Merchant Name associated with the Merchant ID at time of authentication. |
MerchantDetails.CountryCode | 2.1.0 and 2.2.0, Required for message category PA. Optional for message category NPA | This field accepts an additional value. 900 - Country Unknown |
Authentications Response
threeDSecureResponse param | Comments |
---|---|
transStatusReason | The version specified in request is not supported by the ACS. An ECI of 07 will be returned and the authentication value will not be present. |
Cartes Bancaires - FAST'R
Supported Versions Response
Authentications Request
In addition to any specific details in the Rules and Validations table below, the following data elements are recommended by the FAST'R by CB program to increase likelihood of a frictionless authentication.
- AddressMatchIndicator
- AccountInfo (see table below)
- CardholderDetails.BillingAddress
- CardholderDetails.ShippingAddress
- CardholderDetails.Name
- CardholderDetails.EmailAddress
- CardholderDetails.HomePhone
- CardholderDetails.MobilePhone
- CardholderDetails.WorkPhone
- MerchantDetails.RiskIndicator (see table below)
- PriorAuthenticationInformation.PriorTransactionReference (see table below)
Rules and Validations
Request Param | Applicability | Comments |
---|---|---|
RequestorId | Required | This field should be set with the SIRET Number, either of the Merchant or of other entity for which Cardholder authentication is necessary as identified by the Cardholder when initiating the transaction. - If transaction is to be processed by a CB acquirer but NOT for a payment/enrolment with a Wallet approved by CB, then the SIRET Number of the 3DS Requestor (numeric value on 14 characters) must be provided - If transaction is to be processed by a CB acquirer for a payment/enrolment with a Wallet approved by CB, then the SIRET Number of the 3DS Requestor (numeric value on 14 characters) + ‘Identifiant Wallet’ of the approved Wallet (numeric value on 20 characters) must be provided.If transaction processed by a CB acquirer NOT for a payment/enrolment with a Wallet approved by CB:CB2A field 47 / 96 = SIRET Number of the 3DS Requestor (numeric value on 14 characters) If transaction processed by a CB acquirer for a payment/enrolment with a Wallet approved by CB:CB2A field 47 / 96 + CB2A field 59 / 0418 = SIRET Number of the 3DS Requestor + WalletID of the approved Wallet (numeric value on 20 characters) If transaction NOT processed by a CB acquirer: Follow international scheme 3DS Requestor ID |
RequestorName | Required | This field should be set with the name that must be displayed by the ACS in the 3-D Secure UI when it summarizes the operation for cardholder authentication (e.g. on the Challenge UI). If the merchant name field is present in the request, then fill this field with the same value. If the merchant name is not present in the request, then provide the commercial name of the 3DS Requestor. |
AcquirerBin | CB DS has specific provisions for Acquirer BIN if the transaction will be CB Acquired | If transaction processed by a CB acquirer: Same as in authorization request = CB2A field 32 (11 characters with a numeric value) = Acquirer BIN (6 characters) + Bank Code (5 characters) If transaction NOT processed by a CB acquirer: Acquirer BIN should be of the Global Network |
MerchantDetails.AcquirerMerchantId | CB DS has specific provisions for Acquirer BIN if the transaction will be CB Acquired | If transaction processed by a CB acquirer: Same as in 3DS v1 authentication requests = CB2A field 42 (15 characters blank-padded on the right) + “-” (1 character) + CB2A field 41 (8 characters blank-padded on the right) e.g. 123456789_____-1236____ If transaction NOT processed by a CB acquirer: Acquirer BIN should be of the Global Network |
MerchantDetails.CountryCode | 2.1.0 and 2.2.0, Required for message category PA. Optional for message category NPA | This field accepts an additional value. 900 - Country Unknown |
AccountInfo.PurchaseAccount | CB DS has specific provisions for values within the Account Info sub-elements | Allowed values: 0-9999 (9999 if more than 9999 transactions) |
AccountInfo.PaymentAccountAgeIndicator | CB DS has specific provisions for values within the Account Info sub-elements | Allowed values: 01, 02, 03, 04 and 05 |
AccountInfo.ProvisioningAttemptsPerDay | CB DS has specific provisions for values within the Account Info sub-elements | Allowed values: 0-999 (999 if more than 999 transactions) |
AccountInfo.ShippingAddressUsageIndicator | CB DS has specific provisions for values within the Account Info sub-elements | Allowed values: 01, 02, 03 and 04 |
AccountInfo.ShippingNameIndicator | CB DS has specific provisions for values within the Account Info sub-elements | Allowed values: 01 and 02 |
AccountInfo.SuspiciousAccountActivity | CB DS has specific provisions for values within the Account Info sub-elements | Allowed values: 01 and 02 |
AccountInfo.TransactionsPerDay | CB DS has specific provisions for values within the Account Info sub-elements. Rather than recommended, this field is optional. | Allowed values: 0-999 (999 if more than 999 transactions). |
AccountInfo.TransactionsPerYear | CB DS has specific provisions for values within the Account Info sub-elements | Allowed values: 0-999 (999 if more than 999 transactions) |
BrowserInfo.IpAddress | Element is required _if Device Channel is BRW and transaction processed by a CB acquirer, else _recommended _for frictionless if Device Channel = BRW and transaction _not processed by a CB acquirer. | If transaction submitted via a CB Acquirer and Device Channel is BRW, then the CB DS will validate as a required field. Otherwise validated as a recommended field for frictionless if Device Channel is BRW and transaction is not processed by a CB acquirer. |
MerchantDetails.RiskIndicator | Recommended for frictionless authentication. | Additional values accepted. 80 - pick up n go delivery. 81 - locker delivery or other automated pick-up. |
ChallengeIndicator | See Liability Shift | Additional value is accepted that is applicable to message category PA. 90 - CB Scoring Data. |
PriorAuthenticationInformation.PriorTransactionReference | Recommended for frictionless authentication. | If transaction is to be processed by a CB acquirer for a payment with a Wallet approved by CB, then the value to be provided is the ACS Transaction ID of the 3DS operation performed to authenticate the enrolment on the approved Wallet |
Liability Shift
The liability for a fraudulent transaction is shifted to the merchant based off the authentications request ChallengeIndicator
value.
Authentication Request ChallengeIndicator | If the Issuer applies frictionless authentication | If the Issuer applies a challenge |
---|---|---|
Merchant asks for frictionless authentication | Liability holder is the merchant if the authentications request's ChallengeIndicator had the value of 2. | Liability holder is Issuer. |
Merchant requests a challenge | Liability holder is Issuer. | Liability holder is Issuer. |
Merchant has no preference | Liability holder is Issuer. | Liability holder is Issuer. |
Updated 23 days ago