INTEGRATION
CHARGES
DISPUTES & FRAUD
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.
Frictionless Flow
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.
Challenge Flow
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
.
Note that the CReq needs to be base64 URL encoded and not base64 encoded. Some issuers might return an error if this requirement isn't satisfied. Please refer to EMV 3-D Secure Protocol and Core Functions Specification (2018) section A.5.4 (Browser CReq and CRes POST) for more information.
Attempts
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
.
3RI Flow
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.
3DS Method URL
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.
The
threeDSServerTransID
which was used in the Method URL flow should be put as a parameter in the POST/3DS call.
Cryptogram Validity
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).