This is simply the payment operation. It consists in sending all of the information required to make a payment transaction to the bank’s server. It also consists in retrieving the transaction result after it has been processed by the bank.
WSs2s method to use for this purpose is
However, before using this method, it is necessary to assign a value to all the required information, for the passage of the parameters:
shopTransactionId(Transaction ID Code)
cardNumber(Credit Card Account Number)
expiryMonth(Card Expiration Month)
expiryYear(Card Expiration Year)
The following features may optionally be assigned, upon appropriate configuration of the Client configuration | Fields & Parameters section:
buyerEmail(Buyer’s e-mail address)
cvv(String containing the Card Verification Value printed on the credit card as specified in the chapter “Handling of CVV field”)
transKey(check the Verified by Visa Transactions paragraph)
PARes(check the Verified by Visa Transactions paragraph)
customInfo(String containing possible customised fields, declared “Parameters” in the relevant section of the Back Office environment , BackOffice -> PaymentPage -> Fields&Parameters)
MASKEDPANfor a Standard Token, any other value for Custom Token)
TokenValue(Token used for the transaction, in case of PayPal Billing Agrrements is the token provided by PayPal. If a merchant belongs to a group can use a own token or also one of token of the group’s components)
ClientIP(For PayPal Billing Agreements it is required only in the “one click” mode transaction For AMEX transaction not in Euro, in this filed the merchant could provide the ClientIP address to activate the Enhanced Authorization AAV )
CallPagamS2S method sends GestPay all previously assigned data; GestPay checks the correspondence between data received and the configuration set within the Back Office environment, and, if these match, it will operate.
If the M.O.T.O. configuration anticipates a separation between the authorisation and the settlement phase, the activity of GestPay will be limited to the authorisation request only. Checkout the Settlements page to understand how it works.
If, conversely, the M.O.T.O. configuration anticipates that the authorisation and the settlement phase will occur simultaneously, then GestPay will make the authorisation request and, if the response is positive, subsequently perform the settlement operation.
CallPagamS2S method is performed, it is possible to know the outcome of the transaction by using the returned XML file:
<GestPayS2S xmlns=""> <TransactionType>PAGAM</TransactionType> <TransactionResult>OK</TransactionResult> <ShopTransactionID>prova2</ShopTransactionID> <BankTransactionID>65</BankTransactionID> <AuthorizationCode>365530</AuthorizationCode> <Currency>242</Currency> <Amount>0.90</Amount> <Country>ITALIA</Country> <Buyer> <BuyerName/> <BuyerEmail/> </Buyer> <CustomInfo/> <TDLevel/> <ErrorCode>0</ErrorCode> <ErrorDescription>Transazione correttamente effettuata</ErrorDescription> <AlertCode/> <AlertDescription/> <TransactionKey>579428899</TransactionKey> <VbV> <VbVFlag>KO</VbVFlag> <VbVBuyer/> <VbVRisp/> </VbV> </GestPayS2S>
TransactionResult which will return a string
OK if the transaction was authorised or a string
KO if the transaction was not authorised.
KO, by using the
ErrorCode value it is then possible to know whether the failure is caused by technical problems or by a denied authorisation by the credit card network:
ErrorCodereturns a <> 0 value, the authorization of the transaction was negative; the returned value will be different according to the specific reason for the failure.
ErrorDescriptionvalue will return a description (in the language set in the Back Office environment) of the reason for the failure.
OK, the transaction was authorised (and, if the M.O.T.O. was simultaneous, settled as well). It will be then possible to obtain further information about the transaction, using the following values:
BankTransactionIDto obtain the unique code assigned to the transaction by GestPay
AuthorizationCodeto obtain the authorisation code assigned to the transaction by the international credit card network
AlertCode(and the corresponding
AlertDescription) in the case which Risk Management criteria were set through BackOffice and the transaction violated one of them; if no Risk Management criteria were violated,
AlertCodewill be empty.
CustomInforeturns the CustomInfo tag passed during the transaction
TDLevelLevel of authentication for 3D-Secure transactions. The string may have the value
VBVReturns the values for VbV as follows:
VBVFlagReturns the flag Verified by Visa (
VBVBuyerReturns the flag Full Verified by Visa transaction
VBVRispReturns the encrypted string obtained by Visa directory
All the other returned values can be used as usual.