Integration guide Rabo OmniKassa

Transcription

1 Integration guide Rabo OmniKassa 1

2 CONTENTS 1. Introduction Payment flows Protocol description POST fields the Data field syntax the Seal field syntax How to implement a payment? Payment request Fields of the payment request Example Error cases Payment response Manual notification Automatic notification Troubleshooting in case of not received responses Rabo OmniKassa Error management No Seal field in the response How to SEAL a MESSAGE? Why seal a message? Method used to seal a message Coding examples Java Php net How to TEST? Test ideal transaction Test Minitix transaction Test card transaction

3 6.4 Test acceptgiro/incasso/rembours transactions How to GO LIVE? Merchant identifiers Pre-live tests Production / go live Messages description Payment request Mandatory fields Optional fields Responses / Notifications (automatic and manual) Data dictionnary Format convention Fields description Currency codes & amounts Customer languages Payment means The Rabo OmniKassa response code ideal acceptance details MiniTix acceptance details Incasso, Acceptgiro and rembours acceptance details

4 1. INTRODUCTION This document explains exchanges between merchants site and the Rabo OmniKassa server, using the Rabo OmniKassa redirect connector s gateway. This connector aims to be as easy as possible to implement on merchant s side and consists of requests and responses made in the form of HTTP(S) posts to and from the Rabo OmniKassa payment server. Requirements Technical To develop a client for the redirect connector, you will need knowledge in one of the languages commonly used for web programming, such as Java, PHP or.net. Security The Payment platform is PCI DSS compliant (Payment Card Industry Data Security Standard) which represents a security standard defined by VISA and MASTERCARD. With the Rabo OmniKassa, the merchant doesn t need to know the PAN (Personal Account Number) used for payments. We are referring for example to the consumer s credit card number. The request and responses exchanged between the webshop and the payment server are secured via a shared secret key. The Secret key must be stored in a secure environment on the webshops website. In case of (possible) corruption of the secret key, the merchant has to call within the shortest delay the technical support team of Rabo OmniKassa to renew it. This team is reachable from Monday to Saturday between 8:00 AM and 8:00 PM and on Sunday between 8:00 AM and 4:00 PM calling

5 2. PAYMENT FLOWS The objective is to implement the 3 payment flows, exchanged by payment occurrence between the webshop and the payment server. Payment page on merchant s website 1: The customer proceeds to the payment(paymen t request) Rabo OmniKassa redirect connector gateway 2: The connector redirects the customer to the paypages (redirect) Rabo OmniKassa payment server paypage Return page on merchant s website Automatic response 3a: The customer returns to merchant webshop website (manual response) 3b: The connector sends a automatic response to merchant webshop website (On which the customer can choose his/her payment mean and enter the according bank information) Flow 1: Once the customer proceeds with the payment step starting from merchant website, (payment transaction), a payment request must be sent to the Rabo OmniKassa server, using the URL provided to the merchant for this purpose. The simplest way is to do this using an HTML FORM, but any other solution sending an HTTP POST is also suitable. Flow 2: Then the customer is redirected to the paypage of the Rabo OmniKassa payment server for performing the actual payment operation. When this step is completed, either successfully or resulting in an error, responses are sent from the payment server to the response URLs provided as parameters of the payment request. Flow 3: Payment step 3a: Manual response sent as HTTP(S) POSTs by the payment server to the normal return URL as provided in the payment request whenever the customer clicks on the return to merchant s website link on the paypage. Then customer should be redirected to the suitable page on merchant s website. Note that this only happens when customer clicks on related link, which is not mandatory or guaranteed. 5

6 Payment step3b: Automatic responses are always sent as HTTP(S) POSTs by the payment server to the automatic response URL provided in the payment request whenever the payment process is completed. Notice: In the case the payment operation did not succeed, the customer is redirected to an error page on which he/she can click on a link to return to the merchant s website. At this moment the transaction is considered as interrupted. If for instance, another payment mean is preferred, the whole payment transaction must be performed again starting from merchant s website. 6

7 3. PROTOCOL DESCRIPTION 3.1 POST FIELDS Three fields can be provided in the payment requests and the payment responses *. Data InterfaceVersion Seal Contains all the information of the transaction gathered in a single string as explained in Version of the connector s interface in use. Used to validate the integrity of the data. Computed from the Data field and secret key as explained in *All the fields are mandatory the Data field syntax The Data field value is built according to the following scheme: <field name>=<value name> <field name>=<value name> <field name>=<value name> All the fields needed for the transaction (see details in the data dictionary 9) must be put in the string. The field ordering doesn t matter. Example for a payment request: amount=55 currencycode=978 merchantid= normalreturnurl= transacti onreference= keyversion= the Seal field syntax The Seal field value is built by appending the secret key to the Data field value (see 3.1.1) and then getting the result s bytes as UTF-8 and then ciphering the bytes using SHA256 algorithm (see also 3.1.1) : SHA256( UTF-8(Data+secretKey ) ) 7

8 4. HOW TO IMPLEMENT A PAYMENT? 4.1 PAYMENT REQUEST The payment request must be made as an HTTP post to connector s gateway. The easiest way to proceed is by using an HTML form and using the POST method. See example below Fields of the payment request All the data of the payment request must be provided in the POST request fields as detailed in 3.1. InterfaceVersion must be set to HP_1.0. See data dictionary for a description of parameters of the payment request, their format and their optional or mandatory nature Example <form method="post" action=" <input type="hidden" name="data" value="amount=55 currencycode=978 merchantid= normalreturnurl= tr ansactionreference= keyversion=1"> <input type="hidden" name="interfaceversion" value="hp_1.0"> <input type="hidden" name="seal" value="21a57f2fe765e1ae4a8bf15d73fc1bf2a533f547f2343d12a499d9c d4"> <input type="submit" value="proceed to payment"> </form> Error cases When the payment request is received by the gateway, the provided fields values are checked. What follows is the list of errors that may arise, with their explanation and hints to solve the problems encountered. Note that, as the resulting error page is displayed to the customer, full error detail will only be shown on the demo environment used at integration step. Once in Production, only a generic message such as Error while processing your payment request. Please contact the merchant. will be displayed. Message Cause Solution Invalid POST field: <field name> The POST request contains a field which is unknown Check the available POST fields in user guide Missing mandatory POST field: < field name> The mandatory POST field < field name> is missing in the POST request Check the mandatory POST fields in user guide 8

9 Message Cause Solution Unknown interface version: <version> Invalid keyword: <param name>=<param value> Invalid parameter size: <param name>=<param value> The value <version> of the POST field InterfaceVersion is unknown The request contains a parameter <param name> which is not expected in the payment request Value of parameter <param name> does not have the correct size Check available interface versions in user guide Check the payment request parameters in data dictionary Check expected payment request parameter s value size in data dictionary Invalid parameter value: <param name>=<param value> Missing mandatory parameter: <param name> Value of parameter <param name> does not have the right format The mandatory parameter <param name> is missing in the payment request Check expected payment request parameter s value format in data dictionary Check the mandatory payment request parameters in data dictionary Unknown key version: <version> The value <version> of the parameter keyversion is unknown Check available key versions for your merchant in merchant extranet Unknown merchant Id: <ID> Invalid seal Transaction already processed: <transaction reference> Any other message The merchant ID is not known in database The payment request seal check failed due to a miscomputed value in the payment request or a modification of one or many parameters values between its generation and receipt on the Rabo OmniKassa gateway A payment request with the same transactionreference value has already been received and processed by the gateway Check your merchant Id Check the seal computation rules in data dictionary Ensure that the transaction reference is unique for a given transaction Contact Support Team Rabo OmniKassa 9

10 4.2 PAYMENT RESPONSE Response to a payment request can come in two ways: manual and/or automatic response (also called notifications). There s no difference in meaning between the terms response and notification in this document Manual notification After the customer completed his/her payment operation on the paypage, he can click a link back to merchant s website which will return him to the adequate page on merchant s website which URL is provided in the <normalreturnurl> parameter within the payment request. This hit will be sent as an HTTP POST request to the target URL, along with the parameters of the transaction as sent in the payment request plus some additional information (status, payment mean used ). The provided URL targets must be able to process the information provided by the notification posts coming from the Rabo OmniKassa gateway. See POST fields details in 3.1. IMPORTANT: Note that parameters of the response will have the exact upper and lower case characters as given in this document. InterfaceVersion will be set to HP_1.0. See the Rabo OmniKassa data dictionary for a description of parameters contained in the notification. IMPORTANT: Note that the customer may never click this link (browser closed or crashed, page closed ). So the manual notification alone cannot be relied on to be warned of the completion of the payment request Automatic notification If an automaticresponseurl has been set as payment request parameter (it is optional), the Rabo OmniKassa payment server sends a response to it as HTTP POST requests built the same way as for manual response. See POST fields details in 3.1. IMPORTANT: Note that parameters of the response will have the exact casing as given in this document. I.e. the names are composed of upper and lower case letters. InterfaceVersion will be set to HP_1.0. See the Rabo OmniKassa data dictionary for the description of parameters contained in the response Troubleshooting in case of not received responses Rabo OmniKassa In the case you do not receive the reponse on your server, you re pleased to find here a list of verifications to do: 10

11 Check that notifications URLs are provided in the payment request and if so, that those are valid. Provided URLs must be reachable from external internet access. An access control (login/password or IP filter) or a firewall may block access to your server. Hits to the notification URLs should appear in your server s access log (hit history). If you use a non standard port, it must be within the 80 and 9999 range. You cannot add context parameters to the notification URLs. Instead, use the orderid which you provided in the payment request (optional field) and which is given back in the response parameters Error management No Seal field in the response In case of error such as unknown Merchant ID, the payment server cannot seal the response because it cannot retrieve the secret key used by the webshop. In that case, the payment server sends a response without the Seal field. 11

12 5. HOW TO SEAL A MESSAGE? 5.1 WHY SEAL A MESSAGE? The parameters of the transaction (payment request) are transmitted via customer s browser. So a dishonest customer may modify them before it is transmitted to the payment server. Therefore, it is necessary to add a security system to enforce integrity of the transaction parameters. The fact that the seal is OK means two things: - The integrity of the messages request and response; no alteration during the exchange, - The authentication of the sender and receiver because they share the same secret key ( secret Key ). Note: In case of corruption of the key, the merchant has to call the Support Team Rabo OmniKassa to renew it. This team is reachable from Monday to Saturday between 8:00 AM and 8:00 PM and on Sunday between 8:00 AM and 4:00 PM calling METHOD USED TO SEAL A MESSAGE Sealing is done by computing a ciphered value from transaction parameters (Data) and an appended secret key (secret Key) unknown from the customer. Strings are converted to UTF8 bytes before ciphering. The cipher algorithm (SHA256) produces an undecipherable result which is computed again on connector s side for comparison. The result must be set as a hexadecimal value in the Seal POST field Java 5.3 CODING EXAMPLES import java.security.messagedigest; public class ExampleSHA256 { /** * table to convert a nibble to a hex char. */ static final char[] hexchar = { '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'a', 'b', 'c', 'd', 'e', 'f'}; /** * Fast convert a byte array to a hex string * with possible leading zero. 12

13 b array of bytes to convert to string hex representation, two chars per byte. */ public static String encodehexstring ( byte[] b ) { StringBuffer sb = new StringBuffer( b.length * 2 ); for ( int i=0; i<b.length; i++ ) { // look up high nibble char sb.append( hexchar [( b[i] & 0xf0 ) >>> 4] ); // look up low nibble char sb.append( hexchar [b[i] & 0x0f] ); } return sb.tostring(); } /** * Computes the seal the Data the parameters to cipher secretkey the secret key to append to the parameters hex representation of the seal, two chars per byte. */ public static String computeseal(string Data, String secretkey) throws Exception { MessageDigest md = MessageDigest.getInstance("SHA-256"); md.update((data+secretkey).getbytes("utf-8")); } return encodehexstring(md.digest()); /** args */ public static void main(string[] args) { try { System.out.println (computeseal("parameters", "key")); } catch (Exception e) { e.printstacktrace(); } } } Php 5 <?php echo hash('sha256', $Data.$secretKey);?> Data and secretkey must use UTF-8 charset. See utf8_encode to convert from ISO to UTF net (Done using a simple form Form1 containing two text fields for input: txtrabo, txtsecretkey and one for output: lblhex) 13

14 using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Text; using System.Windows.Forms; using System.Security.Cryptography; namespace ExampleDotNET { public partial class Form1 : Form { public Form1() { InitializeComponent(); } private void cmdgo_click(object sender, EventArgs e) { String schaine = txtrabo.text + txtsecretkey.text; UTF8Encoding utf8 = new UTF8Encoding(); Byte[] encodedbytes = utf8.getbytes(schaine); byte[] sharesult; SHA256 sham = new SHA256Managed(); sharesult = sham.computehash(encodedbytes); } lblhex.text = ByteArrayToHEX(shaResult); private string ByteArrayToHEX(byte[] ba) { StringBuilder hex = new StringBuilder(ba.Length * 2); foreach (byte b in ba) hex.appendformat("{0:x2}", b); return hex.tostring(); } } } 14

15 6. HOW TO TEST? The Rabo OmniKassa simulation environment enables users to perform test transactions using a test webshop ID. It is not possible to use your own webshop ID in this environment; this results in an error message. The following payment methods can be used for testing purposes: ideal, MiniTix, Visa, MasterCard and Maestro, along with the cash services Giro Collection Form, Collection, and reimbursement. The table below contains technical information required for the simulation environment, along with an important announcement: Simulation URL connector Webshop ID (merchantid) Version key 1 SecretKey _KEY1 Please note For every transaction, you must enter a unique transaction reference in the transactionreference field. In the simulation environment you can use your Chamber of Commerce registration number (for example) for this purpose, followed by a code for your webshop you choose yourself (if you operate more than one webshop) and a reference of your choice. Example: if your Chamber of Commerce registration number is , the webshop code is 01, and the order ID from your webshop package is 1, this will generate transaction reference TEST IDEAL TRANSACTION When you select IDEAL as the payment mean, you are routed to the test ideal server that simulates an ideal transaction from the amount of the transaction. Afterwards you are returned to payment server that displays a receipt with the result of the transaction. ideal simulation rules Transaction Amount ideal response 2 Transaction cancelled 3 Transaction expired 4 Transaction opened 5 Transaction failure 15

16 Other cases Transaction success 6.2 TEST MINITIX TRANSACTION When you select MINITIX, you are routed to the test MiniTix server that simulates a MiniTix transaction from the amount of the transaction. Afterwards you are returned to payment server that displays a receipt with the result of the transaction. MiniTix Simulation rules On the MiniTix simulation page different buttons are displayed to test all possible cases. 6.3 TEST CARD TRANSACTION When you select VISA, MASTERCARD or MAESTRO, you are routed to the capture card page. On this page you have to fill the form. Card simulation rules o The brand used is defined by the 6 first digits. The PAN (Primary Account Number) length must be between 16 and 19 digits. Card brand Card prefix VISA MASTERCARD MAESTRO o o You can simulate all the response codes (see appendix 9.6) by changing the last two digits. The security code size must be 3 or 4 digits. Example: if you use the card number you will simulate a VISA card payment: your payment will be refused with next listed response code 05 authorization refused. 6.4 TEST ACCEPTGIRO/INCASSO/REMBOURS TRANSACTIONS When you select INCASSO, ACCEPTGIRO or REMBOURS, you are routed directly to a specific payment information page for the selected payment mean with no action possible. You can only select the return to merchant s website button on this page. In other words, there are no specific response codes for testing with one of these payment means. 16

17 17

18 7. HOW TO GO LIVE? The next step is to go to the live environment for proceeding with last pre-live verifications before you are able to work with Rabo OmniKassa in production. This phase will allow controlling the right registration of your contract parameters following requested/accepted payment means. 7.1 MERCHANT IDENTIFIERS The URL to use for the live/pre-live environment is: To access to the live server, you have to get 3 identifiers: - The merchant Id ( webwinkel ID ) that identifies the webshop on the payment server - The keyversion, and - the secretkey. The last two listed identifies are used to seal the request and check the response The merchant ID is provided by the Support Team Rabo OmniKassa during the registration phase. You ll find your assigned keyversion and secretkey using URL You can connect to this URL by using a <login> and <password> given by the Support Team Rabo OmniKassa during the registration phase. 7.2 PRE-LIVE TESTS During the pre-live tests, the merchant has to use a real card number, ideal account and MiniTix account numbers because the transactions are sent to the real acquirer to get an authorization. For Visa or MasterCard, there is no remittance process foreseen meaning no debit/credit operation for the buyer and the merchant can be expected. In case of ideal and MiniTix, there is a single message sent to the payment mean acquirer that includes authorization and payment. The single message mode means that, in this case, a debit/credit operation is generated for the buyer and the merchant. We suggest that the merchant uses his own creditcard, ideal account and MiniTix account numbers to generate these pre-live transactions. 7.3 PRODUCTION / GO LIVE When the pre-live tests are finished and successfully completed, the merchant has to send back (via a reply) on previous received (after reception and processing of Rabo OmniKassa contract) the approval form to the Support Team Rabo OmniKassa with mention of the expected Rabo OmniKassa go live date. 18

19 You re free to do this for all web shops at once (by sending back the only once) or by web shop (sending back the several times, depending on your choice of the go live dates for your web shops). 19

20 8. MESSAGES DESCRIPTION 8.1 PAYMENT REQUEST Mandatory fields These fields must be provided for each transaction. Field name currencycode merchantid normalreturnurl amount transactionreference keyversion Description Currency of the transaction. 3 characters long numeric code. See appendix 9.3. ID of your the Rabo OmniKassa merchant URL to which the customer must be returned once the transaction is completed (manual notification URL). Length is limited to 512 characters. URL must not contain parameters. Amount of the transaction without decimal separator (ex: ). See appendix 9.3. Numeric string limited to 12 characters (i.e. maximum amount is ) Reference of the Rabo OmniKassa transaction which must be unique for a given merchant. Alphanumeric string limited to 35 characters. Version of the secret key to use as provided by the merchant management extranet. Table 1: Payment request mandatory fields Optional fields Field name automaticresponseurl customerlanguage paymentmeanbrandlist Description URL to use for automatic notification. Length is limited to 512 characters. Note: URL may not contain parameters. Language used to display the paypage or the error page. Default is user s browser language. 2 characters long code. See appendix 9.4. List of the authorized payment mean is the case a restriction should occur. Contains the list of Rabo OmniKassa accepted payment mean brand codes, comma separated. Payment means listed must be listed in capital 20

21 Field name Description characters. The ordering used will define the order in which the payment means are listed on the Rabo OmniKassa paypage. Example: IDEAL,MINITIX,VISA,MASTERCARD. orderid expirationdate If not set, by default, all the supported means are proposed to the customer except INCASSO, ACCEPTGIRO and REMBOURS that are only available if they are populated in this field. See appendix 9.5. Private merchant field. For instance, this field can be used by merchant to store the identifier of the order in the merchant information system. Alphanumeric string limited to 32 characters. Expiration date of the payment request. Alphanumeric string formatted according to ISO8601. See appendix 9.1. Table 2: Payment request optional fields 8.2 RESPONSES / NOTIFICATIONS (AUTOMATIC AND MANUAL) The content of the automatic and manual responses of the Rabo OmniKassa Payment Web are identical. It will vary according to the status of the payment request. Field name amount currencycode merchantid transactionreference keyversion orderid responsecode transactiondatetime Description As provided in the payment request. As provided in the payment request. As provided in the payment request. As provided in the payment request. As provided in the payment request. As optionally provided in the payment request. Rabo OmniKassa response code of the payment request. See appendix 9.6. If the payment is sent to acquirer for authorization: Date/Time in the Rabo OmniKassa system when the payment is sent to acquirer in merchant's time zone. Otherwise, date time when the Rabo OmniKassa response code is produced on 21

22 Field name Description the Rabo OmniKassa system. Alphanumeric string formatted according to ISO8601. See appendix 9.1. authorisationid* paymentmeantype* paymentmeanbrand* complementarycode* maskedpan* Identifier of the authorization provided by the acquirer. Set by the merchant for manual authorization. Type of payment mean chosen by the customer. See appendix 9.5. Brand of payment mean chosen by the customer. See appendix 9.5. Response code to complementary checks. Future use Masked primary account number. Format is nnnnnn.nnnn (n is a number between 0 and 9) *: these fields are provided when available, depending on the transaction status and the payment mean which was chosen. Table 3: Payment response fields 22

23 9. DATA DICTIONNARY 9.1 FORMAT CONVENTION. This chapter describes the convention related to the Format Column used in Field Description Value N A S Numeric YYYY YY MM DD hh mm ss Description Indicate that Numeric value [0-9] is accepted Indicate that Alphabetic value [aa-zz] is accepted Indicate that Special characters are accepted Indicate the maximum size of the field Indicate the year Indicate the 2 last digit of the year Indicate the month Indicate the day Indicate hours (24h) Indicate minutes Indicate seconds Indicate an ISO8601 DateTime format (ANS25): YYYY-MM-DDThh:mm:sszzzzzz ISO8601 YYYY-MM-DD : Year, Month, Day, with - as a separator T : «T» static value indicating that the following is a time description. hh:mm:ss : Hour, Minute, Second with : as a separator. A fraction of a second can be added to this time using a dot or a comma as a separator. zzzzzz : time zone or time shift compared to UTC using one of the following formats : «Z» or «+hh:mm» or «-hh:mm» url base64url Indicates that an url is accepted ANS with following accepted special characters [_-=] restrictedstring ANS with following accepted special characters [_@.-+] and blank liststring ANS with following accepted special characters [_@.-+,] and blank 23

24 Value extendedstring Description ANS with following special characters [.-,;:_?!<>+=*^/\&~# and blank Table 4: data dictionary format convention 9.2 FIELDS DESCRIPTION The table below describes all fields. Please note that whenever specific values are mentioned in the description column, the list of values is provided in the specific values section of this document. Field Name Format Description amount authorisationid automaticresponseurl N12 AN10 ANS512 url Final amount of a transaction (Debit or Credit) or amount of an operation (refund, cancel, ) Identifier of the authorization provided by the acquirer. Set by the merchant for manual authorization. This is the address to which the Rabo OmniKassa service should automatically notify the merchant after a payment or a process captureday N2 Settlement delay (in days) indicator Future use capturemode ANS20 Indicates the capture mode (automatic or fulfillment) Future use complementarycode N2 Response code to complementary checks. Future use complementaryinfo ANS255 extendedstring Description of the complementary code Future use currencycode N3 Currency of the amount. Specific values customerlanguage A2 Language of the customer, used for presentation. Specific values expirationdate ANS25 ISO8601 Expiration date of the payment request (UTC timezone) keyversion N10 Identifier of the Merchant secret key maskedpan NS11 Masked primary account number. Format is nnnnnn.nnnn (n is a number between 0 and 9) merchantid N15 Identifier of the merchant normalreturnurl ANS512 url This is the internet address used by the Rabo OmniKassa service to redirect the user after the payment. 24

25 Field Name Format Description orderid AN32 Private merchant field. For instance, this field can be used by merchant to store the identifier of the order in the merchant information system paymentmeanbrand ANS20 Brand of the payment mean. Specific values paymentmeanbrandlist ANS128 liststring Merchant accepted payment means list. Can be set by the merchant for each transaction: list of accepted payment means with comma, separator. If not set, default payment mean list applies except INCASSO, ACCEPTGIRO and REMBOURS that are only available if they are populated in this field. Specific values paymentmeans1,paymentmean2,, paymentmeansn example : IDEAL,MINITIX,INCASSO Payment means listed must be listed in capital characters. The ordering used will define the order in which the payment means are listed on the Rabo OmniKassa paypage. paymentmeantype ANS20 Type of the payment mean. Specific values responsecode N2 Rabo OmniKassa response code of a payment request. Specific values transactiondatetime ANS25 ISO8601 If the payment is sent to acquirer for authorization: Date/Time in the Rabo OmniKassa system when the payment is sent to acquirer in merchant's time zone. Otherwise, date time when the Rabo OmniKassa response code is produced on the Rabo OmniKassa system. transactionreference AN35 Identifier of the transaction Table 5: data dictionary fields description 9.3 CURRENCY CODES & AMOUNTS The currency code are given in the ISO 4217-Numeric codification. To set fields amounts, this table describes for each following currency a sample amount and the value. The fractional unity in the following table stands for the currency number of decimals. Currency code Example Currency name Fractional unity Value Amount Fields amount Euro , American Dollar Swiss Franc , Pound

26 Currency name Currency code Example Fractional unity Value Amount Fields amount Canadian Dollar Yen Australian Dollar Norwegian crown Swedish crown Danish crown Table 6: data dictionary currency code 9.4 CUSTOMER LANGUAGES Here is the list of the main language codes used (ISO Alpha2) and their meaning. Code en fr de it es nl Language English French German Italian Spanish Dutch Table 7: data dictionary customer language 9.5 PAYMENT MEANS PaymentMeanBand ideal PaymentMeanType CREDIT_TRANSFER VISA MASTERCARD CARD 26

27 PaymentMeanBand PaymentMeanType MAESTRO MINITIX OTHER INCASSO ACCEPTGIRO REMBOURS OTHER OTHER OTHER Table 8: data dictionary payment means 9.6 THE RABO OMNIKASSA RESPONSE CODE Depending on the end of payment, the returned responsecode can be: Code Description Transaction success, authorization accepted (transaction succeeded, authorization accepted). Please phone the bank because the authorization limit on the card has been exceeded 03 Invalid merchant contract 05 Do not honor, authorization refused 12 Invalid transaction, check the parameters sent in the request. 14 Invalid card number or invalid Card Security Code or Card (for MasterCard) or invalid Card Verification Value (for Visa) 17 Cancellation of payment by the end user 24 Invalid status. 25 Transaction not found in database 30 Invalid format 34 Fraud suspicion 40 Operation not allowed to this merchant 60 Pending transaction 63 Security breach detected, transaction stopped. 27

28 Code 75 Description The number of attempts to enter the card number has been exceeded (Three tries exhausted) 90 Acquirer server temporarily unavailable 94 Duplicate transaction. (transaction reference already reserved) 97 Request time-out; transaction refused 99 Payment page temporarily unavailable Table 9: data dictionary response code See 9.7 for details on IDEAL response codes and 9.8 for details on MiniTix response codes. 9.7 IDEAL ACCEPTANCE DETAILS This chapter gives details on the response code mapping of ideal scheme acceptance. ideal Status field values Open ideal ideal Description Result not known (yet). A new request is necessary to obtain the status. responsecode Rabo OmniKassa Rabo OmniKassa Transactions stored in Rabo OmniKassa it depends on the 60 (1) final ideal responsecode Failure sending in Issuer unavailable, set by ideal acquirer 90 No Success Positive result; the payment is guaranteed. 00 yes (Status=Remitted to the bank) Cancelled Expired Negative result due to cancellation by consumer; no payment has been made. Negative result due to expiry of validity; no payment has been made. 17 No 97 (3) No Failure Negative result due to other reasons. 05 (4) yes (Status=Refused) Table 10: ideal response code mapping 28

29 (1) Transaction not finalized, the Rabo OmniKassa is waiting for the final ideal status. (3) The Rabo OmniKassa responsecode 97 is sent from the Rabo OmniKassa paypage timeout (4) ideal doesn't distinguish between technical problems and functional refusal 29

30 9.8 MINITIX ACCEPTANCE DETAILS This chapter gives details on the response code mapping of MiniTix scheme acceptance. MiniTix Rabo OmniKassa Minitix errorcode field values MiniTix Description responsecode Rabo OmniKassa Transactions stored in Rabo OmniKassa 10 Syntax error 05 no 20 Integrity error 05 no 30 Merchant not known 05 no 31 Merchant disabled 05 no 40 Payment cancelled 17 no 80 Request outside time window 97 no 90 System error 90 no 100 Unauthorized customer 05 yes (Status=Refused) 110 Payment confirmation started 99 no 120 Insufficient balance 05 yes (Status=Refused) NA Transaction OK 00 yes (Status=Remitted to the bank) Table 11: MiniTix response code mapping 9.9 INCASSO, ACCEPTGIRO AND REMBOURS ACCEPTANCE DETAILS Based on the way of integration in Rabo OmniKassa, there are no payment mean specific request response codes regarding these payment means, near the general used response codes (for details, please refer to Error cases ). 30