Payer Authentication Merchant Workflow

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

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.

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

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. It is important to note that while frictionless flow can occur because the payer is authenticated, 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
.

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.

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 (

= successful or

= failed, unavailable, or rejected).

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.