Recent Revisions to This Document

Payer Authentication Developer Guide
- VISA Platform Connect: Specifications and Conditions for Resellers/Partners

Introduction to Payer Authentication
- Why Payer Authentication Is Needed
- EMV 3-D Secure 2.0
- Payer Authentication Customer Workflow
- Payer Authentication Merchant Workflow
- Acquirer Information
- Enable Merchant Account for EMV 3-D Secure
- Payer Authentication Configuration Testing
- Request Endpoints
- Payer Authentication Integrations

Implementing Direct API for Payer Authentication
- Prerequisites
- After Implementation and Before Go Live

Step 1: Setup Service
- Request Fields
- Important Response Fields

Step 2: Device Data Collection
- Which Device Data is Collected
- Building the Iframe
- Initiating the Device Data Collection Iframe
- Submitting the Device Data Collection Iframe
- Receiving the Device Data Collection URL Response

Step 3: Payer Authentication Check Enrollment Service
- Request Fields
- Interpreting the Check Enrollment Response
- Important Response Fields

Step 4: Step-Up Iframe
- Building the Iframe Parameters
- Creating the Iframe
- Invoking the Iframe
- Receiving the Step-Up Results

Step 5: Payer Authentication Validation Service
- Request Fields
- Interpreting the Validation Response
- Redirecting Customers to Pass or Fail Message Page

Combining the Authentication and the Authorization Services
- Combining Check Enrollment and the Authorization Services
  - Check Enrollment Response Fields and Their Equivalent Authorization Request Fields
- Combining the Validation and the Authorization Services
  - Validation Fields and their Equivalent Authorization Fields

Implementing SDK Payer Authentication
- Implementation Overview
- Process Flow for SDK Integration
- Prerequisites for SDK Implementation
  - Credentials/API Keys
    - Generating your API Key:
- What Mobile Device Data is Collected
- Using the Android SDK
  - Updating the Gradle Build Properties
  - Configuring the Android SDK
  - Setting Up the Initial Call
- Using the iOS SDK
  - Downloading and Importing the SDK
  - Configuring Your Build Environment
  - Configuring the iOS SDK
  - Setting Up the Initial Call
- Running Payer Authentication with SDK
  - Requesting the Check Enrollment Service (SDK)
  - Interpreting the Response
  - Authenticating Enrolled Cards
    - Calling Cardinal.cca_continue (Android SDK)
    - Calling Cardinal session continue (iOS SDK)
    - Receiving the Authentication Results
  - Requesting the Validation Service
    - Interpreting the Response
    - Redirecting Customers to the Message Page

Payer Authentication Use Cases
- Use Case: Setting Up Device Data Collection When Using a TMS Token
  - Required Fields for Device Data Collection
  - Optional Fields for Device Data Collection
  - REST Example: Setting Up Data Collection
- Use Case: Setting Up Device Data Collection Using Digital Payment (Google Pay)
  - Required Fields for Device Data Collection
  - Optional Fields for Device Data Collection
  - REST Example: Setting Up Device Data Collection When Using Digital Payment (Google Pay)
- Use Case: Checking Enrollment in Payer Authentication
  - Required Fields for Checking Enrollment in Payer Authentication
  - Optional Fields for Checking Enrollment in Payer Authentication
  - REST Example: Checking Enrollment
- Use Case: Checking Enrollment in Payer Authentication Using Digital Payment (Google Pay)
  - Required Fields for Checking Enrollment in Payer Authentication
  - Optional Fields for Checking Enrollment in Payer Authentication
  - REST Example: Checking Enrollment in Payer Authentication Using Google Pay
- Use Case: Validating a Challenge
  - Required Fields for Validating a Challenge
  - Optional Fields for Validating a Challenge
  - REST Example: Validating a Challenge
- Use Case: Validating Step Up Using Digital Payment (Google Pay)
  - Required Fields for Validating a Challenge
  - Optional Fields for Validating a Challenge
  - REST Example: Validating a Challenge When Using Google Pay
- Use Case: Validating and Authorizing a Transaction
  - Required Fields for Processing an Authorization Using Visa Secure
  - Optional Fields for Validating a Challenge
  - REST Example: Validating and Authorizing a Transaction
- Use Case: Non-Payment Authentication
  - Required Fields for Checking Enrollment in Payer Authentication
  - REST Example: Checking Enrollment for Non-Payment Authentication

Authentication with TMS Tokens
- Use Case: Setting Up Device Data Collection When Using a TMS Token
  - Required Fields for Setting Up Data Collection When Using a TMS Token
  - REST Example: Setting Up Device Data Collection When Using a TMS Token
- Use Case: Checking Enrollment When Using a TMS Token
  - Required Fields for Checking Enrollment in Payer Authentication While Using a TMS Token
  - REST Example: Checking Enrollment When Using a TMS Token (Frictionless)
  - REST Example: Checking Enrollment When Using a TMS Token (Challenge)
- Use Case: Validating a Challenge When Using a TMS Token
  - Required Fields for Validating a Challenge When Using a TMS Token
  - REST Example: Validating a Challenge When Using a TMS Token

Authentication with Flex Micro Form Tokens
- Use Case: Setting Up Device Data Collection When Using a Flex Micro Form Token
  - Required Fields for Setting Up Device Data Collection When Using a Flex Micro Form Token
  - REST Example: Setting Up Device Data Collection When Using a Flex Micro Form Token
- Use Case: Checking Enrollment When Using a Flex Micro Form Token
  - Required Fields for Checking Enrollment When Using a Flex Micro Form Token
  - REST Example: Checking Enrollment When Using a Flex Token (Challenge)
- Use Case: Validating a Challenge When Using a Flex Micro Form Token
  - Required Fields for Validating a Challenge When Using a Flex Micro Form Token
  - REST Example: Validating a Challenge When Using a Flex Micro Form Token

Authentication with Tokenized Cards
- Use Case: Setting Up Device Data Collection When Using a Tokenized Card
  - Required Fields When Setting Up Device Data Collection Using a Tokenized Card
  - REST Example: Setting Up Device Data Collection When Using a Tokenized Card
- Use Case: Checking Enrollment When Using a Tokenized Card
  - Required Fields for Checking Enrollment When Using a Tokenized Card
  - REST Example: Checking Enrollment When Using a Tokenized Card (Frictionless)

Merchant Initiated Transactions (3RI)
- Challenge Reponses to 3RI Transactions
- Network Specific Values for 3RI

3RI Use Case 1a: Initial Recurring Transaction
- REST Example: Checking Enrollment for a 3RI Initial Recurring Transaction
- REST Example: Validating the Challenge for a 3RI Initial Recurring Transaction

3RI Use Case 1b: Recurring Payments - Subsequent Transaction (Mastercard)
- REST Example: Validating the Challenge for 3RI Subsequent Installment Transactions

3RI Use Case 2a: Installment - Customer Initiated Transaction (Mastercard)
- REST Example: Checking Enrollment for a 3RI Customer Initiated Total Installments (Mastercard)
- REST Example: Validating the Challenge for a 3RI Customer Initiated Total Installments (Mastercard)

3RI Use Case 3a: Split/Partial Shipment (Mastercard)
- REST Example: Checking Enrollment for 3RI Split Shipment Transaction (Mastercard)

3RI Use Case 3b: Split/Delayed Shipment (Visa)
- REST Example: Checking Enrollment for 3RI Split Shipment Transaction (Visa)

3RI Use Case 4a: Multi-Party Commerce or OTA (Visa)
- REST Example: Checking Enrollment for 3RI Multi-Party Commerce Transaction (Visa)

3RI Use Case 4b: Multi-Party Commerce or OTA (MasterCard)
- REST Example: Checking Enrollment for 3RI Multi-Party Commerce Transaction (Mastercard)
- REST Example: Validating the Challenge for 3RI Multi-Party Commerce Transaction (Mastercard)

3RI Use Case 4c: Multi-Party Commerce or OTA (MasterCard)
- REST Example: Checking Enrollment for 3RI Multi-Party Commerce Transaction (Mastercard)

Testing Payer Authentication
- Testing Process
  - Enrollment Check Response Fields
  - Authentication Validation Response Fields
- Test Cases for 3-D Secure 2.x
  - Test Case 2.1: Successful Frictionless Authentication
  - Test Case 2.2: Unsuccessful Frictionless Authentication
  - Test Case 2.3: Attempts Processing Frictionless Authentication
  - Test Case 2.4: Unavailable Frictionless Authentication
  - Test Case 2.5: Rejected Frictionless Authentication
  - Test Case 2.6: Authentication Not Available on Lookup
  - Test Case 2.7: Enrollment Check Error
  - Test Case 2.8: Time Out
  - Test Case 2.9: Bypassed Authentication
  - Test Case 2.10a: Successful Step-Up Authentication
  - Test Case 2.11a: Unsuccessful Step-Up Authentication
  - Test Case 2.12a: Unavailable Step-Up Authentication
  - Test Case 2.14: Require Method URL
- Payer Authentication Exemption Test Cases
  - Test Case 1a: Initial/First Recurring Transaction: Fixed Amount
  - Test Case 2a: Card Authentication Failed
  - Test Case 2b: Suspected Fraud
  - Test Case 2c: Cardholder Not Enrolled in Service
  - Test Case 2d: Transaction Timed Out at the ACS
  - Test Case 2e: Non-Payment Transaction Not Supported
  - Test Case 2f: 3RI Transaction Not Supported
  - Test Case 3a: Transaction Risk Analysis Exemption: Low Value: Mastercard EMV 3-D Secure 2.1 and 2.2
  - Test Case 3b: Transaction Risk Analysis: Low Value: Visa
  - Test Case 3c: Transaction Risk Analysis: Low Value: Discover
  - Test Case 3d: Acquirer Transaction Risk Analysis: Cartes Bancaires
  - Test Case 4a: Trusted Beneficiary Prompt for Trustlist
  - Test Case 4b: Utilize Trusted Beneficiary Exemption
  - Test Case 5a-1: Identity Check Insights (ScoreRequest = N)
  - Test Case 5a-2: Identity Check Insights (ScoreRequest = Y)
- HTTP Status Codes

Website Modification Reference
- Website Modification Checklist
- EMV 3-D Secure Services Logos
- Informational Message Examples

Alternate Methods for Device Data Collection
- Device Data Collection Overview
  - Prerequisites
  - Endpoints
- Collecting Device Data
  - Card BIN in JWT
  - Card BIN as a POST Parameter Plus JWT

Upgrading Your Payer Authentication Implementation
- Benefits
- PSD2 Impact
  - Mandates
- Recommended Integration
- Migrating from EMV 3-D Secure 1.x to 2.x FAQ

Payer Authentication Transaction Details in the Business Center
- Payer Authentication Search
- Storing Payer Authentication Data
- Searching for Payer Authentication Details
  - Enrolled Card
    - Enrollment Check
    - Authentication Validation
  - Card Not Enrolled
    - Transaction Details

Payer Authentication Reports
- Payer Authentication Summary Report
  - Downloading the Report
  - Matching the Report to the Transaction Search Results
  - Interpreting the Report
  - Comparing Payer Authentication and Payment Reports
- Payer Authentication Detail Report
  - Report Element
  - PayerAuthDetail Element
  - ProofXML Element
  - VEReq Element
  - VERes Element
  - PAReq Element
  - PARes Element
  - AuthInfo Element
  - Report Examples

Glossary

On This Page

REST API

Merchant Initiated Transactions (3RI)

A 3RI transaction is a EMV 3-D Secure transaction that is initiated by the requestor (merchant) instead of the cardholder. The merchant keeps the payment data from an initial payment so that the cardholder does not have to be present during subsequent 3RI transactions. Having the payment details from a previous transaction enables the merchant to obtain a new Cardholder Authentication Verification Value (CAVV) to authenticate when authorizing the future payments.

The authorization request contains a

3RI

value in the

consumerAuthenticationInformation.deviceChannel

field. A 3RI transaction can be used for a variety of use cases such as enabling merchants to obtain a new Cardholder Authentication Verification Value (CAVV) after obtaining the initial authentication for a customer-initiated transaction. A 3RI transaction is used for these types of transactions:

Recurring payments: Used when payments occur at regular intervals for an indefinite interval like subscription services.

Installment payments: Used when payments occur at regular intervals for a fixed interval.

Refunded purchases: Used when the cost of an item is refunded before the item is received, any charges for damage or missing items can be charged back to the customer using a 3RI transaction.

Delayed shipments: Used when an ordered item is out of stock delaying the shipment until the item is back in stock.

Split payments: Used when an order is fulfilled in split shipments rather than in a single shipment because one of multiple items in the order is temporarily out of stock.

Multiple party commerce: Used when a single agent is making multiple transactions with different merchants such as with a travel agent booking flights, hotels, and tour excursions.

Unknown final transaction amount: Used when there are extra charges to the customer such as hotel services, driving citations, or tips.

Back to top