Cardholder authentication service (expert mode)

Presentation

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.

Supported protocols

Other authentication protocols may be added to this list.

General principle

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 theAuthenticationInstructiontype, 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.
  • Return page of the remote server that will emit a JavaScript event containing the result of the instruction.
  • Interception of the instruction result in the form of a JavaScript event in the parent window.
  • 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.

Detailed flowchart

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.

Glossary

3DS Method	JavaScript code of the ACS executed in the Buyer’s browser for the purpose of making fingerprints.
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	v2 3DS request message of cardholder authentication, 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.
SDK 3DS	3D Secure development kit. Software component included in a 3DS Requestor Application.
IAN	Server-to-server notification of authentication results (Instant Authentication Notification).
operationUrl	Url sent to authentication script initialization methodkr-authenticate.js.
operationSessionId	Unique identifier for the authentication session.