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.acsInfoIndDescription
01Authentication Available at ACS
02Attempts Supported by ACS or DS
03Decoupled Authentication Supported
04Whitelisting Supported
80Card Range is enrolled is Smart Authentication Stand-In Service
81Card Range is enrolled in Smart Authentication Direct
84Card Range supports payment transactions
86Card Range supports the app channel
85Card Range supports non-payment transactions
87Card Range supports the browser channel
88Card Range supports app-based ACS/Issuer Challenge Capabilities
89Card Range supports browser-based ACS/Issuer Challenge Capabilities
90Card Range is Enrolled in Identity Check Express
91Card range supports Authentication Express Merchant Delegation for Identity Check Express (Type I)
92Card range supports Authentication Express Low Fraud Merchant (Type II)
93Card Range participates in Authentication Express Wallet Delegation
94Card Range participates in Authentication Express Device Delegation

Authentications Request

Rules and Validations

Request ParameterApplicabilityDescription
MerchantDetails.AcquirerMerchantIdRequired: message category PA
Optional: message category NPA
Must match 3DS Enrollment data
AcquirerBinRequired: message category PA
Optional: message category NPA
Must match 3DS Enrollment data
MerchantDetails.NameRequired: 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
MessageCategoryRequired1 (PA) or 2 (NPA) or 80 (IDCI, see section below).

Liability Shift

The below table outlines what to expect for liability shifts.

transStatusMeaningMessage CategoryAuthentication Value presentECIVersionLiability HolderComment
YFully AuthenticatedPAYes022.1.0 and 2.2.0IssuerSuccessful authentication by the ACS (including whitelisting exemption and decoupled authentication)
YFully AuthenticatedPAYes072.1.0 and 2.2.0IssuerRecurring 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).
YFully AuthenticatedPANo022.1.0 and 2.2.0IssuerSuccessful Frictionless authentication of low-risk transaction by Mastercard Stand-In RBA service (including recurring transaction)
AAttempted AuthenticationPANo012.1.0 and 2.2.0IssuerSuccessful Frictionless authentication of non low-risk transaction by Mastercard Stand In RBA service (including recurring transaction)
AAttempted AuthenticationPANo012.1.0 and 2.2.0IssuerMerchant only authenticated.
Attempts: Transaction could not be authenticated by either the ACS or Mastercard RBA (including recurring transaction)
NNot AuthenticatedPANo002.1.0 and 2.2.0AcquirerNot Authenticated: Transaction could not be authenticated, and Attempts doesn’t apply
RRejectedPANo002.1.0and 2.2.0N/APayment Transaction rejected by Issuer. Authorization should not be attempted.
IInformation onlyPAYes062.2.0AcquirerInformation 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)
YFully AuthenticatedPAYes022.1.0 and 2.2.0IssuerSuccessful authentication by the Mastercard Identity Check Express (IDCX) Service
UIdentity Check InsightsPAYes042.1.0 and 2.2.0AcquirerIdentity Check Insights transaction
UIdentity Check InsightsPAYes042.2.0AcquirerIdentity Check Insights transaction on 3RI Device Channel
YFully AuthenticatedNPANoN22.1.0 and 2.2.0N/AAuthenticated: Frictionless Transaction, Authenticated by ACS
YFully AuthenticatedNPAYesN22.1.0 and 2.2.0N/AAuthenticated: Challenge Transaction, Authenticated by ACS
NNot AuthenticatedNPANoN02.1.0 and 2.2.0N/ANot Authenticated: Transaction could not be authenticated, and Attempts doesn’t apply.
RRejectedNPANoN02.1.0 and 2.2.0N/ATransaction rejected by Issuer. Authorization should not be attempted.
IInformation onlyNPANoN02.2.0N/AInformation 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, transStatusReasonApplicabilityApplicable Scenario
802.1.0 and 2.2.0Sent by the Mastercard DS to indicate that the authentication was processed through Identity Check Insights.
812.1.0Sent by the ACS with a transaction status of N in the authentications response, indicating a successful authentication of an Acquirer SCA exemption transaction.
822.1.0 and 2.2.0Sent 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”.
832.1.0 and 2.2.0Sent 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).
842.1.0 and 2.2.0Sent by the Mastercard DS to indicate that the transaction was not processed by Smart Authentication due to challenge cancellation.
872.1.0 and 2.2.0Sent by the Mastercard DS to indicate that the request was not routed to Smart Authentication Stand-In due to the Device Channel being 3RI.
882.1.0 and 2.2.0Sent 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 to 01 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 ParamValue and Details
MessageCategory1 - Payment Authentication
DeviceChannel1 - App, 2 - Browser
AuthenticationIndicator2 - Recurring Transaction
ChallengeIndicator"03" - Challenge requested because merchant preference
"04" - Challenge requested because of a mandate
ThreeDSecureResponse ParamValue and Details
transStatusY - Fully Authenticated
eci02 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 ValueAuthentication FlowAuthentication Value Prefix
02FrictionlesskA
02ChallengedkB
07FrictionlesskO
07ChallengedkP

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 ParamValue and Details
MessageCategory1 - Payment Authentication
DeviceChannel3 - 3RI
ThreeRIIndicator1 - Recurring Transaction
PriorAuthenticationInformation.DataDS Transaction ID of the initial or the first recurring payment transaction
ThreeDSecureResponse ParamValue and Details
transStatusY - Fully Authenticated
eci07 (see authentication value details below)
authenticationValueThe 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 ParamValue 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 ParamValue and Details
MessageCategory80 - IDCI
DeviceChannel3 - 3RI
ThreeRIIndicator1 - Recurring Transaction
PriorAuthenticationInformation.DataDS 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 paramValue and Details
transStatusU - Authentication could not be performed. This transStatus is applicable to every IDCI transaction.
eci04
authenticationValueAn 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 ParamValue and Details
MessageCategory80 - IDCI
DeviceChannel1 - App, 2 - Browser
AuthenticationIndicator2 - Recurring Transaction
ChallengeIndicator"03" - Challenge requested because merchant preference
"04" - Challenge requested because of a mandate
ThreeDSecureResponse ParamValue and Details
transStatusU - Authentication could not be performed. This transStatus is applicable to every IDCI transaction.
eci04
authenticationValueAn authentication value is not present in IDCI transaction responses.

Authentication parameters for a subsequent recurring transaction

Request ParamValue and Details
MessageCategory80 - IDCI
DeviceChannel3 - 3RI
ThreeRIIndicator1 - Recurring Transaction
PriorAuthenticationInformation.DataDS 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 ParamValue and Details
transStatusU - Authentication could not be performed. This transStatus is applicable to every IDCI transaction.
eci04
authenticationValueAn 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.acsInfoIndDescription
01Authentication Available at ACS
02Attempts Supported by ACS or DS
80TRA Supported by issuer
81Data-only Supported by issuer
82Delegated Authentication Supported by issuer

Authentications Request

Rules and Validations

Request ParameterApplicabilityDescription
CardDetails.CardExpiryDateRequiredYYMM
TransactionTypeRequired1 - Goods/Service Purchase
3 - Check Acceptance
10 - Account Funding
11 - Quasi–Cash Transaction
28 - Prepaid Activation and Load
ThreeDSecureRequestorAuthenticationInformation.MethodRequired 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
ThreeRIIndicatorRequired for device channel 3RI1 = 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.
AcquirerBinRequiredVisa requires this field for both Message Categories PA and NPA.

These are additional challenge indicator values applicable to the Visa DS

ChallengeIndicatorDescription
81Visa-specific Data-only transaction. This will only be applicable for 2.2.0.
82NO CHALLENGE REQUESTED. The merchant is requesting to utilize Secure Corporate Exemption as applicable.
83NO 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.

transStatusMeaningAuthentication Value presentECIVersionLiability HolderComment
YFully AuthenticatedYes052.1.0 and 2.2.0IssuerSuccessful authentication.
AAttempted AuthenticationNo062.1.0 and 2.2.0AcquirerAuthentication attempted but no CAVV provided by issuer.
NNot AuthenticatedNo072.1.0 and 2.2.0AcquirerTransaction could not be authenticated and Attempts does not apply.
RRejectedNo072.1.0 and 2.2.0AcquirerPayment Transaction rejected by Issuer. Authorization should not be attempted.
YFully Authenticated with TRA exemptionYes072.2.0AcquirerApplicable when the merchant populated the request's exemption indicator.
YFully Authenticated with TRA exemptionYes052.2.0IssuerApplicable when the merchant did not populate the request's exemption indicator.
YFully Authenticated with low valueYes052.1.0 and 2.2.0IssuerIssuer applied the low value exemption.
YFully Authenticated for Secure Corp PaymentYes072.1.0 and 2.2.0AcquirerApplicable when the merchant populated the request's exemption indicator.
YFully Authenticated for Secure Corp PaymentYes052.1.0 and 2.2.0IssuerApplicable when the merchant did not populate the request's exemption indicator.
YFully Authenticated for Trusted BeneficiariesYes052.2.0IssuerApplicable when the merchant populated the request's exemption indicator.
YFully AuthenticatedYes072.2.0AcquirerFully authenticated via the Visa Delegated auth program.
IInformation OnlyYes072.2.0AcquirerInformation only flow. Transaction was not authenticated by ACS, merchant challenge preference acknowledged.
UUnable to AuthenticateYes072.1.0 and 2.2.0AcquirerAuthentication 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 CodeTransaction Status ReasonECIAuthentication Value present
80Error Connecting to the ACS07No
81ACS Timed Out07No
82Invalid Response from ACS07No
83System Error Response from ACS07No
84Internal error while generating authentication value07No
85Visa Merchant ID not eligible for requested program07No
86Version not supported by ACS07No
87Transaction excluded from Attempts processing07No
88Requested program not supported by ACS07No
89CAVV is included in response. Note: This is applicable for version 2.1.0 in scenarios such as the Secure Corporate Payment Exemption.07Yes

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 ParamApplicabilityDescription
CardDetails.CardExpiryDateRequiredYYMM

Liability Shift

transStatusMeaningECIVersionLiability HolderComments
YFully Authenticated052.1.0 and 2.2.0IssuerSuccessful Authentication
AAttempted Authentication062.1.0 and 2.2.0IssuerAttempts server responds that EMV 3DS is not supported or Issuer Unavailable.
NNot Authenticated072.1.0 and 2.2.0AcquirerNot Authenticated. Transaction could not be authenticated and Attempts do not apply.

Amex - Safekey

Authentications Request

Rules and Validations

Request ParamApplicabilityComments
AuthenticationIndicatorRequiredAdditional 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).
ChallengeIndicatorOptional: 2.2.0If the Challenge Indicator data element contains a value of 05, 06, or 07, the Amex DS will amend this to 02 = No challenge requested.
AcquirerMerchantIdRequired 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 fieldsConditional based on ShippingIndicator valueIf ShippingIndicator is 1, 2, 3, or 4 - then the ShippingAddress fields become required.
PurchaseDetails.CurrencyRequired 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 ParamComments
authenticationTypeThis field could include the value of 80 - Information or Value-Added interaction.
authenticationValueThis 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.
dsTransIDThis value also may be referred to as an XID by the Amex Safekey program.
transStatusThe value A is only applicable to message category PA. The value I is not used by Amex SafeKey.
transStatusReasonAdditional 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.

transStatusMeaningAuthentication Value PresentECIVersionLiability HolderComments
YFully AuthenticatedYes052.1.0 and 2.2.0IssuerSuccessful Authentication
AAttempted AuthenticationYes062.1.0and 2.2.0IssuerAttempts response from Issuer ACS
NNot AuthenticatedNoN/A2.1.0 and 2.2.0AcquirerNot Authenticated. Transaction could not be authenticated and Authorization should not be attempted.
RRejectedNoN/A2.1.0 and 2.2.0AcquirerPayment Transaction rejected by Issuer. Authorization should not be attempted.
UUnable to AuthenticateNo072.1.0 and 2.2.0AcquirerMerchant obtained and conveyed Card Member information, but authentication was not performed by ACS.
UUnable to AuthenticateNo072.1.0 and 2.2.0AcquirerPAN or Token is not eligible for SafeKey. TransStatusReason - 80.
IN/AN/AN/AN/AN/ANot Supported by Amex

JCB - J/Secure

Authentications Request

Rules and Validations

Request ParamApplicabilityComments
RequestorIdRequiredJCB 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.
RequestorNameRequiredJCB 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.CountryCode2.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 paramComments
transStatusReasonThe 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 ParamApplicabilityComments
RequestorIdRequiredThis 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
RequestorNameRequiredThis 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.
AcquirerBinCB DS has specific provisions for Acquirer BIN if the transaction will be CB AcquiredIf 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.AcquirerMerchantIdCB DS has specific provisions for Acquirer BIN if the transaction will be CB AcquiredIf 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.CountryCode2.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.PurchaseAccountCB DS has specific provisions for values within the Account Info sub-elementsAllowed values: 0-9999 (9999 if more than 9999 transactions)
AccountInfo.PaymentAccountAgeIndicatorCB DS has specific provisions for values within the Account Info sub-elementsAllowed values: 01, 02, 03, 04 and 05
AccountInfo.ProvisioningAttemptsPerDayCB DS has specific provisions for values within the Account Info sub-elementsAllowed values: 0-999 (999 if more than 999 transactions)
AccountInfo.ShippingAddressUsageIndicatorCB DS has specific provisions for values within the Account Info sub-elementsAllowed values: 01, 02, 03 and 04
AccountInfo.ShippingNameIndicatorCB DS has specific provisions for values within the Account Info sub-elementsAllowed values: 01 and 02
AccountInfo.SuspiciousAccountActivityCB DS has specific provisions for values within the Account Info sub-elementsAllowed values: 01 and 02
AccountInfo.TransactionsPerDayCB 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.TransactionsPerYearCB DS has specific provisions for values within the Account Info sub-elementsAllowed values: 0-999 (999 if more than 999 transactions)
BrowserInfo.IpAddressElement 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.RiskIndicatorRecommended for frictionless authentication.Additional values accepted.
80 - pick up n go delivery.
81 - locker delivery or other automated pick-up.
ChallengeIndicatorSee Liability ShiftAdditional value is accepted that is applicable to message category PA. 90 - CB Scoring Data.
PriorAuthenticationInformation.PriorTransactionReferenceRecommended 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 ChallengeIndicatorIf the Issuer applies frictionless authenticationIf the Issuer applies a challenge
Merchant asks for frictionless authenticationLiability holder is the merchant if the authentications request's ChallengeIndicator had the value of 2.Liability holder is Issuer.
Merchant requests a challengeLiability holder is Issuer.Liability holder is Issuer.
Merchant has no preferenceLiability holder is Issuer.Liability holder is Issuer.