376\377\000G\000e\000s\000t\000P\000a\000y\000_

Transcription

GestPay Technical
Specifications for
Payment Page
(Security with Encryption)
GestPay Technical Specifications for Payment Page
Page 1 of 111
Document Information................................................................................................. 4
Version Information...................................................................................................... 5
1
Introduction........................................................................................................... 6
3 Description of Process Phases ............................................................................ 9
3.1 Phase I: transaction data encryption ..................................................................9
3.2 Phase II: payment page call ..............................................................................10
3.3 Phase III: communication of transaction result ...............................................11
3.3.1 Response to merchant ...........................................................................11
3.3.2 Response to Buyer ................................................................................11
3.4 Phase IV: decryption of transaction result .......................................................12
4 Authentication .......................................................................................................... 13
5 WSCryptDecrypt Webservice .............................................................................. 14
6 Structure of Transaction Data .............................................................................. 15
6.1 Encrypt Method: how to obtain an encrypted string .......................................16
6.2 Decrypt Method: ho to obtain clear transaction result....................................23
7 Tokenization............................................................................................................. 26
7.1 Token Generation during payments in IFrame architecture..........................27
7.2 Token values........................................................................................................28
7.3 Rules for Custom Tokens...................................................................................29
8 PayPal Seller Protection ....................................................................................... 30
8.1 Seller Protection activation ...............................................................................31
8.2 Seller Protection example .................................................................................32
9 Payment Type .......................................................................................................... 33
10 Payment Type Detail............................................................................................ 34
11 Fraud Prevention Configuration....................................................................... 36
11.1 PC Finger Print..................................................................................................39
11.2 Accreditation Tests...........................................................................................40
12 Consel "Rate in Rete" integration................................................................... 41
12.1 Consel Payment Method activation...............................................................42
12.2 Consel "Rate in Rete" example......................................................................43
13 PayPal Reference Transaction.......................................................................... 44
13.1 PayPal Reference Transaction activation ....................................................44
14 Alternative Payments integration..................................................................... 45
14.1 Alternative Payments activation.....................................................................45
14.2 Sofort Banking..................................................................................................47
14.3 Ideal ....................................................................................................................48
14.4 Klarna..................................................................................................................49
14.5 Qiwi ....................................................................................................................51
14.6 Yandex...............................................................................................................52
14.7 AliPay..................................................................................................................53
15 Merchant’s Profile ................................................................................................. 54
15.1 Authentication configuration ............................................................................55
15.2 Configuration of response url and e-mail.......................................................56
15.3 Configuration of Fields & Parameters ............................................................57
15.3.1 Tokenization set Fields & Parameters.................................................58
15.3.2 Seller Protection set Fields & Parameters ...........................................59
15.3.3 Payment Options Visibility set Fields & Parameters .........................60
15.3.4 Payment Type Detail set Fields & Parameters ...................................61
15.3.5 RED Fraud Prevention set Fields & Parameters ................................62
15.3.6 Consel "Rate in Rete set Fields & Parameters ...................................63
15.3.7 PayPal Reference Transaction set Fields & Parameters ......................64
16 Software Requirements ....................................................................................... 65
Page 2 of 111
16.1 Buyer browser requirements ...........................................................................65
16.2 Merchant server requirements ........................................................................65
17 Table of Errors........................................................................................................ 66
18 Table of currency codes ...................................................................................... 74
19 Table of Language Codes ................................................................................... 75
20 Table of 3D-Secure Codes .................................................................................. 76
21 Table of PayPal Seller Protection State Codes ............................................. 77
22 Table of Country Codes....................................................................................... 80
22.1 PayPal Codes....................................................................................................80
22.2 RED Codes........................................................................................................86
23 Table of Payment Type Codes ........................................................................... 91
24 Example Transactions ......................................................................................... 92
24.1 Transaction # 1..................................................................................................93
24.2 Transaction # 2..................................................................................................96
24.3 Transaction # 3................................................................................................100
24.4 Transaction # 4................................................................................................103
24.5 Transaction # 5................................................................................................107
25 Payment Orders in Test Environment ........................................................... 111
Page 3 of 111
Document Information
Project
name:
Title:
Creation date
Language:
Company:
Ges
tPay
GestPay Technical Specifications for Payment Page (Security with
Encryption)
01.06.2013
English
EasyNolo
Page 4 of 111
Version Information
Version
Description
1_0_0 Initial version
1_1_0 RED, Payment Types, Payment Types
Detail
1_2_0 Consel "Rate in Rete", PayPal Reference
Transaction
1_3_0 Tokenization Group, case sensitive
indication
1_4_0 Order Details, Line Items
Date
01/06/13
21/03/14
21/10/14
13/02/15
27/10/15
1_5_0 Alternatives Payments
13/11/15
1_6_0 Update Software Requirements
27/01/16
Page 5 of 111
1
Introduction
GestPay is the suite that Banca Sella Group offers to online merchants for
accepting and managing online payments.
GestPay is available in many configurations, with different sets of features and
different technical interfaces.
The main division is between the solution that allows merchants to interact in
Server-Server way with GestPay and the solution that allows merchants to
redirect buyers to GestPay's pages for the payment.
The current document describes the architectural and functional features of
GestPay when used for the redirection of buyers Information, link and support
are available on https://www.gestpay.it.
GestPayWS/WsCryptDecrypt web service is exposed by GestPay at following
URLs:
•
•
Test environment:
https://testecomm.sella.it/gestpay/GestPayWS/WsCryptDecrypt.asmx?w
sdl
Production environment:
https://ecommS2S.sella.it/gestpay/GestPayWS/WsCryptDecrypt.asmx?
wsdl
In this document is explained the use of webservice for handling the encryption
and decryption services.
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 WebService focuses on the use of the webservice responsible for
handling the encryption and decryption services – substituting the
WSCryptDecrypt 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.
Page 6 of 111
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 2048-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.
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
Page 7 of 111
passed, the payment page can be displayed and the the data needed to
complete the transaction 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.
Page 8 of 111
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 using the WSCryptDecrypt WebService
The use of the web service does not require any installation on the server, but
simply a call to the web service 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.
Page 9 of 111
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/pagam/pagam.aspx?a=<ShopLogin>&b=<encrypted
string>
for test codes:
https://testecomm.sella.it/pagam/pagam.aspx?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
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.
Page 10 of 111
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
“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.
Page 11 of 111
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
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 is made using 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.
Page 12 of 111
4 Authentication
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.
Page 13 of 111
5 WSCryptDecrypt Webservice
WSCryptDecrypt web service is available on 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.
If the encryption operation is concluded correctly (TransactionResult tag value
with OK), the encrypted data string returned by GestPay will be available by
reading the value of the CryptDecryptString tag.
If this is not the case, the values of the ErrorCode and ErrorDescription tag 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 CryptedString tags 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.
Page 14 of 111
6 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.
Page 15 of 111
6.1 Encrypt Method: how to obtain an encrypted string
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
xml using Encrypt method in order to make a transaction, the tags' names are
case sensitive:
Name
Max
Dim
shopLogin
30
uicCode
3
amount
9
shopTransactionID
50
buyerName
buyerEmail
50
50
languageId
2
customInfo
1000
(1)
(2)
requestToken
25
(3)
ppSellerProtection
shippingDetails
shipToName
shipToStreet
1
Description
shopLogin (Mandatory)
Code identifying currency in which transaction
amount is denominated - see Currency Codes
table - (Mandatory)
Transaction amount. Do not insert thousands
separator. Decimals, max. 2 numbers, are
optional and separator is the point (Mandatory)
Identifier
attributed
to merchant’s
transaction (Mandatory)
Buyer’s name and surname
Buyer’s e-mail address
Code identifying language used in
communication with buyer
String containing specific information as
configured in the merchant’s profile
“MASKEDPAN” for a Standard Token any other
value for Custom Token.
Using :FORCED: before the token, it' s possible
to have the token even if the transaction is not
authorized
Parameter to set the use of a confirmed
addresses
32
100
String containing the shipping name
String containing the shipping address
shipToCity
40
shipToState
40
shipToCountryCode
2
shipToZip
20
shipToStreet2
100
String containing the shipping city
String containing the shipping state (see State
Codes table)
String containing the shipping country code (see
Country Codes table)
String containing the shipping zip
String containing a shipping address additional
field
paymentTypes
(4)
paymentType
25
Set of tags to set the visibility of payment
systems on payment page (see Payment Type
Codes table)
paymentTypeDetail
Page 16 of 111
Max
Dim
Name
MyBankBankCode
IdealBankCode
(5)
(5)
redFraudPrevention
Red_CustomerInfo
Customer_Title
Customer_Name
Customer_Surname
Customer_Email
Customer_Address
Customer_Address2
Customer_City
Customer_StateCode
Customer_Country
Customer_PostalCode
Customer_Phone
Red_ShippingInfo
Shipping_Name
Shipping_Surname
Shipping_Email
Shipping_Address
Shipping_Address2
Shipping_City
Shipping_StateCode
Shipping_Country
Shipping_PostalCode
Shipping_HomePhone
Shipping_FaxPhone
Shipping_MobilePhone
Shipping_TimeToDeparture
Red_BillingInfo
Billing_Id
Billing_Name
Billing_Surname
Billing_DateOfBirth
Billing_Email
Billing_Address
Billing_Address2
Billing_City
Billing_StateCode
Billing_Country
Billing_PostalCode
Billing_HomePhone
25
25
1
Description
Tag to set the Bank to show on payment page (the
bank List is retrieved from
WsS2S.CallMyBankListS2S)
Tag to set the Bank to show on payment page (the
bank List is retrieved from
WsS2S.CallIdealListS2S)
Flag to activate Red Fraud Prevention
(redFraudPreventin=1)
5
30
30
45
30
30
20
2
3
9
19
Customer Title
Customer First Name
Customer Last Name
Customer Email Address - value must contain @
Customer address line 1
Customer address city
Customer address state code
Customer Country Code - ISO-Alpha 3 (IE: ITA)
Customer Post/Zip Code
Customer Phone - no spaces
30
30
45
30
30
20
2
3
9
19
12
19
Shipping First Name
Shipping Last Name
Shipping Email Address - value must contain @
Shipping address line 1
Shipping address city
Shipping address state code
Shipping Country Code - ISO-Alpha 3
Shipping Post/Zip Code
Shipping Home Phone - no spaces
Shipping Fax Phone - no spaces
Shipping Mobile Phone
Shipping Time To Departure (See RED Par. for
details)
1
16
30
30
10
45
30
30
20
2
3
9
19
Billing ID
Billing First Name
Billing Last Name
Billing DoB - format: YYYY-MM-DD
Billing Email Address - value must contain @
Billing address line 1
Billing address city
Billing address state code
Billing Country Code - ISO-Alpha 3
Billing Post/Zip Code
Billing Home Phone - no spaces
Page 17 of 111
Name
Max
Dim
Description
Billing_WorkPhone
19
Billing Work Phone - no spaces
Billing_MobilePhone
19
Billing Mobile Phone
60
45
Transaction Source Website
IP of customer - Format: nnn.nnn.nnn.nnn
PC Finger Print (See PC Finger Print Paragraph
below), if the RED Configuration is defined with the
chance to fill this value, but for some reasons it's
left empty, then pay attention and fill
Red_ServiceType=N to avoid error
Previous Customer Flag - format Y or N
Optional only for merchant with a specific set of
rules (Code provided by Sella)
Optional only for merchant with a specific set of
rules (Code provided by Sella)
Red_CustomerData
MerchantWebSite
Customer_IpAddress
PC_FingerPrint
4000
PreviousCustomer
1
Red_Merchant_ID
12
Red_ServiceType
1
Red_CustomInfo
UserCustomData
From 1
To 10 >256
Custom Data Fields (Zero or more repetitions)
From 11
To 25 >30
Red_Items
NumberOfItems
2
Required to specify the number of repeating item
tags max value 99
Red_Item
Item_ProductCode
Item_StockKeepingUnit
Item_Description
Item_Quantity
12
12
26
12
Item_UnitCost (100=1€)
12
Item_TotalCost
12
Item_ShippingNumber
Item_GiftMessage
Item_PartEAN_Number
Item_ShippingComments
19
160
30
160
Consel_MerchantPro
3
Item Product Code
Item Stock Keeping Unit
Item Description
Item quantity - 1 should be sent as 10000
Item cost amount - €5.00 should be sent as
50000
Total Item Amount (item qty x item cost amt), no
decimal
Item shipping/tracking number
Item gift message
Item Park or EAN Number
Item Shipping Comments
Merchant Promotional Code (Mandatory to show
Consel in the pagam's Payment Method)
Consel_CustomerInfo
Surname
30
Customer Surname
Name
30
Customer Name
TaxationCode
16
Customer Taxation Code
Address
60
Customer Address
City
30
Customer City
StateCode
2
Customer State Code
DateAddress
10
Date since the customer lives in the declared
address (dd/mm/yyyy)
Phone
15
Customer phone
Page 18 of 111
Name
MobilePhone
payPalBillingAgreementDescription
Max
Dim
Description
15
Customer Mobile phone
127
Description of the goods, terms and conditions of
the billing agreement
OrderDetails
CustomerDetail
ProfileID
MerchantCustomerID
FirstName
MiddleName
Lastname
PrimaryEmail
SecondaryEmail
PrimaryPhone
12
50
65
65
65
100
100
20
SecondaryPhone
DateOfBirth
Gender
20
10
1
SocialSecurityNumber
20
Company
ShippingAddress
ProfileID
FirstName
MiddleName
Lastname
StreetName
Streetname2
HouseNumber
HouseExtention
City
ZipCode
State
CountryCode
Email
PrimaryPhone
SecondaryPhone
BillingAddress
ProfileID
FirstName
MiddleName
Lastname
StreetName
Streetname2
HouseNumber
HouseExtention
City
ZipCode
State
CountryCode
Email
PrimaryPhone
SecondaryPhone
ProductDetails
255
Customer profile ID (future use)
Merchant customer ID (future use)
Customer First Name
Customer Middle Name
Customer Last name
Customer primary email
Customer secondary email
Customer's phone including prefix
Customer Date of Birth (dd/mm/yyyy)
Customer Gender (0=Male 1=Female)
Customer's social or fiscal identifier (for Klarna
Use)
Customer Company
12
65
65
65
100
100
5
5
50
50
50
2
100
20
20
Profile ID (future use)
First Name
Middle Name
Last name
Shipping Street
Shipping Street second line
12
65
65
65
100
100
5
5
50
50
50
2
100
20
20
First Name
Middle Name
Last name
Shipping Street
Shipping City
Shipping Zip Code
Shipping State
Alpha-2 code example for US is “US”
Shipping Contact Email
Shipping Primary Phone
Shipping Secondary Phone
BillingCity
BillingZip Code
BillingState
Page 19 of 111
ProductDetail <1...N>
ProductCode
SKU
(6)
Name
12
50
100
Description
(6)
(6)
255
Quantity
3
Price
(6)
UnitPrice
12
12
Type
2
Vat
Discount
2
2
Article’s product Code
Article’s Stock Keeping Unit
Article’s name
Article’s description
The number of products
Article’s price
Article’s Unit Price
The type of article:
1-product, 2-shipping, 3-handling
Value-Added Tax (the value of the tax)
The amount offered by you as discount
(1)
Each field can be up to a maximum of 300 characters in length
Required only when a Token is needed within the transaction
response.
In order to be able to request, obtain and use a Token,
merchants need to appropriately set “Fields and Parameters” in
the dedicated section of GestPay Merchant Back Office.
(3)
PayPal Seller Protection parameter. In order to be able to
activate the Seller Protection Option the merchants need to
appropriately set “Fields and Parameters” in the dedicated
section of GestPay Merchant Back Office.
(4)
Payment Systems Visibility. In order to be able to activate the
Payment Systems Visibility the merchants need to appropriately
set “Fields and Parameters” in the dedicated section of GestPay
Merchant Back Office. The Payment System Visibility can be
configured in the specific interface in the Back Office Merchant.
(5)
paymentTypeDetail. In order to be able to activate the payment
Type Detail the merchants need to appropriately set “Fields and
Parameters” in the dedicated section of GestPay Merchant Back
Office. The correct merchant configuration of Sofort and Ideal
has to be configured in the specific interface of Back Office
Merchant.(1) Each field can be up to a maximum of 300
characters in length
(6)
Line Items: in case the buyer selects PayPal as payment method
in the payment page, fields Name, Description, Quantity and
UnitPrice of every occurrency of the ProductDetail tag will be
used to show the transaction items details in PayPal payment
page.
(2)
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
Page 20 of 111
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*datumn=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*
--
In the RED Fraud Prevention parameters (items tags with "RED" prefix) also the
following characters must not be used:
$
!
^
~
#
Page 21 of 111
Encrypt web service returns back the following information in the xml.
Name
TransactionType
Max Size
7
TransactionResult
2
CryptDecryptString
....
ErrorCode
ErrorDescription
9
255
Description
Decode the transaction type request
(DECRYPT, ENCRYPT)
Transaction result (OK/KO)
Encrypted string get by parameter set in the xml
request
Error code
Error description
Page 22 of 111
6.2 Decrypt Method: ho to obtain clear transaction result
GestPay communicates the payment transaction result to the merchant through
an encrypted string (parameter b of the call to the url preconfigured by the
merchant) with a set of transaction's informations.
To Decrypt the data it is necessary to use Decrypt method passing the following
parameters, the tags' names are case sensitive:
Name
shopLogin
CryptedString
Max Size
Description
30
ShopLogin
Encrypted string get by parameter b of the call to the
....
url preconfigured by the merchant
Decrypt webservice returns back the following information in the xml.
Name
Max
Size
Description
Transaction Type
7
Decode the transaction type request
(DECRYPT, ENCRYPT)
TransactionResult
2
Transaction result (OK/KO)
ShopTransactionID
50
Identifier attributed to merchant’s
transaction
BankTransactionID
9
Identifier attributed to the transaction
by GestPay
AuthorizationCode
6
Transaction authorisation code
Currency
3
Code identifying currency in which transaction
amount is denominated (see Currency Codes
table)
Amount
9
Transaction amount. Do not insert
thousands separator. Decimals (max. 2
numbers) are optional and separator is the
point (see examples)
Country
30
(1)
CustomInfo
1000
Nationality of institute issuing card
String that has the specific
information as configured in the merchant’s
profile
Buyer.BuyerName
50
Buyer’s name and surname
Buyer.BuyerEmail
50
Buyer’s e-mail address
TDLevel
255
Level of authentication for VBV Visa / Mastercard
Securecode transactions.
The string may have the value FULL or HALF
ErrorCode
9
Error code
Page 23 of 111
Name
Max
Size
Description
ErrorDescription
255
Error description
AlertCode
9
Alert code
AlertDescription
255
Alert description in chosen language
CVVPresent
1
Credit Card security code flag
MaskedPAN
25
Masked Pan string
PaymentMethod
100
Indicates the used Payment Method
TOKEN
25
String containing the token value
ProductType
100
String containing Card Type
TokenExpiryMonth
2
String containing the token expiry month
TokenExpiryYear
2
String containing the token expiry year
TransactionKey
18
Transaction identifier for 3D transactions. Not
used in transactions managed with the Payment
Page. It is useful only in Server-Server
transactions
VbV
2
Verified By Visa Flag
VbVRisp
Encrypted string containing information for 3DSecure transactions. Not used in transactions
managed with the Payment Page. It is useful only
in Server-Server transactions
VbVBuyer
2
Information about the enrolment of the buyer's
card to 3D-Secure protocol: "OK" means that the
card is enrolled, "KO" means that the card is not
enrolled
VbVFlag
2
Information about the 3D-Secure status. Not
used in transactions managed with the Payment
Page. It is useful only in Server-Server
transactions.
RedResponseCode
9
RED Fraud Score of the transaction or Error
code if there are problems with RED request
Value
Description
ACCEPT
Passed fraud screening
DENY
Recommend Deny
CHALLENGE
Recommend Challenge
NOSCORE
ReD not required to give a
recommendation
ERROR
Error in request data or internal
ReD Shield
ENETFP
Unable to connect to ReD Shield
ETMOUT
Screening request timed out
Page 24 of 111
Name
Max
Size
Description
EIVINF
RedResponseDescr
iption
(1)
400
Invalid Information
RED Description of the RedResponseCode
Each field can be up to a maximum of 300 characters in length.
The minimum information returned back as transaction result is made up of:
•
•
•
•
•
•
•
•
Currency
Amount
ShopTransactionID
TransactionResult
AuthorizationCode
ErrorCode
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:
Transaction
Result
Description
OK
Positive transaction result
KO
Negative transaction result
XX
Suspended transaction result
(This is not a final result. A
new communication will be provided to the merchant when
the transaction will assume the final OK/KO status)1
(1) The customer with XX transaction is redirect to URL for positive
response
Page 25 of 111
7 Tokenization
"Tokenization" means the replacement of a sensitive piece of information (i.e.:
credit card number) with a non sensitive one, called "Token".
Tokenization is used within GestPay in order to help merchants to match PCI
requirements (https://www.pcisecuritystandards.org/), defined by all major credit
cards companies in order to protect sensitive data of cardholders.
Merchants, who ask to their customers to register in their online shop, often save
the customer's credit card data in their system.
This behaviour has many advantages, first of which is the fact that the registered
buyers will be able to complete their next purchases without the need to enter
their card data again.
This behaviour might not be compliant with PCI rules.
Merchants should not store their customers' cards data into their systems, unless
they had been formally certified as PCI compliant.
In order to offer the same experience to their customers, without the need to face
heavy certification programs, merchants can take advantage of "Tokenization"
feature of GestPay, combined with "IFrame" solution.
With "Tokenization", a merchant will be able to remotely store credit card data in
GestPay archives and receive a Token in answer; the merchant will save the
received Token in its system instead of the credit card data.
For the next purchases, the merchants will send to GestPay the Token instead of
the credit card number.
GestPay will retrieve the credit card number from its archives starting from the
Token and it will complete the transaction.
Merchants will request and obtain new Tokens within the IFrame architecture.
And they will use previously generated Tokens within the Server-Server
architecture.
Therefore it is advisable for merchants, before they begin to work with GestPay
Tokens, to read and understand both IFrame and Server-Server technical
specifications documents.
A group of merchants can share a set of tokens.
So if a merchant belongs to a group he can use all the token of the others
merchants of the same group. This token could be updated or deleted from each
components of the group using the appropriate web service.
The group definition is set offline by Banca Sella operators, when a new
merchant is added to a group he can choose if insert in the group all his previous
token or not. In the same way, if a merchant leaves a group con decide if leave
in the group his tokens or not.
Tokenization feature is not automatically available to all GestPay merchants.
It must be requested and explicitly enabled by Banca Sella operators.
Page 26 of 111PAN
7.1 Token Generation during payments in IFrame architecture
It is very simple to request and obtain a new Token during a transaction with
IFrame architecture.
The involved phases are the first (encryption of transaction data) and the last
(decryption of GestPay answer).
In order to request a new Token, the merchant's system must set a value for
"Request Token" in the call to Encrypt method of WsCryptDecrypt web service.
Next chapter describes which values must be used.
In order to receive the Token data, the merchant's system must read the values
of "Token", "Token Expiry Month" and "Token Expiry Year" in the response of
Decrypt method of WsCryptDecrypt web service.
"Token" will contain the value that the merchant's system will use in the future.
"Token Expiry Month" and "Token Expiry Year" will not be used in the
communication with GestPay: they can be useful for the merchant in order to
know till when that Token will be valid.
"Request Token", "Token", "Token Expiry Month" and "Token Expiry Year"
fields must be properly configured in Merchant Back Office, in "Payment Page" /
"Fields & Parameters" section.
"Request Token" must be defined with "Parameter = true".
"Token", "Token Expiry Month" and "Token Expiry Year" must be defined with
"Response = true" and "Response Web Service = true".
It's possible to create the token in the Encrypt method of WsCryptDecrypt web
service even if the transaction is not authorized.
To achieve this result it's necessary to use :FORCED: before the token request:
<requestToken>:FORCED:MASKEDPAN</requestToken>
Page 27 of 111PAN
7.2 Token values
GestPay can manage two kinds of Tokens: standard Tokens and custom
Tokens.
Standard Tokens will be made as masked card numbers.
They will start with the same 2 digits of the card they replace, and they will end
with the same 4 digits of the card they replace; they will be 16 characters long.
The middle part will be a string made of 10 characters that can be digits or
capital letters.
The first 4 characters of this string will be always the same for each merchant.
(Different merchants will have a different 4 characters substring).
Example:
Card Number: 1234567890123456
Requested Token: MASKEDPAN
Standard Token: 12XYZWABCDEF3456
Card Number: 3456789012345678
Requested Token: MASKEDPAN
Standard Token: 34XYZWGHIJKL5678
Custom Tokens will be defined by the merchants, who will send their values to
GestPay so that GestPay will associate them to the cards they replace.
The returned custom Token will be made by the prefix of 4 characters assigned
to the merchant, followed by the value specified by the merchant.
Example:
Card Number: 1234567890123456
Requested Token: JOHN_SMITH_5533
Returned Custom Token: XYZWJOHN_SMITH_5533
Card Number: 3456789012345678
Requested Token: JACK_JONES_1234
Returned Custom Token: XYZWJACK_JONES_1234
Merchants will be able to choose which kind of Token GestPay must provide,
when they request a new Token.
This will be done by means of the value of “Token Request” parameter.
When merchants request a new Token, they will send “Token Request”
parameter to GestPay.
GestPay will use the value of “Token Request” to create the new Token.
If “Token Request” contains the exact word “MASKEDPAN”, then GestPay will
create a Standard Token.
If “Token Request” contains any other value, then GestPay will create a Custom
Token with that value prefixed by the 4 characters string of that merchant.
Page 28 of 111PAN
7.3 Rules for Custom Tokens
Custom Tokens will be chosen and generated by merchants themselves.
GestPay will simply receive, validate, add the prefix and store them.
Merchants will be free to choose the Token they prefer, but they must respect a
few rules:
• The Requested Token must be at least 10 characters long;
• The Requested Token must be at most 20 characters long;
• The Requested Token can only contain letters, digits, and underscore
(“_”);
• The number of digits in the Requested Token must be at most 8;
• The Requested Tokens are not case sensitive: GestPay will always
transform them in upper case
Page 29 of 111PAN
8 PayPal Seller Protection
PayPal Seller protection provides
Reversals that are based on:
Sellers from Claims, Chargebacks or
Unauthorized Transaction or
Item Not Received
PayPal Seller protection is available for eligible payments from buyers in any
country.
To be eligible for PayPal Seller protection, you must meet all of the basic
requirements listed in the following link
https://cms.paypal.com/it/cgi-bin/marketingweb?cmd=_rendercontent&content_ID=ua/BuyerProtection_full&locale.x=it_IT#11. Seller Protection
Programme
Page 30 of 111PAN
8.1 Seller Protection activation
PayPal Seller Protection option has to be enabled for the merchant from the
Bank Back Office.
The Merchant can decide for every transaction if use the “seller protection” or not
passing the new XML element ppSellerProtection to 1.
In addiction it's necessary to pass these values in the encryption call, so the
transaction have automatically the “Seller Protection” flag:
SHIPTONAME
SHIPTOSTREET
SHIPTOCITY
SHIPTOSTATE
SHIPTOZIP
SHIPTOCOUNTRYCODE
Transaction performed with PayPal Seller Protection will be marked in the Active
Report of Back Office Merchant with a flag
To pass the Seller Protection elements, it is necessary to configure the Fields
and parameters value in the proper way, each value has to be enabled as
parameter. See 12.3 Configuration of Fields & Parameters for detail.
Page 31 of 111PAN
8.2 Seller Protection example
Here an example of filled values. State and Country Code values are listed in
State Codes table and Country Code table. The field ShipToStreet2 is optional
<ecom:ppSellerProtection>1</ecom:ppSellerProtection>
<ecom:shippingDetails>
<ecom:shipToName>Mario Rossi</ecom:shipToName>
<ecom:shipToStreet>Via Roma,1</ecom:shipToStreet>
<ecom:shipToCity>Milano</ecom:shipToCity>
<ecom:shipToState>Milano</ecom:shipToState>
<ecom:shipToCountryCode>IT</ecom:shipToCountryCode>
<ecom:shipToZip>20121</ecom:shipToZip>
<ecom:shipToStreet2></ecom:shipToStreet2>
</ecom:shippingDetails>
Page 32 of 111PAN
9 Payment Type
GestPay merchants can be enabled to a growing set of payment methods.
When a buyer is redirected to the payment page of GestPay, it will be requested
to choose one payment method among all those available.
Merchants might want to offer this choice to their buyers directly on their web
sites, before sending them to GestPay.
GestPay provides a way for merchants to dinamically define which payment
methods must be displayed for each transaction.
When calling Encrypt method of WsCryptDecrypt web service, merchants can
declare the list of the payment methods that GestPay must show to the buyer for
that transaction.
In order to do that, merchants must properly set the tag "paymentType" that can
be repeated as many times as needed, inside the tag "paymentTypes" (with a
final "s").
GestPay will then propose to the buyer the choice among those payment
methods.
If only one value was set for "paymentType", GestPay will propose no
choice, and it will directly show that payment method to the buyer.
If no "paymentType" is specified by the merchant, GestPay will display the
payment methods accordingly to the default configuration set by the merchant in
the dedicated section of Merchant Back Office.
The values that can be used for "paymentType" tag are the following:
PaymentType
Description
BON
CREDITCARD
PAYPAL
MYBANK
UPMOBILE
MASTERPASS
CONSEL
S2PALI
S2PKLA
S2PQIW
S2PYAN
S2PSOF
S2PIDE
COMPASS
Money Transfer
Credit Card
PayPal
MyBank
Mobile - QRCode
MasterPass
Consel
ALIPAY (Alternatives)
KLARNA (Alternatives)
QIWI (Alternatives)
YANDEX (Alternatives)
SOFORT (Alternatives)
IDEAL (Alternatives)
COMPASS C-PAY
As an example, in order to show only Credit Card and MasterPass options to its
buyers, a merchant should call Encrypt method of WsCryptDecrypt web service
including the following XML tag:
<paymentTypes>
<paymentType>CREDITCARD</paymentType>
<paymentType>MASTERPASS</paymentType>
</paymentTypes>
Or, in order to offer only PayPal payment method, it should use the following tag:
Page 33 of 111PAN
<paymentTypes>
<paymentType>PAYPAL</paymentType>
</paymentTypes>
10 Payment Type Detail
Using Payment Types feature described above, in case of third-party payment
methods, merchants can hide the presence of GestPay, so that the buyers can
experience to be directly redirected by the merchant to the third party.
Merchants, indeed, will continue to redirect buyers to GestPay payment page,
but when GestPay finds that only one payment method is available for that
transaction, it will send the buyer to that option without displaying any user
interface.
If, for instance, the merchant sets <paymentType>PAYPAL</paymentType>,
when the buyer reaches GestPay payment page, it is immediately redirected to
PayPal, and its experience will be to have reached PayPal from the merchant's
site.
In case of MyBank and Ideal payment methods, there is one more step for the
buyers before being sent to the third-party processor: they must choose their
bank from a list of participating banks.
Merchants can embed this phase in their websites, in order to manage the
payment method choice and provide their buyers with the same experience of
direct connections to the third party processors.
This can be done through a feature called "Payment Type Detail"
Merchants are free to use this option or not: if they do not use it and they simply
set
<paymentType>MYBANK</paymentType>
or
<paymentType>IDEAL</paymentType> in their call to Encrypt method of
WsCryptDecrypt web service, then the buyer will find in GestPay a page where it
will choose its bank among those available for that kind of payment.
Merchants who want to use "Payment Type Detail" for MyBank and/or IDeal,
must be able to show to their buyers the list of the banks available for that kind of
Payment.
They can store the lists of those banks in their local storage (two distinct lists)
and keep the lists updated by periodically calling the methods CallIdealListS2S
and CallMyBankListS2S of WsS2S web service.
These methods will return a list of banks made like this:
<BankList>
<Bank>
<BankCode>Code0001</BankCode>
<BankName>Name of Bank 1</BankName>
</Bank>
...
<Bank>
<BankCode>Code0000N</BankCode>
<BankName>Name of Bank N</BankName>
</Bank>
</BankList>
There is no need to update the lists of the banks for each transaction.
Page 34 of 111PAN
One update every week is definitely enough, since the list of the banks
partecipating to MyBank and IDeal is not changing so quickly.
The update should consist of a complete replacement of each list with the new
values returned by WsS2S web service.
The merchant page should show the list of the BankNames and use the
corresponding BankCode.
The BankCode must be used for paymentTypeDetail tag, while calling the
Encrypt method of WsCryptDecrypt web service, as a value either for
MyBankBankCode or for IdealBankCode, depending on the payment method.
For example, for a MyBank transaction for which the buyer has chosen "Name of
Bank X", the merchant should call encrypt method with, among the others, these
values:
...
<paymentTypes>
<paymentType>MYBANK</paymentType>
</paymentTypes>
<paymentTypeDetail>
<MyBankBankCode>Code0000X</MyBankBankCode>
</paymentTypeDetail>
...
and, for an IDeal transaction for which the buyer has chosen "Name of Bank Y",
the merchant should call encrypt method with, among the others, these values:
...
<paymentTypes>
<paymentType>IDEAL</paymentType>
</paymentTypes>
<paymentTypeDetail>
<IdealBankCode>Code0000Y</IdealBankCode>
</paymentTypeDetail>
...
The field "PaymentTypeDetail" must be defined as "parameter" in Merchant Back
Office before it can be used by the merchant.
Page 35 of 111PAN
11 Fraud Prevention Configuration
This option gives the merchant a tool of fraud prevention linked to each
transaction, provided by RED.
Each merchant defines his own configuration on RED activation. Based on this
configuration some parameters has to be passed or not, for example
PC_FingerPrint.
For each order is possible to insert into the xml a set of parameters that let RED
the chance to evaluate the fraud risk linked to the order.
More information are provided to RED, more accurate is the risk evaluation.
Based on the collection and processing of this information, Red returns a risk
score (Accept, Deny, Challenge), which must be managed within the payment
flow performed by GestPay.
The merchant can decide the transaction behaviour based on the RED
Response. To define this behaviours Back Office Merchant provide a specific
configuration section [Configuration > Risk Management > RED] .
For each transaction the merchant can switch on the “Fraud Prevention by RED”
feature by sending in the request the new xml tag RedFraudPrevention valued to
1.
Along with the RedFraudPrevention tag valued to 1 to score the transaction for
fraud through RED GestPay need to receive these following information in the
encryption call:
Tag Name
Description
redFraudPrevention
Flag to activate Red Fraud Prevention
(redFraudPreventin=1)
Customer_Title
Customer Title
Customer_Name
Customer First Name
Customer_Surname
Customer Last Name
Customer_Email
Customer Email Address - value must
contain @
Customer_Address
Customer_Address2
Customer_City
Customer address city
Customer_StateCode
Customer address state code
Customer_Country
Customer Country Code - ISO-Alpha 3
(see par 18.2 RED Codes)
Customer_PostalCode
Customer Post/Zip Code
Customer_Phone
Customer Phone - no spaces
Shipping_Name
Shipping First Name
Shipping_Surname
Shipping Last Name
XML parent tag
Red_CustomerInfo: Set of tags
to define the Customer Identity
Red_ShippingInfo:Set of tags
to define the Shipping details
that can be different from the
Page 36 of 111PAN
Tag Name
Description
Shipping_Email
Shipping Email Address - value must
contain @
Shipping_Address
Shipping_Address2
Shipping_City
Shipping address city
Shipping_StateCode
Shipping address state code
Shipping_Country
Shipping Country Code - ISO-Alpha 3
Shipping_PostalCode
Shipping Post/Zip Code
Shipping_HomePhone
Shipping Home Phone - no spaces
Shipping_FaxPhone
Shipping Fax Phone - no spaces
Shipping_MobilePhone
Shipping Mobile Phone
Shipping_TimeToDeparture
Low Cost
C
Designated by
customer
D
International
I
Military
M
Next
Day/Overnight
N
Other
O
Store Pickup
P
2 day Service
T
3 day Service
W
Billing_Id
Billing ID
Billing_Name
Billing First Name
Billing_Surname
Billing Last Name
Billing_DateOfBirth
Billing DoB - format: YYYY-MM-DD
Billing_Email
Billing Email Address - value must
contain @
Billing_Address
Billing_Address2
Billing_City
Billing address city
Billing_StateCode
Billing address state code
Billing_Country
Billing Country Code - ISO-Alpha 3
Billing_PostalCode
Billing Post/Zip Code
Billing_HomePhone
Billing Home Phone - no spaces
Billing_WorkPhone
Billing Work Phone - no spaces
Billing_MobilePhone
Billing Mobile Phone
MerchantWebSite
Transaction Source Website
Customer_IpAddress
IP of customer - Format:
nnn.nnn.nnn.nnn
PC_FingerPrint
PC Finger Print (See PC Finger Print
Paragraph below), if the RED
XML parent tag
that can be different from the
Customer ones.
Red_BillingInfo: Set of tags to
define the billing informations
defining the billing references
and the billing address.
Red_CustomerData: Set of
tags to define the Customer
feature, in terms of computer
connection, new customer flag,
specific set of rules for non
usual orders if predefined with
Sella.
Page 37 of 111PAN
Tag Name
Description
XML parent tag
to fill this value, but for some reasons it's
left empty, then pay attention and fill
Red_ServiceType=N to avoid error
PreviousCustomer
Previous Customer Flag - format Y or N
Red_Merchant_ID
Optional only for merchant with a
specific set of rules (Code provided by
Sella)
Red_ServiceType
Optional only for merchant with a
specific set of rules (Code provided by
Sella)
UserCustomData (*)
Custom Data Fields (Zero or more
repetitions)
NumberOfItems
Required to specify the number of
repeating item tags max value 99
Item_ProductCode
Item Product Code
Item_StockKeepingUnit
Item Stock Keeping Unit
Item_Description
Item Description
Item_Quantity
Item quantity - 1 should be sent as
10000
Item_UnitCost (100=1€)
Item cost amount - €5.00 should be
sent as 50000
Item_TotalCost
Total Item Amount (item qty x item cost
amt), no decimal
Item_ShippingNumber
Item shipping/tracking number
Item_GiftMessage
Item gift message
Item_PartEAN_Number
Item Park or EAN Number
Item_ShippingComments
Item Shipping Comments
Red_CustomInfo: Set of al last
25 tag predefined with Sella, in
which each merchant could pass
specific information that could
be useful for the risk evaluation.
Red_Items: Specify how many
Red_Idem tags will be pass
Red_Item: Set of tags to define
the Item feature, there are the
most common attributes useful
to describe every kind of
product.
(*) This field could be repeated 25 times to pass custom information.
The fraud check is made before processing the order.
Transaction performed with RED check will be marked in the Active Report of
Back Office Merchant with a flag
Each Red related tag must be set up as "Parameter" in the Payment Page >
Fields & Parameter section on the Back Office environment, please see 11.3.4
Configuration of Fields & Parameters for further details.
The RED response will be used to define the transaction life.
Based on the RED response the merchant could configure the GestPay
behaviour regarding the transaction.
See par 11.5 "RED configuration" to define this feature.
Page 38 of 111PAN
11.1 PC Finger Print
This value is obtained by a third-party object, developed by iovation, to obtain
device information.
Web applications obtain device information by sourcing dynamically generated
JavaScript from iovation,called snare.js. The JavaScript determines what
information is available and generates a black box from all available
sources.
There are three ways to obtain a black box from snare.js.
• Include and specify a hidden form field that will be populated with
the value
• Create a JavaScript callback function to collect/process the
blackbox as it is
generated
• Call the JavaScript function ioGetBlackbox to obtain the blackbox
as needed.
For further information about Iovation integration please see RM Channel
Integration Guide v3.4.pdf.
Page 39 of 111PAN
11.2 Accreditation Tests
The purpose of the accreditation is to ensure clients have developed their
interface to meet RED's requirements.
Clients are expected to demonstrate that they can process good transactions.
Each test section has a column available to provide the RED_ID so that RED
can validate the test results.
Please send these completed section back to BancaSella once you have
completed your tests.
Test No.
POS001
POS002
POS003
POS004
Positive Response Testing
Istruction
RED_ID
Send a transaction using
[email protected]
[email protected]
[email protected]
Send a transaction with every field you will be sending
to ReD
Page 40 of 111PAN
12 Consel "Rate in Rete" integration
Consel integration let the buyer to choose between two different payment
method, the "Linea Revolving" and "Prestito Finalizzato".
The Credit line is request directly from the buyer, using the Consel web form.
If the buyer has an open credit line with Consel, "Linea Revolving" solution, the
buyer uses this active credit line, so the transaction response is immediate, like
using a CreditCard.
If the buyer has not a open credit line, he can perform the payment using
"Prestito Finalizzato" that proceeds with a money request using the web
interface. For this payment solution Consel takes some days to return back a
response. So in GestPay the transaction will be displayed as "Pending" until
Consel responses back "OK" for the credit line request.
GestPay will expose the Consel option between the Payment method in the
payment page.
If the buyer chose Consel GestPay redirect him to Consel web sites where he
can login to the reserved area to fill up the form to use an existing credit line or
request a new one.
GestPay will expose, via web service, all the fields that Consel needs to perform
a payment authorization, both mandatory and optional ones.
Page 41 of 111
12.1 Consel Payment Method activation
In order to receive Consel "Rate in Rete" payments the merchant must:
On the Merchant Back Office environment
1. activate his account in the Configuration > Environment > Payment
Methods section
2. set up as "Parameter" the fields ConselMerchantPro on the Payment
Page > Fields & Parameter section
Note.
For changes to take effect, the page must be published.
On the Encrypt method of the WSCryptDecrypt web service
1. value the Consel_MerchantPro tag with the "Codice Promozione" given
by Consel itself, this value will be validate runtime during the encrypt
request.
2. The transaction amount have to be upper than 150 Euro
If any of the requirements above are satisfied and the page is displayed in
Italian, the "Rate in Rete" payment method will be present in the check out
page.
In order to give to the buyer a better experience during the form filling the
merchant may send additional information through the Consel_CustomerInfo
tags.
Before sending it the field ConselCustomerInfo must be set up as parameter on
the Payment Page > Fields & Parameter section.
Page 42 of 111
12.2 Consel "Rate in Rete" example
Here an example of filled values.
<Consel_MerchantPro>WIK</Consel_MerchantPro>
<Consel_CustomerInfo>
<Surname>Rossi</Surname>
<Name>Mario</Name>
<TaxationCode>RSSMRA70D23H501H</TaxationCode>
<Address>Via Torino</Address>
<City>Roma</City>
<StateCode>RM</StateCode>
<DateAddress>11/04/1999</DateAddress>
<Phone>0632...</Phone>
<MobilePhone>331...</MobilePhone>
</Consel_CustomerInfo>
Page 43 of 111
13 PayPal Reference Transaction
A Buyer will be able to subscribe a Billing Agreement on PayPal website so
authorizing the Merchant to debit his/her PayPal account in future transactions.
13.1 PayPal Reference Transaction activation
To use PayPal Reference Transaction it's necessary to fill the tag
PayPalBillingAgreementDescription that can be present or not (in case of a
normal PayPal payment it will be left empty or not passed at all).
The Encryption service, if field payPalBillingAgreementDescription is present
and not empty, assumes that the payment method is PayPal (so paymentType
field in this case is not mandatory: if present it must be valued PAYPAL).
If this tag is passed to Encryption, GestPay bypasses the Pagam page in every
case (even if other payment methods are enabled for the Merchant).
This tag has to be filled with description of the goods, terms and conditions of
the billing agreement:
<payPalBillingAgreementDescription>description of the agreement
</payPalBillingAgreementDescription>
Page 44 of 111
14 Alternative Payments integration
Alternative payment methods option has to be enabled for the merchant from
the Bank Back Office.
Alternatives can be used only from gestpay payment page interface but if
needed the payment type can be used to have a frictionless payment directly to
the payment method selected.
A merchant will be able to use the following alternatives payments:
14.1 Alternative Payments activation
After the activation from the bank office It is necessary to fill and send to gestpay
some specific parameters in order to use alternatives Payments and make a
new page to force the use of the <OrderDetails> tag.
For each order is possible to insert into the xml a set of parameters, most of the
parameters needed are in the tag < OrderDetails>.
OrderDetails
CustomerDetail
ProfileID
MerchantCustomerID
FirstName
MiddleName
Lastname
PrimaryEmail
SecondaryEmail
PrimaryPhone
12
50
65
65
65
100
100
20
SecondaryPhone
DateOfBirth
Gender
20
10
1
SocialSecurityNumber
20
Company
ShippingAddress
ProfileID
FirstName
MiddleName
Lastname
StreetName
Streetname2
HouseNumber
HouseExtention
City
ZipCode
State
CountryCode
Email
PrimaryPhone
SecondaryPhone
255
12
65
65
65
100
100
5
5
50
50
50
2
100
20
20
Customer profile ID (future use)
Merchant customer ID (future use)
Customer First Name
Customer Middle Name
Customer Last name
Customer primary email
Customer secondary email
Customer Date of Birth (dd/mm/yyyy)
Customer Gender (0=Male 1=Female)
Customer's social or fiscal identifier (for Klarna
Use)
Customer Company
First Name
Middle Name
Last name
Shipping Street
Shipping City
Shipping Zip Code
Shipping State
Shipping Contact Email
Shipping Primary Phone
Shipping Secondary Phone
Page 45 of 111
BillingAddress
ProfileID
FirstName
MiddleName
Lastname
StreetName
Streetname2
HouseNumber
HouseExtention
City
ZipCode
State
CountryCode
Email
PrimaryPhone
SecondaryPhone
ProductDetails
ProductDetail <1...N>
ProductCode
SKU
Name
Description
Quantity
Price
UnitPrice
12
65
65
65
100
100
5
5
50
50
50
2
100
20
20
First Name
Middle Name
Last name
Shipping Street
12
50
100
255
3
12
12
Article’s product Code
Article’s Stock Keeping Unit
Article’s name
Article’s description
The number of products
Article’s price
Article’s Unit Price
The type of article:
1-product, 2-shipping, 3-handling
Value-Added Tax (the value of the tax)
The amount offered by you as discount
Type
2
Vat
Discount
2
2
BillingCity
BillingZip Code
BillingState
Page 46 of 111
Here below the specific tag needed for each one:
14.2 Sofort Banking
do not need mandatory parameters but if you send these few parameters:
•
•
•
•
CustomerDetail.FirstName
CustomerDetail.Lastname
CustomerDetail.PrimaryEmail
BillingAddress.CountryCode
you can have a frictionless call directly to the first screen of SOFORT where authentication data
are asked.
This mean that no others values are asked to the buyers but if these field are not sent with the
payment a page will be displayed in order to ask the necessary fields like Name and Email of the
buyer.
Credential Test Environment
You can use the following parameters value in order to test Sofort in test (testecomm.sella.it)
environment. Use low amount like 10.00 EUR.
When landing of Sofort payment select or insert the following value in order to have a successful
test payment :
Credential test values
Field
Value
Country
Germany
Bank
Name
88888888
Account Number
00000
PIN
00000
Transaction confirmation TAN
12345
Page 47 of 111
14.3 Ideal
do not need any mandatory parameters in a middle page the bank of the
buyer will be asked in order to continue the payment.
You can use the following parameters value in order to test Ideal in test (testecomm.sella.it)
When landing of Ideal payment page:
• Select the bank do you prefer in the middle page and then follow the instruction in order
to have a successful test payment.
Page 48 of 111
14.4 Klarna
need some mandatory parameters so if you want Klarna payment will be
available for the buyer these parameters must be provided otherwise Klarna will not be available
for payment or fails.
Mandatory parameters
• BillingAddress.CountryCode possible values [AT|DK|FI|DE|NL|NO|SE]
• PruductDetails.ProductDetail [1….N]
You can also send these parameters if present in your system but are not mandatory in this way
the buyer found the fields already filled in Klarna authentication page.
•
•
•
•
•
•
•
•
•
CustomerDetail.FirstName
CustomerDetail.LastName
CustomerDetail.SocialSecurityNumber
BillingAddress.StreetNumber
String ^.{1,65}$
String ^.{1,65}$
BillingAddress.StreetName
BillingAddress.City
BillingAddress.ZipCode
Please note that the articles from the Shopping Chart have to be sent in the XML post using the
tag ProductDetails like below:
<ecom:OrderDetails>
……
<ecom:ProductDetails>
<ecom:ProductDetail>
<ecom:ProductCode>1</ecom:ProductCode>
<ecom:SKU></ecom:SKU>
<ecom:Name>TV2000</ecom:Name>
<ecom:Description>Television</ecom:Description>
<ecom:Quantity>1</ecom:Quantity>
<ecom:Price>100</ecom:Price>
<ecom:UnitPrice>100</ecom:UnitPrice>
<ecom:Type>1</ecom:Type>
<ecom:Vat>10</ecom:Vat>
<ecom:Discount>0</ecom:Discount>
</ecom:ProductDetail>
</ecom:ProductDetails>
….
</ecom:OrderDetails>
•
•
•
The total value for the ProductDetails needs to be the same as the total amount sent
otherwise the transaction fails.
The Discount is a percentage and must be considered in the Total Amount Value.
For example if the Quantity is 1 the Price is 10 and the Discount is 10(%) the Total Amount
of the transaction must be 9 otherwise the transaction is refused.
Page 49 of 111
Credential for Test Environment
You can use the following parameters value in order to test Klarna in test (testecomm.sella.it)
Remember to set the mandatory field :
•
•
BillingAddress.CountryCode = ‘SE’
PruductDetails.ProductDetail [1….N]
When landing of Klarna payment page use the following parameter to fill the field or send it
directly in the parameters like as described above in order to have a successful test payment:
Field
Value
Personal Number
410321-9202
First Name
Testperson-se
Last Name
Approved
Street
Stårgatan 1
Zip Code
12345
City
Ankeborg
Phone Number
0765260000
Email
[email protected]
Page 50 of 111
14.5 Qiwi
do not need mandatory parameters but if you send these few parameters
•
•
:
CustomerDetail. PrimaryPhone
BillingAddress.CountryCode
you can have a frictionless call directly to the first screen of QIWI where authentication data are
asked.
payment a page will be displayed in order to ask the necessary fields like Phone and
CountryCode of the buyer.
Credential for Test Environment
You can use the following parameters value in order to test Qiwi in test (testecomm.sella.it)
environment. Use very low amount like 0.10 EUR.
If you use RUB currency the minimum amount must be bigger then 3 RUB and not bigger then
10 RUB.
•
•
Send this value “RU” on BillingAddress.CountryCode
Send this value “[email protected]” on CustomerDetail.PrimaryEmail or fill it in
the middle page
When landing of Qiwi payment page use the following parameter to fill the field or send it
Field
Value
Phone number
+7 8000005108
Password
Qazxsw21
Checkout SMS code
975651
Page 51 of 111
14.6 Yandex
do not need mandatory parameters but if you send these few parameters
•
you can have a frictionless call directly to the first screen of Yandex where authentication data
are asked.
payment a page will be displayed in order to ask the necessary fields like Email of the buyer.
You can use the following parameters value in order to test
environment. Use very low amount like 10.00 EUR.
•
Yandex in test (testecomm.sella.it)
Send this value “[email protected]” on CustomerDetail.PrimaryEmail or fill it in
the middle page
When landing of Yandex payment page use the following parameter to fill the field or send it
Field
Value
User
smart2pay.wallet
Password
yandex.money2013
Payment Password
yandexmoney
Page 52 of 111
14.7 AliPay
do not need any mandatory parameters in a middle page the bank of
the buyer will be asked in order to continue the payment.
Alipay do not have credential for test you can only landing on payment page.
Page 53 of 111
15 Merchant’s Profile
Each merchant can configure his/her profile by accessing the GestPay Back
Office environment at:
https://ecomm.sella.it/backoffice for production shops
https://testecomm.sella.it/backoffice for test shops
Some settings regard the procedure and the information that must be sent to or
will be returned by GestPay.
Page 54 of 111
15.1 Authentication configuration
GestPay identifies the merchant requesting the encryption service through the
WSCryptDecrypt web service 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
Page 55 of 111
15.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
Page 56 of 111
15.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
Page 57 of 111
15.3.1 Tokenization set Fields & Parameters
In order to be able to request, obtain and use a Token, merchants need to
appropriately set their “Fields and Parameters” in the dedicated section of
GestPay Merchant Back Office.
Then the merchant has to create a new page in the Back Office Interface to see
the Tokenization features in the list of the parameters.
Following settings must be applied (for changes to take effect, the page must be
published):
Field
Token Request
Settings
PARAMETER = TRUE
Notes
This allows merchants to request a new
token
Page 58 of 111
15.3.2 Seller Protection set Fields & Parameters
In order to use "Pay Pal seller Protection" feature payments merchants must
create a new payment page and set up as "Parameter" all the fields in the list
below through the Payment Page > Fields & Parameter section of the Merchant
Back Office
Note.
Field
Settings
Notes
PayPal Seller
Protection
Ship To City
Ship To Country
Code
Ship To Name
Ship To State
Ship To Street
Ship To Street2
Ship To Zip
PARAMETER = TRUE
PARAMETER = TRUE
PARAMETER = TRUE
This allows merchants to activate Seller
Protection
Ship To City value
Ship to Country Code Value
PARAMETER = TRUE
PARAMETER = TRUE
PARAMETER = TRUE
PARAMETER = TRUE
PARAMETER = TRUE
Ship To Name value
Ship To State value
Ship To Street Value
Optional fields for Ship to Street Value
Ship To Zip value
Page 59 of 111
15.3.3 Payment Options Visibility set Fields & Parameters
In order to configure Payment Options Visibility for the payment page of a
transaction, merchants need to appropriately set their “Fields and Parameters”
in the dedicated section of GestPay Merchant Back Office.
published):
Field
Settings
Notes
PaymentTypes
PARAMETER = TRUE
This allows merchants to insert a tag
<paymentType>?</paymentType> for
each payment method he wants to show
on the payment page
Page 60 of 111
15.3.4 Payment Type Detail set Fields & Parameters
In order to configure Payment Type Detail for the payment page of a
published):
Field
Settings
Notes
PaymentTypeDetail
PARAMETER = TRUE
This allows merchants to insert a tag
<paymentTypeDetail.MyBankBankCode
> or
<paymentTypeDetail.IdealBankCode> to
specify the Bank Code to use in the
payment page
Page 61 of 111
15.3.5 RED Fraud Prevention set Fields & Parameters
In order to use "RED Fraud Prevention" feature merchants must create a new
payment page and set up as "Parameter" all the fields in the list below through
the Payment Page > Fields & Parameter section of the Merchant Back Office.
To perform RED checks the
redFraudPrevention tag valued to 1
Field
authorization
request
Settings
RED_FRAUDPREVENTION PARAMETER = TRUE
must
contain
Notes
Flag to define if the transaction will be
performed with Red control
RED_BILLINGINFO
PARAMETER = TRUE
Billing tag enabled into XML (tag
Red_BillingInfo)
RED_CUSTOMERINFO
PARAMETER = TRUE
Customer data tag enabled into XML
(tag Red_CustomerInfo)
RED_CUSTOMERDATA
PARAMETER = TRUE
Customer data tag enabled into XML
(tag Red_CustomerData)
RED_SHIPPINGINFO
PARAMETER = TRUE
Shipping info tag enabled into XML (tag
Red_ShippingInfo)
RED_CUSTOMINFO
PARAMETER = TRUE
Customer info tag enabled into XML (tag
Red_CustomInfo)
RED_ITEMS
Items tag enabled into XML (tag
Red_Items), this tag colud contain a
PARAMETER = TRUE
variable number of tagset defined by the
Red Field OI_REPEAT
This parameters are a little bit different from the standard parameters defined in
Gest Pay, as a matter of fact these parameters don't correspond field to field to
XML tag, but each parameter is related to a Node (with a correspondent name)
that contains a set of tag specified in this document.
This is done because there are a lot of field for RED configuration (about one
hundred) grouped into categories, a parameter is defined for each category.
Page 62 of 111
15.3.6 Consel "Rate in Rete set Fields & Parameters
In order to configure Consel "Rate in Rete" for the payment page of a
published):
Field
Settings
Notes
ConselMerchantPro
PARAMETER = TRUE
Merchant Pro code to pass in the
encrypt to show Consel "Rate in Rete" in
the payment page (tag
Consel_MerchantPro)
ConselCustomerInfo
PARAMETER = TRUE
Customer Info data tag enabled into
XML (tag Consel_CustomerInfo)
Page 63 of 111
15.3.7 PayPal Reference Transaction set Fields & Parameters
In order to configure PayPal Reference Transaction for the payment page of a
published):
Field
Settings
Notes
PayPallBillingAgreem
ent
PARAMETER = TRUE
a description of the goods, terms and
conditions of the billing agreement
Page 64 of 111
16 Software Requirements
GestPay software requirements concern the buyer’s browser and the server
hosting the virtual store.
GestPay applies TSL1.1 protocol or latest. However, the system has to be
updated to the last security patch, so it's mandatory to verify the compatibility in
the test environment.
16.1 Buyer browser requirements
GestPay's domains are associated with a 256-bit SHA-2 and extended versions
SSL digital certificates issued by Verising.
GestPay applies TSL1.1 protocol or latest.
Buyer's browsers must support this level of encryption and must accept cookies
and Javascript.
Supported Browser:
Internet Explorer (IE) 10* or higher
Mozilla - Firefox 23* or higher
Google Chrome 26 or higher
Safari 7 or higher
* The TSL 1.1 protocol is disable by default, so it's necessary to enable it
16.2 Merchant server requirements
Check with the server administrator that the computer can reach the following
addresses:
PROD
HTTP
(port 80)
http://ecomms2s.sella.it/testhttp/test.asp
HTTPS
(port 443)
https://ecomms2s.sella.it/testhttps/test.asp
TEST
http://testecomm.sella.it/test
http/test.asp
https://testecomm.sella.it/test
https/test.asp
Page 65 of 111
17 Table of Errors
Code
Description
0
Transaction correctly processed
10
Payment page correctly loaded
57
Blocked credit card
58
Confirmed amount exceeds authorized amount
63
Demand for settlement of one nonexistent transaction
64
Expired preauthorization
65
Wrong currency
66
Preauthorization already notified
74
Authorization denied
97
100
Transaction interrupted by bank authorizative system
150
Wrong merchant configuration in bank authorizative system
208
Wrong expiry date
212
Bank authorizative system not available
251
Insufficient credit
401
Call credit card company
402
403
Technical error
404
Collect card
405
Authorization refused by credit card companies
406
Technical error
409
Technical error
412
Technical error
413
Technical error
414
Card not recognized
415
Technical error in connection with Credit Card Company network
416
Pin errato
417
418
Network not available
419
Wrong transaction date
420
Wrong card date
430
Technical error
431
433
Card expired
434
435
436
Card not qualified
437
Operation not allowed
438
Page 66 of 111
Code
Description
439
Card not recognized
441
Blocked credit card
443
Blocked credit card
451
Amount not available
454
Card expired
455
Operation not performed
456
Card not recognized
457
458
461
462
Blocked credit card
468
475
490
Technical error
491
492
494
Technical error
552
MyBank payment not completed
553
MyBank payment abandoned by buyer
600
Technical error
613
Technical error
614
Technical error
810
811
901
902
903
904
905
906
907
908
910
911
913
914
915
916
917
918
919
920
Page 67 of 111
Code
Description
950
Not qualified credit card
951
998
Credit card with wrong 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
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
Not numeric amount
1114
Amount with a wrong number of decimal digits
1115
Missing PAY1_SHOPTRANSACTIONID parameter
1116
Too long PAY1_SHOPTRANSACTIONID parameter
1117
Invalid language identifier
1118
Not numeric characters in credit card number
1119
Credit card number with wrong length
1120
Credit card with wrong check-digit
1121
Credit card belongs to a Company not enabled
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
Too long parameter string
1129
Too long parameter value
1130
Not accepted call: missing parameter A
1131
Not accepted call: Shop not recognized
1132
Not accepted call: shop is not in active state
1133
Not accepted call: missing parameter B
1134
Not accepted call: empty parameter B
1135
Not accepted call: other parameters beside A and B are present
1136
Not accepted call: transaction did not begin with a call to server-server
Page 68 of 111
Code
Description
cryptography system
1137
Not accepted call: transaction already processed before
1138
Not accepted call: card number or expiry date are missing
1139
Not accepted call: missing published payment page
1140
Transaction cancelled by buyer
1141
Not accepted call: input parameter string not acceptable
1142
Not accepted call: invalid IP Address
1143
Transaction abandoned by buyer
1144
Compulsory field not set
1145
Invalid OTP
1146
Too small amount
1147
Too big amount
1148
Invalid cardholder name
1149
Missing or wrong CVV2
1150
IPIN must be set
1151
Parameters error
1153
GestPay failed to verify if the card is enrolled to VBV service
1154
Not accepterd call: missing parameter TransKey
1160
Wrong CustomToken length
1161
Wrong CustomToken digits number
1162
CustomToken with illegal characters
1163
CustomToken used for another card
1164
Expired Token
1165
Token not found
1200
No match between ABI code and BankPass Banks
1201
BankPass Transaction abandoned by buyer
1202
BankPass - Buyer login failed
1203
BankPass - no payment methods available
1204
BankPass - technical error
1205
BankPass Server-Server: URL Return must be set
1206
BankPass Server-Server: too long URL Return (max 250 char)
1207
BankPass Server-Server: invalid URL Return (it must begin with http:// or
https://)
1208
BankPass Server-Server: URL Return parameter missing
1209
BankPass Server-Server: IDBankPass must be set
1210
BankPass Server-Server: invalid IDBankPass
1300
Shipping Address Country Error
1301
Shipping Address1 Empty
1302
Shipping Address City Empty
1303
Shipping Address State Empty
1304
Shipping Address Postal Code Empty
1305
Shipping Address Country Empty
Page 69 of 111
Code
Description
1306
Shipping Address Invalid City State Postal Code
1987
Technical error
1999
2000
Transaction exceeds maximum operations number in time period
2001
Transaction exceeds maximum number of operations performed by the same
buyer in time period
2002
Transaction exceeds maximum amount in time period
2003
Transaction exceeds maximum amount payable by same buyer in time period
2004
Transaction contains a field value that had been declared not acceptable
2005
Buyer abandoned the transaction because it was double
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 more rows related to the same transaction
2014
You requested a refund operation with an amount exceeding transaction
balance
2015
Wrong value in BANKTRANSACTIONID field
2016
Fields BANKTRANSACTIONID and SHOPTRANSACTIONID are empty
2017
Transaction can not be deleted
2018
Transaction can not be refunded
2019
Transaction can not be settled
2020
Transaction can not be renounced
2030
Due to RED configuration, transaction is sent to credit card companies, even
if 3d-Secure authentication is failed
4001
Unexpected parameter value
4002
Not numeric parameter value
4100
4101
Credit card number with wrong length
4102
4103
Technical error
4104
Technical error
4105
Technical error
4106
Technical error
4108
4109
Technical error
4200
Technical error
4201
Technical error
4202
Technical error
Page 70 of 111
Code
Description
4203
4204
4205
4206
Credit card with wrong check-digit. Please double-check the credit card
number typed in.
4207
Technical error
4208
4209
Technical error
4300
Technical error
4301
Too big amount
4302
Technical error
4303
4304
Technical error
4305
4306
4307
Technical error
4308
4309
Too big amount
4400
4401
Wrong expiry date
4402
4403
Technical error
4404
Technical error
4405
4406
4407
4408
4409
4500
Technical error
4501
Technical error
4502
Technical error
4503
4504
4505
4506
Technical error
4507
Technical error
4508
4604
Technical error
4701
4702
Wrong expiry date
4703
Card not qualified
4704
Page 71 of 111
Code
Description
4705
4706
4707
Transaction already processed
4708
MyBank: communication with the buyer's Bank failed
4709
Ideal: communication with the buyer's Bank failed
4710
PayPal Error
4720
Rate in Rete: communication with Consel failed
4730
C-pay: communication with Compass failed
4731
Not authorized transaction by Compass
7400
7401
7402
Card not qualified
7403
Card not recognized
7404
Card expired
7405
7406
Wrong card date
7407
7408
System error
7409
Merchant not recognized
7410
Invalid format
7411
7412
Not settled
7413
7414
Network not available
7415
Collect card
7416
PIN attempts exhausted
7417
Blocked terminal
7418
Forcedly Closed terminal
7419
Not permitted transaction
7420
Not authorized transaction
7421
Service interrupted at 01/01/2002
7500
7600
8000
File correctly processed
8001
Header/bottom record not found
8002
Merchant code not set
8003
Incorrect row number
8004
Incorrect file format
8005
Merchant not enabled
8006
Verify By Visa
8007
Feature disabled for VISA credit card
8008
Feature disabled
Page 72 of 111
Code
Description
8009
Payment interrupted
8010
Wrong credit card number for this transaction
8011
Transaction correctly received
8012
Authorization not found
8013
Settlement not found
8014
Settlement amount > Authorization amount
8015
Refund amount > balance
8016
Transaction without settlement
8017
File waiting to be processed
8018
File correctly processed
8021
Feature disable for MASTERCARD credit card
8022
Feature disable for JCB credit card
8023
Feature disabled for MAESTRO cards
8888
UP Mobile Payment
9991
Browser not supported
9992
Error creating iFrame
9997
Phase with error
9998
Phase correctly ended
9999
System Error
Note.
The error codes returned by GestPay are constantly updated.
If an error code returned by the procedure is missing, please check “Error
codes” entry contained in the “Help On Line” section in the Merchant Back
Office environment.
Page 73 of 111
18 Table of currency codes
Currency codes are handled by GestPay using the currency attribute.
Code UIC
ISOCODE
DESCRIPTION
109
AUD
Australia Dollar
234
BRL
Brazil Real
12
CAD
Canada Dollar
3
CHF
Switzerland Franc
144
CNY
China Yuan Renminbi
223
CZK
Czech Republic Koruna
7
DKK
Denmark Krone
242
EUR
Euro Member Countries
2
GBP
United Kingdom Pound
103
HKD
Hong Kong Dollar
153
HUF
Hungary Forint
18
ITL
Italian Lira
71
JPY
Japan Yen
8
NOK
Norway Krone
237
PLN
Poland Zloty
244
RUB
Russian Ruble
9
SEK
Sweden Krona
124
SGD
Singapore Dollar
1
USD
United States Dollar
Page 74 of 111
19 Table of Language Codes
The language code is handled by GestPay using the Language attribute.
Code
1
2
3
4
5
Description
Italian
English
Spanish
French
German
Page 75 of 111
20 Table of 3D-Secure Codes
The 3d-Secure code is handled by GestPay using the VbV attribute.
Code
OK
KO
Description
3d-Secure certified transaction
Transaction not 3d-Secure certified
Page 76 of 111
21 Table of PayPal Seller Protection State Codes
State Code
Agrigento
Alessandria
Ancona
Aosta
L'Aquila
Arezzo
Ascoli Piceno
Asti
Avellino
Bari
Bari
Belluno
Benevento
Bergamo
Biella
Bologna
Bolzano
Brescia
Brindisi
Cagliari
Caltanissetta
Campobasso
Carbonia-Iglesias
Caserta
Catania
Catanzaro
Chieti
Como
Cosenza
Cremona
Crotone
Cuneo
Enna
Fermo
Ferrara
Firenze
Foggia
Forli-Cesena
Frosinone
Genova
Gorizia
Grosseto
Imperia
State Code Description
Agrigento
Alessandria
Ancona
Aosta
L'Aquila
Arezzo
Ascoli Piceno
Asti
Avellino
Bari
Barletta-Andria-Trani
Belluno
Benevento
Bergamo
Biella
Bologna
Bolzano
Brescia
Brindisi
Cagliari
Caltanissetta
Campobasso
Carbonia-Iglesias
Caserta
Catania
Catanzaro
Chieti
Como
Cosenza
Cremona
Crotone
Cuneo
Enna
Fermo
Ferrara
Firenze
Foggia
Forli-Cesena
Frosinone
Genova
Gorizia
Grosseto
Imperia
Page 77 of 111
State Code
Isernia
Latina
Lecce
Lecco
Livorno
Lodi
Lucca
Macerata
Mantova
Massa Carrara
Matera
Medio Campidano
Messina
Milano
Modena
Monza Brianza
Napoli
Novara
Nuoro
Ogliastra
Olbia-Tempio
Oristano
Padova
Palermo
Parma
Pavia
Perugia
Pesaro e Urbino
Pescara
Piacenza
Pisa
Pistoia
Pordenone
Potenza
Prato
Ragusa
Ravenna
Reggio Calabria
Reggio Emilia
Rieti
Rimini
Roma
Rovigo
Salerno
Sassari
Savona
Siena
Isernia
Latina
Lecce
Lecco
Livorno
Lodi
Lucca
Macerata
Mantova
Massa Carrara
Matera
Medio Campidano
Messina
Milano
Modena
Monza Brianza
Napoli
Novara
Nuoro
Ogliastra
Olbia-Tempio
Oristano
Padova
Palermo
Parma
Pavia
Perugia
Pesaro e Urbino
Pescara
Piacenza
Pisa
Pistoia
Pordenone
Potenza
Prato
Ragusa
Ravenna
Reggio Calabria
Reggio Emilia
Rieti
Rimini
Roma
Rovigo
Salerno
Sassari
Savona
Siena
Page 78 of 111
State Code
Siracusa
Sondrio
La Spezia
Taranto
Teramo
Terni
Torino
Trapani
Trento
Treviso
Trieste
Udine
Varese
Venezia
Verbania-Cusio-Ossola
Vercelli
Verona
Vibo Valentia
Vicenza
Viterbo
Siracusa
Sondrio
La Spezia
Taranto
Teramo
Terni
Torino
Trapani
Trento
Treviso
Trieste
Udine
Varese
Venezia
Verbania-Cusio-Ossola
Vercelli
Verona
Vibo Valentia
Vicenza
Viterbo
Page 79 of 111
22 Table of Country Codes
22.1 PayPal Codes
The list of Country Code is from https://cms.paypal.com/en/cgibin/?cmd=_render-content&content_ID=developer/e_howto_html_countrycodes
Country
PayPal Code
AFGHANISTAN
ÅLAND ISLANDS
AF
AX
ALBANIA
AL
ALGERIA
DZ
AMERICAN SAMOA
AS
ANDORRA
AD
ANGOLA
AO
ANGUILLA
AI
ANTARCTICA
AQ
ANTIGUA AND BARBUDA
AG
ARGENTINA
AR
ARMENIA
AM
ARUBA
AW
AUSTRALIA
AU
AUSTRIA
AT
AZERBAIJAN
AZ
BAHAMAS
BS
BAHRAIN
BH
BANGLADESH
BD
BARBADOS
BB
BELARUS
BY
BELGIUM
BE
BELIZE
BZ
BENIN
BJ
BERMUDA
BM
BHUTAN
BT
BOLIVIA
BO
BOSNIA AND HERZEGOVINA
BA
BOTSWANA
BW
BOUVET ISLAND
BV
BRAZIL
BR
BRITISH INDIAN OCEAN TERRITORY
IO
BRUNEI DARUSSALAM
BN
BULGARIA
BG
BURKINA FASO
BF
BURUNDI
BI
CAMBODIA
KH
CAMEROON
CM
CANADA
CA
Page 80 of 111
Country
CAPE VERDE
PayPal Code
CV
CAYMAN ISLANDS
KY
CENTRAL AFRICAN REPUBLIC
CF
CHAD
TD
CHILE
CL
CHINA
CN
CHRISTMAS ISLAND
CX
COCOS (KEELING) ISLANDS
CC
COLOMBIA
CO
COMOROS
KM
CONGO
CG
CONGO, THE DEMOCRATIC REPUBLIC OF THE
CD
COOK ISLANDS
CK
COSTA RICA
CR
COTE D'IVOIRE
CI
CROATIA
HR
CUBA
CU
CYPRUS
CY
CZECH REPUBLIC
CZ
DENMARK
DK
DJIBOUTI
DJ
DOMINICA
DM
DOMINICAN REPUBLIC
DO
ECUADOR
EC
EGYPT
EG
EL SALVADOR
SV
EQUATORIAL GUINEA
GQ
ERITREA
ER
ESTONIA
EE
ETHIOPIA
ET
FALKLAND ISLANDS (MALVINAS)
FK
FAROE ISLANDS
FO
FIJI
FJ
FINLAND
FI
FRANCE
FR
FRENCH GUIANA
GF
FRENCH POLYNESIA
PF
FRENCH SOUTHERN TERRITORIES
TF
GABON
GA
GAMBIA
GM
GEORGIA
GE
GERMANY
DE
GHANA
GH
GIBRALTAR
GI
GREECE
GR
GREENLAND
GL
GRENADA
GD
Page 81 of 111
Country
PayPal Code
GUADELOUPE
GP
GUAM
GU
GUATEMALA
GT
GUERNSEY
GG
GUINEA
GN
GUINEA-BISSAU
GW
GUYANA
GY
HAITI
HT
HEARD ISLAND AND MCDONALD ISLANDS
HM
HOLY SEE (VATICAN CITY STATE)
VA
HONDURAS
HN
HONG KONG
HK
HUNGARY
HU
ICELAND
IS
INDIA
IN
INDONESIA
ID
IRAN, ISLAMIC REPUBLIC OF
IR
IRAQ
IQ
IRELAND
IE
ISLE OF MAN
IM
ISRAEL
IL
ITALY
IT
JAMAICA
JM
JAPAN
JP
JERSEY
JE
JORDAN
JO
KAZAKHSTAN
KZ
KENYA
KE
KIRIBATI
KI
KOREA, DEMOCRATIC PEOPLE'S REPUBLIC OF
KP
KOREA, REPUBLIC OF
KR
KUWAIT
KW
KYRGYZSTAN
KG
LAO PEOPLE'S DEMOCRATIC REPUBLIC
LATVIA
LA
LV
LEBANON
LB
LESOTHO
LS
LIBERIA
LR
LIBYAN ARAB JAMAHIRIYA
LIECHTENSTEIN
LY
LI
LITHUANIA
LT
LUXEMBOURG
LU
MACAO
MO
MACEDONIA, THE FORMER YUGOSLAV REPUBLIC OF
MADAGASCAR
MK
MG
MALAWI
MW
MALAYSIA
MY
Page 82 of 111
Country
PayPal Code
MALDIVES
MV
MALI
ML
MALTA
MT
MARSHALL ISLANDS
MH
MARTINIQUE
MQ
MAURITANIA
MR
MAURITIUS
MU
MAYOTTE
YT
MEXICO
MX
MICRONESIA, FEDERATED STATES OF
FM
MOLDOVA, REPUBLIC OF
MD
MONACO
MC
MONGOLIA
MN
MONTSERRAT
MS
MOROCCO
MA
MOZAMBIQUE
MZ
MYANMAR
MM
NAMIBIA
NA
NAURU
NR
NEPAL
NP
NETHERLANDS
NL
NETHERLANDS ANTILLES
AN
NEW CALEDONIA
NC
NEW ZEALAND
NZ
NICARAGUA
NI
NIGER
NE
NIGERIA
NG
NIUE
NU
NORFOLK ISLAND
NF
NORTHERN MARIANA ISLANDS
MP
NORWAY
NO
OMAN
OM
PAKISTAN
PK
PALAU
PW
PALESTINIAN TERRITORY, OCCUPIED
PS
PANAMA
PA
PAPUA NEW GUINEA
PG
PARAGUAY
PY
PERU
PE
PHILIPPINES
PH
PITCAIRN
PN
POLAND
PL
PORTUGAL
PT
PUERTO RICO
PR
QATAR
QA
REUNION
RE
ROMANIA
RO
Page 83 of 111
Country
PayPal Code
RUSSIAN FEDERATION
RU
RWANDA
RW
SAINT HELENA
SH
SAINT KITTS AND NEVIS
KN
SAINT LUCIA
LC
SAINT PIERRE AND MIQUELON
SAINT VINCENT AND THE GRENADINES
SAMOA
PM
VC
WS
SAN MARINO
SM
SAO TOME AND PRINCIPE
ST
SAUDI ARABIA
SA
SENEGAL
SN
SERBIA AND MONTENEGRO
CS
SEYCHELLES
SC
SIERRA LEONE
SL
SINGAPORE
SG
SLOVAKIA
SK
SLOVENIA
SI
SOLOMON ISLANDS
SB
SOMALIA
SO
SOUTH AFRICA
ZA
SOUTH GEORGIA AND THE SOUTH SANDWICH ISLANDS GS
SPAIN
ES
SRI LANKA
LK
SUDAN
SD
SURINAME
SR
SVALBARD AND JAN MAYEN
SJ
SWAZILAND
SZ
SWEDEN
SE
SWITZERLAND
CH
SYRIAN ARAB REPUBLIC
SY
TAIWAN, PROVINCE OF CHINA
TAJIKISTAN
TW
TJ
TANZANIA, UNITED REPUBLIC OF
THAILAND
TZ
TH
TIMOR-LESTE
TL
TOGO
TG
TOKELAU
TK
TONGA
TO
TRINIDAD AND TOBAGO
TT
TUNISIA
TN
TURKEY
TR
TURKMENISTAN
TM
TURKS AND CAICOS ISLANDS
TC
TUVALU
TV
UGANDA
UG
UKRAINE
UA
Page 84 of 111
Country
PayPal Code
UNITED ARAB EMIRATES
AE
UNITED KINGDOM
GB
UNITED STATES
US
UNITED STATES MINOR OUTLYING ISLANDS
URUGUAY
UM
UY
UZBEKISTAN
UZ
VANUATU
VU
VENEZUELA
VE
VIET NAM
VN
VIRGIN ISLANDS, BRITISH
VG
VIRGIN ISLANDS, U.S.
VI
WALLIS AND FUTUNA
WF
WESTERN SAHARA
EH
YEMEN
YE
ZAMBIA
ZM
ZIMBABWE
ZW
Page 85 of 111
22.2 RED Codes
The list of Country Code in ISO 3 digit format. This is only an example it's not
exhaustive of the actual standard.
ISO Code 3 digit
ABW
AFG
AGO
AIA
ALA
ALB
AND
ANT
ARE
ARG
ARM
ASM
ATA
ATF
ATG
AUS
AUT
AZE
BDI
BEL
BEN
BES
BFA
BGD
BGR
BHR
BHS
BIH
BLM
BLR
BLZ
BMU
BOL
BRA
BRB
BRN
BTN
BVT
BWA
CAF
CAN
CCK
CHE
CHL
CHN
Country
ARUBA
AFGHANISTAN
ANGOLA
ANGUILLA
Isole Åland
ALBANIA
ANDORRA
NETHERLAND ANTILLES
UNITED ARAB EMIRATES
ARGENTINA
ARMENIA
AMERICAN SAMOA
ANTARTIDE
TERRITORI FRANCESI DEL SUD
ANTIGUA AND BARBUDA
AUSTRALIA
AUSTRIA
AZERBAIJAN
BURUNDI
BELGIO
BENIN
Isole BES
BURKINO FASO
BANGLADESH
BULGARIA
BAHRAIN
BAHAMAS
BOSNIA HERZEGOVINA
Saint-Barthélemy
BELARUS
BELIZE
BERMUDA
BOLIVIA
BRASILE
BARBADOS
BRUNEI DARUSSALAM
BHUTAN
ISOLA DI BOUVET
BOTSWANA
REPUBBLICA CENTROAFRICANA
CANADA
ISOLE COCOS
SVIZZERA
CILE
CINA
Page 86 of 111
ISO Code 3 digit
CIV
CMR
COD
COG
COK
COL
COM
CPV
CRI
CUB
CUW
CXR
CYM
CYP
CZE
DEU
DJI
DMA
DNK
DOM
DZA
ECU
EGY
ERI
ESH
ESP
EST
ETH
FIN
FJI
FLK
FRA
FRO
FSM
GAB
GBR
GEO
GGY
GHA
GIB
GIN
GLP
GMB
GNB
GNQ
GRC
GRD
GRL
GTM
GUF
GUM
GUY
Country
COTE D.IVOIRE
CAMEROON,UNITED REP.
ZAIRE
CONGO
COOK ISLANDS
COLOMBIA
COMORE
CAPE VERDE IS.
COSTA RICA
CUBA
CURACAO
ISOLA DI NATALE
CAYMAN ISLANDS
CYPRUS
REPUBBLICA CECA
GERMANIA
GIBUTI
DOMINICA
DENMARK
REPUBBLICA DOMINICANA
ALGERIA
ECUADOR
EGITTO
ERITREA
SAHARA OCCIDENTALE
SPAGNA
ESTONIA
ETHIOPIA
FINLANDIA
FIJI
ISOLE FALKLAND
FRANCIA
ISOLE FAROE
STATI FEDERATI DELLA MICRONESIA
GABON
GRAN BRETAGNA
GEORGIA
Guernsey
GHANA
GIBRALTAR
GUINEA
GUADALUPA
GAMBIA
GUINEA-BISSAU
GUINEA EQUATORIALE
GREECE
GRENADA
GROENLANDIA
GUATEMALA
GUYANA FRANCESE
GUAM
GUYANA
Page 87 of 111
ISO Code 3 digit
HKG
HMD
HND
HRV
HTI
HUN
IDN
IMN
IND
IOT
IRL
IRN
IRQ
ISL
ISR
ITA
JAM
JEY
JOR
JPN
KAZ
KEN
KGZ
KHM
KIR
KNA
KOR
KWT
LAO
LBN
LBR
LBY
LCA
LIE
LKA
LSO
LTU
LUX
LVA
MAC
MAF
MAR
MCO
MDA
MDG
MDV
MEX
MHL
MKD
MLI
MLT
MMR
Country
HONG KONG
ISOLA HEARD E ISOLE MCDONALD
HONDURAS
CROAZIA
HAITI
HUNGARY
INDONESIA
ISOLA DI MAN
INDIA
Territorio Britannico Oceano Indiano
IRELAND
IRAN
IRAQ
ICELAND
ISRAEL
ITALIA
JAMAICA
Jersey
JORDAN
JAPAN
KAZAKHSTAN
KENYA
KYRGYZSTAN
KAMPUCHEA DEMOCRATIC
KIRIBATI
ST. KITTS-NEVIS
KOREA, REPUBLIC OF
KUWAIT
LAO PEOPLES DEMOCRATIC REPUBLIC
LIBANO
LIBERIA
LIBIA
SAINT LUCIA
LIECHTENSTEIN
SRI LANKA
LESOTHO
LITUANIA
LUSSEMBURGO
LATVIA
MACAU
Saint-Martin
MAROCCO
MONACO
MOLDOVA, REP. OF
MADAGASCAR
MALDIVES
MEXICO
ISOLE MARSHALL
MACEDONIA
MALI
MALTA
MYANMAR
Page 88 of 111
ISO Code 3 digit
MNE
MNG
MNP
MOZ
MRT
MSR
MTQ
MUS
MWI
MYS
MYT
NAM
NCL
NER
NFK
NGA
NIC
NIU
NLD
NOR
NPL
NRU
NZL
OMN
PAK
PAN
PCN
PER
PHL
PLW
PNG
POL
PRI
PRK
PRT
PRY
PSE
PYF
QAT
REU
ROU
RUS
RWA
SAU
SCG
SDN
SEN
SGP
SGS
SHN
SJM
SLB
Country
REPUBLIC OF MONTENEGRO
MONGOLIA
ISOLE MARIANNE SETTENTRIONALI
MOZAMBIQUE
MAURITANIA
MONTSERRAT
MARTINICA
MAURITIUS
MALAWI
MALAYSIA
MAYOTTE
NAMIBIA
NUOVA CALEDONIA
NIGER
ISOLA NORFOLK
NIGERIA
NICARAGUA
NIUE
NETHERLANDS
NORWAY
NEPAL
NAURU
NEW ZEALAND
OMAN
PAKISTAN
PANAMA
PITCAIRN
PERU
PHILIPPINES
PALAU
PAPUA NEW GUINEA
POLONIA
PUERTO RICO
COREA DEL NORD
PORTOGALLO
PARAGUAY
PALESTINA
POLINESIA FRANCESE
QATAR
REUNION
ROMANIA
RUSSIA
RUANDA
SAUDI ARABIA
SERBIA E MONTENEGRO
SUDAN
SENEGAL
SINGAPORE
SUD GEORGIA E ISOLE SANDWICH
SANT'ELENA
SVALBARD E JAN MAYEN
SOLOMON ISLANDS
Page 89 of 111
ISO Code 3 digit
SLE
SLV
SMR
SOM
SPM
SRB
SSD
STP
SUR
SVK
SVN
SWE
SWZ
SXM
SYC
SYR
TCA
TCD
TGO
THA
TJK
TKL
TKM
TLS
TON
TTO
TUN
TUR
TUV
TWN
TZA
UGA
UKR
UMI
UNK
URY
USA
UZB
VAT
VCT
VEN
VGB
VIR
VNM
VUT
WLF
WSM
YEM
ZAF
ZMB
ZWE
Country
SIERRA LEONE
EL SALVADOR
SAN MARINO
SOMALIA
SAINT PIERRE E MIQUELON
SERBIA AND MONTENEGRO
Sudan del Sud
SAO TOME E PRINCIPE
SURINAME
SLOVAK REPUBLIC
SLOVENIA
SVEZIA
SWAZILAND
SINT MAARTEN (DUTCH)
SEYCHELLES
SYRIAN ARAB REPUBLIC
TURKS AND CAICOS ISLANDS
CIAD
TOGO
THAILAND
TAJIKISTAN
TOKELAU
TURKMENISTAN
TIMOR EST
TONGA
TRINIDAD AND TOBAGO
TUNISIA
TURCHIA
TUVALU
TAIWAN PROVINCE OF CHINA
TANZANIA, UNITED REPUBLIC OF
UGANDA
UKRAINE
ISOLE MINORI DEGLI STATI UNITI D'AMERICA
UN INT ADMIN MISSION IN KOSOVO
URUGUAY
STATI UNITI
UZBEKISTAN
VATICAN CITY STATE (HOLY SEE)
SAINT VINCENT AND GRENADINES
VENEZUELA
VIRGIN ISLANDS BRITISH
VIRGIN ISLANDS U.S.
VIET NAM
VANUATU
WALLIS E FUTUNA
SAMOA
YEMEN
SUD AFRICA
ZAMBIA
ZIMBABWE
Page 90 of 111
23 Table of Payment Type Codes
Table of the Payment Type available at the moment in GestPay.
Payment Type Code
Description
BON
CREDITCARD
PAYPAL
MYBANK
UPMOBILE
MASTERPASS
CONSEL
S2PALI
S2PKLA
S2PQIW
S2PYAN
S2PSOF
S2PIDE
COMPASS
SOFORT
IDEAL
Money Transfer
Credit Card
PayPal
MyBank
Mobile - QRCode
MasterPass
Consel
ALIPAY (Alternatives)
KLARNA (Alternatives)
QIWI (Alternatives)
YANDEX (Alternatives)
SOFORT (Alternatives)
IDEAL (Alternatives)
COMPASS C-PAY
SOFORT
IDEAL
Page 91 of 111
24 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 profiles
IP Address
Server-to-server Communication Url
Url for positive responses
Url for negative responses
E-mail for sending OK result
E-mail for sending KO result
E-mail for sending information
171.85.234.97
http://www.myshop.com/s2s.asp
http://www.myshop.com/respOK.
asp
http://www.myshop.com/respKO.
asp
[email protected]
[email protected]
[email protected]
Page 92 of 111
24.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 required to complete the
payment in protected (SSL 2048-bit) mode.
The transaction to process has the following characteristics:
Merchant’s Transaction
Shop Transaction ID
Transaction Amount
Currency Transaction
34az85ord19
1828.45
euro
Let us suppose that the transaction is concluded positively (payment will be
made), returning the following result:
Result
Authorisation code
Bank transaction ID
54e813
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
Page 93 of 111
Phase I
Using the Encrypt method of web service WSCryptDecrypt, the merchant’s has
to set:
<Encrypt>
<shopLogin>9000001</shopLogin>
<uicCode>242</uicCode>
<amount>1828.45</amount>
<shopTransactionId>34az85ord19</shopTransactionId>
</Encrypt>
GestPay authenticates the calling server and validates the information
characterising the transaction. If the checks are passed, it returns an encrypted
string to GestPay:
<DecryptResult>
<GestPayCryptDecrypt xmlns="">
<TransactionType>ENCRYPT</TransactionType>
<TransactionResult>OK</TransactionResult>
<CryptDecryptString>2C53F1B5...</CryptDecryptString>
<ErrorCode>0</ErrorCode>
<ErrorDescription/>
</GestPayCryptDecrypt>
</DecryptResult>
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/pagam/pagam.aspx?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..............
Page 94 of 111
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.ction
of buyer’s client
The transaction result is also communicated to the merchant via e-mail.
Phase IV
GestPay communicates the transaction result to the merchant, sending an
encrypted data string. Using the Decrypt method of web service Using the
Decrypt method of the WSCryptDecrypt web service, the merchant must request
the string decryption service to interpret the transaction result correctly and
update the information in his/her own information system, this allowing the buyer
to complete the purchasing process.
<Decrypt>
<CryptedString>4D341A8B....</CryptedString>
</Decrypt>
GestPay authenticates the calling server and the integrity of the encrypted data
string. If the controls are passed, it returns the unencrypted information via XML
allowing the merchant to interpret the transaction result correctly:
<DecryptResult>
<TransactionType>DECRYPT</TransactionType>
<ShopTransactionID>34az85ord19</ShopTransactionID>
<BankTransactionID>216</BankTransactionID>
<AuthorizationCode>58e813</AuthorizationCode>
<Currency>242</Currency>
<Amount>1828.45</Amount>
<ErrorDescription>Transazione correttamente effettuata
</ErrorDescription>
</DecryptResult>
Page 95 of 111
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.
Transaction
Shop Transaction ID
Transaction Amount
Buyer’s Name and Surname
Buyer’s E-mail Address
Customised info 1
Customised info 2
34az85ord19
1245.6
Euro
Mario Bianchi
[email protected]
BV_CODCLIENTE=12
BV_SESSIONID=398
We shall assume that the transaction is concluded positively (payment is made),
reporting the following result:
Result
Authorisation code
Bank transaction ID
9823y5
860
The following pages describe each individual phase that makes up the payment
process, highlighting the information exchanged between GestPay and the
Page 96 of 111
Phase I
The merchant’s server communicates the information that characterises the
transaction to GestPay, setting the value of the WSCryptDecrypt web service
attributes:
<Encrypt>
<amount>1245.6</amount>
<buyerName>Mario Bianchi</buyerName>
<buyerEmail>[email protected]</buyerEmail>
<customInfo>BV_CODCLIENTE=12*P1*BV_SESSIONID=398</customInfo>
</Encrypt>
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:
<DecryptResult>
<CryptDecryptString>30715CA8...</CryptDecryptString>
<ErrorDescription/>
</DecryptResult>
Phase II
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/pagam/pagam.aspx?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.
Page 97 of 111
Phase III
After processing the transaction, GestPay communicates the transaction result
(encrypted data string) to the merchant.
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.
Phase IV
encrypted data string. Using the WSCryptDecrypt web service , 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 WSCryptDecrypt web service.
<Decrypt>
<CryptedString>F45E129A....</CryptedString>
</Decrypt>
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:
<DecryptResult>
<AuthorizationCode>9828y5</AuthorizationCode>
<Amount>1245.6</Amount>
<CustomInfo>BV_CODCLIENTE=12*P1*BV_SESSIONID=398</CustomInfo>
Page 98 of 111
<ErrorDescription>Transazione correttamente effettuata
</ErrorDescription>
</DecryptResult>
Page 99 of 111
The merchant decides to communicate to GestPay not only the information that
is indispensable to allow the buyer to make the payment, but also request a
token to operate with the tokenization function.
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.
Transaction
Shop Transaction ID
Transaction Amount
requestToken
34az85ord19
985
Euro
MASKEDPAN
To fill and pass the requestToken parameter the merchant has to activate it in
the "Fields and parameters" section of Back Office Merchant.
We shall assume that the transaction is concluded positively (payment is
made), reporting the following result:
Result
Authorisation code
Bank transaction ID
8754p2
656
The following pages describe each individual phase that makes up the payment
process, highlighting the information exchanged between GestPay and the
Phase I
attributes:
<Encrypt>
<amount>985</amount>
<requestToken>MASKEDPAN</requestToken>
</Encrypt>
characterises the transaction. If the controls are passed, it returns an
Page 100 of 111
encrypted string to GestPay:
<DecryptResult>
<CryptDecryptString>897543..</CryptDecryptString>
<ErrorDescription/>
</DecryptResult>
Phase II
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/pagam/pagam.aspx?a=9000001&b=897543....................
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.
http://www.myshop.com/s2s.asp?a=9000001&b=HT987YU..............
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.
http://www.myshop.com/respOK.asp?a=90000011&b= HT987YU.............
The transaction result is also communicated to the merchant and the buyer
via e-mail.
Page 101 of 111
Phase IV
encrypted data string. Using the WSCryptDecrypt web service, the merchant
<Decrypt>
<CryptedString>HT987YU....</CryptedString>
</Decrypt>
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:
<DecryptResult>
<AuthorizationCode>876TY5</AuthorizationCode>
<Amount>985</Amount>
<TOKEN>47MRWNGIYB6F9015</TOKEN>
<ErrorDescription>Transazione
correttamente
effettuata
</ErrorDescription>
</DecryptResult>
Page 102 of 111
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
shipping information useful to activate the Seller Protection option on the
transaction.
data necessary to complete the payment in protected mode (128–bit SSL).
Transaction
Shop Transaction ID
Transaction Amount
ppSellerProtection
shipToName
shipToStreet
shipToCity
shipToState
shipToCountryCode
shipToZip
shipToStreet2
34az85ord19
985
Euro
1
Marco Bianchi
Via Milano 1
Torino
Torino
IT
10100
--
To fill and pass the PayPal Seller Protection parameters the merchant has to
activate them in the "Fields and parameters" section of Back Office Merchant.
Result
Authorisation code
Bank transaction ID
8754p2
656
The following pages describe each individual phase that makes up the
payment process,
highlighting the information exchanged
between
GestPay and the merchant’s server.
Page 103 of 111
Phase I
attributes (the merchant has to have enabled the fields from Fields and
Parameters Function par.12.3.2):
<Encrypt>
<ppSellerProtection>1</ppSellerProtection>
<shippingDetails>
<shipToName>Marco Bianchi</shipToName>
<shipToStreet>Via Milano 1</shipToStreet>
<shipToCity>Torino</shipToCity>
<shipToState>Torino</shipToState>
<shipToCountryCode>IT</shipToCountryCode>
<shipToZip>10100</shipToZip>
<shipToStreet2/>
</shippingDetails>
</Encrypt>
<DecryptResult>
<CryptDecryptString>897543..</CryptDecryptString>
<ErrorDescription/>
</DecryptResult>
Phase II
process.
Payment page Url
https://ecomm.sella.it/pagam/pagam.aspx?a=9000001&b=897543....................
Page 104 of 111
communicated.
Phase III
http://www.myshop.com/s2s.asp?a=9000001&b=HT987YU..............
process.
http://www.myshop.com/respOK.asp?a=90000011&b= HT987YU.............
via e-mail.
Phase IV
<Decrypt>
<CryptedString>HT987YU....</CryptedString>
</Decrypt>
<DecryptResult>
Page 105 of 111
<AuthorizationCode>983RT4</AuthorizationCode>
correttamente
</ErrorDescription>
</DecryptResult>
effettuata
Page 106 of 111
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
additional information useful to activate the RED Fraud Prevention option on
the transaction.
data necessary to complete the payment in protected mode (128–bit SSL).
Transaction
Shop Transaction ID
Transaction Amount
redFraudPrevention
Customer_Name
Customer_Surname
NumberOfItems
Item_ProductCode
Item_ProductCode
34az85oer5676
200
Euro
1
Mario
Rossi
2
23467
89754
To fill and pass the PayPal Seller Protection parameters the merchant has to
activate them in the "Fields and parameters" section of Back Office Merchant.
Result
Authorisation code
Bank transaction ID
5r4567
456
The following pages describe each individual phase that makes up the
payment process,
highlighting the information exchanged
between
GestPay and the merchant’s server.
Page 107 of 111
Phase I
attributes (the merchant has to have enabled the fields from Fields and
Parameters Function par.12.3.2):
<Encrypt>
<shopTransactionId>34az85oer5676</shopTransactionId>
<redFraudPrevention>1</redFraudPrevention>
<Red_CustomerInfo>
<Customer_Name>Mario</Customer_Name>
<Customer_Surnamet>Rossi</Customer_Surname>
</Red_CustomerInfo>
<Red_Items>
<NumberOfItem>2</NumberOfItem>
<Red_Item>
<Item_ProductCode>23467</Item_ProductCode>
</Red_Item>
<Red_Item>
<Item_ProductCode>89754</Item_ProductCode>
</Red_Item>
</Red_Items>
</Encrypt>
<DecryptResult>
<CryptDecryptString>swqdqwdasdadiqwidk*****.....</CryptDecryptString>
<ErrorDescription/>
</DecryptResult>
Phase II
process.
Page 108 of 111
Payment page Url
https://ecomm.sella.it/pagam/pagam.aspx?a=9000001&b=swqdqwdasd..............
communicated.
Phase III
http://www.myshop.com/s2s.asp?a=9000001&b=edrftyy7..............
process.
http://www.myshop.com/respOK.asp?a=90000011&b= edrftyy7.............
via e-mail.
Phase IV
<Decrypt>
<CryptedString>edrftyy7 ....</CryptedString>
</Decrypt>
Page 109 of 111
<DecryptResult>
<ShopTransactionID>34az85oer5676</ShopTransactionID>
<AuthorizationCode>5r4567</AuthorizationCode>
correttamente
effettuata
</ErrorDescription>
<RedResponseCode>CHALLENGE</RedResponseCode>
<RedResponseDescription>Transaction challenged due to a hit on a
suspicious
database.</RedResponseDescription>
</DecryptResult>
Page 110 of 111
25 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.
Page 111 of 111

376\377\000G\000e\000s\000t\000P\000a\000y\000_

Transcription

Similar documents

RE/MAX vs. THE INDUSTRY

Morgan Stanley Smith Barney Benefit Access Quick

Harborstone Credit Union

instructions for housing deposit ($250.00 usd)

How to Pay My Bill - Students and Authorized Payers

Natalie Merchant - Charlotte Symphony Orchestra

Rules Concerning Ribā Q1605: A driver was interested in buying a

Currency exchange via Traderoom sectionin Swedbank Internet

KO Brocks Bostitch Drive Event 022516f

TCPDF Example 021