Cardholder authentication service
The PCI/Charge/Authenticate Web Service is intended to authenticate the cardholder using the authentication protocol supported by the payment method.
The service authenticates the cardholder and returns the authentication information at the end of the process.
Other authentication protocols may be added to this list.
When 3DS v2 authentication is not possible, the service automatically and seamlessly attempts 3DS v1 authentication.
The service adopts an operating principle that ignores the underlying protocol to provide a unique integration experience, and not integration by protocol.
The typical flow of a complete authentication can be broken down into several steps:
- An initial call to the PCI/Charge/Authenticate service with a response of AuthenticationResult or AuthenticationInstruction type.
- If the return belongs to the AuthenticationInstruction type, the operation must be performed on the merchant side:
- Creation of a visible or invisible iFrame.
- In the iFrame, browser redirection to a target page after submitting a form that respects the definition specified in the instruction.
- Potential interaction with the cardholder or the browser.
- New call to the PCI/Charge/Authenticate service with the signed result of the instruction obtained via the browser.
- Then, the PCI/Charge/Authenticate service once again returns either an instruction or a result.
- If the return is of AuthenticationResult type, it will contain the final authentication result and the process is complete.
The following flowchart presents a generic payment scenario with authentication: the initial call to the service, an instruction, an interaction, the final authentication result and the end of payment.
Payment gateway server
Remote server (e.g.: ACS)
|3DS Requestor||The requestor upon 3DS authentication, usually the Merchant or their payment gateway.|
|3DS Server||3DS Server. Component of the 3DS Requestor domain that initiates the 3DS v2 process and communicates with the DS or the ACS during transaction authentications. It facilitates the interaction between the 3DS Requestor and the DS.|
|ACS||Access Control Server. Component that checks whether authentication is available for a card number and authenticates specific transactions.|
|Application 3DS Requestor||Application on the Buyer’s mobile device that can process a 3DS transaction thanks to the use of 3DS SDK. The application is available by means of integration with 3DS SDK.|
|Challenge||Interactive authentication phase between the Buyer and their bank (ACS).|
|CReq||3DS v2 cardholder authentication request message sent to the ACS.|
|DS||Directory Server. Component that maintains the list of intervals for cards with possible authentication allowing MPIs / 3DS Servers / ACS to communicate with each other during authentications.|
|Fingerprinting||Corresponds to getting a fingerprint. Unique Buyer identification using browser data.|
|MPI||Merchant Plug-In. Component that initiates the v1 3DS process and communicates with the DS or the ACS during transaction authentications.|
|paReq||3DS v1 request message of cardholder authentication, sent to the ACS.|
|SDK 3DS||3D Secure development kit. Software component included in a 3DS Requestor Application.|