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.

Authentications Request

Rules and Validations

Liability Shift

The below table outlines what to expect for liability shifts.

The below table provides details of the specific reason codes defined by the Mastercard DS.

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

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.

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 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.

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 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

Authentication parameters for a subsequent recurring transaction

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

Authentications Request

Rules and Validations

These are additional challenge indicator values applicable to the Visa DS

Liability Shift

The below table outlines what to expect for liability shifts.

The below table provides details for additional reason codes defined by the Visa DS.

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

Liability Shift

Amex - Safekey

Authentications Request

Rules and Validations

Authentications and Challenge Results Response

Liability Shift

The below table outlines what to expect for liability shifts.

JCB - J/Secure

Authentications Request

Rules and Validations

Authentications Response

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

Liability Shift

The liability for a fraudulent transaction is shifted to the merchant based off the authentications request ChallengeIndicator value.