On This Page

{#jumplink-list}  
[Markdown](/content/cybsdeveloper2021/amer/en/docs/barclays/en-us/payer-authentication/developer/all/rest/payer-auth/pa2-intro-intro/pa2-intro-workflows.md)

Payer Authentication Customer Workflow {#pa2-intro-workflows}
=============================================================

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*).

#### Figure: {#pa2-intro-workflows_fdc}

Payer Authentication Workflow ![Payer Authenticatiion Workflow Diagram](/content/dam/new-documentation/documentation/en-us/topics/risk/payer-authentication/payer-auth/images/how-payer-auth-works-3.svg/jcr:content/renditions/original)

Frictionless Workflow {#pa2-intro-workflows_section_nqp_xv3_mxb}
----------------------------------------------------------------

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.
   {#pa2-intro-workflows_ol_wl4_n3f_kxb}

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.

