Payer Authentication Customer Workflow

During authentication for each transaction, data is collected about the customer's device, and the shipping and billing information is compared with transaction history. The workflow in payer authentication can go one of two possible ways: frictionless and challenge (also known as step-up).

Frictionless Workflow

With frictionless flow, the authentication process is not visible to the customer. The data collected during the transaction matches the data collected from past transactions with the customer. The risk for fraud is calculated to be low enough that further authentication is unnecessary. The transaction can continue to authorization.

1. The customer enters card information at checkout. Information about the device being used by the customer and shopping behavior is collected and relayed from the merchant to the issuing bank. A delay of about 10 seconds is built into the process to ensure that the device data can be transmitted and assessed before the Buy option is enabled.
2. The customer selects Buy.
3. The issuing bank verifies the information it receives against previous transactions. If the device data correlates with the information, the transaction is approved without the buyer having to provide any additional information.

Challenge Workflow

A challenge flow occurs when the data collected during the transaction does not match the information on file from previous transactions with the customer. This process occurs for multiple reasons and does not necessarily mean that the customer has fraudulent intent. For example, it could occur because the customer got a new device that has not been registered yet or because they bought something while traveling. The issuer of the card decides whether further authentication of the customer is required and if necessary, requests that the customer prove their identity by returning a passcode to the issuer. This sequence describes the interaction from the customer viewpoint.

1. The customer enters card information at checkout. Information about the customer's device is collected and sent from the merchant to the issuing bank.
2. The customer selects Buy.
3. The issuing bank assesses risk by comparing the information it receives to information on file from previous transactions with the customer. If the device data does not match the information collected previously, the issuer requests further authentication.
4. A small window opens on the checkout page where a message from the bank asks if the customer wants to use email or text message to receive a one-time password (OTP) from the bank.
5. The customer chooses how the password is sent.
6. The issuer sends an OTP to the account on file for the customer.
7. A window opens on the checkout page on the customer device prompting the customer to enter the OTP sent by the issuer.
8. The customer enters the password that they received and sends it back to the issuer.
9. If the password entered by the customer matches the password sent by the issuer, the customer is authenticated, and the transaction can proceed to authorization. If the password does not match the password that the bank sent, the customer receives a message that the transaction is declined and that they should attempt another form of payment.

Payer Authentication Merchant Workflow

Transaction circumstances might result in differences to the more detailed payer authentication process described in this section.

1. Before the Buy button is selected at checkout, the Setup service is called. The full card number identifies how to contact the issuing bank. The issuing bank sends an access token and a URL (called the DCC URL) to use for the data collected about the device where the transaction is occurring.
2. The merchant collects data about the device and includes billing and shipping information. The merchant posts this data to a hidden 10 pixel x 10 pixel iframe to send to the DDC URL provided by the card issuer for comparison with past transactions. After the data points are collected and sent, the issuing bank confirms that data collection ended and the Buy button is enabled. An 8-10 second delay ensures enough time for data collection.
3. Clicking Buy triggers the Check Enrollment service sending the order data (and session ID) to the issuer. If the bank is not part of an EMV 3-D Secure program, the payer authentication process stops. If the issuing bank is part of an EMV 3-D Secure program, the device data is compared to information on file collected at the bank during previous transactions with the cardholder.
   • The issuer's risk analysis software determines whether enough data points collected by the merchant match the data in the bank's files. If the data matches well, no further interaction is needed. This is called frictionless flow because no challenge to the buyer is necessary. The response returned to the merchant includes a payload with values like the ECI, CAVV, DS Transaction Id, and the PARes Status. These values must be passed on during the request for authorization. Note that frictionless flow can occur because the payer is authenticated, but it can also occur for other reasons. For example, the issuing bank does not participate in payer authentication. Therefore, response values must be verified to determine why no step-up is needed.
   • If a significant discrepancy occurs between the transaction data and the data on file with the bank, the bank requests that the payer authenticate. This is a friction workflow and is called a step up or challenge. The response from the bank contains the same values returned for a frictionless workflow but also includes additional values like the Access Control Server (ACS) URL, the PAReq payload, a Pares Status = C, a Step Up URL, a new JWT, and a Transaction Id.
4. The JWT and the step up URL received in the check enrollment response are returned to the customer. Using the step up URL with the JWT as a POST parameter, a challenge screen opens in a viewable iframe on the buyer's device so that the cardholder can view and respond to the bank challenge. The challenge consists of the bank sending a pass code that the customer returns to the bank. The challenge asks how the customer wants to receive a pass code, by text or email. After the customer chooses, they receive a pass code that they must enter into the challenge screen.
5. After the cardholder enters and sends the passcode, the response is sent to the merchant's return URL contained in the JWT. This response causes the merchant to make a validation call to the bank to obtain the final authentication outcome. The response to this validation request contains the final authentication results including these values: ECI, CAVV (if successful), DSTransactionId, ThreeDSVersion, and PARes Status (Y or A = successful or N, U, R = failed, unavailable, or rejected).
6. The next action depends on the outcome:
   • Successful: proceed to authorization, and append the EMV 3-D Secure data points to the authorization message.
   • Failed, unavailable, or rejected: display a message to prompt the customer to try payment with a different card.