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

Request Fields

The

consumerAuthenticationInformation.referenceId

field is mapped from the

consumerAuthenticationInformation.referenceId

field as discussed in Step 1: Setup Service.

consumerAuthenticationInformation.returnUrl

is set to the URL to which the issuing bank redirects the customer as discussed in Step 4: Step-Up Iframe.

To request the Check Enrollment service, you must send either the encrypted payment data or a token or some other equivalent of card data used by your integration. The request fields can include any of these:

paymentInformation.card.number

paymentInformation.fluidData.value

paymentInformation.fluidData.descriptor

paymentInformation.customer.customerID

tokenInformation.transientToken

These fields are required (merchant ID is in the header):

consumerAuthenticationInformation.referenceId

consumerAuthenticationInformation.returnUrl

orderInformation.amountDetails.currency

orderInformation.amountDetails.totalAmount

orderInformation.billTo.address1

orderInformation.billTo.administrativeArea

orderInformation.billTo.country

orderInformation.billTo.email

orderInformation.billTo.firstName

orderInformation.billTo.lastName

orderInformation.billTo.postalCode

paymentInformation.card.expirationMonth

paymentInformation.card.expirationYear

paymentInformation.card.cardType

paymentInformation.card.number

You can send additional request data to reduce your issuer step-up authentication rates. Send all available fields. As a backup, if device data collection fails, include the 11 device information fields listed among the optional fields for the Check Enrollment service in your request. If a failure does occur, adding these device information fields ensures a transaction is not downgraded. If you do not have data for a field, do not send dummy data.

The size of the step-up iframe discussed in Step 4: Step-Up Iframe can vary depending on the EMV 3-D Secure version of the transaction. You can request the size of the challenge window in the

consumerAuthenticationInformation.acsWindowSize

request field.

Requesting a specific window size does not guarantee this size. Parsing the PAReq as described in Step 4: Step-Up Iframe determines the actual size.

For further details on individual API fields, refer to the API Field Reference Guide
. The field values should use the ISO 3166-2 format.

Back to top