GestPay Cryptography Technical Specification 2.1

Doc: GestPay - Security with Encryption Technical Specifications

GestPay Security with Encryption Technical Specifications

of 46


Summary Document information ...................................................................................................3 Version information …………………………………………………………………...4 1 Introduction.............................................................................................................5 2 System Architecture................................................................................................6 3 Description of Process Phases.................................................................................8

3.1 Phase I: Transaction Data Encryption................................................…………...8 3.2 Phase II: Payment Page Call ................................................................................8 3.3 Phase III: Communication of Transaction Result ..............................................10

3.3.1 Response to Merchant .................................................................................10 3.3.2 Response to Buyer ......................................................................................10

3.4 Phase IV: Decryption of Transaction Result ......................................................11 4 Authentication ...........................................................................................................12 5 Structure of Transaction Data ...................................................................................13

5.1 Transaction Data to Send to GestPay .................................................................13 Transaction Data Received by GestPay ...................................................................15

6 Merchant’s Profile ....................................................................................................17 6.1 Authentication Configuration ............................................................................17 6.2 Configuration of response url and e-mail...........................................................18 6.3 Configuration of Fields & Parameters ..............................................................19

7 Description of GestPayCrypt Object ....................................................................…20 8 WebService ..........................................................................................................23 Instructions for use of encryption module with WEBSERVICE interface...................23 List of calls available with WSCryptDecrypt webservice. ..........................................25 9 Software requirements .........................................................................................27

9.1 Buyer browser requirements ........................................................................27 9.2 Merchant server requirements .....................................................................27

9.2.1 Installation of GestPayCrypt.class (Java) ............................................27 9.2.2 Installation of GestPayCrypt.dll (COM)..............................................28

10 Example transactions .......................................................................................30 10.1 Transaction number 1 ..................................................................................30 10.2 Transaction number 2 ..................................................................................33

11 Examples of implementation ...........................................................................36 12 Table of errors..................................................................................................39 13 Table of currency codes ...................................................................................43 14 Table of language codes .................................................................................44 15 Table of Verified by Visa codes ......................................................................45 16 Payment orders in test environment.................................................................46 17 Links ................................................................................................................46

of 46


Document Information Project name: GestPay Title: GestPay - Security with Encryption Technical

Specifications Creation date Marco Loro Language: English Company:

EasyNolo

of 46


Version Information

Version Description Date Author 1.0.0 Initial version 15.03.2001 Sellanet 1.0.1 Handling of TransactionResult attribute 20.03.2001 Sellanet

1.0.2 Chapter 2, list corrected

GestPay url modified

22.03.2001

Sellanet

1.1.0 Document totally revised 28.03.2001 Sellanet 1.1.1 Browser requirements updated 09.04.2001 Sellanet 1.1.2 Server requirements updated 22.11.2001 Sellanet 1.1.3 Custom field requirements updated 04.03.2002 Sellanet 1.1.4 Error Codes updated 15.03.2002 Sellanet 1.1.5 Language Codes updated 30.05.2002 Sellanet 1.1.6 Custom code requirements and gestpay

parameters updated 20.08.2002 Sellanet

1.1.7 Currency codes updated 27.01.2003 Sellanet 2.0.0 3D Secure 28.01.2003 Sellanet 2.0.1 Errata Corrige 20.04.2005 Easy Nolo S.p.A. 2.0.2 Specific domain for test codes

introduced 13.06.2007 Easy Nolo S.p.A.

2.0.3 New 3DLevel response parameter introduced

15.07.2009 Easy Nolo S.p.A.

2.1 Webservice Encryption Specifications 12.01.2010 EasyNolo S.p.a.

of 46


1 Introduction

The purpose of this document is to illustrate the architectural and functional aspects of the GestPay platform and to provide the necessary indications regarding the interface. The chapter System architecture describes the various components of the system and the modes of interaction between them and between the parties involved (merchant, buyer and GestPay). The chapter Description of process phases details all of the phases that make up the payment process, in particular the information that must be passed to GestPay and the information that will be returned. The chapter Authentication describes how GestPay authenticates the merchant server that makes calls to the system. The chapter Payment transaction data structure describes the information that identifies a payment transaction and the result that GestPay returns after processing the transaction. The chapter Merchant profile describes how to configure the merchant profile that allows GestPay to process transactions correctly. The chapter GestPayCrypt object description examines the use of the component that handles server-to-server communication during the phases in which this kind of communication is sent between the server that receives the virtual shop as guest and GestPay. The chapter WebService focuses on the use of the webservice responsible for handling the encryption and decryption services – substituting the GestpayCrypt object described above – between the server which hosts the virtual store and GestPay. The chapter Software requirements illustrates the minimum requirements for installation of the software required to interface with GestPay. The chapter Example transactions describes a number of typical transactions, highlighting the information exchanged and the modes of interaction between the various components. In addition, there are some tables that make it possible to code certain information sent by or received from GestPay.

of 46


2 System Architecture Within the system architecture, 3 components can be identified:

• Buyer client • Merchant Server • GestPay Server

Communication between the various components takes place over the Internet using the http or https protocols (the GestPay server has a 128-bit Verisign digital certificate). The payment process is split into communication steps in which the components interact, exchanging the information needed to complete the transaction.

1

8b

Customer

Merchant 4

2 7a 9b

3 6 8a 10b

PRE-payment

POST-payment

Request

Responses

GestPay

Architecture scheme 1. The buyer selects the items to buy and decides to proceed with payment. 2. The merchant’s server contacts GestPay server via the Internet to encrypt the

payment transaction data. 3. GestPay performs the necessary controls to authenticate the merchant’s server and

validate the transaction data, returning, in the event of an affirmative response, an encrypted parameter string that represents the payment transaction to be processed.

4. The encrypted parameter string is communicated to the customer’s browser. The customer is directed to the GestPay server to complete the payment process.

5. The merchant’s browser calls back the payment page, passing the encrypted parameter string and the code assigned to the merchant (Shop Login). Data security checks are performed on the transaction: if the checks are passed, the payment page can be displayed and the the data needed to complete the transaction

of 46


can be entered. The following steps describe the process by which the transaction result is communicated both to the merchant and to the buyer.

6. GestPay communicates to the merchant’s server an encrypted parameter string which returns the result of the transaction.

7a.The merchant’s server contacts the GestPay server via Internet to decrypt the encrypted data string which returns the result of the transaction.

8a.GestPay decrypts the string and returns the parameters which return the result of the transaction in unencrypted form.

7b.GestPay communicates the encrypted parameter string which brings the transaction result to the browser of the customer, who is directed to the merchant’s server.

8b.The buyer’s browser calls back the response page created by the merchant, passing the encrypted parameter string.

9b.The merchant’s server contacts the GestPay server via Internet to decrypt the encrypted data string that returns the transaction result.

10b. GestPay decrypts the string and returns, in unencrypted form, the parameters that return the transaction result, allowing the merchant to provide the buyer with the references required to complete the purchase process.

The following scheme analyses the payment process, underlining the chronological order in which the communication steps take place. Notice that in some cases (steps 7 and 8) simultaneous communications are established between the components under consideration when they implement the procedures that must manage the information exchanged between the steps.

Components

GestPay Server

Merchant Server

Customer Client

1 2 3 4 5 6 7 8 9 10 Step

of 46


3 Description of Process Phases A payment transaction is made up of 4 basic phases in which there are one or more communication steps. In each phase, the information necessary to process the transaction is exchanged between the various components.

3.1 Phase I: transaction data encryption

The information required for the payment is previously communicated to GestPay to be encrypted. To guarantee an optimum security level, no sensitive information is communicated in unencrypted form to the buyer’s server. In this phase, the merchant’s server requests the encryption service from GestPay, obtaining the encrypted string that represents the transaction to process. The data that identify a transaction and their use will be described in chapter 4. Encryption can be handled in one of two ways: Use of the GestPayCrypt object Server-to-server communication is handled by the GestPayCrypt object released by EasyNolo, which must be previously installed on the merchant’s server. The virtual shop pages concerned with handling information required for the payment call the object. Use of the WSCryptDecrypt WebService The use of the webservice does not require any installation on the server, but simply a call to the webservice using the https protocol. The response is in the XML format. If the merchant’s authentication checks and validation of transaction data are passed, GestPay returns the encrypted data string to the merchant’s server to be sent to the buyer’s server to continue the payment process. Otherwise, a specific error code will be returned to allow the problem detected to be identified.

3.2 Phase II: payment page call After obtaining the encrypted data string (as described in the preceding section), the buyer’s browser is directed to the payment page on the GestPay server at the following address:

https://ecomm.sella.it/gestpay/pagam.asp?a=<ShopLogin>&b=<encrypted string> for test codes:

https://testecomm.sella.it/gestpay/pagam.asp?a=<ShopLogin>&b=<encrypted string>

The call to the page will be made passing two parameters: a The code identifying the merchant (Shop Login) b The encrypted data string identifying the transaction The payment page will acquire the parameters and verify the identity checks (parameter a must refer to a recognised merchant) and transaction data security (parameter b must

of 46

Doc: GestPay - Security with Encryption Technical Specifications correspond to the encrypted data string communicated by the merchant during the previous phase). If the checks are passed, the payment page will be displayed to the buyer, who must enter the data required to complete the payment process. If the checks are not passed, the payment page is not displayed and the process passes to the following phase in order to communicate the negative transaction result.

of 46

Doc: GestPay - Security with Encryption Technical Specifications 3.3 Phase III: communication of transaction result

GestPay communicates the transaction result both to the merchant and the buyer. 3.3.1 Response to merchant Notification is forwarded with a server-to-server call to the page specifically configured on the merchant’s server (the notification page URL is one of the items of information that make up the merchant’s profile, configurable through the GestPay Back Office environment). Call syntax is the following:

http://<url server to server>?a=<ShopLogin>&b=<encrypted string>

The call to the page will be made passing two parameters: a the code which identifies merchant (Shop Login) b the encrypted data string which contains the result of the transaction The page residing on the merchant’s server must have the html tags <HTML></HTML> in the source. If there are communication errors, GestPay will make several forwarding attempts for two days after the transaction. The merchant will also receive a transaction result notification e-mail at the address configured in his/her profile. In addition, the processed transaction can be viewed by accessing the GestPay Back Office environment in the Active Report section.

3.3.2 Response to Buyer GestPay immediately communicates the result of the transaction by displaying a “virtual receipt ” showing essential transaction data. GestPay directs the buyer’s browser to the merchant’s server to conclude the purchasing process. The merchant must prepare two urls (and configure them in the merchant’s profile) which will be called in the event of a negative or positive response and will allow the merchant to manage communication with the buyer while maintaining the editorial style that characterises the virtual shop. The call syntax is the following:

http://<url merchant>?a=<ShopLogin>&b=<encrypted string>

If there is an anomaly in the server-to-server communication described above, GestPay displays a message to the buyer warning that there may be problems directing him/her to the merchant’s server to conclude the purchasing process. In this situation, the buyer receives a notification from GestPay about the transaction result and is invited, if there are anomalies, to contact the merchant by other means (e.g. e-mail) to conclude the purchasing process. The buyer will also receive a transaction result notification e-mail at the address provided on the payment page, if indicated.

3.4 Phase IV: decryption of transaction result

GestPay communicates the transaction result through an encrypted string (parameter b of the call to the url preconfigured by the merchant). The string is initially forwarded to

of 46

Doc: GestPay - Security with Encryption Technical Specifications the merchant during server-to-server communication and makes it possible – once it has been decrypted – to update the status of the transaction recorded in the merchant’s information system. The same string is also sent from the buyer’s browser to the merchant’s server and makes it possible – once it has been decrypted – to complete the payment process. Web pages preconfigured by the merchant for receiving the transaction result (in the case of both server-to-server communication and through the buyer’s browser) must call the GestPay server to request the decryption service and obtain the information that represents the result of the processed transaction in unencrypted form. The request to decrypt the string received can be made through: GestPayCrypt Object Server-to-server communication is handled by the GestPayCrypt object released by EasyNolo and which must be installed on the merchant’s server in advance. WebService WSCryptDecrypt The use of the webservice does not require any installation on the server, but simply a call to the webservice using the https protocol. The response is in the XML format.

of 46

Doc: GestPay - Security with Encryption Technical Specifications 4 Authentication Server-to-server calls are managed by a component released by EasyNolo. Server authentication of the merchant requesting encryption or decryption services is made by verifying:

• Shop Login validity: ShopLogin parameter must correspond to a code recorded in GestPay customers’ details.

• IP address server: the calling server IP address must correspond to one of the IP addresses configured in the merchant’s profile.

• Shop Login status: the merchant’s status must be active (the merchant’s status is managed by the GestPay administrator and not directly by the merchant)

If the authentication checks are not passed, a specific error will be returned, making it possible to identify the anomaly found in the authentication process.

of 46


5 Structure of Transaction Data A transaction is characterised by a series of information that must be communicated to GestPay to complete the payment process and by information returned to the system as the transaction result. By suitably configuring his/her profile within the Back Office environment, the merchant can define what information to send to or receive from GestPay, and by what means.

5.1 Transaction Data to Send to GestPay Some of the information to communicate to GestPay is required in order to complete the payment process, while other information can be omitted without compromising the processing of the transaction.Through the GestPay Back Office environment, merchants can define what information is required and what information is optional.

Some information that is essential to the payment process is configured as compulsory by GestPay. This attribute cannot be modified. The following table gives the information that must be communicated to GestPay in order to make a transaction:

Name Format Type R/O Description

ShopLogin VarChar (30) P R ShopLogin

Currency Num (3) P R Code identifying currency in which transaction amount is denominated (see Currency Codes table)

Amount Num (9) P R Transaction amount. Do not insert thousands separator. Decimals (max. 2 numbers) are optional and separator is the point (see examples)

ShopTransactionID VarChar (50) P R Identifier attributed to merchant’s transaction

CardNumber VarChar (20) I/P R Credit card number

ExpMonth Char (2) I/P R Credit card expiry month (01, 02…12)

ExpYear Char (2) I/P R Credit card expiry year (01, 02…99)

BuyerName VarChar (50) I/P O Buyer’s name and surname BuyerEmail VarChar (50) I/P O Buyer’s e-mail address

Language Num (2) P O Code identifying language used in communication with buyer

CustomInfo (1)

VarChar (1000)

P

O

String containing specific information as configured in the merchant’s profile

1 Each field can be up to a maximum of 300 characters in length

The Name column contains the attribute identifier with which a specific item of information is communicated to the GestPayCrypt object, which handles server-to-server communication for the encryption services. The Format column indicates whether the information value is numeric or alphanumeric. If it is alphanumeric, the maximum allowable number of characters is given in brackets.

of 46


The Type column specifies whether the information must be communicated to the component (passed as Parameter) or if it can be entered by the buyer (passed as Input) in the payment page. The R/O column specifies whether the information is Required (if omitted the transaction cannot be completed) or Optional. However, the minimum quantity of information configured, which allows phase I to be processed, is made up of: • Currency • Amount • Shop TransactionID This information, in fact, is defined as required and must be communicated to GestPay using the GestPayCrypt component. During phase I, GestPay makes validation checks on the information that constitutes the payment transaction, verifying consistency with the merchant’s profile setup. If anomalies are detected, the transaction is abandoned, returning a specific error. This approach makes it possible to identify possible anomalies connected with the transaction immediately, preventing the buyer from being directed to the payment page with an encrypted data string that corresponds to an invalid transaction. The CustomInfo attribute contains specific information that the merchant wishes to communicate to or receive from GestPay. What information is included in the CustomInfo attribute is defined in the Back Office environment in the “Fields & Parameters” section. The information included will follow this form:

datum1=value1*P1*datum2=value2*P1* … *P1*datum n=valuen The separator between logically different information is the reserved sequence of characters *P1*. Other characters that must not be used within the parameters encoded by GestPay and in customised information are:

& (space) § ( ) *

< > , ; : *P1*

/ [ ] ? = --

/* % //

of 46

Name Format Type R/O Description ShopLogin VarChar (30) P R ShopLogin

Currency Num (3) P R Code identifying currency in which transaction amount is denominated (see Currency Codes table)

Amount Num (9) P R Transaction amount. Do not insert thousands separator. Decimals (max. 2 numbers) are optional and separator is the point (see examples)

ShopTransactionID VarChar (50) P R Identifier attributed to merchant’s transaction

BuyerName VarChar (50) I/P O Buyer’s name and surname

BuyerEmail VarChar (50) I/P O Buyer’s e-mail address

TransactionResult Char (2) P R Transaction result AuthorizationCode VarChar (6) P R Transaction authorisation code BankTransactionID Num (9) P R Identifier attributed to the transaction

by GestPay

Country

VarChar (30) P

O

Nationality of institute issuing card

VbV

VarChar (50)

P

O

Flag for Verified by Visa transactions (see table of VbV Codes)

ErrorCode Num (9) P R Error code ErrorDescription VarChar (255) P R Error description

AlertCode Num (9) P O Alert code 3DLevel

VarChar(255)

P

O

Level of authentication for VBV Visa / Mastercard Securecode transactions. The string may have the value FULL or HALF

AlertDescription VarChar (255) P O Alert description in chosen language

CustomInfo(1) VarChar (1000) P O String that has the specific information as configured in the merchant’s profile


Transaction data received by GestPay

GestPay communicates the payment transaction result to the merchant through an encrypted data string that contains a series of information returned. Using the GestPayCrypt object, merchants will obtain the information reporting the transaction result in unencrypted form and will be able to update their own information system, allowing buyers to complete the purchasing process. The following table contains the information returned by GestPay as transaction result.

1 Each field can be up to a maximum of 300 characters in length.

The minimum information required to report the transaction result (defined as required) is made up of:

♦ Currency ♦ Amount ♦ ShopTransactionID ♦ TransactionResult ♦ AuthorizationCode ♦ ErrorCode

of 46


♦ ErrorDescription ♦ BankTransactionID Other information is defined as optional and will be returned according to the merchant’s profile settings made in the GestPay Back Office environment. A transaction result can be interpreted by verifying the TransactionResult field value. The possible values are:

TransactionResult Description

OK Positive transaction result KO Negative transaction result XX Suspended transaction result (only in the case of money transfers)

of 46


6 Merchant’s Profile Each merchant can configure his/her profile by accessing the GestPay Back Office environment at:

for test codes

https://ecomm.sella.it/gestpay/login.asp

https://testecomm.sella.it/gestpay/login.asp Some settings regard the procedure and the information that must be sent to or will be returned by GestPay.

6.1 Authentication configuration

GestPay identifies the merchant requesting the encryption service through the GestPayCrypt component by comparing the calling server IP address to the IP addresses configured in the profile associated with the Shop Login used for the call. If the calling server is not recognised, the transaction process ends and a specific error is returned. In the Configuration – IP Addresses section of the Back Office environment, the merchant can enter up to a maximum of 10 IP addresses (if calls to GestPay originate from a server farm).

Configuration – IP Addresses

of 46

Doc: GestPay - Security with Encryption Technical Specifications 6.2 Configuration of response url and e-mail

GestPay communicates the transaction result with a server-to-server call to the page specifically prepared by the merchant and by directing the buyer’s browser to the pages configured by the merchant (different pages for positive or negative results). In the Configuration – Responses section in the Back Office environment, it is possible to specify the URLs used by the system to communicate the transaction result. In this section it is also possible to specify the addresses that will be used for notifications via e-mail.

Configuration – Responses

of 46

Doc: GestPay - Security with Encryption Technical Specifications 6.3 Configuration of Fields & Parameters

Merchants can define the transaction structure (specifying what information beside the required information will have to be sent to GestPay) by configuring in the Back Office environment what information is to be sent in phase I and what information must be returned when the transaction result is communicated. This system allows the merchant to customise the transaction structure with proprietary information that will be stored in the GestPay archives and will allow each transaction to be identified using customised search keys. Moreover, customised information can be returned with the transaction result communication, thus allowing the merchant’s information system to manage this information appropriately.

Merchant’s profile configuration - Fields & Parameters

of 46


7 Description of GestPayCrypt Object Server-to-server communication between GestPay and merchant is automatically handled by the GestPayCrypt component released by EasyNolo. This component is a Java library that will be called by the web pages preconfigured by the merchant to handle encryption of the transaction data and decryption of the result communicated by GestPay. The GestPayCrypt library is available as open source on the EasyNolo website. Table 1 contains the attributes and the methods made available by the Java library. In the virtual shop pages configured to handle payments the merchant implements a call to the GestPayCrypt component which handles requests to use the GestPay encryption service. Class attributes will be filled in with data that identify the transaction. To request the encryption service it is necessary to call the Encrypt method. If the encryption operation has concluded correctly (value of ErrorCode attribute = 0), the encrypted data string returned by GestPay will be available by reading the EncryptedString attribute value. Otherwise, the values of the ErrorCode and ErrorDescription attributes will allow the reasons that have prevented the encryption operation to be identified. To request the decryption service, it is necessary to call the Decrypt method, after filling in the Shop Login and EncryptedString attributes with values communicated by GestPay in Phase III. Information containing the result of the transaction will be available by reading the Java library attributes that correspond to the information regarding the transaction result.

of 46


The attributes and methods of the GestPayCrypt Java library are described below:

Class: GestPayCrypt Attr ibu tes

AlertCode Alert code AlertDescription Alert description Amount Transaction amount AuthorizationCode Transaction authorisation code BankTransactionID Identifier assigned to transaction by GestPay BuyerEmail Buyer’s email address BuyerName Buyer’s name and surname CardNumber Credit card number Country Nationality of institute issuing card Currency Code identifying currency in which transaction amount is denominated CustomInfo String containing specific merchant information CVV String containing value of Cvv2 / Cvc2 / 4dbc code of credit card EncryptedString Encrypted string Encryption Flag to activate local encryption ErrorCode Error code ErrorDescription Error description ExpMonth Credit card expiry month ExpYear Credit card expiry year Language Language code for communication with buyer MIN Not used PasswordEncrypt Password for local encryption ShopLogin Shop login identifying merchant ShopTransactionID Identifier assigned to transaction by merchant TransactionResult Transaction result VBV Flag for Verified by Visa transactions VBVrisp Not used 3DLevel Level of authentication for Visa VBV / Mastercard

Securecode transactions SET Methods SetAmount (val) Used to set Amount attribute SetBuyerEmail (val) Used to set BuyerEmail attribute SetBuyerName (val) Used to set BuyerName attribute SetCardNumber (val) Used to set CardNumber attribute SetCurrency (val) Used to set Currency attribute SetCustomInfo (val) Used to set CustomInfo attribute SetCVV Used to set CVV attribute SetExpMonth (val) Used to set ExpMonth attribute SetExpYear (val) Used to set ExpYear attribute SetEncryptedString (val) Used to set EncryptedString attribute SetEncryption Used to set Encryption attribute to TRUE SetLanguage (val) Used to set Language attribute SetMIN Not used SetPasswordEncrypt Used to set PasswordEncrypt attribute SetShopLogin (val) Used to set ShopLogin attribute SetShopTransactionID (val) Used to set ShopTransactionID attribute SetWithoutEncryption Used to set Encryption attribute to FALSE

of 46


GET methods Decrypt Used to request encryption service attribute Encrypt Used to request decryption service attribute GetAlertCode Used to read AlertCode attribute attribute GetAlertDescription Used to read AlertDescription attribute GetAmount Used to read Amount attribute GetAuthorizationCode Used to read AuthorizationCode attribute GetBankTransactionID Used to read BankTransactionID attribute GetBuyerEmail Used to read BuyerEmail attribute GetBuyerName Used to read BuyerName attribute GetCountry Not used GetCurrency Used to read Currency attribute GetCustomInfo Used to read CustomInfo attribute GetEncryptedString Used to read EncryptedString attribute GetErrorCode Used to read ErrorCode attribute GetErrorDescription Used to read ErrorDescription attribute GetShopLogin Used to read ShopLogin attribute GetShopTransactionID Used to read ShopTransactionID attribute GetTransactionResult Used to read TransactionResult attribute GetVBV Used to read VbV attribute GetVBVrisp Not used Get3DLevel Used to read 3DLevel attribute

of 46


8 Webserv ice

Instructions for the use of the encryption module w ith the WEBSERVICE interface

This document contains the necessary instructions for using the WSCryptDecrypt webservice. This component is a library that must be called from the web pages configured by the merchant to handle transaction data encryption and decryption of the result communicated by GestPay. The WSCryptDecrypt web service is available on the production and test servers and does not require any installation on the merchant’s server. The merchant must implement – in the page(s) of the virtual store configured to handle payments – a call to the webservice which handles requests to use the GestPay encryption service. To request the encryption service it is necessary to call the Encrypt method.

An example of a positive XML response returned by the web service is given below: <?xml version="1.0" encoding="utf-8" ?> <GestPayCryptDecrypt >

<TransactionType >ENCRYPT</ TransactionType > <TransactionResult >OK</ TransactionResult > <CryptDecryptString >CF66F38B4EC881….</ CryptDecryptstring > <ErrorCode >0</ ErrorCode > <ErrorDescription />

</ GestPayCryptDecrypt >

If the encryption operation is concluded correctly (TransactionResult value = OK), the encrypted data string returned by GestPay will be available by reading the value of the CryptDecryptString attribute. If this is not the case, the values of the ErrorCode and ErrorDescription attributes will make it possible to identify the reasons that prevented the encryption operation. To request the decryption service it is necessary to call the Decrypt method, passing the Shoplogin and EncryptedString attributes with the values communicated by GestPay in Phase III. The information containing the transaction result will be available by reading the information in the XML response file corresponding to the result of the transaction. The webservice must be called from the application configured by the merchant to handle the sending of transaction data and reading the result communicated by GestPay in XML format.

The address of the service is the following URL:

https://ecomms2s.sella.it/gestpay/gestpayws/WSCrypt Decrypt.asmx

for test codes

https://testecomm.sella.it/gestpay/gestpayws/WSCryp tDecrypt.asmx

of 46


Generation of Proxy Class to use webservice functions from various languages

The proxy class in the chosen language can be creat ed automatically through the wsdl.exe program (in this case provided by Microsoft) simply by specifying the contract file relating to the webservice, in this case: The addresses of descriptions of the service are fo und at the following URLs:

For production codes: https://ecomms2s.sella.it/gestpay/gestpayws/WSCryptDecrypt.asmx?WSDL

For test codes: https://testecomm.sella.it/gestpay/gestpayws/WSCryptDecrypt.asmx?WSDL

For example: wsdl /language:VB /out: wss2sProxyClass.vb https://testecomm.sella.it/gestpay/gestpayws/WSCryp tDecrypt.asmx?WSDL

The .vb file will be generated, with handling of th e proxy class relating to the webservice which will simply be imp orted into the project and used.

With visual Studio .net it is possible to add the w ebservice references in order to have the classes of the refe renced webservice automatically available in the project (see “Add We b Reference”).

For other languages, verify normal operations for i nterfacing with webservices.

of 46


List of calls available with WSCryptDecrypt webserv ice.

A complete list of methods for the WSCryptDecrypt object is provided below.

WEBService methods Method name Description Encrypt Encryption Decrypt Decryption

The various method calls are handled as function calls to the web service without passing an XML string. The values of the various calls must be passed as parameters. Input parameters, Encrypt method Method name Description ShopLogin Used to set value of ShopLogin attribute UICCode Assigns currency code Amount Assigns transaction amount ShopTransactionID (val) Assigns code attributed by merchant to transaction CardNumber (val) Assigns card number ExpMonth (val) Assigns card expiry month ExpYear (val) Assigns card expiry year BuyerName (val) Assigns buyer’s name BuyerEmail Assigns buyer’s email Language (val) Assigns language for emails to buyer CVV (val) Assigns security code printed on card CustomInfo (val) Assigns string containing any customised parameter s

Input parameters, Decrypt method Method name Description ShopLogin Used to set value of ShopLogin attribute CryptedString String to decrypt received from GestPay

of 46


Il file XML e’ descritto e può essere validato tramite il relativo file GestPayCryptDecrypt.xsd che qui andiamo a descrivere nel dettaglio

XML values returned Method name Description TransactionType The type of request executed can have the following values:

ENCRYPT (E) DECRYPT (D)

TransactionResult (E,D) Returns result of transaction with values O K and KO CryptDecryptString (E) Returns encrypted string ShopTransactionID (D) Returns code attributed by merchant to transaction BankTransactionID (D) Returns code attributed by bank to transaction AuthorizationCode (D) Returns authorisation code Currency (D) Returns currency code Amount (D) Returns transactio amount Country (D) Returns nationality of institute issuing card CustomInfo (D) Returns any aditional parameters BuyerType (D) Returns buyer’s name and email address, separated a s follows:

BuyerEmail Returns buyer’s email address BuyerName Returns buyer’s name ErrorCode (E,D) Returns a code referring to result of transaction ErrorDescription (E,D) Returns description associated with value of ErrorC ode AlertCode (D) Returns code for violation of risk management crite ria AlertDescription (D) Returns description associated with value of AlertC ode

of 46

Doc: GestPay - Security with Encryption Technical Specications 9 Software Requirements

GestPay software requirements concern the buyer’s browser and the server hosting the virtual store.

9.1 Buyer browser requirements The https://ecomm.sella.it/gestpay/ domain is associated with a 128-bit Verisign digital certificate. Browsers must be compatible with this level of encryption. The minimum recommended required versions are Internet Explorer 4.0 and Netscape 4.76.

The buyer’s browser must be configured to accept cookies and Javascript.

9.2 Merchant server requirements Check with the server administrator that the computer can reach the following addresses: If http (port 80) communication is used: http://ecomms2s.sella.it/testhttp/test.asp

For test codes: http://testecomm.sella.it/testhttp/test.asp

If https (port 443) communication is used: https://ecomms2s.sella.it/testhttps/test.asp

For test codes: https://testecomm.sella.it/testhttps/test.asp 9.2.1 Installation of GestPayCrypt.class (Java) The GestPayCrypt Java library (GestPayCrypt. class) must be copied into the web server directory containing the Java libraries. For example, in a system with architecture based on Windows NT and Internet Information Server it must be installed in the following directory:

…...\java\TrustLib On the web server that hosts web pages that call the GestPayCrypt library, Java Virtual Machine (from 1.1.3 version on) must be installed.

of 46

Doc: GestPay - Security with Encryption Technical Specications 9.2.2 Installation of GestPayCrypt.dll (COM)

The COM object can be installed only in Windows environments (NT 4.0 or above; MTS; IE 4.x or above installed with Microsoft VM Java ), saved at any location on the disk and subsequently registered using one of the following operations:

Windows NT - 2000

• from the command prompt using the command:

REGSVR32 path (e.g. c:\winnt\system32\GestPayCrypt.dll) Note. For Windows Server 2003 and Windows Xp versions this registration method is not recommended.

• Through Com+ (for Windows 2000 or above) or MTS (for NT 4.0) Path: Left panel

consoleroot /Microsoft transaction server/Computer/MyComputer (or other computer name)/Packages Installed

Right-click > Create new package (taking care not to use Interactive User, but assign an account with sistem administrator privileges for the package) Open the package /Components Right-click > New Component > Install new component >Add

Select the Dll

OK

Note. For more information consult the Microsoft website at the following address: http://msdn.microsoft.com/library/default.asp?url=/library/en- us/cossdk/htm/pgcreatingapplications_06ib.asp

of 46

Doc: GestPay - Security with Encryption Technical Specications

Windows 2003

Follow the manual available at the following address:

http://service.easynolo.it/download/Tutorial_Installazione_oggetti.zip

of 46

Doc: GestPay - Security with Encryption Technical Specications

10 Example Transactions

This chapter describes a number of significant examples of interfacing with Gestpay. The ShopLogin used in the examples is 9000001. The merchant’s profile is the following:

Merchant’s Profile IP Address 171.85.234.97 Server-to-server Communication Url http://www.myshop.com/s2s.asp Url for positive responses http://www.myshop.com/respOK.asp Url for negative responses http://www.myshop.com/respKO.asp E-mail for sending OK result [email protected] E-mail for sending KO result [email protected] E-mail for sending information [email protected]

9.1 Transaction # 1

The merchant decides to communicate to GestPay only the essential information to allow the buyer to make the payment. The payment page must be displayed to the buyer who enters the sensitive data requie to complete the payment in protected (SSL 128-bit) mode. The transaction to process has the following characteristics:

Merchant’s Transaction

Shop Transaction ID 34az85ord19 Transaction Amount 1828.45 Currency Transaction euro

Let us suppose that the transaction is concluded positively (payment will be made), returning the following result:

Result Authorisation code 54e813 Bank transaction ID 216

In the following pages, each individual phase that makes up the payment process will be described, highlighting the information exchanged between GestPay and the merchant’s server.

of 46


Phase I

The merchant’s server communicates the information that characterises the transaction to GestPay, setting the value of the GestPayCrypt attributes:

GestPayCrypt ShopLogin 9000001 Currency 242 Amount 1828.45 ShopTransactionID 34az85ord19 Language 2

GestPay authenticates the calling server and validates the information characterising the transaction. If the checks are passed, it returns an encrypted string to GestPay:

Encrypted Data String ShopLogin 9000001 EncryptString 2C53F1B5...................

Phase II

The buyer’s server is directed to the GestPay server to complete the payment process. The call to the payment page is made passing two parameters that correspond to the shop login and to the encrypted data string received in the previous phase by GestPay:

Payment page Url Https://ecomm.sella.it/gestpay/pagam.asp?a=9000001&b=2C53F1B5....................

GestPay authenticates the Shop login (parameter a) and performs security checks on the encrypted data string (parameter b). If the checks are passed, the payment page is displayed to the buyer, who can enter the data necessary to complete the payment. Otherwise, an error will be communicated.

Phase III

After processing the transaction, GestPay communicates the transaction result (encrypted data string) to the merchant.

Server-to-server communication Http://www.myshop.com/s2s.asp?a=9000001&b=4D341A8B..............

After server-to-server communication has concluded positively, GestPay directs the buyer’s browser to the merchant’s server (in this case to the Url for positive responses). If this is not the case, the buyer is informed that it is not possible to direct him/her to the merchant’s server to conclude the purchasing process.

of 46


Redirection of buyer’s client Http://www.myshop.com/respOK.asp?a=90000011&b=4D341A8B.............

The transaction result is also communicated to the merchant via e-mail.

Send E-mail [email protected]

Phase IV

GestPay communicates the transaction result to the merchant, sending an encrypted data string. Using the GestPayCrypt object, the merchant must request the string decryption service to interpret the transaction result correctly and update the information in his/her own information system, thus allowing the buyer to complete the purchasing process. The merchant’s server communicates the encrypted data string containing the transaction result to GestPay, through GestPayCrypt.

Encrypted Data String ShopLogin 9000001 EncryptedString 4D341A8B.............

GestPay authenticates the calling server and the integrity of the encrypted data string. If the controls are passed, it returns the unencrypted information to GestPayCrypt allowing the merchant to interpret the transaction result correctly:

GestPay Result ShopLogin 9000001 Currency 242 Amount 1828.45 ShopTransactionID 34az85ord19 TransactionResult OK AuthorizationCode 54e813 BankTransactionID 216 ErrorCode 0 ErrorDescription Transaction Executed

of 46


10.2 Transaction #2

The merchant decides to communicate to GestPay not only the information that is indispensable to allow the buyer to make the payment, but also the buyer’s name, surname and e-mail address (this information is suggested by default on the payment page so that the buyer does not need to enter it a second time). Other customised information is sent by the merchant (the client code attributed to the buyer and technical information). The payment page must be displayed to the buyer who enters any sensitive data necessary to complete the payment in protected mode (128–bit SSL). In addition, one of the customised items of information (client code) must be displayed on the payment page. The transaction to process has the following characteristics:

Transaction

Shop Transaction ID 34az85ord19 Transaction Amount 1245.6 Currency Transaction Euro Language Spanish Buyer’s Name and Surname Mario Bianchi Buyer’s E-mail Address [email protected] Customised info 1 BV_CODCLIENTE=12 Customised info 2 BV_SESSIONID=398

We shall assume that the transaction is concluded positively (payment is made), reporting the following result:

Result Authorisation code 9823y5 Bank transaction ID 860

The following pages describe each individual phase that makes up the payment process, highlighting the information exchanged between GestPay and the merchant’s server.

Phase I

The merchant’s server communicates the information that characterises the transaction to GestPay, setting the value of the GestPayCrypt attributes:

GestPayCrypt

ShopLogin 9000001 Currency 242 Amount 15.6 ShopTransactionID 34az85ord19 Language 3 BuyerName Mario Bianchi BuyerEmail [email protected] CustomInfo BV_CODCLIENTE=12*P1*SESSIONID=398

of 46

Doc: GestPay - Security with Encryption Technical Specifications GestPay authenticates the calling server and validates the information that characterises the transaction. If the controls are passed, it returns an encrypted string to GestPay:

Encrypted Data String ShopLogin 9000001 EncryptString 30715CA8………………..

Phase II

The buyer’s server is directed to the GestPay server to complete the payment process. The call to the payment page is made passing two parameters that correspond to Shop login and to the encrypted data string received in the previous phase by GestPay:

Payment page Url https://ecomm.sella.it/gestpay/pagam.asp?a=9000001&b=30715CA8....................

GestPay verifies the Shop login (parameter a) and performs security checks on the encrypted data string (parameter b). If the checks are passed, the buyer, who can now enter the data necessary to complete the payment, views the payment page. If the checks are not passed, an error will be communicated.

Phase III

After processing the transaction, GestPay communicates the transaction result (encrypted data string) to the merchant.

Server-to-server communication http://www.myshop.com/s2s.asp?a=9000001&b=F45E129A..............

After server-to-server communication has concluded positively, GestPay directs the buyer’s browser to the merchant’s server (in this case to the Url for positive responses). If this is not the case, the buyer is informed that it is not possible to direct him/her to the merchant’s server to complete the purchasing process.

Redirection of Buyer’s Client http://www.myshop.com/respOK.asp?a=90000011&b= F45E129A.............

The transaction result is also communicated to the merchant and the buyer via e-mail.

Send E-mail [email protected] [email protected]

of 46


Phase IV

GestPay communicates the transaction result to the merchant, sending an encrypted data string. Using the GestPayCrypt object, the merchant must request string encryption to interpret the transaction result correctly and update the information in his/her own system, thus allowing the buyer to complete the purchasing process. The merchant’s server communicates the encrypted data string containing the transaction result to GestPay, through GestPayCrypt.

Encrypted Data String

ShopLogin 9000001 EncryptedString 6C12459A............

GestPay authenticates the calling server and checks the encrypted data string. If the checks are passed, it returns an unencrypted data string containing the transaction result:

GestPay Result

ShopLogin 9000001 Currency 242 Amount 15.6 ShopTransactionID 34az85ord19 TransactionResult OK AuthorisationCode 9823y5 BankTransactionID 860 CustomInfo BV_CODCLIENTE=12*P1*SESSIONID=398 ErrorCode 0 ErrorDescription Transaction Executed

of 46


11 Examples of Implementation This chapter describes an example of interfacing with GestPay created using the ASP language. Working scripts created using some of the most widely distributed development languages (ASP,JSO,PHP…) can be downloaded from http://service.easynolo.it/download.asp.

ASP Example

PAGE FOR CONNECTING TO PAYMENT PAGE (PAYMENT REQUEST)

<% ‘ START OF ENCRYPTION SCRIPT

‘DO NOT MODIFY THIS PART

Set objCrypt = GetObject("java:GestPayCrypt")

if Err.number <> 0 then

Response.Write Err.number & Err.description end if

‘MODIFY THIS PART (SETTING VALUES OF TRANSACTION ATTRIBUTES)

‘Replace text contained between square brackets [] with data ‘required to carry out transaction. ‘The lines containing data marked as NOT REQUIRED ‘must be deleted if not used

‘REQUIRED FIELDS

myshoplogin= “[SHOP LOGIN]” ‘e.g. 9000001 mycurrency=[CURRENCY CODE] ‘e.g. 242 for euro or 18 for lira myamount=[AMOUNT WITHOUT THOUSANDS SEPARATOR WITH POINT AS DECIMAL SEPARATOR] ‘e.g. 1256.28 myshoptransactionID=“[TRANSACTION IDENTIFIER]” ‘e.g. “34az85ord19”

‘FIELDS NOT REQUIRED (DELETE ANY LINES WHICH ARE NOT RELEVANT)

mybuyername=”[BUYER’S NAME AND SURNAME]”‘e.g. “Mari o Bianchi” mybuyeremail=”[ BUYER’S EMAIL]”‘e.g. “[email protected]” mylanguage=[CODE FOR LANGUAGE TO USE IN COMMUNICATI ON] ‘e.g. 3 for Spanish mycustominfo=”[CUSTOMISED PARAMETERS]” ‘e.g. “BV_CODCLIENTE=12*P1*BV_SESSIONID=398”

of 46

‘DO NOT MODIFY THIS PART

objCrypt.SetShopLogin(myshoplogin) objCrypt.SetCurrency(mycurrency) objCrypt.SetAmount(myamount) objCrypt.SetShopTransactionID(myshoptransactionID) objCrypt.SetBuyerName(mybuyername) objCrypt.SetBuyerEmail(mybuyeremail) objCrypt.SetLanguage(mylanguage) objCrypt.SetCustomInfo(mycustominfo)

call objCrypt.Encrypt

if objCrypt.GetErrorCode = 0 then

b = objCrypt.GetEncryptedString a = objCrypt.GetShopLogin

end if

‘END OF ENCRYPTION SCRIPT.

‘IF ALL OK 2 VARIABLES , A AND B, ARE OBTAINED, TO BE USED TO PASS ‘PARAMETERS TO BANCA SELLA

‘EXAMPLE WITH HTML FORM %>

<form action=”https://ecomm.sella.it/gestpay/pagam.asp”>

<input name=”a” type=”hidden” value=”<%=a%>”> <input name=”b” type=”hidden” value=”<%=b%>”> <input type=”submit” value=” OK “>

</form>

of 46


PAGE FOR HANDLING PAYMENT RESPONSE

<% ‘START OF DECRYPTION SCRIPT ‘DO NOT MODIFY

‘INPUT PARAMTERS ARE READ AND PARAMETER B IS DECRYPTED

parameter_a = trim(request(“a”)) parameter_b = trim(request(“b”))

Set objdeCrypt = GetObject("java:GestPayCrypt")

if Err.number <> 0 then

Response.Write Err.number & Err.description end if

objdeCrypt.SetShopLogin(parameter_a) objdeCrypt.SetEncryptedString(parameter_b)

call objdeCrypt.Decrypt

‘THERE FOLLOWS A SERIES OF VARIABLES WHOSE VALUE IS SET TO THE DATA ‘RECEIVED BY GESTPAY TO BE USED TO INTEGRATE WITH M ERCHANT’S OWN ‘SYSTEM

myshoplogin=trim(objdeCrypt.GetShopLogin) mycurrency=objdeCrypt.GetCurrency myamount=objdeCrypt.GetAmount myshoptransactionID=trim(objdeCrypt.GetShopTransact ionID) mybuyername=trim(objdeCrypt.GetBuyerName) mybuyeremail=trim(objdeCrypt.GetBuyerEmail) mytransactionresult=trim(objdeCrypt.GetTransactionR esult) myauthorizationcode=trim(objdeCrypt.GetAuthorizatio nCode) myerrorcode=trim(objdeCrypt.GetErrorCode) myerrordescription=trim(objdeCrypt.GetErrorDescript ion)

myerrorbanktransactionid=trim(objdeCrypt.GetBankTra nsacti onID)

myalertcode=trim(objdeCrypt.GetAlertCode) myalertdescription=trim(objdeCrypt.GetAlertDescript ion) mycustominfo=trim(objdeCrypt.GetCustomInfo)

‘END OF DECRYPTION SCRIPT

%>

of 46


12 Table of Errors

Code Descri ption 0 Transaction correctly processed 57 Credit card frozen 58 Confirmed amount exceeds authorised amount 63 Demand for settlement of a non-existent transaction 64 Pre-authorisation expired 65 Incorrect currency 66 Pre-authorisation already notified 74 Authorisation denied 97 Authorisation denied 100 Transaction interrupted by bank authorisation system 150 Incorrect merchant configuration in bank authorisation system 208 Incorrect expiry date 212 Bank authorisation system unavailable 251 Insufficient credit 810 Bank authorisation system not available 811 Incorrect merchant configuration in bank authorisation system 901 Authorisation denied 902 Authorisation denied 903 Authorisation denied 904 Authorisation denied 905 Authorisation denied 906 Authorisation denied 907 Authorisation denied 908 Authorisation denied 910 Authorisation denied 911 Authorisation denied 913 Authorisation denied 914 Authorisation denied 915 Authorisation denied 916 Authorisation denied 917 Authorisation denied 918 Authorisation denied 919 Authorisation denied 920 Authorisation denied 950 Credit card not authorised 951 Incorrect merchant configuration in bank authorisation system 998 Incorrect credit card check-digit 999 Operation not performed 1100 Empty parameter string 1101 Invalid format of parameter string 1102 No parameter name precedes = symbol 1103 Parameter string ending with a separator 1104 Invalid parameter name

of 46


Code Description 1105 Invalid parameter value 1106 Repeated parameter name 1107 Unexpected parameter name. Please double check "Fields and

Parameters" configuration in Back Office. 1108 Compulsory parameter not set 1109 Missing parameter 1110 Missing PAY1_UICCODE parameter 1111 Invalid currency code 1112 Missing PAY1_AMOUNT parameter 1113 Nonnumeric amount 1114 Amount with incorrect number of decimal digits 1115 Missing PAY1_SHOPTRANSACTIONID parameter 1116 PAY1_SHOPTRANSACTIONID parameter too long 1117 Invalid language identifier 1118 Non-numeric characters in credit card number 1119 Credit card number incorrect length 1120 Incorrect credit card check-digit 1121 Credit card belongs to a non-authorised company 1122 Expiry year without expiry month 1123 Expiry month without expiry year 1124 Invalid expiry month 1125 Invalid expiry year 1126 Expired expiry date 1127 Invalid cardholder email address 1128 Parameter string too long 1129 Parameter value too long 1130 Call rejected: missing parameter A 1131 Call rejected: Shop not recognised 1132 Call rejected: shop without active status 1133 Call rejected: missing parameter B 1134 Call rejected: empty parameter B 1135 Call rejected: other parameters beside A and B are present 1136 Call rejected: transaction did not begin with a call to server-to-server 1137 Call rejected: transaction already processed 1138 Call rejected: card number or expiry date missing 1139 Call rejected: missing published payment page 1140 Transaction cancelled by buyer 1141 Call rejected: input parameter string not acceptable 1142 Call rejected: invalid IP address 1143 Transaction abandoned by buyer 1144 Compulsory field not set 1145 Invalid OTP 1146 Amount too small

of 46


Code Description 1147 Amount too large 1148 Invalid cardholder name 1150 IPIN must be set 1151 Parameter error 1999 Technical error in connection with credit card company network 2000 Transaction exceeds maximum number of operations within time period 2001 Transaction exceeds maximum number of operations performed by the

same buyer within time period 2002 Transaction exceeds maximum amount within time period 2003 Transaction exceeds maximum amount payable by same buyer within

time period 2004 Transaction contains a field value that had been declared not

acceptable 2005 Buyer abandoned transaction because it was a duplicate transaction 2006 Wrong line length 2007 Wrong value in SHOPTRANSACTIONID field 2008 Wrong value in CURRENCY field 2009 Wrong value in AMOUNT field 2010 Wrong value in AUTHORIZATION DATE field 2011 Transaction not found 2012 Transaction ambiguous 2013 Text file contains several rows regarding same transaction 2014 Refund operation requested for amount exceeding

transaction balance 2015 Wrong value in BANKTRANSACTIONID field 2016 Fields BANKTRANSACTIONID and SHOPTRANSACTIONID are

empty 2017 Transacion cannot be deleted 2018 Transacion cannot be refunded 2019 Transacion cannot be settled 2020 Transacion cannot be renounced 7401 Authorisation refused by credit card companies 7402 Card not authorised 7403 Card not recognised 7404 Card empire 7405 Call credit card company 7406 Incorrect card date 7407 Incorrect transaction date 7408 System error 7409 Merchant not recognised 7410 Invalid format 7411 Amount not available 7412 Not settled 7413 Operation not allowed 7414 Network not available

of 46


Code Description 7415 Collect card 7416 Number of PIN attempts exceeded 7417 Blocked terminal 7418 Forcibly closed terminal 7419 Transaction not permitted 7420 Transaction not authorised 7421 Service suspended on 01.01.2002 9997 Phase with error 9998 Phase correctly ended 9999 System error

Note. The error codes returned by GestPay are constantly updated. If you do not find a specific error code returned by the procedure, please see the “Error codes” entry contained in the “OnLine Help” section in the Back Office environment.

of 46

13 Table of currency codes

Currency codes are handled by GestPay using the currency attribute.

Code UIC Description 18 Italian lira 242 Euro 1 Dollar 2 Pound 71 Japanese Yen 103 Hong Kong Dollar 234

Real

3 Swiss franc of 46


14 Table of Language Codes The language code is handled by GestPay using the Language attribute.

Code Description 1 Italian 2 English 3 Spanish 4 French 5 German

of 46


15 Table of Verified by Visa Codes

The VbV code is handled by GestPay using the VbV attribute.

Code Descr iption

OK VbV-certified transaction KO Transaction not VbV-certified

of 46

16 Payment Orders in Test Environment Remember that to simulate the authorisation of a payment order in the test environment it is necessary to use a currently valid credit card. Amounts relating to authorised payment orders will be set against the credit limit of the card used and will never be debited. We therefore recommend that payment orders are made for small amounts so as not to run down the remaining credit on the card used for the tests.

17 Links

Test codes http://service.easynolo.it/download.asp Technical support https://www.easynolo.it/easynolo/ecommerce/assistenza/richiedi_assistenza.jsp?p=com_42 F.A.Q. https://www.easynolo.it/easynolo/ecommerce/assistenza/faq_ecommerce.jsp?p=com_55 Forum http://service.easynolo.it/forum.asp E-Commerce on Sella. http://www.sella.it/gbs/shop/ecommerce/gestpay/index.jsp Back Office environment for actual merchants https://ecomm.sella.it/gestpay/backoffice/LoginGestPay.asp Back Office environment for test merchants https://testecomm.sella.it/gestpay/backoffice/logingestpay.asp

of 46

GestPay Cryptography Technical Specification 2.1

Documents

Transcript of GestPay Cryptography Technical Specification 2.1