3D Secure transactions
Transactions made with credit cards, if the merchant is registered with the 3D Secure service, ensure that the cardholder cannot renounce the transaction. There are two main cases:
- Transactions made with non 3D Secure cards involving merchants with 3D Secure authorisation
- Transactions made with 3D Secure cards involving merchants with 3D Secure authorisation
Transactions made with non 3D Secure cards
From a functional perspective, the transaction is processed as a normal authorisation request. When a transaction is not 3D Secure, the field
VbV is set to
Transactions made with 3D Secure cards
When a transaction is 3D Secure, the field
VbV is set to
Transactions made with 3D Secure credit cards require cardholder authentication. The buyer is redirected to the card issuer’s website and must enter the password provided by the issuer. If the outcome of the authentication process is positive, the transaction proceeds and generates a positive or negative outcome according to the response of the international credit card network.
In functional terms the process consists of 3 phases:
Phase I: authorisation request
A standard authorisation request is made. If the card is recognised as 3D, the outcome of the request is a specific error code (
8006) which is readable in the
ErrorCode field. The error description (Verified By Visa) will be readable by means of the
In this phase the following additional information is also shown. This information is required during the payment process and is specific to 3D secure transactions. In particular it is necessary to acquire the transaction code, which can be read by means of the
TransKey field and an encrypted string to be used during the subsequent phases and which is readable by means of the
VbVRisp value, which is as well a field of the response.
Phase II: cardholder authentication
In this phase it is necessary to allow the buyer to authenticate him/herself to the credit card issuer. The buyer’s browser must be redirected to a specific page on Banca Sella website which will act as an interface for authentication and that directs the buyer to the issuer’s site, providing him/her with all of the information required for authentication.
The page to be retrieved has the following URL:
for test codes:
The page must be retrieved through the following 3 parameters:
||an encrypted string acquired in the previous phase through
||the URL of the merchant’s web site to which the buyer must be redirected after the authentication procedure|
Any additional parameter will not be returned in response to the second call. You have to store them in specifically created variables during Phase I.
An example of an html form for redirection could be:
<html> <body> <form action="https://ecomm.sella.it/pagam/pagam3d.aspx" method="post"> <input type="hidden" name="a" value="9000001"> <input type="hidden" name="b" value="dffbihuihiuhe656erh12t5"> <input type="hidden" name="c" value="http://www.sitoesercente.it/rientro.asp"> <input type="submit" value="authentication"> </form> </body> </html>
At the end of the authentication process the buyer will be redirected to the merchant’s site to the URL specified as redirection parameter
The merchant’s page for welcoming back the buyer after authentication will be retrieved by means of a
PARES parameter (an encrypted string containing the result of authentication) which must be acquired by the merchant and forwarded to Banca Sella during the following phase.
Phase III: conclusion of transaction
At this stage the merchant is in possession of all of the information required to conclude the transaction. A new authorisation request must be made (by using the
However, before using again such call, it is necessary to assign to WSs2s all of the information required by providing the variables:
shopTransactionID(transaction identification code)
transKey(transaction ID acquired during Phase I)
PARes(encrypted string containing the result of authentication acquired during Phase II)
The result of the transaction displayed by Axerve Ecommerce Solutions will be interpreted as depicted in the Authorisation Request section.