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 KO.

Transactions made with 3D Secure cards

When a transaction is 3D Secure, the field VbV is set to OK.

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 ErrorDescription field.

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:

https://ecomm.sella.it/pagam/pagam3d.aspx

for test codes:

https://sandbox.gestpay.net/pagam/pagam3d.aspx

The page must be retrieved through the following 3 parameters:

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:

<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>

At the end of the authentication process the buyer will be redirected to the merchant’s site to the URL specified as redirection parameter c.

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 CallPagamS2S method).

However, before using again such call, it is necessary to assign to WSs2s all of the information required by providing the variables:

• shopLogin (merchant code)

• uicCode (currency code)

• amount (amount)

• 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.