On This Page
Simple Order API

Payer Authentication Customer Workflow

During authentication for each transaction, data is collected about the device that the customer is using 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
).
Payer Authentication Workflow
Payer Authenticatiion Workflow Diagram

Frictionless Workflow

With frictionless workflow, 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 workflow 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. It could occur because the customer got a new device that has not been registered yet or because they bought something while traveling on vacation. The issuer of the card decides whether further authentication of the customer is required and requests that the customer prove that they are the cardholder. The customer is asked to return a passcode to the issuer. Below is a general description of this workflow 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 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 buyer.
  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 was 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 sees a message that the transaction is declined and that another form of payment should be attempted.