localización del número de documento de...

Virtual POS EXTENDED MERCHANT MANUAL

LATEST UPDATE July 2009

VIRTUAL POS – EXTENDED MERCHANT MANUAL

Pág. 2

1. INTRODUCTION 2. SECURITY GUARANTEES – 3DSECURE 3. CROSS-BORDER LICENSES 4. OPERATING FEATURES

4.1. TYPES OF AUTHORIZATION REQUESTS 4.2. OPERATING RESTRICTIONS 4.3. ADDITIONAL SECURITY MEASURES 4.4. REGULATIONS

5. ADMINISTRATION MODULE 5.1. ACCESS 5.2. USERS 5.3. CHECKING TRANSACTIONS 5.4. REFUNDS 5.5. CHECKING TOTALS

6. INSTALLATION

6.1. GATEWAY ‘realizarPago’ 6.2. GATEWAY ‘entradaXMLEntidad’ 6.3. GATEWAY ‘operaciones’ 6.4. DESIGN OF HASH ALGORITHM 6.5. TECHNICAL INSTALLATION SUPPORT SERVICE

7. OTHER TECHNICAL INFORMATION 7.1. ON-LINE RESPONSE 7.2. RECURRING TRANSACTIONS 7.3. TEST ENVIRONMENT

8. QUERIES ON TRANSACTIONS VIA SOAP-XML

8.1. ON-LINE QUERIES 8.1.a. SOAP CLIENT 8.1.b. XML SEND AND RESPONSE 8.1.c. CALCULATING THE SIGNATURE 8.1.d. WDSL OF SERVICE 8.1.e. SOAP ERROR CODES

8.2. SOAP SYNCHRONIZATION 9. REGULAR INFORMATION FILES 9.1. SETTLEMENT OF ACCOUNTING TRANSACTIONS FILE

9.2. CHARGEBACK FILE 9.3. CONFIRMED FRAUD FILE 9.4. RETRIEVAL REQUEST FILE

10. MONITORING PROGRAMMES AND PENALTIES

11. PCI-DSS – PAYMENT CARD INDUSTRY DATA SECURITY STANDARD


ANNEXES

ANNEX I. DESCRIPTION OF PAYMENT AND RESPONSE FORMS

ANNEX II. TABLE OF RESPONSE CODES

ANNEX III. TABLE OF ERRORS ANNEX IV. LIST OF COUNTRY CODES ANNEX V. SECURITY DIGITAL CERTIFICATES SSL/TLS ANNEX VI. DISPUTE CIRCUIT ANNEX VII. DISPUTING A CHARGE-BACK ANNEX VIII. RETRIEVAL REQUESTS CIRCUIT


1. INTRODUCTION Caixa Catalunya’s Virtual POS is a computer application which allows shops and businesses which sell their products and services on the Internet to accept payments for transactions with a credit/debit card and have the amount credited to their account. The cards accepted are the same as those accepted by ‘physical’ POS terminals; specifically, Visa, MasterCard and Maestro. You can also request authorization to operate with JCB cards, American Express and Diners Club. The Virtual POS can be used in various languages (Spanish, Catalan, English, French, German, Dutch, Italian, Swedish, Portuguese, Valencian, Polish, Galician and Basque) and can also operate with four different currencies (Euros, US Dollars, Sterling Pounds and Yens). The Virtual POS uses standard Internet functions and algorithms, what means it can be installed in any server or platform, regardless of the operating system or programme language. It has also been designed to be viewed on both desktop browsers (standard PCs) and handheld devices (e.g. PDAs). Communications with the Virtual POS are always made using a secure SSL connection (see annex V). The system incorporates a tool known as the ADMINISTRATION MODULE which allows the business establishment to keep track of movements (using a selection of different parameters), check totals, cancel transactions and make partial refunds, amongst other options.


2. SECURITY GUARANTEES – 3DSECURE The Virtual POS has been designed to operate completely securely for sales transactions made over the Internet, i.e.: 1. It will try to contact the card issuer to seek authorization of the cardholder (verification of identity) before making the relevant authorization request. In this way it guarantees that only the genuine cardholder can use it.

2. It uses SSL in every communication, preventing third parties from intercepting the information. Therefore confidentiality is assured in every communication established during the transaction (see annex V).

3. It also features mechanisms to test the authenticity of origin of transactions and to prevent third parties from manipulating data. This guarantees the integrity of the transaction details.

The Caixa Catalunya Virtual POS incorporates, as a matter of course, a space for the card’s CVV2 to be entered (the threedigit security code on the back of the card) as this has proven to be an effective measure against card fraud. The Caixa Catalunya Virtual POS was one of the first to adapt to new client authentication technologies and to protect its virtual merchants against delayed transactions by adopting, amongst other measures, the 3DSECURE system which incorporates the VERIFIED by VISA, MASTERCARD SECURECODE and JCB Secure protocols. 3DSECURE is mandatory for transactions done with MAESTRO cards, except for domestic transactions, where the Maestro card is issued by a Spanish bank. THE CARDHOLDER CANNOT REVERSE THE PURCHASE BY ARGUING THAT HE HAS NOT MADE IT, even if it has not been authenticated, as international entities such as VISA and MasterCard oblige the card issuer to accept responsibility in these cases. The Caixa Catalunya Virtual POS is certified by the VISA, MASTERCARD and JCB card systems as a secure virtual terminal and therefore you are guaranteed payment for all operations except in the following circumstances: 1. The merchant cannot provide documentary proof that the product or service has been supplied to the cardholder in accordance with the terms and conditions of sale.

2. In the case of recurring payments, if on the initial payment the card issuer had not made a positive authentication of the cardholder.

3. Operations carried out with Visa Business, Visa Corporate and Visa Purchasing cards. The Virtual POS will be updated with the latest secure payment versions when they are ordained by international organisations, though you should be advised that merchants will NOT have to make these modifications themselves; they will always be implemented centrally.


3. CROSSBORDER LICENSES The CrossBorder license acquired by Caixa Catalunya from the international card companies (VISA, MASTERCARD and JCB) allows it to process transactions by merchants whose fiscal residence is outside Spain. Each credit card company has independently demarcated the catchment area of their license. Given below are the countries that currently make up the geographical crossborder area of each credit card company: VISA:

Merchants resident in Germany, Andorra, Austria, Belgium, Bulgaria, Cyprus, Denmark, Slovakia, Slovenia, Spain, Estonia, Finland, France, Gibraltar, Greece, Greenland, Holland, Hungary, Iceland, Faeroe Islands, Ireland, Israel, Italy, Latvia, Lithuania, Luxembourg, Malta, Norway, Poland, Portugal, United Kingdom, Czech Republic, Romania, Sweden, Switzerland and Turkey.

MASTERCARD: Western Europe Region

Merchants resident in Germany, Andorra, Austria, Belgium, Bulgaria, Cyprus, Vatican City, Denmark, Slovakia, Slovenia, Spain, Estonia, Finland, France, Gibraltar, Greece, Holland, Hungary, Iceland, Ireland, Isle of Man, Channel Islands, Italy, Latvia, Liechtenstein, Lithuania, Luxembourg, Malta, Monaco, Norway, Poland, Portugal, Romania, United Kingdom, Czech Republic, San Marino, Sweden, Switzerland and Turkey.

JCB: Any merchant resident in any country in the world.


4. OPERATING FEATURES 4.1. TYPES OF AUTHORIZATION REQUESTS Depending on the needs of each merchant, the Virtual POS offers a wide variety of authorization request options which the merchant can combine according to his requirements. Authorization (Ds_Transaction_Type = ‘0’ or ‘A’) This is the most general situation. The transaction is instigated by the cardholder who is present during the sales process. Once it has received the purchase request from the merchant, the Virtual POS asks the client for the details to authorize the transaction. If the cardholder’s bank has an authentication system, the cardholder will be asked by the card issuer to provide the necessary proof for authentication. The request for authentication takes place in real time and the amount is charged immediately to the cardholder’s account (credit or debit). It should be noted that the guarantees are the same for both types of card. The transaction is automatically recorded by the Virtual POS and sent on a daily basis for batch processing to be credited to the merchant. The cardholder receives a receipt of the payment he has made. Preauthorization (Ds_Transaction_Type = ‘1’) NOTE: in accordance with international brand regulations, this operation is restricted to businesses working in the following areas: hotels, travel agencies or car hire companies. This option can be used when the exact amount cannot be determined at the time of purchase, or if, for any reason, the merchant does not want the amount to be charged to the customer’s account immediately. The transaction is transparent to the cardholder, who at all times proceeds in exactly the same way as the example given above, i.e. providing his/her details and authentication, if applicable, and receiving the relevant receipt from the Virtual POS. The request for preauthorization is carried out in real time, resulting in a retention of the sales amount from the cardholder’s account. The transaction is not recorded and therefore does not have any accounting impact on the cardholder’s account and is not paid to the merchant (in the case of debit cards, some issuing entities debit the sum from the cardholder’s account, which is automatically cancelled after a few days). All preauthorizations must be supported by a Preauthorization Confirmation within a maximum of 7 calendar days. Should this not be the case, they will lose their validity as a payment guarantee. Preauthorization Confirmation (Ds_Transaction_Type = ‘2’) This is an essential complement to the above operation. The cardholder is not present and therefore this is always instigated by the merchant.


This operation should be done within 7 calendar days of the original preauthorization and the amount should be LESS THAN or EQUAL TO the original amount. This transaction is valid for accounting purposes and is automatically charged to the cardholder’s account and sent for batch processing and payment to the merchant. The preauthorization confirmation guarantees payment and maintains the secure transaction conditions of the original preauthorization. The Virtual POS will validate the existence of the original transaction and the amount that needs to be confirmed, rejecting the transaction if there is an error. Cancellation of Preauthorization (Ds_Transaction_Type = ‘9’) The cardholder is not present and therefore this is always instigated by the merchant. It should be done within 7 days of the original preauthorization. The Virtual POS will validate the existence of the original transaction, rejecting the transaction if there is an error. Partial or Total Refund (Ds_Transaction_Type = ‘3’) These are accounting transactions instigated by the merchant. The Administration Module of the Virtual POS can also be used to do these manually. The Virtual POS corroborates the existence of the original authorization of the sum that needs to be refunded, and that this amount in no way exceeds the originally authorized amount. This is accounted for in the cardholder’s account (some card issuers may delay payment to the cardholder by a few days) and therefore is automatically recorded and sent for the settlement process which subsequently makes the relevant charge to the merchant’s account. Recurring transaction (Ds_Transaction_Type = ‘5’) This allows the cardholder to subscribe to a regular service offered by the merchant. The total amount of this service is paid by a predetermined number of instalments. By using this operation, the merchant notifies the total amount to be paid, the minimum number of days at which the payment of the next instalment should be made, and the date of the final instalment. The flow of this operation is similar to that of a normal purchase authorization. The customer must be informed of the total amount payable and the instalments that make it up, and the authentication is based on these details. However, the request for authorization, which will be accounted for, is only done for the amount of the initial instalment like a normal authorization request. Subsequently, the merchant sends successive authorization requests at the due date of every instalment.


Successive transactions (Ds_Transaction_Type = ‘6’) These form an essential complement to the above operation. The cardholder is not present and therefore this transaction is always instigated by the merchant. This operation should be carried out in line with the conditions of the original recurring transaction in terms of the amount, instalments and final date. These details will be validated by the Virtual POS, which will reject the transaction if it detects any errors. This transaction is accounted for by an entry in the cardholder’s account for each instalment, and sent for the daily settlement process to be credited to the merchant. Successive transactions have the same security conditions as the original recurring transaction except when the original transaction was regarded as secure but there was no positive authentication of the client. In this case, the successive transactions will not be regarded as secure. In order to process these transactions, a new authorization request will need to be submitted for each instalment. Authentication (Ds_Transaction_Type = ‘7’) This kind of operation can be used by the merchant when the sales amount cannot be determined exactly at the time of purchase. The operation is similar to that of the preauthorization, though in this case only the first part of the operation takes place, i.e. the authentication of the cardholder. There is no request for authorization, which means that the transaction is not immediately accountable and is not deducted from the cardholder’s account. Subsequently, within the next 45 calendar days, the merchant should send an authentication confirmation which will complete the original transaction. Confirmation of authentication (Ds_Transaction_Type = ‘8’) This is an inseparable part of the above operation. The cardholder is not present and therefore this is always instigated by the merchant. The amount may be different to the original operation (and can even be HIGHER). This transaction is immediately accountable, creating an entry in the cardholder’s account and sent to the settlement process for crediting the merchant. Authentication confirmations have the same security conditions as the original authentication. The Virtual POS will validate the existence of the transaction, rejecting it if there are any errors.


Deferred Preauthorization (Ds_Transaction_Type = ‘O’) These are similar operations to preauthorizations but are available for all sectors of activity. Authorization is obtained from the issuing bank in real time which will need to be confirmed within the next 72 hours if the transaction is definitely going to go through. If confirmation has not been sent within 72 hours of the day/time of the Deferred Preauthorization, the authorization will be cancelled automatically and thus cannot be confirmed. In contrast to traditional preauthorizations, the amount of the Deferred Preauthorization must be exactly the same as its respective preauthorization. The request for preauthorization takes place in real time and results in a withholding of the sales amount from the cardholder’s account. The transaction is not captured and therefore is neither deducted from the cardholder’s account nor credited to the merchant (in the case of debit cards, some issuing entities deduct it from the cardholder’s account, which is then cancelled after a few days). To activate the Deferred Preauthorization service, it is necessary for the merchant to make a specific request at his/her Caixa Catalunya branch. Confirmation of Deferred Preauthorization (Ds_Transaction_Type = ‘P’) This is an inseparable complement to the previous operation. The cardholder is not present, and therefore this is always instigated by the merchant. It should be done within 72 hours of the original preauthorization and the amount must be exactly the same as the original. This transaction is accounted for, being automatically debited from the cardholder’s account and sent for batch processing to be credited to the merchant. The confirmation of the preauthorization is a guaranteed payment and has the same conditions with regard to secure transactions as the original preauthorization. The VIRTUAL POS will validate the existence of the original transaction and the amount that needs to be confirmed, rejecting the transaction if there is any kind of error. Cancellation of Preauthorization (Ds_Transaction_Type = ‘Q’) The cardholder is not present and therefore this is always instigated by the merchant. It can only be done within the 72 hours following the original preauthorization. The VIRTUAL POS will validate the existence of the original transaction, rejecting the transaction if there is any kind of error. Recurring Deferred Preauthorization (Ds_Transaction_Type = ‘R’) This is similar to the recurring transaction and allows the cardholder to subscribe to a regular service offered by the merchant. However, it differs in that the first authorization will not have any accounting validity unless the confirmation is made within 72 hours of the preauthorization. In contrast to traditional preauthorizations, the amount of the confirmation of the Recurring Deferred Preauthorization must be exactly the same as its respective preauthorization.


If confirmation has not been sent within 72 hours of the day/time of the Deferred Preauthorization, the authorization will be cancelled automatically and thus cannot be confirmed. The total amount of this service will be paid by a specific number of instalments. By means of this transaction, the merchant should inform the total amount payable, the minimum number of days before payment of the next instalment can take place, and the deadline for paying the last instalment. Confirmation of Recurring Deferred Preauthorization and Successive Transactions (Ds_Transaction_Type = ‘S’) The same type of transaction is used for both the confirmation of the Recurring Deferred Preauthorization (the first transaction) and the successive payments associated with this first authorization. These form an inseparable part of the previous operation. A new authorization request needs to be made for each instalment. The cardholder is not present and therefore this operation is instigated by the merchant. This transaction is accounted for, being debited from the cardholder’s account for each instalment and sent to the daily settlement process to be credited to the merchant. Successive transactions have the same security conditions as the original recurring transaction, except if the original transaction was regarded as secure but there was no positive authentication of the client. In this case, the successive transactions will not be regarded as secure. The table below shows a summary of the main features of each operation:

Type of operation Instigated by

Accountable Validation of original transaction

Guarantee of secure transaction

Authorization Cardholder YES If conditions allow

Preauthorization Cardholder NO If conditions allow

Confirmation of preauthorization

Merchant YES Preauthorization: 7 days Amount < or =

Same as original

Cancellation of preauthorization

Merchant NO Preauthorization: 7 days Amount =

Automatic refund Merchant YES

Authorization: Sum of returned amounts < or = 120 days

Recurring Cardholder YES If conditions allow

Successive Merchant YES Recurring: amount, instalments and final date

If the original was authenticated

Authentication Cardholder NO If conditions allow

Confirmation of authentication Merchant YES Authentication: 45 days Same as original

Deferred Preauthorization Cardholder NO If conditions allow

Confirmation of Deferred Preauthorization

Merchant YES Preauthorization: 72 hours maximum Amount =

Same as original


Type of operation Instigated

by Accountable Validation of original

transaction Guarantee of secure

transaction

Cancellation of Deferred Preauthorization

Merchant NO Preauthorization: 72 hours maximum

Recurring Deferred Preauthorization Cardholder NO If conditions allow

Confirmation of Recurring Deferred Preauthorization

Merchant YES Preauthorization: 72 hours maximum Amount =


Successive of Recurring Deferred Preauthorization

Merchant YES Recurring Preauthorization: amount, instalments and final date


4.2. OPERATING RESTRICTIONS Given that these transactions take place in a virtual environment, Virtual POS operations are more likely to be subject to fraud, e.g. when it is not actually the cardholder making the purchase. To reduce the risk inherent in these operations, Caixa Catalunya offers the possibility of implementing a series of restrictions on the operating capacity of each merchant. These restrictions must be adapted to values that do not hamper the merchant’s sales prospects but at the same time avoid exaggerated deviations in his regular turnover (in most cases, this would mean that he is subject to attack from stolen and/or fraudulent cards). Maximum number of transactions per day (authorized and declined) Maximum amount per transaction Maximum amount which can be accumulated in one day Maximum number of daily transactions (accepted and declined) per card Maximum daily amount per card Maximum number of daily transactions (accepted and declined) per user (IP address) Maximum daily amount per user (IP address)

If the merchant wishes to modify any of these parameters, he should submit a request to Caixa de Catalunya. 4.3. ADDITIONAL SECURITY MEASURES To protect the interests of the merchant and reduce the volume of incidents as far as possible, we suggest adopting the following additional security measures whenever you accept payments with cards. SIGNS TO DETECT INTERNET FRAUD When one of the following signs is present in an internet purchase, the merchant has to be concerned, but when several appear in a transaction, he must take care to avoid becoming a victim of fraud.

First time shopper. Multiple transactions on one card over a very short period of time. Multiple transactions on one card (o similar cards) with a single billing address, but multiple

shipping addresses. Transactions on similar account numbers.


Orders shipped to a single address but made on multiple cards. Multiple cards used from a single Internet Protocol (IP) address. Orders consisting of several of the same item. Larger than normal orders. Orders made up “rushed” or “overnight”. Crooks want these fraudulently obtained items as soon as

possible for the quickest possible resale and aren‛t concerned about extra delivery charges. Orders made up “big-ticket” items. These items have maximum resale value. Orders from Internet addresses making use of free e-mail services. Orders shipped to an international address.

TRANSACTIONS CONTROLS 1. It is useful that the merchant knows the Internet Protocol address (IP) to identify the computer network source. To determine the IP he can use an own geolocation software or the ADMINISTRATOR MODULE of the CAIXA CATALUNYA VIRTUAL POS (the IP is shown in the QUERY option see section 5.3.). The merchant should check that:

a. The same user (same IP address) has not paid (or tried to pay) with more than two different cards.

b. The same user (IP) or the same card has not made multiple transactions in a short period of time.

c. Purchases are not being made with generated cards (i.e. the first digits of the card numbers are the same but the last ones change).

d. When making different purchases, the same user (IP) or the same card is not recorded on the website with different details.

e. If the POS terminal has rejected the first card transaction, it should be checked that other operations with the same IP or the same card for lower amounts have not been processed.

2. By means of the response message ("Ds_Response" field) or the ADMINISTRATION MODULE of the VIRTUAL POS, you are notified whether the transaction has been accepted (codes 000 to 099) or declined (other codes). The type 2xx refusal codes indicate that the card has been blocked due to loss, robbery, falsification or fraudulent use of the card number. In these cases, the merchant should block the user (identifiable by the IP address and registration details) to prevent him from attempting any new payments.

3. There is also a field in the response message known as "Ds_Card_Country" which gives the ISO code of the country where the card was issued. By comparing this with the IP address of the buyer, you can filter suspected fraudulent behavior (e.g. a card issued in one country but used from an IP address in another country).

4. If the merchant capture the card number, it would be useful to implement a “Mod 10” algorism that quickly check the validity of the card number presented for purchase.

5. Check the validity of the customer’s registration data.

a. Validate telephone numbers using directory lookups. b. Use a telephone code and prefix table to ensure that entered area and telephone prefix are valid for the entered city and state.

c. Use a postcode table to verify that the entered postcode is valid for the entered city and state.

d. Test the validity of the email address by sending an order of confirmation. 6. Establish velocity limits. You can significantly reduce risk exposure by using internal transaction controls to identify highrisk transactions prior to authorization. These controls help determine when an individual cardholder or transaction should be flagged for special review. a. Set review limits based on the number and amount of transactions approved within a specified number of days. Adjust these limits to fit prior purchasing patterns.


b. Set review limits based on single transaction amount. c. Ensure that velocity limits are checked across multiple characteristics, including shipping address, telephone number, and email address.

d. Contact customers that exceed these limits to determine whether the activity is legitimate and should be approved, providing that the issuer also approves it during the authorization process.

e. Do not permit cardholders to use more than one account number per purchase i.e. “split sale”.

Modify transaction controls and velocity limits based upon transaction risk. Vary transaction controls and velocity limits to reflect your risk experience with selected products, shipping locations, and customer purchasing patterns.

7. Use preauthorization transaction type (Ds_Transaction_Type = ‘1/2’ for hotels, travel agencies or car hire

companies, and Ds_Transaction_Type = ‘O/P/Q/R/S’ for the rest of merchants), to authorize the payment orders but do not confirm (therefore does not have any accounting impact on the cardholder’s account) until they have passed the merchant antifraud controls.

8. Payment authentication through 3D Secure (Verified by Visa, MasterCard SecureCode and JCB JSecure) enables de issuer bank to verify the identity of the cardholder during an online purchase, reducing fraudulent usage of cards. Transactions that meet the 3D Secure requirements will qualify for chargeback blocking (see section 3).

9. Use CVV2 code to verify card authenticity. 10. If the merchant has active the daily report of incidences (chargeback’s, confirmed fraud and

retrieval requests) –see section 9, it would be suitable that the merchant security department put in contact with the clients listed, cancel their accounts or subscriptions, add them to their blacklists or take any other measure they deem necessary.

If the transaction does not satisfactorily fulfill all the controls indicated, the merchant must refuse the card as a method of payment and cancel, if applicable, the POS transaction. The merchant’s management and staff must be aware of these security measures and all employees should be trained in how to deal with card payments, and regularly checked to make sure they are complying with these security measures. Should this not be the case, you run the risk of fraudulent transactions reverting to the merchant, and if there are a significant number of reverted or fraudulent transactions, the terminal will be blocked and the contract with Caixa Catalunya rescinded. 4.4. REGULATIONS The Virtual POS, by its very nature, is subject to certain regulations which stem from its use in international payment systems and its management by Caixa Catalunya. These regulations appear in the Retail Establishments Contract signed between Caixa Catalunya and the merchant. Some of the more important of these are listed below: 1. The merchant can only process transactions that originate from the website/s detailed in the

contract with Caixa Catalunya. 2. The website must feature the following information, among other:

2.1 The merchant’s name and that of the website’s owner, whether an individual or


company, must appear on the homepage and the card payment page of the site. 2.2 The merchant’s cancellation and product returns policy. 2.3 The merchant’s shipment and delivery date policy. 2.4 Details of the customer service department and how to access it 2.5 The merchant’s privacy and protection of personal data policy.

3. The merchant should immediately cancel any card transaction when an undue charge has been made or the full sales and delivery process of the goods has not been completed.

4. The merchant may under no circumstances store the details of credit/debit cards in his facility

except when this is necessary for operational purposes, in which case he will be subject to the VISA and MASTERCARD PCI/DSS Security Programme. Even in these circumstances, it is totally forbidden to keep CVV2 numbers.

5. The merchant may only process transactions under the same establishment number which are

covered by the business activity code with which he is registered. Furthermore, in cases where the merchant carries out certain business activities (sale of tobacco or medication, adult content products, airlines and gambling), special authorization will have to be sought in advance from Caixa Catalunya so that the bank can submit a proposal to the card companies.


5. ADMINISTRATION MODULE

5.1. ACCESS

The Administration Module of Caixa Catalunya’s Virtual POS allows the merchant to make refunds, consult the details of transactions made and the total amounts paid by credit/debit cards. To access the Administration Module, the merchant should select the relevant option in the service menu of Caixa Catalunya’s Online Banking system (www.cconline.es), or go to the following Internet address:

https://canales.sermepa.es

5.2. USERS

Caixa Catalunya will provide the merchant with a username/password to access the Administration Module as an administrator. In the user management option it will be possible to register new users with one of the following two access profiles: 1. Informative: for checking movements and totals only. 2. Administrative: as well as checking movements and totals, you can make total or partial

refunds of sales transactions. For security reasons, we recommend you change the passwords. The “Users” section contains the following subsections: 1. Password: this allows you to change the access password with which you are currently

connected. 2. Users: this allows you to perform all the functions relating to queries, registering,

deregistering and modifying merchant users. 3. Generate Users: by using a merchant code and terminal number you can automatically

generate a user with access to the Administration Module with characteristics or permits established by default, and send the details of this user to the email of the merchant in question.

Two kinds of users can be registered: 1. Terminal: for managing transactions made at a specific merchant and terminal. 2. Merchant: for managing transactions made by all a merchant’s terminals.

5.3. CHECKING TRANSACTIONS

In order to check transactions that have taken place during the last 365 calendar days, whether authorized or declined, you should select the QUERIES option on the main page and enter the start and end date relating to the period for which you want to obtain this information. You can not send searches including more that 30 days. In case you need that you must send consecutive queries of 30days periods.

http://www.cconline.es/


If you want to refer to a specific transaction, and you know the purchase reference number, you can also go directly to the details of this transaction. When you have clicked on the ACCEPT button, a screen will appear listing the transactions found within the search dates. The result of the search, as well as being visible on the screen, can be PRINTED or EXPORTED to a text file with fields demarcated by the “;” character:

Date ; Time ; Authorization ; Order ; Purchase (Ptas.) ; Purchase (Euros) ; Refund (Ptas.) ; Refund (Euros) 25/04/2001;13:03:14;Authorized 045803;125747 ;500;3,01;15;0,09 25/04/2001;13:05:23;Declined ;130009 ;500;3,01; 25/04/2001;13:06:05;Authorized 085903;130043 ;500;3,01;3;0,02 30/04/2001;09:54:13;Authorized 043150;094522 ;500;3,01; 30/04/2001;10:02:43;Authorized 045105;095146 ;1425;8,58; 30/04/2001;10:35:07;Authorized 001534;100743 ;3127;18,84;127;0,77

5.4. REFUNDS

The two final columns in the above screen, “Check Refunds” and “Generate Refunds”, allow the merchant to check any refunds made and generate total or partial refunds of the transactions shown. Only users who can access the Administration Module with an administrative profile are authorized to make refunds. The transactions should be viewed by Merchant No. and Terminal No. (usually No. 1, terminal in Euros). To make a partial or total refund of the selected transaction, you should click on the red button in the “Generate Refund” column corresponding to the transaction in question and then a page will appear in which you can enter the amount to be refunded. The refund amount should never exceed the amount of the original transaction. When you have clicked on the ACCEPT button, a page will appear showing the receipt of the refund which can be printed or saved.

5.5. CHECKING TOTALS

By pressing the TOTALS button on the lefthand side of the homepage, a list of the last 45 sessions will appear. Select the required session and press ACCEPT. A screen will then appear showing the total amounts and number of transactions.


6. INSTALLATION This guide provides the information necessary for the merchant/company or its computer systems service to install the Virtual POS on the emerchant’s website. The installation basically consists of entering certain computer instructions in the website which remotely execute the Virtual POS software resident in Caixa Catalunya’s secure server. We recommend that this installation is done by the specialist personnel who look after the maintenance of the merchant’s website. To carry out the first actual checks during the installation phase, we recommend using any fictitious 16digit number sequence. If the installation has been done correctly, the response message from the Virtual POS should read “TRANSACTION DECLINED: INVALID CARD”. When using real cards to do the tests, the transactions will actually go through, for both the merchant and the cardholder. In this case, it is advisable to do the relevant refund transaction to undo the accounting entries in the respective accounts which also offers you the opportunity of checking the refund function. To send the transactions to the Virtual POS of Caixa de Catalunya there are three different gateways. Each one of them is configured for a different way of use.

realizarPago: this is for HTML. This gateway is the most common as it is used when the merchant doesn’t have any contact with the card data. The installation basically consists of entering certain computer instructions in the website which remotely execute the Virtual POS software resident in Caixa Catalunya’s secure server.

entradaXMLEntidad: the purchase form via the virtual POS will consist on a single input. The input value will be the XML document, which must be in the format of x-www-form-urlencoded. This form will be sent via a POST. This allows the merchant to capture card data but also is able to process 3DSECURE transactions. Operaciones: is for HOSTtoHOST transactions that work as an XML conversation. Often used to send refunds, subscriptions, and other operations where the cardholder is not present. It’s not possible to process 3DSECURE transactions.

Merchants that don’t want to get the card data themselves (and to avoid being PCIDSS compliant) must use the realizarpago option. Once the registration process of the Virtual POS has been completed, the merchant will receive the following installation help files by email:

A simulator of the merchant’s Virtual POS made up of:

A payment form implemented in HTML.

A SHA1 implemented in JavaScript.

Examples of SHA1 programming implemented in:

C

CGI in C

JavaJSP

JavaJSP+Bean

JavaScript (not recommended if being installed in the merchant’s own website)

ASP

Perl

PHP

If the merchant’s Internet server needs other languages, the merchant/company should get in contact with Caixa Catalunya’s Technical Installation Support Service.


6.1. GATEWAY ‘realizarPago’

HTML language. This gateway is the most common as it is used when the merchant doesn’t have any contact with the card data. The installation basically consists of entering certain computer instructions in the website which remotely execute the Virtual POS software resident in Caixa Catalunya’s secure server. The payment page of the merchant’s website should include a button for the buyer to associate the payment with his card. This button should be linked to the hidden payment form which is detailed below. When the buyer selects this button, the merchant should send the payment form for the transaction to the Caixa Catalunya server at the following address:

https://sis.sermepa.es/sis/realizarPago The window or frame in which the Virtual POS opens must have vertical and horizontal movement bars so it can be adapted to the different authentication pages that may be shown to the buyer in subsequent processes. The cardholder will inform his card data directly in the Virtual POS webpage of Caixa de Catalunya so the merchant’s website doesn’t have any contact with it. The details which must be included in the payment form are shown in ANNEX I. There is an additional field in the message where the main details relating to the purchase are transmitted in code by the Secure Hash Algorithm (SHA1), see chapter 6.4.

Applications to be installed:

MANDATORY: A payment form installed in the merchant’s website.

MANDATORY: SHA1 installed in the merchant’s Internet server.

OPTIONAL: An application for receiving and processing online responses to payment authorization requests.

Once the cardholder has completed the payment process, the screen showing the result appears which includes a button so the customer can return to shopping on the merchant’s site. The way in which the customer continues his session on the merchant’s website will depend on the instructions associated with the button. These instructions, which the merchant will have given Caixa Catalunya in the questionnaire provided when he registered, may include:

“CLOSE WINDOW” instruction: On selecting , the window or frame showing the payment result closes and the session continues on the merchant’s web page which was in the background. “URL_OK and URL_KO” instruction: On selecting , the browsing session continues on the same payment page, being redirected to a URL that the merchant will have given Caixa Catalunya in advance. This URL can be different depending on whether the payment has been authorized (URL_OK) or declined (URL_KO).

You should bear in mind that if the customer closes the window using the button on

Mark Up Language . . . . . . . . . . . . . . . . . . . HTML Is it 3DSecure available? . . . . . . . . . . . . . YES Can the merchant capture Card Data? . . . NO


the browser, the URL_OK/URL_KO will not work and the session will continue on the webpage in the background. Option for merchants with ONLINE RESPONSE VIA URL: As well as the two previous instructions, for merchants with the ONLINE RESPONSE VIA URL service, the session continuity can be done from the merchant’s own website, closing the payment window as soon as the online response has been received. See chapter 7.1.

During the installation process if, when you send the payment form which remotely executes the Virtual POS application, one error messages appears, this indicates that one of the parameters in the fields sent was wrong. To locate the incorrect field, you should look at the source code of the error page and search in the HTML text for the “SIS” chain. The numerical value xxxx next to the “<!SISxxxx:>” instruction will indicate the type of error, as described in ANNEX III. Also, ANNEX III includes a second table with the message shown to the cardholder in the case of the different errors.

6.2. GATEWAY ‘entradaXMLEntidad’

The purchase form via the virtual POS will consist of a single input. The input value will be the XML document, which must be in the format of x-www-form-urlencoded. This form will be sent via a POST. This allows the merchant to capture card data but also is able to process 3DSECURE transactions. The merchant should provide the information on the purchase to the following Web server address so it can authorize the transaction:

https://sis.sermepa.es/sis/entradaXMLEntidad The window or frame in which the Virtual POS opens must have vertical and horizontal movement bars so it can be adapted to the different authentication pages that may be shown to the buyer in subsequent processes. The data that can be included in the XML document, and which are essential for authorization, are mainly described in ANNEX I. We can identify two types of XML document:

1. DATOSENTRADA: document sent by the merchant 2. NOTIFICACIONXML: document sent by the payment platform in response. For further

details, see section 7.1 of this section. A description of the first document is given below:

Version 1.<fuc_comercio> <!ELEMENT DATOSENTRADA (DS_VERSION, DS_MERCHANT_AMOUNT, DS_MERCHANT_CURRENCY, DS_MERCHANT_ORDER, DS_MERCHANT_MERCHANTCODE,

Mark Up Language . . . . . . . . . . . . . . . . . . . XML (single input) Is it 3DSecure available? . . . . . . . . . . . . . YES Can the merchant capture Card Data? . . . YES


DS_MERCHANT_MERCHANTURL?, DS_MERCHANT_MERCHANTNAME?, DS_MERCHANT_CONSUMERLANGUAGE?, DS_MERCHANT_MERCHANTSIGNATURE, DS_MERCHANT_TERMINAL, DS_MERCHANT_TRANSACTIONTYPE, DS_MERCHANT_MERCHANTDATA ?, DS_MERCHANT_PAN, DS_MERCHANT_EXPIRYDATE, DS_MERCHANT_CVV2?)> <!ELEMENT DS_VERSION (#PCDATA)> <!ELEMENT DS_MERCHANT_AMOUNT (#PCDATA)> <!ELEMENT DS_MERCHANT_CURRENCY (#PCDATA)> <!ELEMENT DS_MERCHANT_ORDER (#PCDATA)> <!ELEMENT DS_MERCHANT_MERCHANTCODE (#PCDATA)> <!ELEMENT DS_MERCHANT_MERCHANTURL (#PCDATA)> <!ELEMENT DS_MERCHANT_MERCHANTNAME (#PCDATA)> <!ELEMENT DS_MERCHANT_MERCHANTSIGNATURE (#PCDATA)> <!ELEMENT DS_MERCHANT_TERMINAL (#PCDATA)> <!ELEMENT DS_MERCHANT_TRANSACTIONTYPE (#PCDATA)> <!ELEMENT DS_MERCHANT_MERCHANTDATA (#PCDATA)> <!ELEMENT DS_MERCHANT_PAN (#PCDATA)> <!ELEMENT DS_MERCHANT_EXPIRYDATE (#PCDATA)> <!ELEMENT DS_MERCHANT_CVV2 (#PCDATA)> Where: DS_VERSION: message version. DS_MERCHANT_AMOUNT: see Annex I DS_MERCHANT_CURRENCY: see Annex I DS_MERCHANT_ORDER: see Annex I DS_MERCHANT_MERCHANTCODE: see Annex I DS_MERCHANT_MERCHANTURL: see Annex I DS_MERCHANT_MERCHANTNAME: see Annex I DS_MERCHANT_MERCHANTSIGNATURE: see section 6.4 DS_MERCHANT_TERMINAL: see Annex I DS_MERCHANT_TRANSACTIONTYPE: see Annex I DS_MERCHANT_MERCHANTDATA: see Annex I DS_MERCHANT_PAN: see Annex I DS_MERCHANT_EXPIRYDATE: see Annex I DS_MERCHANT_CVV2: see Annex I

An example of the message is given below: <DATOSENTRADA> <DS_VERSION>1.999008881</DS_VERSION> <DS_MERCHANT_CURRENCY>978</DS_MERCHANT_CURRENCY> <DS_MERCHANT_TRANSACTIONTYPE>0</DS_MERCHANT_TRANSACTIONTYPE> <DS_MERCHANT_AMOUNT>45</DS_MERCHANT_AMOUNT> <DS_MERCHANT_MERCHANTCODE>999008881</DS_MERCHANT_MERCHANTCODE> <DS_MERCHANT_TERMINAL>1</DS_MERCHANT_TERMINAL> <DS_MERCHANT_ORDER>112545</DS_MERCHANT_ORDER> <DS_MERCHANT_PAN>4548812049400004</DS_MERCHANT_PAN> <DS_MERCHANT_EXPIRYDATE>1205</DS_MERCHANT_EXPIRYDATE> <DS_MERCHANT_CVV2>123</DS_MERCHANT_CVV2> <DS_MERCHANT_MERCHANTSIGNATURE> </DS_MERCHANT_MERCHANTSIGNATURE> </DATOSENTRADA>

In response to the request made, Caixa Catalunya’s payment platform will return an XML document to the merchant with the result of the request. This response document (NOTIFICACIONXML) will be entered in the same way, as a form, in the field known as data after having been put into the format xwwwformurlencoded. The fields this document can have are explained in ANNEX I Example of notification format:

Version 1.<fuc_comercio> <!ELEMENT NOTIFICACIONXML


(Ds_Version, Ds_Amount, Ds_Currency, Ds_Order, Ds_MerchantCode, Ds_Terminal, Ds_Response, Ds_MerchantData?, Ds_SecurePayment, Ds_Card_Number, Ds_ExpiryDate, Ds_Card_Country, Ds_TransactionType, Ds_AuthorisationCode, Ds_Signature, Ds_ErrorCode ?)> <!ELEMENT Ds_Version (#PCDATA)> <!ELEMENT Ds_Amount (#PCDATA)> <!ELEMENT Ds_Currency (#PCDATA)> <!ELEMENT Ds_Order (#PCDATA)> <!ELEMENT Ds_MerchantCode (#PCDATA)> <!ELEMENT Ds_Terminal (#PCDATA)> <!ELEMENT Ds_Response (#PCDATA)> <!ELEMENT Ds_MerchantData (#PCDATA)> <!ELEMENT Ds_SecurePayment (#PCDATA)> <!ELEMENT Ds_Card_Number (#PCDATA)> <!ELEMENT Ds_ExpiryDate (#PCDATA)> <!ELEMENT Ds_Card_Country (#PCDATA)> <!ELEMENT Ds_TransactionType (#PCDATA)> <!ELEMENT Ds_AuthorisationCode (#PCDATA)> <!ELEMENT Ds_Signature (#PCDATA)> <!ELEMENT Ds_ErrorCode (#PCDATA)> Where: Ds_Version: version of DTD to validate XML message. Ds_Amount: amount of transaction. Ds_Currency: transaction currency. Ds_Order: transaction order. Ds_Signature: same fields as online notification of a normal transaction. Ds_MerchantCode: merchant’s code of the transaction. Ds_Terminal: POS terminal number of the transaction. Ds_Response: figure showing the result of the transaction, indicating whether it has been authorized or not. Its possible values are those of PRICE. Ds_AuthorisationCode: authorization code, if applicable. Ds_TransactionType: type of transaction. Ds_MerchantData: see table. Ds_SecurePayment: see table. Ds_Card_Number: card number. Ds_ExpiryDate: month and year of card expiry date in YYMM format. Ds_Card_Country: country of card issue. Ds_ErrorCode: optional field which will appear if an error is detected while the transaction is being processed.

An example of the message is given below:

<NOTIFICACIONXML> <Ds_Version>1.XXXX</Ds_Version> <Ds_Amount>100</Ds_Amount> <Ds_Currency>978</Ds_Currency> <Ds_Order>0001</Ds_Order> <Ds_MerchantCode>999008881</Ds_MerchantCode> <Ds_Terminal>1</Ds_Terminal> <Ds_Response>0</Ds_Response> <Ds_MerchantData>Mis Datos</ Ds_MerchantData> <Ds_SecurePayment>1</Ds_SecurePayment> <Ds_Card_Number>9999999999999999999</Ds_Card_Number> <Ds_ExpiryDate>0204</Ds_ExpiryDate> <Ds_TransactionType>0</ Ds_TransactionType > <Ds_AuthorisationCode>222FFF</ Ds_AuthorisationCode> <Ds_Signature>…………………………</Ds_Signature>

</NOTIFICACIONXML>


In the same way that section 6.4. explains the procedure for calculating the signature which protects the data of the transaction generated by the merchant. If the merchant wishes to receive an online response to its requests, the system will provide a signature which, in turn, guarantees the integrity of responses. By default, the Virtual POS can communicate with ports 80, 443, 8080 and 8081 of the merchant. Other ports need to be consulted. Once the merchant has received the form, the response code (Ds_Response) will indicate whether the transaction has been accepted or, if not, the reason for its refusal. The possible values in this field and their meanings can be referred to in ANNEX II. It is important to notice that this option entails complying with the requirements of the PCIDSS security programme explained in section 11 of this manual. If during the installation process one error messages appeared, it would indicate that one of the parameters in the fields sent was wrong. To locate the incorrect field, you should search the text for the “SIS” chain. The numerical value xxxx next to the “<!SISxxxx:>” instruction will indicate the type of error, as described in ANNEX III. Also, ANNEX III includes a second table with the message shown to the cardholder in the case of the different errors.

6.3. GATEWAY ‘Operaciones’

It is for HOSTtoHOST transactions working as an XML conversation. Often used to send refunds, subscriptions, and other operations where the cardholder is not present. It’s not possible to process 3DSECURE transactions. It is very important to bear in mind that this resource is only valid for the following types of transactions (Ds_Merchant_TransactionType), because as the cardholder is not present he cannot be authenticated (3D Secure Environment):

1Preauthorization (only if the merchant is authorized to perform this type of operation and is working in nonsecure mode)

2Confirmation of preauthorization 3Automatic refund 6Successive transactions 8Confirmation of authentication 9Cancellation of preauthorizations ANonsecure payment without authentication (by default, this operation is not permitted and can only be done with prior authorization from Caixa Catalunya).

ODeferred Preauthorization PConfirmation of Deferred Preauthorization QCancellation of Deferred Preauthorization RDeferred Recurring Preauthorization SConfirmation of Deferred Recurring Preauthorization / Successive of Deferred Recurring Preauthorization

The communication is done by sending the XML document to the address indicated by the Virtual POS. The system will interpret the XML document and make the relevant validations, after which it

Mark Up Language . . . . . . . . . . . . . . . . . . . XML Is it 3DSecure available? . . . . . . . . . . . . . NO Can the merchant capture Card Data? . . . YES


will process the transactions. Depending on the result of the transaction, a response XML document is set up with the result. The XML document is sent by a POST dispatch to the following address:

https://sis.sermepa.es/sis/operaciones The document is sent by simulating the request made by a form whose only input is known as “entrada”. The value of the “entrada” is the XML document, which should be in the following format: xwwwformurlencoded. It is important to notice that this option entails complying with the requirements of the PCIDSS security programme explained in section 11 of this manual. Two types of message are defined as follow:

1. DATOSENTRADA: Request message sent. 2. RETORNOXML: Response to request.

The fields these messages can contain are explained in ANNEX I 1. Specification of the DATOSENTRADA document. This message is sent to the Virtual POS platform to request a transaction: Version 1.0: <!ELEMENT DATOSENTRADA (DS_Version, DS_MERCHANT_AMOUNT, DS_MERCHANT_CURRENCY, DS_MERCHANT_ORDER, DS_MERCHANT_MERCHANTCODE, DS_MERCHANT_MERCHANTURL, DS_MERCHANT_MERCHANTNAME ?, DS_MERCHANT_CONSUMERLANGUAGE ?, DS_MERCHANT_MERCHANTSIGNATURE, DS_MERCHANT_TERMINAL, DS_MERCHANT_TRANSACTIONTYPE, DS_MERCHANT_MERCHANTDATA ?, DS_MERCHANT_PAN?, DS_MERCHANT_EXPIRYDATE ?, DS_MERCHANT_CVV2 ?)>

<!ELEMENT DS_Version (#PCDATA)> <!ELEMENT DS_MERCHANT_AMOUNT (#PCDATA)> <!ELEMENT DS_MERCHANT_CURRENCY (#PCDATA)> <!ELEMENT DS_MERCHANT_ORDER (#PCDATA)> <!ELEMENT DS_MERCHANT_MERCHANTCODE (#PCDATA)> <!ELEMENT DS_MERCHANT_MERCHANTURL (#PCDATA)> <!ELEMENT DS_MERCHANT_MERCHANTNAME (#PCDATA)> <!ELEMENT DS_MERCHANT_CONSUMERLANGUAGE (#PCDATA)> <!ELEMENT DS_MERCHANT_MERCHANTSIGNATURE (#PCDATA)> <!ELEMENT DS_MERCHANT_TERMINAL (#PCDATA)> <!ELEMENT DS_MERCHANT_TRANSACTIONTYPE (#PCDATA)> <!ELEMENT DS_MERCHANT_MERCHANTDATA (#PCDATA)> <!ELEMENT DS_MERCHANT_PAN (#PCDATA)> <!ELEMENT DS_MERCHANT_EXPIRYDATE (#PCDATA)> <!ELEMENT DS_MERCHANT_CVV2 (#PCDATA)> Where: - DS_MERCHANT_TRANSACTIONTYPE: only allows the following types: 1, 2, 3, 6, 8, 9, O, P, Q, R, S, A - DS_MERCHANT_AUTHORIZATIONCODE: only valid for refunds of recurring/successive transactions - DS_MERCHANT_TRANSACTIONDATE: only valid for refunds of recurring/successive transactions

https://sis.sermepa.es/sis/operaciones


See ANNEX I for explanations of each field. An example of the message is shown below: <DATOSENTRADA>

<DS_Version> 1.0 </DS_Version> <DS_MERCHANT_CURRENCY> 978 </DS_MERCHANT_CURRENCY> <DS_MERCHANT_MERCHANTURL> https://pruebaCom.jsp

</DS_MERCHANT_MERCHANTURL> <DS_MERCHANT_TRANSACTIONTYPE>

2 </DS_MERCHANT_TRANSACTIONTYPE> <DS_MERCHANT_MERCHANTDATA>

Pad+for+mouse </DS_MERCHANT_MERCHANTDATA> <DS_MERCHANT_AMOUNT>

45 </DS_MERCHANT_AMOUNT> <DS_MERCHANT_MERCHANTNAME>

Comercio de Pruebas </DS_MERCHANT_MERCHANTNAME> <DS_MERCHANT_MERCHANTSIGNATURE>

a63dfa507e549936f41f4961ccdace126b8ecdea </DS_MERCHANT_MERCHANTSIGNATURE> <DS_MERCHANT_TERMINAL>

1 </DS_MERCHANT_TERMINAL> <DS_MERCHANT_MERCHANTCODE>

999008881 </DS_MERCHANT_MERCHANTCODE> <DS_MERCHANT_ORDER>

114532 </DS_MERCHANT_ORDER> </DATOSENTRADA> 2. Specification of RETORNOXML document. This message is the one sent by the platform as a result of the transaction. <!ELEMENT RETORNOXML (Ds_Version ?,CODE,(OPERACION|RECIBIDO ))> <!ELEMENT Ds_Version (#PCDATA)> <!ELEMENT CODE (#PCDATA)> <!ELEMENT OPERACION (Ds_Amount, Ds_Currency, Ds_Order, Ds_Signature, Ds_MerchantCode, Ds_Terminal, Ds_Response, Ds_AuthorizationCode,Ds_TransactionType, Ds_SecurePayment, Ds_Reference ?, Ds_Language ?, Ds_CardNumber ?, Ds_ExpiryDate ?, Ds_MerchantData ?, Ds_MerchantDTD)>

<!ELEMENT Ds_Amount (#PCDATA)> <!ELEMENT Ds_Currency (#PCDATA)> <!ELEMENT Ds_Order (#PCDATA)> <!ELEMENT Ds_Signature (#PCDATA)> <!ELEMENT Ds_MerchantCode (#PCDATA)> <!ELEMENT Ds_Terminal (#PCDATA)> <!ELEMENT Ds_Response (#PCDATA)> <!ELEMENT Ds_AuthorizationCode (#PCDATA)> <!ELEMENT Ds_TransactionType (#PCDATA)> <!ELEMENT Ds_SecurePayment (#PCDATA)> <!ELEMENT Ds_Reference (#PCDATA)> <!ELEMENT Ds_Language (#PCDATA)> <!ELEMENT Ds_CardNumber (#PCDATA)> <!ELEMENT Ds_ExpiryDate (#PCDATA)> <!ELEMENT Ds_MerchantData (#PCDATA)> <!ELEMENT RECIBIDO (#PCDATA)>

Where:

- Ds_Version: version of the DTD used to validate the XML.


- CODE: indicates whether the transaction is correct or not (it does not indicate whether it has been authorized, only whether it has been processed). A 0 indicates that the operation has been processed correctly. If a 0 does not appear, the error code will appear but not any information on the transaction. CODE is not the Ds_Response; a transaction can have a CODE = 0 and still be declined (Ds_Response different from 0).

- RECEIVED: this is a text chain which contains the XML that the merchant sent by POST in the entry field.

The Ds_Version field will only appear if the transaction has been processed correctly as it is a value sent by the merchant; if not correct, the data will go in the RECEIVED field. Three examples of messages appear below: 1 Transaction correct and authorized: <RETORNOXML>

<DS_Version>1.0</DS_Version> <CODE>0</CODE> <OPERACION>

<Ds_Amount>100</Ds_Amount> <Ds_Currency>978</Ds_Currency>

<Ds_Order>0001</Ds_Order> <Ds_Signature>EEFF45687hgth</Ds_Signature> <Ds_MerchantCode>999008881</Ds_MerchantCode> <Ds_Terminal>1</Ds_Terminal> <Ds_Response>0</Ds_Response> <Ds_AuthorizationCode>222FFF</ Ds_AuthorizationCode> <Ds_TransactionType>2</ Ds_TransactionType > <Ds_SecurePayment>1</Ds_SecurePayment> <Ds_MerchantData>Mis Datos</ Ds_MerchantData>

</OPERACION> </RETORNOXML> 2 – Transaction correct but declined (190 – Declined by the issuer bank): <RETORNOXML>

<DS_Version>1.0</ DS_Version > <CODE>0</CODE> <OPERACION>

<Ds_Amount>100</Ds_Amount> <Ds_Currency>978</Ds_Currency>

<Ds_Order>0001</Ds_Order> <Ds_Signature>EEFF45687hgth</Ds_Signature> <Ds_MerchantCode>999008881</Ds_MerchantCode> <Ds_Terminal>1</Ds_Terminal> <Ds_Response>190</Ds_Response> <Ds_AuthorizationCode>222FFF</ Ds_AuthorizationCode> <Ds_TransactionType>2 Ds_TransactionType > <Ds_SecurePayment>1</Ds_SecurePayment> <Ds_MerchantData>Mis Datos</ Ds_MerchantData>

</OPERACION> </RETORNOXML> 3 – Transaction incorrect (051 – order number repeated). This will never be authorized: <RETORNOXML>

<CODE>SIS0051</CODE> <RECIBIDO>

<DATOSENTRADA> <DS_MERCHANT_CURRENCY>

978 </DS_MERCHANT_CURRENCY> <DS_MERCHANT_MERCHANTURL>

https://pruebaCom.jsp </DS_MERCHANT_MERCHANTURL> <DS_MERCHANT_TRANSACTIONTYPE>

2 </DS_MERCHANT_TRANSACTIONTYPE> <DS_MERCHANT_MERCHANTDATA>

Pad+for+mouse </DS_MERCHANT_MERCHANTDATA> <DS_MERCHANT_AMOUNT>

45


</DS_MERCHANT_AMOUNT> <DS_MERCHANT_MERCHANTNAME>

Comercio de Pruebas </DS_MERCHANT_MERCHANTNAME> <DS_MERCHANT_MERCHANTSIGNATURE>

a63dfa507e549936f41f4961ccdace126b8ecdea </DS_MERCHANT_MERCHANTSIGNATURE> <DS_MERCHANT_TERMINAL>

1 </DS_MERCHANT_TERMINAL> <DS_MERCHANT_MERCHANTCODE>

999008881 </DS_MERCHANT_MERCHANTCODE> <DS_MERCHANT_ORDER>

114532 </DS_MERCHANT_ORDER> <DS_Version>

1.0 </ DS_Version >

</DATOSENTRADA> </RECIBIDO>

</RETORNOXML>

If during the installation process one error messages appeared, it would indicate that one of the parameters in the fields sent was wrong. To locate the incorrect field, you should search the text for the “SIS” chain. The numerical value xxxx next to the “<!SISxxxx:>” instruction will indicate the type of error, as described in ANNEX III. Also, ANNEX III includes a second table with the message shown to the cardholder in the case of the different errors.

6.4. DESIGN OF HASH ALGORITHM IN INTERNET SERVER

Caixa de Catalunya will provide the merchant a code to be used to sign the details provided by him, which not only allows the merchant’s identification to be verified but also that the details have not been changed at any time. It will be used as a security protocol in the public Secure Hash Algorithm (SHA1) which guarantees the minimum security requirements in terms of authentication of origin. This same algorithm is also used so the merchant can be assured of the authenticity of the response details in the event that the merchant opts for URL notification. The SHA1 code is not available for PHP versions lower than 4.3.0. If your server uses a previous version, please get in contact with Caixa Catalunya’s technical support service to find an alternative solution. The calculation of the algorithm is different depending on the gateway you’re working on: GATEWAY ‘realizarPago’ There are two possible cases for calculating the electronic signature: • For transactions with Ds_Merchant_TransactionType ≠ ‘5’ or ‘R’: the merchant’s electronic signature should be calculated thus:

Digest=SHA1(Ds_Merchant_Amount+Ds_Merchant_Order + Ds_Merchant_MerchantCode + Ds_Merchant_Currency + Ds_Merchant_TransactionType + Ds_Merchant_MerchantURL + SECRET CODE)

• For transactions with Ds_Merchant_TransactionType = ‘5’ or ‘R’ (INITIAL RECURRING PAYMENT): the merchant’s electronic signature should be calculated thus:


Digest=SHA1(Ds_Merchant_Amount + Ds_Merchant_Order + Ds_Merchant_MerchantCode + Ds_Merchant_Currency + Ds_Merchant_SumTotal + Ds_Merchant_TransactionType + Ds_Merchant_MerchantURL + SECRET CODE)

If the merchant did not have an online URL notification, the Ds_Merchant_MerchantURL field should be left blank. Example

AMOUNT (Ds_Merchant_Amount) = 1235 (multiplied by 100 to come out the same as the Ds_Merchant_Amount). ORDER NUMBER (Ds_Merchant_Order) = 29292929 MERCHANT CODE (Ds_Merchant_MerchantCode) = 201920191 CURRENCY (Ds_Merchant_Currency) = 978 SECRET CODE = h2u282kMks01923kmqpo Resulting chain: 123529292929201920191978h2u282kMks01923kmqpo SHA1 result: c8392b7874e2994c74fa8bea3e2dff38f3913c46

GATEWAYS ‘entradaXMLEntidad’ and ‘operaciones’ The merchant’s electronic signature should be calculated as follows:

Digest = SHA1(Ds_Merchant_Amount + Ds_Merchant_Order + Ds_Merchant_MerchantCode+ Ds_Merchant_Currency + Ds_Merchant_Pan + Ds_Merchant_MerchantURL(3) + Ds_Merchant_Sumtotal (1) + Ds_Merchant_CVV2 (2) + Ds_Merchant_TransactionType + SECRET CODE)

(1) Only if it is the first of a RECURRING payment (Ds_Transaction_Type = ‘5’ or ‘R’) (2) Only if the CVV2 is given (3) Only for ‘entradaXMLgateway’

Is very important to notice that is forbidden to store the CVV2, even if you’re planning to use it in the Successive Transactions (Ds_Transaction_Type = ‘6’ or ‘S’) coming from the recurrent transactions (‘5’ or ‘R’). For this reason you don’t have to write the CVV2 when you’re sending the Successive transaction (‘6’ or ‘S’) and when calculating the signature of this transaction.

Example (of conventional signature):

AMOUNT=1235 (multiplied by 100 so it is equal to the Ds_Merchant_Amount). ORDER NUMBER=29292929 MERCHANT CODE=999008881 CURRENCY=978 CARD NO=4548812049400004 MERCHANT URL=http://www.sermepa.es MERCHANT SIGNATURE=h2u282kMks01923kmqpo Resulting chain: 1235292929292019201919784548810000000003 SHA1 result: 8cbd9137533846152fc3b8921d909742e6b87f8e

For these two gateways, the same algorithm will be used to assure the merchant of the authenticity of the response data if the merchant uses a URL notification system. In the RETORNOXML document

- Ds_Signature= SHA1 (Ds_Amount + Ds_Order + Ds_MerchantCode + Ds_Currency + Ds_Response +

Ds_CardNumber + Ds_TransactionType + Ds_SecurePayment + SECRET CODE) The Ds_CardNumber field will only form part of the signature if the card number is sent. If the card is sent with an asterisk, the Ds_CardNumber field will also form part of the signature with the value asterisked.


You should remember that: Once the signature has been generated, you should not modify the data in any way as the POS will use it to validate the signature. If the information received is not exactly the same as that used to generate the signature, the platform will reject the transaction. The Amount will be multiplied by 100, with no decimal points and no zeros to the left. The order number should be different for each transaction and the first 4 positions should be numerical.

The secret code must NEVER be divulged, nor should it appear in the source code of the merchant’s website, nor should it be accessible in the website file structure. The calculation of the SHA-1 should be implemented in the private part of the merchant’s Internet server. If the merchant’s domain is in a different server under a hosting or similar formula, he should get in contact with his supplier to find out the method of implementing the encryption algorithm.

Caixa Catalunya provides examples of connections with the POS terminal in different programming languages. SHA1 references: - Standard for the Secure Hash Standard, FIPS PUB 1801. http://www.itl.nist.gov/fipspubs/fip1801.htm

http://csrc.nist.gov/publications/fips/fips1801/fips1801.pdf - List of DSA Validated Implementations:

http://csrc.nist.gov/cryptval/dss/dsaval.htm - Specifications of the Secure Hash Standard (SHA1):

http://csrc.nist.gov/cryptval/shs.html - What are SHA and SHA1?

http://www.rsasecurity.com/rsalabs/faq/365.html

6.5. TECHNICAL INSTALLATION SUPPORT SERVICE

Caixa Catalunya offers to merchants and companies who wish to install a Virtual POS the services of its Technical Installation Support Service, which will be delighted to help with any technical or operational queries free of charge.

Similarly, for any incidents concerning communications, system instability or similar problems, Caixa Catalunya offers the 24hour 365day helpline on tel. 902198747. This telephone will not help in any other incidence or question.

[email protected]

Tel. 902 110 558 (34) 93 479 9191 for international calls

Times of service:

WINTER: 16 September – 30 June Monday - Thursday 8 am – 6 pm Friday 8 am – 3 pm

SUMMER: 1 July – 15 September Monday - Friday 8 am – 3 pm.


7. OTHER TECHNICAL INFORMATION 7.1. ONLINE RESPONSE If the merchant wants to see the result of the payments immediately after they have been made, there are four response mechanisms which can coexist simultaneously: 1. By going to the Administration Module via the Internet.

You can check, print or export to files the transactions made in the last 45 days. 2. By receiving a file with a list of transactions.

The file is generated on a regular basis (usually every day) and sent to an email address in encrypted form.

3. By consulting SOAP. This allows the merchant to consult transactions using SOAPXML technology.

4. Only in the gateways “entradaXMLEntidad” and “operaciones”, a XML document is returned to the merchant with the result of the request.

5. By implementing the Online Response solution.

This means that at the same time as the cardholder receives the response to the card payment request, the merchant’s website receives a message with the same information.

There are two possible ways of receiving the Online Response, which can be combined, either using both at the same time or one of them as a back up if the other fails:

Via email: reception of the response to the payment authorization request at the email address provided by the merchant on registering for the Virtual POS.

Via URL: reception of the response at the URL address given on the payment form. This option requires a simple computer adjustment on the merchant’s website to facilitate reception of the response and integrate it in the merchant’s database. This option is only valid for merchants with an active verification field installed. This is our recommended option. To implement the online response via URL, a URL address where responses should be sent will need to be given on the payment request form (Ds_Merchant_MerchantURL field). This URL should be a CGI, Servlet or similar in the language regarded as appropriate for the merchant’s server to be able to interpret the response sent from the Virtual POS. This page will be transparent to the user (i.e. it will not be loaded on the browser). On it, you will be able to receive and compile details of online responses and add them to your database. The protocol used for responses via URL can be http or https. The message format is an HTML form sent using the POST method with the fields shown in Annex I.

As in the request to pay for a purchase, the online response includes an electronic signature that guarantees the integrity of the responses. The algorithm will be the same, and the formula for calculating it is:

Digest=SHA-1(Ds_ Amount + Ds_ Order + Ds_MerchantCode + Ds_ Currency + Ds _Response +

+ SECRET CODE) The connection used for notifying the online confirmation between the Virtual POS and the merchant can be SSL (see annex V). To prevent fraudulent communications, the merchant may optionally activate a filter to limit the reception of online confirmations from the Virtual POS only.


By default, the Virtual POS can communicate with ports 80, 443, 8080 and 8081 of the merchant. Other ports will need to be discussed with Caixa Catalunya’s technical support service. When the merchant receives the form, the values of the response code indicate whether the transaction has been approved or declined, and in the latter case the reason for the refusal. The list of values can be found in ANNEX II. The Virtual POS will send online notifications for purchase transactions which are authorized or declined by the card issuer, as well as in situations where the purchasing process has been interrupted due to one of the following errors:

SIS0051 -> Order repeated. Notification with code 913 sent. SIS0078 -> Method of payment not available for this card. Notification with code 118 sent. SIS0093 -> Card not valid. Notification with code 180 sent. SIS0094 -> Error – call to MPI not checked. Notification with code 184 sent.

7.2. RECURRING TRANSACTIONS

A recurring transaction is one where the purchase is made in instalments, for example the payment of regular subscriptions or deferred payments. Caixa Catalunya’s Virtual POS terminal is certified so that recurring transactions made with Visa or MasterCard cards via the Internet where a positive authentication has been made of the cardholder cannot be reversed by the cardholder if he/she then claims not to have made the purchase. In order to process recurring transactions you need to request authorization by means of the Virtual POS payment form, completing different fields depending on whether it is the first instalment (recurring transaction) or subsequent instalments (successive transactions):

FIELD NAME MANDATORY OPTIONAL NO INFORMATION

Ds_Merchant_Amount Recurring/Successive

Ds_Merchant_Currency Rec. /Suc.

Ds_Merchant_Order Rec. /Suc. (same value for all transactions)

Ds_Merchant_MerchantCode Rec. /Suc.

Ds_Merchant_MerchantURL Rec. /Suc.

Ds_Merchant_MerchantName Rec. /Suc.

Ds_Merchant_ConsumerLanguage Rec. /Suc.

Ds_Merchant_MerchantSignature Rec. /Suc.

Ds_Merchant_Terminal Rec. /Suc.

Ds_Merchant_MerchantData Rec. /Suc.

Ds_Merchant_Transaction_Type Rec. (value “5” or “R”)/Suc.(value “6” or “S”)

Ds_Merchant_DateFrecuency Recurring Successive

Ds_Merchant_ChargeExpiryDate Recurring Successive

Ds_Merchant_SumTotal Recurring Successive


Is very important to notice that is forbidden to store the CVV2, even if you’re planning to use it in the Successive Transactions (Ds_Transaction_Type = ‘6’ or ‘S’) coming from the recurrent transactions (‘5’ or ‘R’). For this reason you don’t have to write the CVV2 when you’re sending the Successive transaction (‘6’ or ‘S’) and when calculating the signature of this transaction. 7.3. TEST ENVIRONMENT To carry out installation tests, Caixa Catalunya has enabled a test environment so the merchant can make transactions in an environment which is identical to the real one, but without the sales having any accounting validity. The characteristics of the test environment are detailed below:

Payment URLs: GATEWAY ‘realizarpago‛: https://sis-t.sermepa.es:25443/sis/realizarPago

GATEWAY ‘entradaXMLentidad‛: https://sis-t.sermepa.es:25443/sis/entradaXMLEntidad GATEWAY ‘operaciones‛: https://sis-t.sermepa.es:25443/sis/operaciones Merchant code (Ds_Merchant_MerchantCode): 091358382 SECRET CODE (Ds_Merchant_MerchantSignature): qwertyasdf0123456789 Terminal numbers (Ds_Merchant_Terminal):

001 – For payments in EUROS (Ds_MerchantCurrency = 978) to merchants protected by VERIFIED BY VISA and MASTERCARD SECURECODE

002 – For payments in EUROS (Ds_MerchantCurrency = 978) to merchants in a NON-SECURE environment

Cards accepted in the test environment: For 001 terminals (VbV and MasterCard SecureCode environments): card 4548

8120 4940 0004 (expiry date 12/05). This card has been activated to simulate a cardholder who needs to authenticate him/herself with the bank. To do so, you need to enter the ID code 123456.

For 002 terminals (NON-SECURE environment), any expiry date later than the present date and earlier than 12/49 can be used:

4792-5877-6655-4414 4792-5877-6655-4422 4792-5877-6655-4430 4792-5877-6655-4448 4792-5877-6655-4455

URL administration module: https://sis-t.sermepa.es:25443/sis/admin/caixacat/ Access to administration module:

For 001 terminals - USERNAME: test1 PASSWORD: 123456 For 002 terminals - USERNAME: test2 PASSWORD: 123456

If you want to do the tests using your own merchant identification, please to put in contact with the TECHNICAL INSTALLATION SUPPORT SERVICE (see section 6.5). The test merchant that Caixa Catalunya will provide you, it will have the same configuration that your merchant in real environment (same Merchant Id., same terminals configuration, same users to access to the Administration Module, …).

https://sis-t.sermepa.es:25443/sis/admin/caixacat/

https://sis-t.sermepa.es:25443/sis/realizarPago

https://sis-t.sermepa.es:25443/sis/entradaXMLEntidad


In the test environment, payments in EUROS are authorized against the test server for Spanish SERVIRED cards. If you want to run a test in a different currency or for a nonSpanish card, it will be necessary to arrange a session with the computer systems services of the international card companies (Visa, MasterCard, JCB, Diners Club or American Express) who administer the authorization centers for this environment.

For this reason, to avoid any delays in carrying out the tests, we recommend that you only do test transactions in EUROS with the Spanish cards detailed above, reserving transactions in other currencies or with other cards for a real situation.


8. QUERIES ON TRANSACTIONS VIA SOAPXML SOAP is a standard XMLbased protocol which allows communications with Web services. SOAP provides a simple, consistent mechanism for sending XML messages to another application. By using the SOAP protocol, Caixa Catalunya’s virtual payment platform allows the merchant to obtain information on his transactions by two possible mechanisms:

Online queries SOAP synchronization

8.1. ONLINE QUERIES By using this service, merchants can query specific transactions regardless of whether there has been a response to them or not. The online query service offers the possibility of obtaining information on all transactions that have been initiated. There are two types of queries: by transaction and by monitor. The query by transaction allows you to obtain information on a certain type of transaction (e.g. Authorization) relating to an order, while the query by monitor gives you information on all the transaction types (e.g. Authorization and Refund) associated with an order number. The possible values of a query by transaction are:

<Ds_TransactionType> = 0 (normal payment transaction) <Ds_TransactionType> = 1 (unconfirmed preauthorization) <Ds_TransactionType> = 4 (payment by reference) <Ds_TransactionType> = 5 (recurring payment) <Ds_TransactionType> = 7 (authentication) <Ds_TransactionType> = A (traditional payment)

The online query service is implemented with SOAPXML technology (Simple Object Access Protocol). This service offers a reliable and simple way of obtaining all the information on a specific transaction requested by the merchant. The person requesting this service should submit a query which will return the results of the data requested. 8.1.a. SOAP CLIENT Detailed below is an example of a SOAP client. SOAP clients should take the following steps:

A. – Give the URL of the SOAP service you want to access: E.g. URL = new URL("http://smp3006/soap/rpcrouter");

B. Create a SOAPMappingRegistry object:

E.g. SOAPMappingRegistry smr = new SOAPMappingRegistry();

C. Create a Call type object with the following details:

SOAPMappingRegistry (previously created) TargetObjectURI. URL of messaging service.


MethodName. Method you want to access. EncodingStyleURI. Constant. Vector with query parameters. E.g.: Call call = new Call(); call.setSOAPMappingRegistry(smr); call.setTargetObjectURI("urn:mensajeriaCIBERPAC"); call.setMethodName("procesaMensajeRecibido"); call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC); Vector params = new Vector(); params.addElement(new Parameter("Mensaje", String.class, xml_doc, null)); call.setParams(params);

D. Invoke the URL of the SOAP service which will return a Response object:

E.g.: Response resp=null; resp = call.invoke(url, ""); Parameter ret = resp.getReturnValue(); Object value = ret.getValue();

Example of JAVA SOAP client (SERVLET)

import java.util.*; import javax.servlet.*; import javax.servlet.http.*; import java.io.*; Import java.net. *; import org.apache.soap.*; import org.apache.soap.messaging.*; import org.apache.soap.transport.*; import org.apache.soap.util.xml.*; import org.apache.soap.encoding.*; import org.apache.soap.encoding.soapenc.*; import org.apache.soap.rpc.*; public class SerSvlCIBERPAC extends HttpServlet public void doPost(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException String respuesta = ""; try String xml_doc = req.getParameter("elXMLEnvio"); respuesta = ejecutaCallRPCStyle(xml_doc); catch(Exception e) e.printStackTrace(); public String ejecutaCallRPCStyle(String xml_doc) throws ServletException, IOException String respuesta = ""; String encodingStyleURI = Constants.NS_URI_SOAP_ENC; URL url = new URL("http://smp3006/soap/rpcrouter"); SOAPMappingRegistry smr = new SOAPMappingRegistry(); Call call = new Call(); call.setSOAPMappingRegistry(smr); call.setTargetObjectURI("urn:mensajeriaCIBERPAC"); call.setMethodName("procesaMensajeRecibido"); call.setEncodingStyleURI(encodingStyleURI); Vector params = new Vector(); params.addElement(new Parameter("Mensaje", String.class, xml_doc, null)); call.setParams(params); Response resp=null; try resp = call.invoke(url, ""); catch (SOAPException e) e.printStackTrace();


if (!resp.generatedFault()) Parameter ret = resp.getReturnValue(); Object value = ret.getValue(); respuesta = (String) value; else Fault fault = resp.getFault(); respuesta = fault.getFaultString(); return (respuesta);

8.1.b. XML SEND AND RESPONSE This annex details how an XMLSCHEMA describes the incoming and outgoing messages of the Web service for transactions queries.

<schema targetNamespace="http://www.w3.org/namespace/" xmlns:t="http://www.w3.org/namespace/" xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="unqualified" attributeFormDefault="unqualified"> <element name="Messages"> <complexType>

<sequence> <element ref="t:Version"/> <element ref="t:Signature"/> </sequence> </complexType> </element> <element name="Version"> <complexType> <sequence maxOccurs="unbounded"> <element ref="t:Message"/> </sequence> <attribute name="Ds_Version" type="string" use="required"/> </complexType> </element> <element name="Message">

<complexType> <choice> <element ref="t:Transaction"/> <element ref="t:Monitor"/> <sequence minOccurs="0" maxOccurs="unbounded"> <element ref="t:Response"/> </sequence> <element ref="t:ErrorMsg"/> </choice> </complexType>

</element> <element name="Transaction"> <complexType> <sequence> <element ref="t:Ds_MerchantCode"/> <element ref="t:Ds_Terminal"/> <element ref="t:Ds_Order"/> <element ref="t:Ds_TransactionType"/> <element ref="t:Ds_Merchant_Data" minOccurs="0"/> </sequence> </complexType> </element> <element name="Monitor"> <complexType> <sequence>

<element ref="t:Ds_MerchantCode"/> <element ref="t:Ds_Terminal"/>


<minLength value="13"/> <maxLength value="19"/> </restriction> </simpleType> </element> <element name="Ds_ExpiryDate"> <simpleType> <restriction base="string"> <length value="4"/> </restriction> </simpleType> </element> <element name="Ds_TelephoneNumber" type="int"/> <element name="Ds_SecurePayment"> <simpleType> <restriction base="short"> <minInclusive value="0"/> <maxInclusive value="1"/> </restriction> </simpleType> </element> <element name="Ds_State" type="string"/> <element name="Ds_Response" type="int"/> <element name="ErrorMsg"> <complexType> <sequence> <element ref="t:Ds_ErrorCode"/> </sequence> </complexType> </element> <element name="Ds_ErrorCode"> <complexType mixed="true"/> </element> <element name="Signature" type="string"/>

</schema> Based on this XMLSCHEMA, shown below is an example of an incoming message and an outgoing message. EXAMPLE OF SEND MESSAGE:

<Messages> <Version Ds_Version="0.0"> <Message> <Transaction> <Ds_MerchantCode>111111111</Ds_MerchantCode> <Ds_Terminal>1</Ds_Terminal> <Ds_Order>132600</Ds_Order> <Ds_TransactionType>0</Ds_TransactionType> </Transaction> </Message> </Version> <Signature>a454dfdfdf079c9df8b871d7487drtyhj323d345</Signature> </Messages>

EXAMPLE OF RESPONSE MESSAGE:

<Messages> <Version Ds_Version="0.0"> <Message> <Response>

<Ds_MerchantCode>111111111</Ds_MerchantCode> <Ds_Terminal>1</Ds_Terminal> <Ds_Order>132600</Ds_Order> <Ds_TransactionType>0</Ds_TransactionType> <Ds_Date>2002-06-27</Ds_Date> <Ds_Hour>13:24:43</Ds_Hour> <Ds_Amount>45</Ds_Amount>


<Ds_Currency>978</Ds_Currency> <Ds_CardNumber>1111111111111111</Ds_CardNumber> <Ds_ExpiryDate>0303</Ds_ExpiryDate> <Ds_SecurePayment>1</Ds_SecurePayment> <Ds_State>F</Ds_State> <Ds_Response>0</Ds_Response>

</Response> </Message> </Version> <Signature>a454dfdfdf079c9df83331d7487drtyhj323d345</Signature> </Messages>

8.1.c. CALCULATING THE SIGNATURE To calculate the signature for an outgoing message, the following data are used:

Data of outgoing XML + merchant secret code

Digest=SHA-1(“<version...</version>” + merchant secret code)

To calculate the signature for the response, the following data are used:

Data of response XML + merchant code.

Digest=SHA-1(“<version...</version>” + merchant code)

8.1.d. WSDL OF SERVICE The URLs of the Web services of the Virtual POS are as follows:

Test environment: https://sisi.sermepa.es:25443/aplSOAP/rpcrouter

Real environment: https://sis.sermepa.es/aplSOAP/rpcrouter

These URLs are used as destination points of the service. The WDSL which describes the transaction query service of the Virtual POS is as follows:

<?xml version="1.0" encoding="UTF8"?> <wsdl:definitions

name="SerClsConsultasSIS" targetNamespace="http://tempuri.org/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://tempuri.org/" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"> <wsdl:message name="procesaMensajeRecibidoResponse">

<wsdl:part name="return" type="xsd:string"/> </wsdl:message> <wsdl:message name="procesaMensajeRecibidoRequest">

<wsdl:part name="Mensaje" type="xsd:string"/> </wsdl:message> <wsdl:portType name="SerClsConsultasSISPortType">

<wsdl:operation name="procesaMensajeRecibido"> <wsdl:input message="tns:procesaMensajeRecibidoRequest"/>


<wsdl:outputmessage="tns:procesaMensajeRecibidoResponse"/> </wsdl:operation>

</wsdl:portType> <wsdl:binding name="SerClsConsultasSISBinding"type="tns:SerClsConsultasSISPortType">

<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="procesaMensajeRecibido">

<soap:operation soapAction="urn:mensajeriaCIBERPAC#procesaMensajeRecibido"/> <wsdl:input>

<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:mensajeriaCIBERPAC"/>

</wsdl:input> <wsdl:output>

<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:mensajeriaCIBERPAC"/>

</wsdl:output> </wsdl:operation>

</wsdl:binding> <wsdl:service name="SerClsConsultasSISService">

<wsdl:port name="SerClsConsultasSISPort" binding="tns:SerClsConsultasSISBinding"> <soap:address location="https://sis.sermepa.es/aplSOAP/rpcrouter"/>

</wsdl:port> </wsdl:service>

</wsdl:definitions>

8.1.e. SOAP ERROR CODES The SOAP transaction query service has its own error codes which are detailed below:

ERROR DESCRIPTION

XML0000 Various errors in the XMLString process received

XML0001 Error in generating the DOM from the defined XMLString and DTD

XML0002 No “Message” element in the XMLString received

XML0003 The type of “Message” in the XMLString received has an unknown or invalid value in the request

XML0004 No “Ds_MerchantCode” element in the XMLString received

XML0005 The “Ds_MerchantCode” element is empty in the XMLString received

XML0006 The length of the “Ds_MerchantCode” element is wrong in the XMLString received

XML0007 The “Ds_MerchantCode” element does not have a numerical format in the XMLString received

XML0008 There is no “Ds_Terminal” element in the XMLString received

XML0009 The “Ds_Terminal” element is empty in the XMLString received

XML0010 The length of the “Ds_Terminal” element is wrong in the XMLString received

XML0011 The “Ds_Terminal” element does not have a numerical format in the XMLString received

XML0012 There is no “Ds_Order” element in the XMLString received

XML0013 The “Ds_Order” element is empty in the XMLString received

XML0014 The length of the “Ds_Order” element is wrong in the XMLString received

XML0015 The first four positions of the “Ds_Order” element are not numerical in the XML


ERROR DESCRIPTION

String received

XML0016 There is no “Ds_TransactionType” element in the XMLString received

XML0017 The “Ds_TransactionType” element is empty in the XMLString received

XML0018 The length of the “Ds_TransactionType” element is wrong in the XMLString received

XML0019 The “Ds_TransactionType” element does not have a numerical format in the XMLString received

XML0020 The “Ds_TransactionType” element has an unknown or invalid value in the transaction message

XML0021 There is no “Signature” element in the XMLString received

XML0022 The “Signature” element is empty in the XMLString received

XML0023 The signature is not correct

XML0024 There are no transactions in the TZE for the data requested

XML0025 The response XML is not properly formulated

XML0026 There is no “Ds_fecha_inicio” element in the XMLString received

XML0027 There is no “Ds_fecha_fin” element in the XMLString received

8.2. SOAP SYNCHRONIZATION This new synchronization method allows the merchant to receive notification of transactions by a SOAP service. To activate this service, the merchant needs to get in contact with the Technical Support Service of Caixa Catalunya. If the SOAP synchronization option is enabled for a merchant, this means that the platform will send notifications for Authorization, Preauthorization, Recurring Transaction and Authentication operations as SOAP requests to a service published by the merchant. For other transactions, notifications will be done synchronously in accordance with the chosen option in the merchant’s configuration for online notifications. The unique factor of this notification is that Caixa Catalunya’s payment platform waits for a response to the notification before presenting the results of the transaction to the cardholder making the purchase. If the merchant returns a response with a KO value, or there is an error during the notification process, the platform will cancel the transaction and present the cardholder with a receipt showing a KO result, i.e. the platform conditions the result of the transaction to the response obtained from the merchant in the notification.


9. REGULAR INFORMATION FILES Caixa Catalunya has created a system for sending files on a regular basis to complement the usual information received by the merchant. These files contain information on settled transactions, claims received (chargebacks), Confirmed Frauds experienced by the merchant and requests for documentation (retrieval requests) that have been made. These files can be sent in various ways:

Email: to an agreed address. FTP: either by posting the file on the client’s FTP server or allowing the client to access

Caixa Catalunya’s FTP server to download it. The communication is secured by Open SSH protocol.

EDI (in Spain, the Editran protocol).

Caixa Catalunya also carries out weekly checks on the number of chargebacks and confirmed fraud cases. If the merchant has exceeded the permitted limits, he will receive a warning email containing this information. 9.1. SETTLEMENT OF ACCOUNTABLE TRANSACTIONS FILE This file provides information on transactions processed by the merchant which have been duly accounted for in his financial account. The frequency of this file can be daily, weekly or monthly, although for merchants with a very high volume of transactions we particularly recommend it is sent daily. It should be noted that this file does not detail the transactions that have been processed on that day but the transactions actually settled. Usually, Caixa Catalunya settles transactions processed up to 06.00 on the settlement day. These timings are approximate as it will depend on the volume of computer processes on any given day. The total of the transactions listed in each file will match the amount deposited daily in the merchant’s financial account. When a chargeback is requested by a cardholder on any of the merchant’s sales, the staff in our PAYMENT METHODS department will carry out a manual validation to check whether the claim is valid or not. In the cases where the transaction does not meet the regulations of Visa, MasterCard or JCB, it will be returned to the issuing bank in the form of a representment without being charged to the merchant’s account. In other cases, it will be charged to the merchant. For merchants who have a very high volume of transactions or whose office is a long way from a Caixa Catalunya branch, there is a remote management service available (via email) for requesting a representment of chargebacks charged to their accounts. ANNEX II – DISPUTING A CHARGEBACK shows the process for this. The settled transactions file also includes chargebacks that have passed the Caixa Catalunya filters and need to be charged to the merchant. These are identified by the field TRANSACTION TYPE (POS. 71[2] = 15). The code for the reason for each Chargeback is given in pos. 178[2].


The format of the file will be as follows:

FILE HEADER RECORD

INITIAL POS. LENGTH DESCRIPTION OF FIELD

1 2 RECORD TYPE: 10

3 10 PROCESSING DATE (DD-MM-YYYY)

13 10 START DATE OF TRANSACTIONS (DD-MM-YYYY)

23 10 END DATE OF TRANSACTIONS (DD-MM-YYYY)

33 168 FILLER

MERCHANT HEADER RECORD


1 2 RECORD TYPE: 00

3 18 MERCHANT’S CONTRACT NUMBER

21 10 MERCHANT’S CODE

31 18 ASSOCIATED ACCOUNT NUMBER

49 4 MERCHANT’S BRANCH OFFICE



73 10 END DATE OF TRANSACTIONS (DD-MM-YYYY)

83 118 FILLER

DETAIL RECORD


1 2 RECORD TYPE: 01

3 10 SETTLEMENT DATE (DD-MM-YYYY)

13 5 REMITTANCE NUMBER

18 3 INVOICE NUMBER

21 4 REMITTANCE BRANCH

25 22 CARD NUMBER

47 1 CARD TYPE

48 1 “D” - DEBIT CARD / “C” - CREDIT CARD

49 10 TRANSACTION DATE

59 6 TRANSACTION TIME (HHMMSS)

65 6 AUTHORIZATION NUMBER


DETAIL RECORD


71 2

TRANSACTION TYPE: 05 – SALE (BY THE MERCHANT) 06 – REFUND (BY THE MERCHANT) 15 – CHARGEBACK (CARDHOLDER CLAIM) 35 - CHARGEBACK REPRESENTMENT 16 – CANCELLATION OF CHARGEBACK 25 – CANCELLATION OF SALE 26 – CANCELLATION OF REFUND 36 – CANCELLATION OF CHARGEBACK REPRESENTMENT

73 3 TYPE OF CAPTURE

76 11 TRANSACTION AMOUNT (WITH 2 DECIMALS)

87 5 DISCOUNT PERCENTAGE (WITH 2 DECIMALS)

92 9 DISCOUNT AMOUNT (WITH 2 DECIMALS)

101 13 PAYMENT AMOUNT (WITH 2 DECIMALS)

114 11 POS NUMBER

125 38 FILLER

163 3 CURRENCY CODE

166 12 TRANSACTION NUMBER

178 2 CHARGEBACK REASON CODE (ONLY GIVEN FOR CHARGEBACKS (pos.71[2] = 15))

180 11 PAYMENT AMOUNT (WITH 2 DECIMALS) IN ORIGINAL CURRENCY

191 3 ORIGINAL CURRENCY OF PAYMENT

194 7 FILLER

TOTAL MERCHANT RECORD


1 2 RECORD TYPE: 99

3 25 FILLER

28 9 TOTAL TRANSACTIONS

37 14 TOTAL AMOUNT IN EUROS (WITH 2 DECIMALS AND +/- SIGNS)

51 150 FILLER

FILE TOTAL RECORD


1 2 RECORD TYPE: 90

3 9 TOTAL NUMBER OF MERCHANTS

12 25 FILLER

37 9 TOTAL TRANSACTIONS

46 14 TOTAL AMOUNT IN EUROS (WITH 2 DECIMALS AND +/- SIGNS)

60 141 FILLER


9.2. CHARGEBACK FILE A chargeback is the tool the cardholder can use to request, through his/her financial entity (issuing bank), the return of the purchase amount. Chargebacks must comply with the regulations of the card company in question. Caixa Catalunya verifies that the chargebacks received comply with these rules, directly notifying the issuing bank of any chargebacks it believes do not comply, and charging the merchant’s account for those which do. In some cases, it may be necessary for Caixa Catalunya to ask the establishment to provide documentation, to assess whether to make a representment or seek documentation for the representment and thus have a greater chance of success. In these cases, the merchant will receive a request for documentation (retrieval request) as per the file described in section 5.4. Caixa Catalunya will send a daily file of the chargebacks received, whether they have been charged to the account or not, to notify the establishment of which clients are asking for chargebacks. In this way, the merchant’s security department can get in contact with them, cancel their subscriptions, add them to blacklists or take any other measures they regard as necessary. This file thus does not contain accounting information but is solely for information purposes. The format of the file is as follows:

AN INDICATOR OF THE FILE TYPE ("CB" for chargeback files) MERCHANT ID CODE (F.U.C.) DATE OF RECEIPT OF CHARGEBACK CARD NUMBER AMOUNT CURRENCY TRANSACTION DATE (of the original transaction) TRANSACTION TIME (of the original transaction) SETTLEMENT DATE (of the original transaction) REMITTANCE NUMBER (of the original transaction) NUMBER OF INVOICE IN REMITTANCE (of the original transaction) AMOUNT OF ORIGINAL TRANSACTION CURRENCY (of the original transaction) TRANSACTION NUMBER (of the original transaction) TYPE OF INCIDENT (usually a 15 for chargebacks or a 16 for cancellation of a chargeback) REASON FOR CHARGEBACK (code of reason for chargeback) ORDER NUMBER OF INCIDENT TEXT ACCOMPANYING THE CHARGEBACK RECEIVED

Shown below are two lists – one for VISA and the other for MasterCard – showing each code with a description of the reason for the chargeback: VISA:

30 Service not provided or merchandise not received 41 Cancelled recurring transaction 53 Merchandise not as described or defective 57 Fraudulent multiple drafts 60 Copy illegible or invalid 62 Counterfeit transaction or falsification of magnetic strip 70 No verification/exception file 71 Authorization denied 72 No authorization 73 Expired card


74 Late presentment 75 Cardholder does not recognise 76 Incorrect currency or transaction code 77 Non-matching account number 78 Violation of service code 80 Processing error – incorrect amount or account 81 Fraudulent transaction – card present environment 82 Duplicate processing 83 Fraudulent transaction – card absent environment 85 Credit not processed 86 Altered amount/paid by other means 90 Non-receipt of cash or merchandise 93 Risk identification service 96 Transaction exceeds limited amount terminal

MASTERCARD:

01 Requested data transaction not received 02 Requested/required information illegible or missing 07 Warning bulletin file 08 Requested/required authorization not obtained 12 Account number not on file 31 Transaction amount differs 34 Duplicate processing 35 Card not valid or expired 37 No cardholder authorization 40 Fraudulent processing of transactions 41 Cancelled recurring transaction 42 Late presentment 46 Correct transaction currency code not provided 47 Exceeds floor limit – Transaction fraudulent and not authorized 49 Questionable merchant activity 50 Credit posted as a purchase 53 Cardholder dispute - Merchandise defective/not as described 55 Merchandise not received 57 Card-activated telephone transaction 59 Services not provided 60 Credit not processed 63 Cardholder does not recognise. Potential fraud 4801 Requested Transaction data not received 4802 Requested/required item illegible or missing 4807 Warning bulletin File 4808 Requested/required Authorization not obtained 4812 Account number not on file 4831 Transaction amount differs 4834 Duplicate processing 4835 Card not valid or Expired 4837 No cardholder authorization 4840 Fraudulent processing of transactions 4841 Canceled recurring transaction 4842 Late presentment


4846 Correct transaction currency code not provided 4847 Requested/required Authorization not obtained and fraudulent transaction 4849 Questionable merchant activity 4850 Credit posted as a purchase 4853 Cardholder dispute – defective/not as described 4854 Cardholder dispute – not elsewhere classified 4855 Nonreceipt of merchandise 4857 Card-activated telephone transaction 4859 Services not rendered 4860 Credit not processes 4862 Counterfeit transaction magnetic stripe POS fraud 4863 Cardholder does not recognize – potential fraud

To differentiate the card type (Visa or MasterCard) you can refer to field pos. 47[2] in the settlement file. 9.3. CONFIRMED FRAUD FILE Confirmed Fraud is the tool used by the issuing bank to notify that a transaction has been subject to fraud (the cardholder has neither made nor authorized the transaction). This notification is completely independent of the existence of a previous or subsequent chargeback, or whether it has been charged to the merchant or a representment issued. This is a method for notifying that a transaction has not been made by the cardholder so that VISA/MASTERCARD can identify which merchants are processing a high number of fraudulent transactions. A high number of Confirmed Frauds is an indicator that the merchant is either carrying out a fraudulent activity or is experiencing an attack by illegal buyers and has not put the necessary mechanisms in place to reduce this. If the level is very much higher than permitted, or if it happens over several consecutive months, the card companies may demand the cancellation of the contract with that establishment and, on occasions, may even heavily penalize the establishment. The maximum permitted level of Confirmed Fraud is regarded as three times the average confirmed fraud index for European merchants. At present, the European fraud average is around 0.3% of monthly turnover. Therefore, any merchant whose monthly Confirmed Fraud figure exceeds 0.9% will be above the permitted level. As in the case of Chargebacks, Caixa Catalunya sends a daily file of Confirmed Fraud transactions reported by the different card companies. This file, as in the previous case, is solely for information purposes and does not have any accounting validity. Its purpose is to inform the establishment of the cards with which fraudulent transactions are being made so that its security department can get in contact with the clients listed, cancel their accounts, add them to their blacklists or take any other measure they deem necessary. The format is very similar to that of the Chargeback file:

AN INDICATOR OF THE FILE TYPE ("FC" for Confirmed Fraud files) MERCHANT ID NUMBER (F.U.C.) DATE OF RECEIPT OF CHARGEBACK OR FRAUD REPORT CARD NUMBER AMOUNT CURRENCY TRANSACTION DATE (of the original transaction) TRANSACTION TIME (of the original transaction)


SETTLEMENT DATE (of the original transaction) REMITTANCE NUMBER (of the original transaction) INVOICE NUMBER IN REMITTANCE (of the original transaction) AMOUNT OF ORIGINAL TRANSACTION CURRENCY (of the original transaction) TRANSACTION NUMBER (of the original transaction)

9.4. RETRIEVAL REQUEST FILE Retrieval request is an option that the cardholder and the issuing bank can use to check the integrity of a transaction, either because the cardholder does not remember the purchase, does not recognise it, or for any other reason. Everyone who makes a purchase (whether in person or not) using a financial card has the right to ask for documentation from the merchant to justify the payment. The maximum period for this request to be honored is 12 months from the date of the transaction. This request is normally made because the cardholder cannot remember the transaction, or wants more details of it, or maintains he has not made it and wants a refund. In some cases it is because he cannot associate the name of the merchant with the website on which he made the purchase. Caixa Catalunya will send the merchant a daily information file showing a single block of records (without headings) with the following fields, separated by ‘;’ :

LENGTH DESCRIPTION OF FIELD

10 PROCESSING DATE (DD-MM-YYYY)

10 MERCHANT IDENTIFICATOR (MID)

17 MERCHANT NAME

10 SETTLEMENT DATE (DD-MM-YYYY)

5 REMITTANCE NUMBER

3 SETTLEMENT ORDER NUMBER

2 REQUEST ORDER

10 TRANSACTION DATE (DD-MM-YYYY)

19 CARD NUMBER

9 TRANSACTION AMOUNT (999999,99)

1 SETTLEMENT CURRENCY CODE: E (EUROS)

6 REQUEST TYPE

8 ENVIRONMENT

23 REFERENCE

12 TRANSACTION ID This documentation can also be requested by Caixa Catalunya when it considers it necessary to either defend or make a representment on a transaction, and must be provided by the merchant if he/she wishes to avoid a chargeback. The merchant is obliged to present this receipt. The deadline for its presentation is 7 working days.


If goods have been sent, the delivery note issued by the company that made the delivery should be attached. It is important to note that this delivery note must be signed by the cardholder and not by someone else. As an exception, and only for those cases where it is not possible to deliver the merchandising to the cardholder (either because he cannot be at the agreed place and time, either because it’s a present) the deliverance can be done to a third person. In this case, it must be stated this option at the order form that cardholder did at the merchant website, filled with next information:

Authorized person, identified by name a personal identity document (DNI, Passport, etc.). The order must be delivered only to this person and the delivery note must include the signature of the receiver as well as a statement as the personal identity document has been checked. Hotel’s Reception, identified by name, hotel’s address, name and document of the guest who must receive the delivery. The delivery note must be signed by a perfectly identified hotel’s employee and stamped by the hotel. Moreover, on the delivery note it must be stated that it has been checked that the receiver is a guest of the hotel.

In the case of a merchant which offers services and not products, i.e. there is no goods delivery involved, the merchant should provide the following details on the reply form:

Merchant’s name Merchant’s CIF/NIF Merchant’s code (FUC) Authorization number Date of transaction Card number Website address (URL) Amount of transaction Currency Name of Buyer Description of purchase Description of the merchant’s returns policy, or the URL where users can find this information

ANNEX VI – DISPUTE CIRCUIT of this manual details how the whole process for requesting documentation works, whether it originates from the issuing bank or whether it is requested by Caixa Catalunya. For merchants with a very high volume of transactions or which are located a long way from a Caixa Catalunya branch, there is a remote management service available (via email) for processing the requested documentation. ANNEX VIII – RETRIEVAL REQUESTS shows this process.


10. MONITORING PROGRAMMES AND PENALTIES Both Visa and MasterCard have chargeback monitoring programmes for merchants and penalize those that exceed the maximum percentages. The figures that give rise to a penalty are as follows:

a) For VISA, if there are more than 200 chargebacks and the percentage is more than 2% of the total monthly transactions.

b) For MASTERCARD (ECM Excessive Chargeback Merchant), if there are more than 50 chargebacks and during two consecutive months the percentage of chargebacks received is higher than 1% of the previous month’s transactions.

In addition to the above, since 1 October 2006 Visa and MasterCard have set up programmes to identify merchants who, though not exceeding the maximum penalty parameters, are very close to them. The warning parameters are:

a) For VISA, if there are more than 100 chargebacks and the percentage is higher than 1% of the total monthly transactions.

b) For MASTERCARD (CMM Chargeback Monitored Merchant), if there are more than 50 chargebacks and the percentage of chargebacks is higher than 0.5% of the previous month’s transactions.

Although the warnings do not necessarily mean that the merchant will be penalized, they do require the merchant to give an explanation and send Visa or MasterCard an Action Plan to demonstrate that he is taking all the necessary steps to prevent this from happening in the future. If the Action Plan sent by the merchant is regarded as insufficient by the card companies, they can ask for up to a onemonth temporary suspension of card processing to be imposed on the merchant. If a merchant repeatedly appears on a warning file, Visa or MasterCard may take more severe measures (exclusion). For this reason, even though there is no direct penalty, it is necessary to take the maximum warning parameters as the absolute maximum acceptable for a merchant’s commercial activities. So that merchants can monitor their turnover and any incidents generated on their websites, Caixa Catalunya can send a Word file containing a periodic report (by week, month and current financial year) of the merchant’s turnover volume and the number of incidents received (Retrieval Requests, Chargebacks and Confirmed Fraud). This report will be generated whenever any of the merchant’s monthly incident parameters exceed 0.5%.


11. PCIDSS – PAYMENT CARD INDUSTRY DATA SECURITY STANDARD In accordance with current VISA and MASTERCARD regulations, all merchants which capture, transmit, process and store information on cards must comply with certain security standards which vary depending on the number of transactions they process per year. If the merchant already has a valid certificate which demonstrates that he complies with these requirements, he simply needs to provide Caixa Catalunya with a copy of this document (which can be scanned). If this is not the case, the conditions of this programme are detailed below. Merchants are classified according to the number of annual transactions they process, level 4 being the least demanding and level 1 corresponding to the highest number of transactions, for which the merchant obviously has to fulfill more conditions. The classification is as follows:

Level Selection criteria Requirement Validated by

1

Any merchant which processes more than 6,000,000 transactions per year. Any merchant that has suffered a hack or attack that resulted in an account data compromise. Any merchant which, at the discretion of VISA and MASTERCARD, has been identified as a Level 1 merchant All IPSP companies (Internet Services Payment Providers) regardless the number of transactions.

Annual Security Audit

- - - - -

Quarterly scan

Independent security consultant or the

company itself, if signed by a representative of

the company.

- - - - -

By a specialist company

2 Any e-merchant which processes more than 150,000 and less than 6,000,000 transactions per year.

Annual self-assessment questionnaire

- - - - -

Quarterly scan

By the merchant

- - - - -

By a specialist company 3 Any e-merchant which processes more than 20,000 and less than 150,000 transactions per year

4 Other merchants Annual self-assessment questionnaire By the merchant

The requirements in the above table are mandatory. These are: 1 SELFASSESSMENT QUESTIONNAIRE: This is known as the SAQ (AIS in Spain) and consists of a questionnaire on the merchant’s computer system architecture and how it processes and stores data on cards. It is done on an ANNUAL basis. Caixa Catalunya has the questionnaire as well as its instructions and frequentlyasked questions.

2 QUARTERLY SCANS: These controls have to be done by a company certified by VISA/MASTERCARD as a Quality Security Assessor (QSA). The merchant is responsible for contracting this service from one of these companies (Caixa Catalunya can provide a list of them). This scan is done on a QUARTERLY basis.

3 SECURITY AUDIT: This is an IN SITU audit which must be done by a company certified by VISA/MASTERCARD as a Quality Security Assessor (QSA), which will assess the security of the computer systems involved in processing card data (Hardware, Software and Netware). The merchant is responsible for contracting this service from one of these companies (Caixa Catalunya can provide a list of them). This audit is done on an ANNUAL basis.


ANNEXES

ANNEX I. Description of Payment and Response Forms

DETAIL FIELD NAME LENGTH COMMENTS

Amount

Ds_Merchant_Amount

12 N

Mandatory. The last two positions are regarded as decimals except for yen.

Currency

Ds_Merchant_Currency

4 N

Mandatory. 978 – Euros 840 – Dollars 826 – Pounds 392 – Yen There’s an agreement between Spanish banks where it’s said that Spanish cards that want to process in Spanish merchants, the only available currency it is Euros.

Order code

Ds_Merchant_Order

min. 4N max.12 AN

Mandatory. The first 4 digits must be numerical; the remaining digits should only use the following ASCII characters: from 30 = 0 to 39 = 9 from 65 = A to 90 = Z from 97 = a to 122 = z The code must be different from previous transactions.

Product description Ds_Merchant_ProductDescription Max.125 AN This field will be shown to the cardholder on the

purchase confirmation page.

Name and surname/s of cardholder

Ds_Merchant_Titular Max. 60 AN This field will be shown to the cardholder on the purchase confirmation page.

Merchant ID code FUC

Ds_Merchant_MerchantCode

9 N

Mandatory. Fixed code assigned by Caixa Catalunya.

URL

Ds_Merchant_MerchantURL

250 AN

Mandatory if the merchant wants online notification. The merchant’s URL which will receive a POST with the transaction details.

URLOK Ds_Merchant_UrlOK 250 AN

Optional. If sent, it will be used as URLOK, ignoring what has been configured in the Administration Module, if applicable.

URLKO Ds_Merchant_UrlKO 250 AN

Optional. If sent, it will be used as URLKO, ignoring what has been configured in the Administration Module, if applicable.

Merchant’s name Ds_Merchant_MerchantName 25 AN Optional. This will be the name that appears on the client’s payment page, if there is one.

Cardholder’s

language

Ds_Merchant_ConsumerLanguage

3 N

Optional. 0 – Client 8 – Swedish 1 – Spanish 9 – Portuguese 2 – English 10 – Valencian 3 – Catalan 11 – Polish 4 – French 12 – Galician 5 – German 13 – Basque 6 – Dutch 7 – Italian

Merchant’s signature

Ds_Merchant_MerchantSignature

40 AN

Mandatory. See section 6.4.

POS terminal number

Ds_Merchant_Terminal

3 N

Mandatory.

Details of merchant

Ds_Merchant_MerchantData

1024 AN

Optional. Optional information from the merchant to be sent in


DETAIL FIELD NAME LENGTH COMMENTS the online response (via URL or e-mail).

Type of transaction

Ds_Merchant_TransactionType

1 N

Optional (by default equal to “0”). 0 – Standard payment (‘realizarpago’ and “entradaXMLEntidad’ gateways) A – Standard Payment (only ‘operaciones’ gateway) 1 – Pre-authorization (authorized merchants only) 2 – Confirmation of pre-authorization 3 – Partial or total refund 5 – Recurring transaction 6 – Successive transactions 7 – Authentication 8 – Confirmation of authentication 9 – Cancellation of pre-authorization O-Deferred Pre-authorization P-Confirmation of Deferred Preauthorization Q-Cancellation of Deferred Pre-authorization R-Deferred Recurring Pre-authorization S-Confirmation of Deferred Recurring Pre-

authorization / Successive of Deferred Recurring Pre-authorization

GATEWAY ‘operaciones’ only allows the following types: 1, 2, 3, 6, 8, 9, O, P, Q, R, S, A

Total Amount

Ds_Merchant_SumTotal 12 N

Mandatory if “Transaction type 5” This represents the sum total of the instalment amounts. The last two positions are decimals. (see 7.2)

Frequency of a recurring

transaction Ds_Merchant_DateFrecuency 3 N

Mandatory of “Transaction type 5” This gives the minimum interval in days between the instalment charges of a recurring payment (see 7.2)

Expiry date of a recurring

transaction Ds_Merchant_ChargeExpiryDate 10 AN

Mandatory if “Transaction type 5” Date of the final instalment of a recurring payment (see 7.2)

Format: YYYY-MM-DD

Authorization code Ds_Merchant_AuthorisationCode 6 N

Optional. This is the authorization code necessary to identify recurring/successive transactions in the case of refunds.

Date of the successive recurring

transaction

Ds_Merchant_TransactionDate 10 AN

Optional. Format YYYY-MM-DD. It represents the date of the successive recurring transaction, necessary to identify the transaction in the refunds of successive recurring transactions. Mandatory for the refunds of recurring transactions.

Described below are the fields relating to the card details, given the possibility that they may be captured by the merchant. These new fields will only have to be sent by merchants who capture the data on the card themselves (you should remember that this entails complying with the requirements of the PCIDSS security programme explained in section 11 of this manual).

DATA

FIELD NAME

LENGTH/TYPE

COMMENTS

Card number <Ds_Merchant_Pan> 16-19/Num. Card number (*).

Expiry date <Ds_Merchant_ExpiryDate> 4 /Num. This has the YYMM format (*).

CVV2 <Ds_Merchant_CVV2> 3/Num. CVV2/CVC2 code on the card sent (*)

(*) The transaction types 2 / 3 / 6 / 8 / 9 / P / Q / S do not require that the card number, expiry date and CVV2 was informed. In these cases the order (Ds_Merchant_Order) has to be the same that the original transaction.


Fields of the response to the merchant.

DATA DATA NAME LENGTH/TYPE COMMENTS

Version <Ds_Version> - N Version of the message. Not available for gateway “RealizarPago”. Format 1.xxxxxxxx where xxxxxxxx is the Merchant Code.

Date <Ds_Date> 10 A Date of transaction (DD-MM-YYYY). Only available in gateway “RealizarPago”.

Time <Ds_Hour> 5 A Time of transaction (HH:MM). Only available in gateway “RealizarPago”.

Amount <Ds_Amount> 12 N Same amount as request.

Currency <Ds_Currency> 4 N Same as request. Four is regarded as the maximum length.

Order no. <Ds_Order> min. 4N max. 12 AN Same as request.

Merchant code <Ds_MerchantCode> 9 N Same as request.

Terminal no. <Ds_Terminal> 3 N Same as request. Three is regarded as the maximum length.

Merchant’s signature <Ds_Signature> 40 AN Mandatory.

See section 6.4.

Response code <Ds_Response> 4 N See ANNEX II

Merchant data Ds_Merchant_MerchantData 1024 AN Optional information sent by merchant in the payment form

Secure Payment <Ds_SecurePayment> 1 N

0 – if the payment is NOT secure 1 – if the payment is secure Note: in the case of pre-authorizations only, a “0” is returned if it is authorized and the cardholder has been authenticated with his/her bank, and a “1” if it is authorized but the cardholder has not been authenticated with the issuer bank.

Transaction type <Ds_TransactionType> 1 N Type of transaction sent in the payment form

Card number <Ds_Card_Number> 16-19/Num Card number sent in the payment form. This is returned masked. Not available for gateway “RealizarPago”.

Expiry date <Ds_ExpiryDate> 4/Num The expiry date on the card sent in the payment form. Not available for gateway “RealizarPago”.

Card country <Ds_Card_Country> 3/Num Country of issue of the card used for the payment. See ANNEX IV.

Authorization code <Ds_AuthorisationCode> 6 N

Alphanumerical code of the authorization given by the card issuer or the Authorization Centre to which it has delegated this service.

Language of Cardholder <Ds_ConsumerLanguage> 3 N Value 0 indicates that the language of the client has not been

determined (optional). Only in gateway “RealizarPago”.

Type of Card <Ds_Card_Type> 1 AN Two possible values: C – Credit D – Debit

In the fields Ds_Currency, Ds_Terminal and Ds_ConsumerLanguage, the length is regarded as the maximum so it is not essential to complete them with zeros on the lefthand side. The signature will be generated with the fields exactly as sent.


ANNEX II. TABLE OF RESPONSE CODES (Ds_Response)

Response codes sent by the card issuing bank

RESPONSE CODES INDICATING THAT THE TRANSACTION HAS BEEN APPROVED CODE BRIEF DESCRIPTION COMMENTS

000 TRANSACTION APPROVED Transaction authorized by the card issuer.

001 TRANSACTION APPROVED SUBJECT TO IDENTIFICATION OF CARDHOLDER

Exclusive code for Verified by Visa or MasterCard SecureCode transactions

- - - - - The transaction has been authorized and also the card issuer informs us that it has correctly authenticated the identity of the cardholder.

002 - 099 TRANSACTION APPROVED Transaction authorized by the card issuer.

0900 REFUND / CONFIRMATION APPROVED Transaction authorized for Refunds and Confirmations

RESPONSE CODES INDICATING THAT THE TRANSACTION HAS BEEN DECLINED CODE BRIEF DESCRIPTION COMMENTS

101 CARD EXPIRED Transaction declined because the expiry date on the card used for payment has already passed.

102 CARD BLOCKED TEMPORARILY OR UNDER SUSPICION OF FRAUD

Card has been blocked temporarily by the card issuer or suspected of being used fraudulently.

104 TRANSACTION NOT PERMITTED Transaction not permitted for this type of card.

107 CONTACT THE CARD ISSUER The card issuer does not permit automatic authorization. You need to contact the authorization centre by telephone for approval.

109 INVALID IDENTIFICATION BY MERCHANT OR POS TERMINAL

Declined because the merchant is not properly registered with international card systems.

110 INVALID AMOUNT The amount of the transaction is unusual for the type of merchant seeking payment authorization.

114 CARD CANNOT BE USED FOR THE REQUESTED TRANSACTION

This kind of transaction is not permitted for this type of card.

116 INSUFFICIENT CREDIT The cardholder does not have enough credit to make this payment.

118 NON-REGISTERED CARD Card does not exist or has not been cleared by the issuing bank.

125 CRAD NOT EFFECTIVE There’s a problem (undetermined) with the card.

129 CVV2/CVC2 ERROR Exclusive code for transactions where the 3-digit CVV2 (Visa) or CVC2

(MasterCard) number on the back of the card has been requested. - - - - -

It means that the CVV2/CVC2 code given by the buyer is wrong.

167 CONTACT THE CARD ISSUER – SUSPECTED FRAUD

The card issuer cannot permit automatic authorization because it suspects that the transaction is fraudulent. You need to contact the authorization centre by telephone to get approval.

180 CARD OUT OF SERVICE

This transaction is not permitted for this type of card. We remember that there’s an agreement between Spanish banks where it’s said that Spanish cards that want to process in Spanish merchants, the only available currency it is Euros. If these transactions there are processed in other currency that Euros, they will be declined using the reason code 180.

181 - 182 CARD WITH CREDIT OR DEBIT RESTRICTIONS

Card temporarily blocked by the issuer bank.

184 AUTHENTICATION ERROR

Exclusive code for Verified by Visa or MasterCard SecureCode transactions.

- - - - - The transaction has been declined because the card issuer cannot properly authenticate the cardholder.


RESPONSE CODES INDICATING THAT THE TRANSACTION HAS BEEN DECLINED CODE BRIEF DESCRIPTION COMMENTS

190 REFUSAL WITH NO SPECIFIC REASON Transaction declined by the card issuer with no explanation given as to the reason.

191 EXPIRY DATE INCORRECT Transaction declined because the expiry date of the card used for payment does not correspond with the correct date.

RESPONSE CODES INDICATING THAT THE TRANSACTION HAS BEEN DECLINED AND, FURTHERMORE, THE CARD ISSUER BELIEVES THE CARD IS POSSIBLY BEING USED FRAUDULENTLY AND ASKS THE MERCHANT

TO PHYSICALLY WITHHOLD IT OR ACTIVATE IT VIRTUALLY ON A BLACKLIST CODE BRIEF DESCRIPTION COMMENTS

201 CARD EXPIRED

Transaction declined because the expiry date on the card used for payment has already passed.

- - - - - In addition, the card issuer believes the card is possibly being used fraudulently and asks for the card to physically withheld or activated virtually on a blacklist.

202 CARD BLOCKED TEMPORARILY OR UNDER SUSPICION OF FRAUD

Card blocked temporarily by the card issuer or suspected of being used fraudulently.


204 TRANSACTION NOT PERMITTED

This transaction is not permitted for this type of card. - - - - -

In addition, the card issuer believes the card is possibly being used fraudulently and asks for the card to physically withheld or activated virtually on a blacklist.

207 CONTACT THE CARD ISSUER

The card issuer does not permit automatic authorization. You need to contact the authorization centre by telephone for approval.


208 - 209 LOST OR STOLEN CARD

Card blocked by the card issuer because the cardholder has reported it as being lost or stolen.


280 CVV2/CVC2 ERROR

Exclusive code for transactions where the 3-digit CVV2 (Visa) or CVC2 (MasterCard) number on the back of the card has been requested.

- - - - - The CVV2/CVC2 given by the buyer is wrong.


290 DECLINED WITH NO SPECIFIC REASON

Transaction declined by the card issuer with no explanation given as to the reason.



RESPONSE CODES RELATING TO CANCELLATIONS OR PARTIAL REVERSALS (Ds_Merchant_TransactionType = 3 or Q)

CODE BRIEF DESCRIPTION COMMENTS

400 CANCELLATION ACCEPTED The cancellation or partial reversal of the transaction has been accepted by the card issuer.

480 ORIGINAL TRANSACTION NOT LOCATED, OR TIME-OUT EXCEEDED

The cancellation or partial reversal has not been accepted either because the original transaction cannot be located or because the card issuer has not responded within the pre-established time-out.

481 CANCELLATION ACCEPTED The cancellation or partial reversal of the transaction has been accepted by the card issuer. However, the response from the card issuer has been received very late, outside the pre-established time-out.

RESPONSE CODES RELATING TO RECONCILIATIONS OF PRE-AUTHORIZATIONS OR PRE-AUTHENTICATIONS (Ds_Merchant_TransactionTypes = 2, 8, P or S )


500 RECONCILIATION ACCEPTED The reconciliation transaction has been accepted by the card issuer.

501 - 503 ORIGINAL TRANSACTION NOT LOCATED, OR TIME-OUT EXCEEDED

The reconciliation transaction has not been accepted because the original transaction cannot be located or because the card issuer has not responded within the pre-established time-out.

RESPONSE CODES RELATING TO RECONCILIATIONS OF DEFERRED PRE-AUTHORIZATIONS OR RECURRING DEFERRED PRE-AUTHORIZATIONS (Ds_Merchant_TransactionTypes = O or R)


9928 CANCELLATION OF DEFERRED PREAUTHORIZATIONS DONE BY THE SYSTEM

The system has cancelled the Deferred Preauthorization after 72 hours.

9929 CANCELLATION OF DEFERRED

PREAUTHORIZATIONS DONE BY THE MERCHANT

The cancellation of the Deferred Preauthorization has been accepted.

Response codes sent by the CAIXA CATALUNYA payment platform:

RESPONSE CODES INDICATING THAT THE TRANSACTION HAS BEEN DECLINED BY THE CAIXA CATALUNYA PAYMENT PLATFORM


904 MERCHANT NOT REGISTERED AT FUC There is a problem in the configuration of the MID (Merchant Identification). Contact Caixa Catalunya to solve.

909 SYSTEM ERROR Error in the stability of the Caixa Catalunya payment platform or the Visa or MasterCard exchange systems.

912 ISSUER NOT AVAILABLE The authorization centre of the card issuer is not operational at this particular time.

913 DUPLICATE TRANSMISSION A transaction has recently been processed with the same order number (Ds_Merchant_Order).

916 AMOUNT TOO LOW It’s not accepted to operate with this amount.

928 TIME-OUT EXCEEDED The card issuer has not responded to the authorization request within the pre-established time-out.

940 TRANSACTION CANCELLED PREVIOUSLY

A cancellation or partial reversal is being requested for a transaction that has already been cancelled.

941 AUTHORIZATION OPERATION

ALREADY CANCELLED BY A PREVIOUS CANCELLATION

A request to confirm a transaction is being made with an order number (Ds_Merchant_Order) which corresponds to a transaction that has already been cancelled.


RESPONSE CODES INDICATING THAT THE TRANSACTION HAS BEEN DECLINED BY THE CAIXA CATALUNYA PAYMENT PLATFORM


942 ORIGINAL AUTHORIZATION TRANSACTION DECLINED

The confirmation of a transaction is being requested with an order number (Ds_Merchant_Order) which corresponds to a transaction that has been declined.

943 DIFFERENT DETAILS FROM ORIGINAL TRANSACTION

A confirmation is being requested which is incorrect.

944 SESSION ERROR A request is being made to open a third session. Only two sessions can be open during the payment process (the existing one and the previous one pending closure).

945 DUPLICATE TRANSMISSION A transaction has been processed recently with the same order number (Ds_Merchant_Order).

946 CANCELLATION OF TRANSACTION WHILE IN PROGRESS

A request is being made to cancel or partially reverse an original transaction which is still being processed and pending a response.

947 DUPLICATE TRANSMISSION WHILE IN PROGRESS

An attempt is being made to process a transaction with the same order number (Ds_Merchant_Order) as another transaction which is still pending a response.

949 POS INOPERATIVE The merchant code (Ds_Merchant_MerchantCode) or the terminal code (Ds_Merchant_Terminal) are either not yet registered or not operative.

950 REFUND NOT POSIBLE The refund is not accepted by regulation

9064 CARD NUMBER INCORRECT The number of positions in Card Number is incorrect

9078 NO PAYMENT METHOD AVAILABLE The type of payment defined for the POS (Ds_Merchant_Terminal) through which the transaction is processed does not allow payment with this type of card.

9093 NON-EXISTENT CARD Non-existent card.

9218 RECURE TRANSACTIONS IN BAD GATEWAY

The merchant is not allowed to make Secure Transactions using gateway “operaciones”

9253 CHECK-DIGIT INCORRECT The check-digit of the card does not match up (position 16 of the card number calculated according to the “Mod 10” algorithm).

9256 PREAUTH. NOT ALLOWED FOR MERCHANT The merchant is not allowed to make Preathorizations

9257 PREAUT. NOT ALLOWED FOR CARD The card is not allowed to make Preauthorizations

9261 OPERATING LIMIT EXCEEDED The transaction exceeds an operating limit established by Caixa Catalunya

9912 ISSUER NOT AVAILABLE The authorization centre of the card issuer is not operational at this time.

9913 CONFIRMATION ERROR Error in the confirmation sent by the merchant to the Virtual POS (this only applies with the SOAP synchronization option).

9914 “KO” CONFIRMATION “KO” confirmation of the merchant (this only applies with the SOAP synchronization system)

9928 DEFERRED PRE-AUTH. CANCELLED Cancellation of deferred preauthorization made by the system (more that 72 hours)

9929 DEFERRED PRE-AUTH. CANCELLED Cancellation of deferred preauthorization made by the merchant

Other response codes different from the previous list can be shown starting with 9 (9xxx). To know the response reason it would be necessary to find the code without the first 9 and to loock of the xxx code in the previous list.


ANNEX III. TABLE OF ERRORS

The following table lists the possible error values you may receive in the response from the Virtual POS, the field they affect (if applicable) and what they mean. It also specifies the error message that will be seen by the client (buyer) for each of these errors.

SISxxxx FIELD AFFECTED REASON MESSAGE

SIS0007 Error on dismantling entry XML MSG0008

SIS0008 Ds_Merchant_MerchantCode Field is missing MSG0008

SIS0009 Ds_Merchant_MerchantCode Format error MSG0008

SIS0010 Ds_Merchant_Terminal Field is missing MSG0008

SIS0011 Ds_Merchant_Terminal Format error MSG0008

SIS0014 Ds_Merchant_Order Format error MSG0008

SIS0015 Ds_Merchant_Currency Field is missing MSG0008

SIS0016 Ds_Merchant_Currency Format error MSG0008

SIS0018 Ds_Merchant_Amount Field is missing MSG0008

SIS0019 Ds_Merchant_Amount Format error MSG0008

SIS0020 Ds_Merchant_Signature Field is missing MSG0008

SIS0021 Ds_Merchant_Signature No data in field MSG0008

SIS0022 Ds_TransactionType Format error MSG0008

SIS0023 Ds_TransactionType Unknown value MSG0008

SIS0024 Ds_ConsumerLanguage Value higher than 3 digits MSG0008

SIS0025 Ds_ConsumerLanguage Format error MSG0008

SIS0026 Ds_Merchant_MerchantCode Merchant/terminal sent does not exist

MSG0008

SIS0027 Ds_Merchant_Currency Currency does not coincide with the one assigned to this terminal

MSG0008

SIS0028 Ds_Merchant_MerchantCode Merchant/Terminal is no longer registered

MSG0008

SIS0031 Ds_Merchant_TransactionType Method of payment not defined MSG0000

SIS0040 Merchant/Terminal has no method of payment assigned

MSG0008

SIS0041 SIS0042

Ds_Merchant_Signature Error in calculating HASH algorithm

MSG0008

SIS0043 Error during online notification MSG0008

SIS0046 The card BIN has not yet been cleared

MSG0002

SIS0051 Ds_Merchant_Order Repeated order number MSG0001

SIS0054 Ds_Merchant_Order There is no transaction on which to make a refund MSG0008

SIS0055 Ds_Merchant_Order There’s more than one payment with that Ds_Merchant_Order MSG0008



SIS0056 Ds_Merchant_Order The transaction you wish to refund is not authorized

MSG0008

SIS0057 Ds_Merchant_Amount The amount to be refunded is higher than permitted

MSG0008

SIS0058 Inconsistent data in validating a confirmation

MSG0008

SIS0059 Ds_Merchant_Order The transaction you wish to confirm does not exist

MSG0008

SIS0060 Ds_Merchant_Order There is already a confirmation associated with this preauthorization

MSG0008

SIS0061 Ds_Merchant_Order The preauthorization you want to confirm is not authorized

MSG0008

SIS0062 Ds_Merchant_Amount The amount to be confirmed exceeds the permitted amount

MSG0008

SIS0063 SIS0064 SIS0065

Error in card number MSG0008

SIS0066 SIS0067 SIS0068 SIS0069 SIS0070

Error in card expiry date MSG0008

SIS0071 Card expired MSG0000

SIS0072 Ds_Merchant_Order Transaction cannot be cancelled MSG0000

SIS0074 Ds_Merchant_Order Field is missing MSG0008

SIS0075 Ds_Merchant_Order The value has fewer than 4 positions or more than 12 MSG0008

SIS0076 Ds_Merchant_Order The value is not numerical MSG0008

SIS0078 Ds_TransactionType Unknown value MSG0005

SIS0089 Ds_Merchant_Expirydate The value has not 4 positions MSG0008

SIS0092 Ds_Merchant_Expirydate Value not accepted MSG0008

SIS0093 Card cannot be found in range table

MSG0006

SIS0094 Card has not been authenticated as 3D Secure

MSG0004

SIS0112 Ds_TransactionType Value not permitted MSG0008

SIS0114 A GET has been called instead of a POST

MSG0000

SIS0115 Ds_Merchant_Order There is no transaction on which to pay the instalment

MSG0008

SIS0116 Ds_Merchant_Order The transaction on which you want to pay an instalment is not valid

MSG0008

SIS0117 Ds_Merchant_Order The transaction on which you want to pay an instalment is not authorized

MSG0008



SIS0118 Ds_Merchant_Amount

The total number of instalments indicated in the first transaction of a recurring transaction has been exceeded

MSG0008

SIS0119 Ds_Merchant_DateFrecuency Format error MSG0008

SIS0120 Ds_Merchant_ChargeExpiryDate Format error MSG0008

SIS0121 Ds_Merchant_SumTotal Format error MSG0008

SIS0122 Ds_Merchant_ChargeExpiryDate Ds_Merchant_SumTotal

Format error in one of the two fields

MSG0008

SIS0123 Ds_Merchant_ChargeExpiryDate The date limit indicated in the first transaction of a recurring transaction has been passed

MSG0008

SIS0124 Ds_Merchant_DateFrecuency

The minimum frequency indicated in the first transaction of a recurring transaction has been exceeded

MSG0008

SIS0132 The date of the authorization confirmation cannot be more than 7 days after the preauthorization

MSG0008

SIS0133

The date of the authentication confirmation cannot exceed the prior authentication by more than 45 days

MSG0008

SIS0139 The initial recurring payment has been duplicated

MSG0008

SIS0142 Time for payment has been exceeded

MSG0000

SIS0198 The amount is over the permitted limit for this merchant MSG0008

SIS0199 The number of transactions exceeds the permitted limit for this merchant

MSG0008

SIS0200 The cumulative amount exceeds the permitted limit for this merchant

MSG0008

SIS0214 This merchant does not accept refunds

MSG0008

SIS0216 The CVV2 has more than three digits

MSG0008

SIS0217 Format error of CVV2 MSG0008

SIS0218 The merchant is not able to do Secure Transactions in ‘operaciones’ gateway

SIS0219 The number of card transactions exceeds the permitted limit for this merchant

MSG0008

SIS0220 The cumulative amount of the card exceeds the permitted limit for this merchant

MSG0008

SIS0221 Error. The CVV2 is mandatory MSG0008



SIS0222 There is already a cancellation associated with the preauthorization

MSG0008

SIS0223 The preauthorization you want to cancel has not been authorized

MSG0008

SIS0224 The merchant does not accept cancellations as there is no extended signature

MSG0008

SIS0225 There is no transaction available to be cancelled

MSG0008

SIS0226 Inconsistent data in the validation of a cancellation

MSG0008

SIS0227 Ds_Merchant_TransactionDate Invalid value MSG0008

SIS0229 There is no code for the deferred payment request MSG0008

SIS0252 The merchant does not allow the card to be sent MSG0008

SIS0253 The card’s checkdigit does not match up MSG0008

SIS0254 The number of transactions per IP exceeds the maximum permitted for this merchant

MSG0008

SIS0255 The cumulative IP amount exceeds the limit permitted for this merchant

MSG0008

SIS0256 The merchant cannot do preauthorizations MSG0008

SIS0257 The card does not allow preauthorizations MSG0008

SIS0258 Inconsistent confirmation details MSG0008

SIS0261 The transaction exceeds an operating limit established by Caixa Catalunya

MSG0008

SIS0270 Ds_Merchant_TransactionType Transaction Type not activated for this merchant MSG0008

SIS0274 Ds_Merchant_TransactionType Unknown transaction Type or not allowed for this gateway MSG0008


Table of messages that the buyer receives when an error occurs in the transaction together with their meanings.

CODE MESSAGE

MSG0000 The system is busy, please try later on

MSG0001 Order number repeated

MSG0002 The card BIN has not been cleared with FINANET

MSG0003 The system is starting up; please try again in a few minutes

MSG0004 Authentication error

MSG0005 There is no valid payment method for this card

MSG0006 Card out of service

MSG0007 Some details are missing; please check whether your browser accepts cookies

MSG0008 Error in details sent. Please contact your merchant.


ANNEX IV. LIST OF COUNTRY CODES

004 Afghanistan 178 Congo 360 Indonesia 008 Albania 180 Zaire 364 Iran 010 Antarctic 184 Cook Islands 368 Iraq 012 Algeria 188 Costa Rica 372 Ireland 016 American Samoa 191 Croatia 376 Israel 020 Andorra 192 Cuba 380 Italy 024 Angola 196 Cyprus 384 Ivory Coast 028 Antigua and Barbuda 203 Czech Republic 388 Jamaica 031 Azerbaijan 204 Benin 392 Japan 032 Argentina 208 Denmark 398 Kazakhstan 036 Australia 212 Dominica 400 Jordan 040 Austria 214 Dominican Republic 404 Kenya 044 Bahamas 218 Ecuador 408 North Korea 048 Bahrain 222 El Salvador 410 South Korea 050 Bangladesh 226 Equatorial Guinea 414 Kuwait 051 Armenia 230 Ethiopia 417 Kyrgyzstan 052 Barbados 233 Estonia 418 Laos 056 Belgium 234 Faeroe Islands 422 Lebanon 060 Bermuda 238 Falkland Islands 426 Lesotho 064 Bhutan 242 Fiji 428 Latvia 068 Bolivia 246 Finland 430 Liberia 070 Bosnia-Herzegovina 250 France 434 Libya 072 Botswana 254 French Guyana 438 Lichtenstein 074 Bouvet Island 258 French Polynesia 440 Lithuania 076 Brazil 260 French Southern territories 442 Luxembourg 084 Belize 262 Djibouti 446 Macao 086 Mauritius 266 Gabon 450 Madagascar 090 Solomon Islands 268 Georgia 454 Malawi 092 British Virgin Islands 270 Gambia 458 Malaysia 096 Brunei 280 Germany 462 Maldives 100 Bulgaria 288 Ghana 466 Mali 104 Burma 292 Gibraltar 470 Malta 108 Burundi 296 Kiribati 474 Martinique 112 Byelorussia 300 Greece 478 Mauritania 116 Cambodia 304 Greenland 480 Mauritius 120 Cameroon 308 Granada 484 Mexico 124 Canada 312 Guadeloupe 492 Monaco 132 Cape Verde 316 Guam 496 Mongolia 136 Cayman Islands 320 Guatemala 498 Moldavia 140 Central African

Republic 324 Guinea 500 Montserrat

144 Sri Lanka 328 Guyana 504 Morocco 148 Chad 332 Haiti 508 Mozambique 152 Chile 334 Heard and McDonald Islands 512 Oman 156 China 336 Vatican City 516 Namibia 158 Taiwan 340 Honduras 520 Nauru 162 Christmas Island 344 Hong Kong 524 Nepal 166 Cocos Islands 348 Hungary 528 Holland 170 Colombia 352 Iceland 530 Dutch Antilles 174 Comoros 356 India 533 Aruba


540 New Caledonia 646 Rwanda 762 Tajikistan 548 Vanuatu 654 St. Helens 764 Thailand 554 New Zealand 659 Anguilla 768 Togo 558 Nicaragua 662 St. Lucia 776 Tonga 562 Niger 666 St. Pierre and Miquelon 780 Trinidad and Tobago 566 Nigeria 670 St. Vincent and the

Grenadines 784 United Arab Emirates

570 Niue 674 San Marino 788 Tunisia 574 Norfolk Island 678 Sao Tome and Principe 792 Turkey 578 Norway 682 Saudi Arabia 795 Turkmenistan 580 Northern Mariana

Islands 686 Senegal 796 Turks and Caicos Islands

581 Minor (US) 690 Seychelles 798 Tuvalu 582 Pacific 694 Sierra Leone 800 Uganda 583 Micronesia 702 Singapore 804 Ukraine 584 Marshall Islands 703 Slovakia 807 Macedonia 586 Pakistan 704 Vietnam 818 Egypt 591 Panama 705 Slovenia 826 United Kingdom 598 Papua-New Guinea 706 Somalia 834 Tanzania 600 Paraguay 710 South Africa 840 United States 604 Peru 716 Zimbabwe 849 miscellaneous (US) 608 Philippines 720 Yemen 850 US Virgin Islands 612 Pitcairn 722 Tokelau Islands 854 Burkina 616 Poland 724 Spain 858 Uruguay 620 Portugal 736 Sudan 860 Uzbekistan 624 Guinea-Bissau 740 Surinam 862 Venezuela 626 Timor 744 Svalbard and Jan Mayen 876 Wallis and Futuna 630 Puerto Rico 748 Swaziland 882 Samoa 634 Qatar 752 Sweden 886 Yemen 638 Reunion 756 Switzerland 891 Yugoslavia 642 Rumania 760 Syria 894 Zambia 643 Russia


ANNEX V. SECURITY DIGITAL CERTIFICATES SSL / TLS Due to the heyday that in the last times has had the electronic commerce, merchants and Service providers have turned out to be forced to guarantee the safety of the transactions by Internet using strong mechanisms that contribute authentication of (at least) one of the ends, and the confidentiality and integrity of the interchanged information. It is this context where there appear the protocols SSL and TLS. The server's certificate SSL of the merchant must be expressed by a public recognized CA. Autosigned certificates are not accepted. The certificates listed below have been tested in our system and work correctly. These certificates of CA are loaded in the containers of certificates of confidence of our applications. In case the merchant wants to make use of a certificate expressed by a public recognized CA that is not in the list, it will have to get in touch with Caixa de Catalunya to verify his validity and interoperability with the different applications. In case the CA is accepted, it will be loaded in the applications and will be included in this document and the merchant will be informed of the acceptance. In case it should not be accepted the merchant will be informed so that it should obtain one expressed by the list. The average necessary time to analyze the validity or not of a CA for request of a merchant it will be 2 weeks. RECOGNIZED ENTITIES OF CERTIFICATION Next there appears the list of certificates of CA Root and Intermediate CA loaded in the containers of certificates of our system. It is important that the merchant verifies that his hierarchy of CAs is included in the following stage. Root CA’s ID. COMPANY SUBJECT SERIAL NUMBER CADUCITY

R1 ACE / Verisign OU = Class 3 Public Primary Certification Authority O = VeriSign, Inc. C = US

70BA E41D 10D9 2934 B638 CA7B 03CC BABF

02/08/2028

R2 Cybertrust CN = GTE CyberTrust Global Root OU = GTE CyberTrust Solutions, Inc. O = GTE Corporation C = US

01A5 14/08/2018

R3 Usertrust CN = UTNUSERFirstHardware OU = http://www.usertrust.com O = The USERTRUST Network L = Salt Lake City S = UT C = US

44BE 0C8B 5000 24B4 11D3 362A FE65 0AFD

09/06/2019

R4 Geotrust/Equifax CN = Equifax Secure Global eBusiness CA1 O = Equifax Secure Inc. C = US

01 21/06/2020

R5 Valicert E = [email protected] CN = http://www.valicert.com/ OU = ValiCert Class 2 Policy Validation Authority O = ValiCert, Inc. L = ValiCert Validation Network

01 26/06/2019

R6 Thawte E = premium[email protected] CN = Thawte Premium Server CA OU = Certification Services Division O = Thawte Consulting cc L = Cape Town S = Western Cape C = ZA

01 01/01/2021

R7 Thawte E = server[email protected] 01 01/01/2021


ID. COMPANY SUBJECT SERIAL NUMBER CADUCITY CN = Thawte Server CA OU = Certification Services Division O = Thawte Consulting cc L = Cape Town S = Western Cape C = ZA

R8 Verisign OU = Secure Server Certification Authority O = RSA Data Security, Inc. C = US

02AD 667E 4E45 FE5E 576F 3C98 195E DDC0

08/01/2010

R9 IPSCA E = [email protected] CN = IPS SERVIDORES OU = Certificaciones O = IPS Seguridad CA L = BARCELONA S = BARCELONA C = ES

00 30/12/2009

R10 Agencia Catalana de Certificación

CN = ECACC OU = Jerarquia Entitats de Certificacio Catalanes OU = Vegeu https://www.catcert.net/verarrel (c)03 OU = Serveis Publics de Certificacio O = Agencia Catalana de Certificacio (NIF Q 0801176I) C = ES

EE2B 3DEB D421 DE14 A862 AC04 F3DD C401

08/01/2031

R11 FNMT OU = FNMT Clase 2 CA O = FNMT C = ES

36F1 1B19 18/03/2019

R12 Equifax OU=Equifax Secure Certificate Authority O=Equifax C=US

35DE F4CF 22/08/2018

R13 AddTrust AB CN = AddTrust External CA Root OU = AddTrust External TTP Network O = AddTrust AB

01 30/05/2020

Intermediates CA’s ID COMPANY SUBJECT ISSUER SERIAL NUMBER CADUCITY

I1 ACE / Verisign I1 OU = www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign OU = VeriSign International Server CA Class 3 OU = VeriSign, Inc. O = VeriSign Trust Network

R1

254B 8A85 3842 CCE3 58F8 C5DD AE22 6EA4 78EE 48DE 185B 2071 C9C9 C3B5 1D7B DDC1

25/10/2011

I2 Comodo CN = Comodo Class 3 Security Services CA OU = (c)2002 Comodo Limited OU = Terms and Conditions of use: http://www.comodo.net/repository OU = Comodo Trust Network O = Comodo Limited C = GB

R2 0200 029A 28/08/2008

I3 Digisign CN = DigiSign CA DigiSSL Xp OU = Terms and Conditions of use: http://www.digisign.com/repository O = DigiSign Limited L = Dublin S = Dublin C = IE

R3 0B41 F1C4 7162 6DD1 D355 42AF C562 BBCB

09/06/2019

I4 Starfield Technologies

E = [email protected] CN = Starfield Secure Certification Authority OU = http://www.starfieldtech.com/repository O = Starfield Technologies, Inc. L = Scottsdale S = Arizona C = US

R5 0104 09/06/2024

I5 Thawte CN = Thawte SSL Domain CA O = Thawte Consulting (Pty) Ltd. C = ZA

R7 3000 0001

I6 ACE / Verisign CN = VeriSign Class 3 Secure Server CA OU = Terms of use at https://www.verisign.com/rpa (c)05 OU = VeriSign Trust Network O = VeriSign, Inc. C = US

R1 7533 7D9A B0E1 233B AE2D 7DE4 4691 62D4

19/01/2015

I7 IPSCA E = [email protected] CN = CLASE B3 ipsCAIPS Seguridad 2005 OU = Certificaciones O = IPS Seguridad CA L = Barcelona S = Barcelona C = ES

R9 0090 33 31/12/2009


ID COMPANY SUBJECT ISSUER SERIAL NUMBER CADUCITY

I8 Agencia Catalana de Certificación

CN = ECAL OU = Administracions Locals de Catalunya OU = Vegeu https://www.catcert.net/verCIC2 (c)03 OU = Serveis Publics de Certificacio ECV2 L = Passatge de la Concepcio 11 08008 Barcelona O = Agencia Catalana de Certificacio (NIF Q 0801176I) C = ES

R10 3D97 D393 0439 622A 3E1C 4DA6 BED1 730E

08/01/2019

I9 UserTrust CN = UTNUSERFirstHardware OU = http://www.usertrust.com O = The USERTRUST Network L = Salt Lake City S = UT C = US

R13 2621 1BF5 2AEB 51B0 0BFS 9FDD 8D36 DA9E

30/05/2020

URL of the companies listed above: COMPANY URL ACE/Verisign http://www.ace.es Comodo http://www.comodogroup.com/index.html DigiSign http://www.digisign.com Geotrust/ Equifax http://www.quickssl.com Starfield Technologies http://www.starfieldtech.com Thawte http://www.thawte.com IPSCA http://www.ipsca.com Agencia Catalana de Certificación

http://www.catcert.net

CyberTrust http://www.cybertrust.com

http://www.cybertrust.com/

http://www.ace.es/

http://www.comodogroup.com/index.html

http://www.digi-sign.com/

http://www.quickssl.com/

http://www.starfieldtech.com/

http://www.thawte.com/

http://www.ipsca.com/

http://www.catcert.net/


ANNEX VI. DISPUTE CIRCUIT


ANNEX VII. DISPUTING A CHARGEBACK


ANNEX VIII. RETRIEVAL REQUESTS CIRCUIT

localización del número de documento de...

Documents