On This Page
REST API

Payer Authentication Process Flow Overview

While each merchant's web browser-based flow will differ according to their individual circumstances, a general overview of the Payer Authentication process is described below.
  1. When the cardholder checks out, and
    before
     the
    Buy Now
     button is pressed, a call is made to the
    pa_setup
     service. This call generates a JWT and returns a
    sessionId
     that is used for device collection in the next step.
  2. The response from the
    pa_setup
     service call, returns a JWT and device data collection URL (DCC URL) to which the merchant must POST to the DDC URL in a hidden 10x10 frame including the JWT as a POST parameter; enabling EMVCo and issuer device collection.
  3. After device collection is completed, a POST response is sent to the merchant to confirm that device collection completed and that the user can place the order by pressing the
    Buy Now
     button. To ensure enough time for device collection to complete, you should ensure that there Is an eight-second delay before the
    Buy Now
     button is enabled.
  4. Pressing
    Buy Now
     triggers the
    pa_enroll
     service request that relays the order details (billing, email, phone information, etc.) and the initial
    sessionId
     returned from the
    pa_setup
     service. The
    pa_enroll
     initiates 3-D Secure and checks with the issuing bank to see if a bank challenge/step up requiring the cardholder to provide additional authentication is necessary.
  5. The
    pa_enroll
     response can occur in two different ways:
    • If no step up or challenge is necessary (frictionless flow), the response includes the ECI, CAVV, DSTransactionId, and a PAResStatus. The PAResStatus can be Y or A for successful authentication or N, U, R for failed, unavailable, or rejected authentication. With successful authentication, the data points are added to the authorization message and the order is completed.
    • If the issuer needs to step up and challenge (friction flow), the response returns an ACS Url, a PAReq payload, a ParesStatus=C, a StepUpURL, a new JWT, and a TransactionId.
  6. The JWT and the StepUpUrl received in the
    pa_enroll
     response, is passed to the client and a POST goes to the StepUpUrl in a viewable iframe with the JWT as a POST parameter to display a bank challenge screen. This enables the cardholder to view and respond to any bank challenge screen.
  7. After the cardholder completes the bank challenge by providing additional authentication, a POST is sent to the merchant's returnUrl contained in the JWT. This POST is a notification that the challenge is complete and triggers the merchant to make a
    pa_validate
     call to obtain the final authentication outcome.
  8. The challenge response triggers the
    pa_validate
     request with the TransactionId. The response to this
    pa_validate
     request contains the final authentication results including the final ECI, CAVV (if successful), DSTransactionId, ThreeDSVersion, and PAResStatus (Y or A = successful or N, U, R = failed, unavailable, or rejected).
  9. If the authentication result is:
    • Successful—Proceed to authorization and append the 3-D Secure data points to the authorization message.
    • Failed, Unavailable, or Rejected—The cardholder is returned to the payment page to attempt payment with a different card.