On This Page
Simple Order 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.
- When the cardholder checks out, andthebeforeBuy Nowbutton is pressed, a call is made to thepa_setupservice. This call generates a JWT and returns asessionIdthat is used for device collection in the next step.
- The response from thepa_setupservice 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.
- Provide an eight-second delay before theBuy Nowbutton is enabled, so there is enough time for device collection to complete. After device collection is completed, a POST response is sent to the merchant confirming that device collection completed and that the user can press theBuy Nowbutton to place the order.
- PressingBuy Nowtriggers thepa_enrollservice request that relays the order details (billing, email, phone information, etc.) and the initialsessionIdreturned from thepa_setupservice. Thepa_enrollinitiates 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.
- Thepa_enrollresponse 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 must 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.
- The JWT and the StepUpUrl received in thepa_enrollresponse, is passed to the client. 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.
- 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 apa_validatecall to obtain the final authentication outcome.
- The challenge response triggers thepa_validaterequest with the TransactionId. The response to thispa_validaterequest 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).
- 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.