3D-Secure

Silverflow provides a simple API to perform 3DS authentications. The goal of this API is to provide a nice and simple abstraction over the 3DS protocol, yet still provide all the data the card network exposes. Upon providing the right type of transaction, in combination with other mandatory data, such as the amount and card number, Silverflow will take care of constructing the right 3DS protocol messages and the interaction with the card network.

The 3DS protocol knows two flows: the frictionless flow and the challenge flow. The frictionless flow is executed if the issuer considers the transaction to have a low risk of fraud (a low amount for example). If the transaction has a higher risk of fraud, then additional cardholder interaction is necessary, also known as the challenge flow. The result of the 3DS process is an authentication value which has to be provided to the issuer through the card networks during authorization. Note that PIN, CVC and AVS authentication are performed during the authorization process.

The 3DS frictionless flow is the simplest 3DS flow. A 3DS call is made, and if the flow property is frictionless and the result property is authenticated, the authentication is completed.

The ares.authenticationValue and ares.dsTransID can be used for authorization; the values of these properties need to be passed in threeDsAuthenticationResult.authenticationValue and threeDsAuthenticationResult.directoryServerTransId of the charge request, respectively.

The challenge flow is a more involved flow. A challenge flow is observed when the flow property and the result property both contain challenge. This means the initial call succeeded but the cardholder still needs to perform a challenge.A cardholder challenge can be initiated by creating a CReq and filling it in with the data received in the 3DS response:

This CReq needs to be base64 URL encoded, and sent to the ares.acsURL through the cardholder browser. The HTTP method must be POST and the Content-Type must be application/x-www-form-urlencoded.

If the result in the first call is a 3DS attempt, or a non-authenticated, the flow property will be none and the result property will be attempt or non-authenticated.

3DS requester-initiated authentications (3RI), also known as merchant-initiated authentications, allows merchants to authenticate a transaction without the direct involvement of the cardholder. Essentially, 3RI is a 3DS authentication message that allows merchants to submit data to the issuer so that they can assess and authorize a payment when the buyer is not present.

The merchant just needs to have the cardholder's information stored from a previous transaction in order to generate the authentication data necessary for authorization.

In order to allow for additional browser information to be gathered by an issuer prior to the regular 3DS authentication flow, Silverflow provides the possibility to use the 3DS Method URL to facilitate this risk assessment.

The use of the 3DS Method is optional, and not all account ranges support 3DS and / or the Method URL. To assess whether a 3DS Method URL is available a POST call can be made to the /3ds/cardRanges endpoint, returning amongst other the threeDSMethodURL.

After obtaining the information on the Method URL, a hidden iFrame can be generated on the checkout page through which a POST call to the threeDSMethodURL should be made that includes the threeDSMethodNotificationURL and the threeDSServerTransID, generated by the 3DS Requestor.

When the issuer is finished, the 3DS Requestor will receive a notification on the threeDSMethodNotificationURL that was provided and the normal 3DS authentication flow can be completed.

According to the Mastercard Rules, there is specific limit on the validity of an UCAF / AAV cryptogram and the Visa 3D Secure guides make no mention of the validity but generally it is advised to use an UCAF / AAV within the first 90 days.

After this point in time an Issuer might still approve an authorization request with the provided UCAF / AAV. An authorization can still be attempted without the AAV of UCAF data but then the merchant becomes liable in case of fraud (loss of liability shift).