The integration schema is depicted below.
The flow of integration for external Payment Gateway may be described as follows:
- 3dsmethod service is called to check the PAN is involved in 3DS2 or not. If yes then threeDSMethodURL is returned with threeDSMethodData, contains threeDSServerTransID and threeDSMethodNotificationURL.
- browserinfo service accurate Browser Information is obtained in the AReq message for an ACS to determine the ability to support authentication on a particular Cardholder browser for each transaction. The 3DS Server needs to accurately populate the browser information for each transaction. This data can be obtained by 3DS software provided to the 3DS Requestor or through for example, remote JavaScript calls. It is the responsibility of the 3DS Server to ensure that the data is not altered or hard-coded, and that it is unique to each transaction.
- 3dsmethod/collect service autosubmit earlier gathered Browser Information from browserinfo call
- pArq service performs the main functionality viz. collect all necessary data, format AReq according to EMV specification and send it to appropriate DS. After the interaction with Issuer is completed transStatus has been obtained from the response. If status is С then challenge required and ACS URL is provided.
- If challenge is required then challenge is called. In response D8 3DSS will provide HTML form with CReq. The following interaction between cardholder and Issuer (challenge itself) is out of scope of 3DSS responsibility and vision.
- The next step is required when notificationURL (AReq) was specified to Payment Gateway endpoint (or browser through Payment Gateway). To obtain final CRes it is required to notificate it with 3DSS via the cresponse service.