1. Table of Contents Preface About this Document About Xt-payments... Error! Bookmark not defined.

Transcription

1 1. Table of Contents 1. Table of Contents Preface About this Document About Xt-payments... Error! Bookmark not defined About the Public Payment Page (PPP) Terms Used in this Guide PPP Workflow Creating the HTTP Request The minimum required parameters Input checksum parameter algorithm Submitting an HTTP Request Using a Browser Sending an HTTP Request in a Full Production Mode A sample PHP Script Handling the PPP Response The output parameters The output checksum parameters Appendix I: Input Parameters Tables Table 1: Merchant Details Table 2: Merchant Site Details Table 3: Item Details... 16

2 7.4. Table 4: Credit Card Details Table 5: Customer Details Table 6: Other Parameters Table 7: Navigation parameters Table 8: Merchant custom fields Appendix II: Output Parameters Tables Table 9: Transaction parameters Table 10: Payment parameters Table 11: General items info parameters Table 12: Specific items info parameters Table 13: Other parameters Table 14: General Response Codes Table 15: Filter error codes Table 16: Decline Reasons Appendix III: General Parameters Tables Table 17: Currencies Table Payment Page example skins... 26

3 3. Preface 3.1. About this Document This document is intended for Merchants wishing to integrate and use the xt-payments Public Payment Page (PPP) system in their web sites. It contains detailed information on the full online purchase chain of events, the data transferred in the process and the outcome of each event. The guide also contains description of the PPP s API (Application Programming Interface) required for sending information to the PPP and receiving and understanding the PPP s response About the Public Payment Page (PPP) The Public Payment Page (PPP) is a customized web page provided by xt-payments, intended to enable Merchants selling products and services over the web to process online Customer Transactions as simply and effortlessly as possible. The PPP provides a web page which receives the purchase details as provided by the Customer in the Merchant s web site, asks and receives the payment details directly from the Customer and then performs the payment process itself. According to the process result the PPP then redirects the Customer to the relevant next page to conclude the purchase process (or reiterate it, if needed) Terms Used in this Guide For the purpose of creating a common language in reading this guide and when contacting xt-payments personnel, these are the terms used in this guide: Transaction: The exchange of a product or a service provided by a seller (the Merchant) for a payment, provided by a buyer (the Customer).

4 Also: in xt-payments terms, a Transaction is the request made to the xt-payments server using the HTTPS request. Merchant: a client of xt-payments which uses the PPP as its payment page for processing Transactions. Customer: the individual purchasing the product/service from the Merchant via its web site. Merchant s Web Site: the web site accessed by the Customer to purchase the product/service. Chargeback: a process in which due to an illegitimate use of a credit card or an erroneous payment process, the bank involved in the Transaction process initiates a Transaction refund, transferring the original Transaction s funds back from the Merchant to the Customer s Issuer bank. Payment process: the process where the xt-payments server arranges for the payment to transfer from the Customer s credit card/account to the Merchant s account. Checksum: a string of characters, letters and numbers, which is the encoded reflection of a valid data. 4. PPP Workflow Following is the PPP workflow, from Customer purchase to final processing. 1. Purchase the Customer enters the Merchant s web site and selects products/services to purchase, updating quantities and personal details. 2. Redirecting once all details are entered and the payment stage is reached, the Merchant s web page is required to redirect the Customer to the PPP (for example: using a Purchase button). 3. Payment Details Entry once inside the PPP, the Customer is required to fill in the full credit card payment details (fields) and approve the purchase. Note: A Merchant may choose to remove a number of fields from this page. This can only be done by a special customization process. Consult xt-payments personnel. 4. Charging/Processing the actual funds transfer from the Customer s Issuer bank to the Merchant s bank, processed by Xt-payments.

5 5. Redirecting Once the charging process is concluded, the PPP redirects the Customer back to a page at the Merchant s site as per the transaction s result - a successful Transaction will lead to a Success Page, a failed or canceled Transaction will lead to a Failure Page while a suspended Transaction (Customer clicking BACK ) will lead to a Back Page. 6. Final Processing based on the outcome of the payment process, the Merchant s web site processes the response and, once finished, resumes normal operation. 5. Creating the HTTP Request Once a Customer decides on a purchase and enters its details, the Merchant s web site redirects him/her to the PPP. At the same time it is also required to send, using an HTTP POST method, an HTTPS request to the PPP containing the required parameters for the Transaction to take place. An HTTPS request is basically the line typed into the web browser s address bar to access a web page (for example: The PPP utilizes this functionality in an automated mode to enable the Merchant to send Transactions data to its URL address. Testing this ability is done in a manual mode using an HTTP GET request. However, to send an HTTP request to the PPP in a full production (working) mode, the Merchant s web application must use an HTTP POST call. Both requests must be in the following format:

6 Where: - is the address of the server and the command to accept the upcoming parameters. It is always followed by a list of parameters and their values. <Parameter> - is the name of the parameter, as listed in the chapter Appendix I: Input Parameters Tables on page 14. <Value> - is the value of the parameter. The ampersand ( & ) symbol a separator between one parameter (and its value) and the next. The full list of parameters is found in the Appendix I: Input Parameters Tables chapter on page The minimum required parameters Following is a list of the minimum parameters the Merchant s web site is required to provide the PPP (using the HTTP request) to enable the PPP to process the Transaction: Merchant Id (merchant_id) the Merchant s unique identification number as provided by Xt-payments. Merchant Site Id (merchant_site_id) the Merchant s web site s unique identification number as provided by Xt-payments. This parameter is specifically useful for Merchants operating more than one web site and using the same xtpayments account. Total amount (total_amount) total Transaction charge. Currency (currency) the currency used in the Transaction. See the Table 17: Currencies Table on page 26. Items list: a numbered list of all items purchased in the sent Transaction. Each item requires 3 parameters: o Name (item_name_n) the name of item number N. o Amount (item_amount_n) the price of item number N. o Quantity (item_quantity_n) the quantity of item number N. Timestamp (time_stamp) current GMT time in the following format: YYYY-MM-DD.HH:MM:SS. Request version (version) currently HTTP POST requests use version=3.0.0 Checksum the Transaction s checksum. See the Input Checksum section below.

7 Example: Using the following values: merchant_id= merchant_site_id=37501 total_amount=15 currency=usd item_name_1=ball item_amount_1=15 item_quantity_1=1 time_stamp= :04:26 version=3.0.0 checksum=(see below) The HTTP request will look like this: &time_stamp= :12:50&total_amount=10&currency=EUR&checksum=8c58e5fa6689b65e2ace0c3c4089b617 &item_name_1=test product&item_amount_1=10&item_quantity_1=1&version=3.0.0 Attention: never insert your secret key in an HTTP request. Instead, it should be used as a component in the checksum s calculation. Sending it in the HTTP request may compromise your security, opening your business to outside web attacks.

8 5.3. Input checksum parameter algorithm To avoid data confusion and corruptness and ascertain its integrity, an MD5 checksum value is calculated and added as a parameter to the Transaction HTTP request. The checksum is unique to each Transaction. One option for checking the MD5 checksum calculation is to use an online tool such as However, for the purpose of running in full production, an MD5 calculator must be integrated into the Merchant s web application to allow the automatic calculation of the Checksum for the creation of the HTTPS POST request. To calculate a checksum using the md5-hash-online site: 1. Create a constant (no spaces) string made up of the values of the following parameters in the exact order listed below: o o o o o o Secret Key Merchant id Currency Total amount Item list (item_name_1, Item_amount_1, item_quantity_1 to item_name_n, Item_amount_N, item_quantity_n) Timestamp 2. Copy the created string into the web site s calculator input box and click the Calculate MD5 hash button. Wait for the calculated checksum to appear in the input box. 3. Insert the result checksum to its place in the HTTP request line.

9 Example: The string made up of the values used in the above example and a sample secret key (fmirgj1npkjqjjjucsgesel4bvfrijjn3j7xpucwldsgtotyrvdkiledgg05nbht) and item_quantity_1 (1) would be: xl0azgqlnkvuxjutxkcxii4oxsj5dx3ljxohh8nywosfakp0na721dodh880audt EUR10test product :12:50 The calculated checksum would then be: 8c58e5fa6689b65e2ace0c3c4089b617 The full HTTP request using these values would therefore be: &time_stamp= :12:50&total_amount=10&currency=EUR&checksum=8c58e5fa6689b65e2ace0c3c4089b617 &item_name_1=test product&item_amount_1=10&item_quantity_1=1&version= Submitting an HTTP Request Using a Browser Before fully integrating an HTTP POST process, it is recommended to test the created HTTP request string by sending it via a web browser s address bar. To run the HTTP GET request in a web browser: 1. Open a web browser and copy the HTTP request created in the previous chapter into the address bar. 2. Click Enter to run the request. A valid HTTP GET request will cause the browser to open the first page of the PPP, as shown below.

10 Figure 1: PPP's Order Page

11 6. Sending an HTTP Request in a Full Production Mode Once the manual processing of an HTTP GET request is performed (as described in the previous chapter), it is time to develop the process which will perform this and the checksum calculation automatically and in real time. The languages and platforms which can be used are PHP, Java, and.net. Attention: do not use JavaScript or any other client-server languages as you may run the risk of comprising your secret key. Attention: in order for xt-paymentsto accept and process the HTTP request, the vendor must in all cases provide the referrer domain. For security reasons xt-payments is not accepting requests from any or unknown referrer A sample PHP Script Following is a sample of a simple PHP script which may be used to send the HTTP request. To run this script, a PHP environment is required. Consult your web developers if needed. <?php header("location: "." version=3.0.0&merchant_id=<your_merchant_id>&merchant_site_id=<your_merchant_site_id>&total_amou nt=<total_amount>&currency=<currency>&item_name_1=<item_name_1>&item_amount_1=<item_amount _1>&item_quantity_1=<item_quantity_1>&time_stamp=<current_time>&checksum=<calculated_checksum> ");?>

12 8. Handling the PPP Response The payment process has three outcomes: 1. Transaction was approved and successfully completed: the Customer s browser is redirected to the Merchant s Success Page. 2. Transaction was cancelled by the Customer, one option being the Customer clicking the CANCEL button: the Customer s browser is redirected to the Merchant s Failure Page. 3. Transaction failed due to wrong/invalid data or an authorization failure: the Customer s browser is redirected to the Merchant Failure Page The output parameters Once the PPP concludes its work, it redirects the Customer s browser to one of the above-listed pages. At the same time, it uses HTTP GET to also send a set of parameters back the Output parameters. The sent parameters are divided into four (4) groups: 1. Transaction Parameters the parameters of the transaction originally sent to the PPP and the parameters of the outcome of the PPP s work (including the responsechecksum). 2. Payment Parameters the unprotected payment method information, as updated by the Customer in the PPP (name on card, expiration data, the last four digits of the credit card number, token, etc.). 3. Customer Details the Customer s personal information, as updated by the Customer in the PPP the first and last name, the address, the contact details, etc. 4. Other Parameters Merchant custom fields and other miscellaneous parameters.

13 The full list of output parameters is found in the Appendix II: Output Parameters Tables chapter on page The output checksum parameters There are two parameters - responsechecksum and advanceresponsechecksum. They contain checksum numbers, which enables validating the received using different data. Attention: The advanceresponsechecksum check is mandatory, and the responsechecksum check is optional. Implementing a mechanism which checks the responsechecksum and advanceresponsechecksum blocks the option to enter the PP, submit a failed Transaction (invalid CC number, declined/fraudulent Transaction, etc.) and then manipulate the Failure response URL string so as to get redirected to the Success page without actually submitting any payment (thus obtaining the service/product without actually paying for it). Use an MD5 process to calculate the output responsechecksum parameter using the values of the following output parameters in the exact order in which they are listed: Secret key Gateway Transaction Id Error Code Extended Error Code Status Use an MD5 process to calculate the output advanceresponsechecksum parameter using the values of the following output parameters in the exact order in which they are listed: Secret key totalamount currency responsetimestamp PPP_TransactionID Status productid

14 If the calculated checksum is equal to the responsechecksum or advanceresponsechecksum (depends which is used) output parameters, the output parameters are authenticate. If not, the Merchant is required fail the Transaction and redirect the Customer s web browser to the Failure page. Example: The string made up of the values used in the above example and a sample secret key (AJHFH9349JASFJHADJ9834) and item_quantity_1 (1) would be: AJHFH9349JASFJHADJ USD :22: APPROVEDYourProduct The calculated checksum would then be: 826fb8c4a2451e86f41df511c46f5a9b

15 9. Appendix I: Input Parameters Tables Following are tables containing the full list and description of all parameters available for the Merchant to send to the PPP via its HTTP request. Note: When making the actual HTTP request to xt-payments, all numeric input parameters must be presented as Strings. Attention: All parameters are case sensitive and must be in lower case Table 1: Merchant Details Parameter Type Size Mandatory Description merchant_id Number 64bits Yes merchant_unique_id String Char(64) No merchant_site_id Number 64bits Yes The Merchant s unique identification number as provided by xt-payments. The unique ID (identifier) of the Transaction in the Merchant s database. The Merchant s web site s unique identification number as provided by Xt-payments. This parameter is specifically useful for Merchants operating more than one web site using the same xt-payments account Table 2: Merchant Site Details Parameter Type Size Mandatory Description customsitename String Char(50) No The Merchant s Site name which should replace the default MerchantSite name. This parameter is specifically useful for Merchants operating with a lot of web sites which distinguish only by a name.

16 9.3. Table 3: Item Details Parameter Type Size Mandatory Description numberofitems Number 32bits Per need Number of items to process. Default value is 1. item_name_n* String Char(400) Yes The name of item number N** item_number_n String Char(400) Yes item_amount_n Double 64 bits Yes Item_shipping_N Double 64 bits No item_handling_n Double 64 bits No item_discount_n Double 64 bits No item_quantity_n Number 64 bits Yes The first part of the items list the serial number. Counted from iten_number_1 to item_number_n. The cost of the item numbered in the item_number_n parameter Shipping costs of the item numbered in the item_number_n parameter Handling costs of the item numbered in the item_number_n parameter Discount rate of the item numbered in the item_number_n parameter Number of pieces of the item numbered in the item_number_n parameter. Default value is 1. discount Double 64 bits No The total discount out of the total amount. shipping Double 64 bits No Total shipping costs. handling Double 64 bits No Total handling costs. total_amount Double 64 bits Yes Total transaction charge. total_tax Double 64 bits No Total taxes. *** productid String Char(50) No * N represents the item count number. The first item is item_name_1 up to item_name_n. ** Currently item names can only include ISO character set encoding. *** For statistics use only. Merchant s product ID. If this parameter is left empty, PPP will insert a concatenation of all item names. ***

17 9.4. Table 4: Credit Card Details Parameter Type Size Mandatory Description cc_card_number String Char(20) For Token usage* Credit card number. cc_name_on_card String Char(70) No The name on the credit card. cc_exp_year Number 2 digits No Credit card expiration year (YY format). cc_exp_month Number 2 digits No Credit card expiration month (MM format). cc_cvv2 Number 3/4 digits No CVV2 number of the credit card. dc_start_month Number 2 digits No Debit card expiration year (YY format) dc_start_year Number 2 digits No Debit card expiration month (MM format) dc_issue_number Number 2 digits No Debit card issue number (similar to cvv2). * When token used it is mandatory to include the masked card number 9.5. Table 5: Customer Details Parameter Type Size Mandatory Description first_name String 30 No Customer s first name. last_name String 40 No Customer s last name. String 100 No Customer s address. address1 String 60 No Customer s address. address2 String 60 No Customer s address. city String 30 No Customer s city. country String 20 No Customer s country. state String 20 No Customer s state. zip String 18 No Customer s zip code. phone1 String 18 No Customer s phone1. phone2 String 18 No Customer s phone2. phone3 String 18 No Customer s phone3.

18 9.6. Table 6: Other Parameters Parameter Type Size Mandatory Description version String Char(10) Yes Insert for HTTP POST Transaction s checksum. See the checksum String Char(102400) Yes time_stamp String Char(19) Yes currency String Char(3) Yes invoice_id String Char(400) No Input checksum section on page 8. Current GMT time in the following format: YYY-MM-DD.HH:MM:SS. The currency used in the Transaction. See the Table 17: Currencies Table on page 26. A unique invoice identifier provided by the Merchant or randomly generated. payment_method String Char(256) No Credit card name or Giropay. Set the join page to a default specific language (current default value is English). Values can be: merchantlocale String Char(5) No English Italian Spanish French Hebrew German Arabic Russian Dutch Bulgarian Czech Japanese Korean Turkish Portuguese en_us it_it Es_ES fr_fr iw_il de_de ar_aa ru_ru nl_nl bg_bg zh_cn ja_jp ko_kr tr_tr pt_br userid String Char(50) No The customer s ID as per the

19 customdata String Char(255) No encoding String Char (20) No webmasterid String Char(255) No Merchant s UserID. General data about the Customer provided by the Merchant. Character encoding. Default value is ISO Affiliate parameter - additional parameter which merchant can send to PPP Table 7: Navigation parameters Parameter Type Size Mandatory Description skip_billing_tab String No skip_review_tab String No A switch (true, false) indicating whether or not to skip the PPP s billing page *. A switch (true, false) indicating whether or not to skip the PPP s review page. * If some of the page s mandatory parameters are missing, the Customer s browser will be redirected to the Cancel Page URL Table 8: Merchant custom fields Parameter Type Size Mandatory Description customfield1 String Char(64) No customfield2 String Char(64) No customfield3 String Char(64) No customfield4 String Char(64) No customfield5 String Char(64) No customfield6 String Char(64) No customfield7 String Char(64) No customfield8 String Char(64) No customfield9 String Char(64) No customfield10 String Char(64) No customfield11 String Char(64) No customfield12 String Char(64) No customfield13 String Char(64) No customfield14 String Char(64) No customfield15 String Char(64) No Custom fields for the Merchant to update miscellaneous data. Is sent to the PPP in the HTTP response and sent back in its response.

20 10. Appendix II: Output Parameters Tables These are the parameters sent by the PPP back to the Customer s browser upon the completion of a payment process Table 9: Transaction parameters Parameter Status totalamount TransactionID ClientUniqueID ErrCode Explanation Status of the executed transaction: APPROVED, DECLINED, etc. Total transaction charge. A 32-bit unique integer ID generated by our system, used for tracking purposes. Custom data parameter. If parameter not specified the default value is the name of the vendor s account. The error code of a failed transaction, where relevant. See the Table 14: General Response Codes section on page 22. ExErrCode The extended error code of a failed transaction, where relevant. See the on page 22. AuthCode The authentication code received by the Gateway for the Transaction. The reason for a failed transaction, where relevant. See Reason Token Table 16: Decline Reasons on page 25. The token of the credit card that was returned by the Xt-payments server. The failed Transaction s reason s code, where relevant. See ReasonCode

21 Table 16: Decline Reasons on page 25. responsechecksum See The output checksum parameter section on page 13 advanceresponsechecksum See The output checksum parameter section on page 13.

22 10.2. Table 10: Payment parameters Parameter nameoncard currency Explanation The name on the credit card. The currency used in the transaction Table 11: General items info parameters This table lists the financial parameters related to all items purchased in the Transaction. Parameter total_discount total_handling total_shipping total_tax Explanation Total discount for current order. Total handling for current order. Total shipping for current order. Total tax for current order Table 12: Specific items info parameters This table lists the parameters sent back in the xt-paymentsresponse regarding the individual items purchased in the relevant Transaction. Parameter item_number_n item_amount_n item_quantity_n item_discount_n item_handling_n item_shipping_n Explanation The number of item number N The cost of item number N The quantity of item number N The discount for item number N The handling costs for item number N The shipping costs for item number N

23 10.5. Table 13: Other parameters Parameter customdata merchant_unique_id merchant_site_id merchant_id requestversion message Error PPP_TransactionID UserID ProductID ppp_status merchantlocale unknownparameters Explanation Custom data sent to the PPP The Merchant_unique_id value as provided by the Merchant to the PPP in the HTTP request. The unique ID (identifier) of the Transaction in the Merchant s database as provided by the Merchant to the PPP in the HTTP request. The unique Merchant id supplied by Xt-payments. The processed PPP request s version. A message sent from the PPP regarding the transaction. An error message sent from the PPP, where relevant. The ID number of the Transaction s history table in the PPP database. The UserID value transferred by the Merchant in the PPP HTTP request. The purchased product s ID as provided by the Merchant to the PPP in the HTTP request. The PPP transaction s status OK or FAIL. Merchants location, as sent to the PPP. All unknown PPP parameters sent with the current transaction. customfield1 String Char(64) No customfield2 String Char(64) No customfield3 String Char(64) No customfield4 String Char(64) No customfield5 String Char(64) No customfield6 String Char(64) No customfield7 String Char(64) No customfield8 String Char(64) No customfield9 String Char(64) No customfield10 String Char(64) No customfield11 String Char(64) No customfield12 String Char(64) No customfield13 String Char(64) No customfield14 String Char(64) No customfield15 String Char(64) No Custom fields for the Merchant to update miscellaneous data. Is sent to the PPP in the HTTP response and sent back in its response.

24 10.6. Table 14: General Response Codes This table contains the response and their descriptions. The first three rows, marked in blue, are the mapping of the error codes to the corresponding response status field. ErrCode ExErrCode Description 0 0 APPROVED -1 0 DECLINED * 0-2 PENDING > 0 ERROR (Filter error)** < 0!= 0 ERROR (Gateway/Bank Error) Invalid Login IP out of range Timeout/Retry * Refer to the Decline reasons ** Please refer to Table 15: Filter error codes below Table 15: Filter error codes This table contains the possible filter numbers and their descriptions. ErrCode for all filters error is ExErrCode Description 1001 Invalid expiration date 1002 Expiration date too old 1101 Invalid card number (alpha numeric) 1102 Invalid card number (digits count) 1103 Invalid card number (MOD 10) 1104 Invalid CVV Auth Code/Trans ID/Credit card number mismatch 1106 Credit amount exceed total charges 1107 Cannot credit this CC company 1108 Illegal interval between auth and force 1109 Not allowed to process this CC company 1110 Unrecognized credit card company 1111 This Transaction was charged back 1112 Sale/Settle was already credited 1113 Terminal is not ready for this credit card company 1114 Black listed card number

25 1115 Illegal BIN number 1116 <Custom Fraud Screen Filter> 1118 'N' Cannot be a Positive CVV2 Reply 1119 'B'/'N' Cannot be a Positive AVS Reply 1120 Invalid AVS 1121 CVV2 check is not allowed in Credit/Settle/Void 1122 AVS check is not allowed in Credit/Settle/Void 1124 Credits total amount exceeds restriction 1125 Format Error 1126 Credit amount exceeds ceiling 1127 Limit exceeding amount 1128 Invalid Transaction Type Code 1129 General Filter Error 1130 Bank required fields are missing or incorrect 1131 This transaction type is not allowed for this bank 1132 Amount exceeds bank limit 1133 GW required fields are missing 1134 AVS Processor Error 1135 Only one credit per sale is allowed 1136 Mandatory fields are missing 1137 Credit count exceeded CCC restriction 1138 Invalid Credit Type 1139 This card is not supported in the CFT Program 1140 Card must be processed in the GW System 1141 Transaction type is not allowed 1142 AVS required fields are missing or incorrect 1143 Country does not match ISO Code 1144 Must provide UserID in a Rebill transaction 1145 Your Rebill profile does not support this transaction type 1146 Void is not allowed due to CCC restriction 1147 Invalid Account Number 1148 Invalid cheque number 1201 Invalid amount 1202 Invalid currency 1149 Account number/trans ID mismatch 1150 UserID/Trans Type /Trans ID mismatch 1151 Transaction does not exist in the rebill system Transaction was already canceled 1153 Invalid Bank Code(Digits Count) 1154 Invalid Bank Code (Alpha Numeric) 1155 VBV Related transaction is missing or incorrect 1156 Debit card required fields are missing or incorrect 1157 No update parameters were supplied 1158 VBV PaRes value is incorrect 1159 State does not match ISO Code 1160 Invalid Bank Code (Checksum Digit) 1161 This Bank allows only 3 digits in CVV2 value 1163 Transaction must contain a credit card number/token 1164 Invalid Token 1165 Token mismatch

26 10.8. Table 16: Decline Reasons This table contains the possible decline reasons. You will receive the decline reason in the Reason Output field. ErrCode ExErrCode Decline reason Explanation -1 0 Decline Refused by the bank (Customer has to refer to his issuer bank) Referral Request for voice authorization (to be treated as a decline) Call issuer Request to call the issuer bank (usually a security violation) Lost/Stolen A lost or stolen card (this can also be an indication for the Customer to pick the card from the bank) Timeout/Retry There was a timeout waiting for the issuer bank s response Expired card The bank indicated that the expiration date supplied is invalid Black listed by the bank CC was rejected by the bank s fraud system Retain Card The bank placed a hold on purchases due to issue with the cardholder account Invalid Card Number Invalid card number or attempt to process a card which has been replaced by the issuer (either due to lost/stolen or new exp. date/card issued) Stolen Card, Pick Up The card is reported as stolen, potential fraud Restricted Card The credit card is blacklisted by card association (Visa/MC) -1 0 Suspicion of Manipulation CVN (CVV/CVC) either missing or invalid Insufficient Funds The cardholder cannot supply the transaction s amount.

27 11. Appendix III: General Parameters Tables Following are tables of data which may be used in all requests and responses Table 17: Currencies Table Code EUR GBP USD CHF Full Name Euro - Euro Member Countries Pounds - United Kingdom Dollars - America (United States of America) Swiss Francs (Switzerland)