TPV Virtual - Extended Merchant Manual July09

Virtual POS
EXTENDED MERCHANT MANUAL
LATEST UPDATE July 2009
VIRTUAL POS EXTENDED MERCHANT MANUAL
1. 2. 3. 4.
INTRODUCTION SECURITY GUARANTEES 3DSECURE CROSS-BORDER LICENSES OPERATING FEATURES

4.1. 4.2. 4.3. 4.4. TYPES OF AUTHORIZATION REQUESTS OPERATING RESTRICTIONS ADDITIONAL SECURITY MEASURES 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. GATEWAYrealizarPago 6.2. GATEWAYentradaXMLEntidad 6.3. GATEWAYoperaciones 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 PCI-DSS PAYMENT CARD INDUSTRY DATA SECURITY STANDARD
Pg. 2
11.
ANNEXES
ANNEX I. ANNEX II. DESCRIPTION OF PAYMENT AND RESPONSE FORMS 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
Page 3
VIRTUAL POS EXTENDED MERCHANT MANUAL 1.INTRODUCTION

CaixaCatalunyasVirtualPOSisacomputerapplicationwhichallowsshopsandbusinesseswhich sell their products and services on the Internet to accept payments for transactions with a credit/debitcardandhavetheamountcreditedtotheiraccount. ThecardsacceptedarethesameasthoseacceptedbyphysicalPOSterminalsspecifically,Visa, MasterCard and Maestro. You can also request authorization to operate with JCB cards, AmericanExpressandDinersClub. TheVirtualPOScanbeusedinvariouslanguages(Spanish,Catalan,English,French,German, Dutch,Italian,Swedish,Portuguese,Valencian,Polish,GalicianandBasque)andcanalso operatewithfourdifferentcurrencies(Euros,USDollars,SterlingPoundsandYens). TheVirtualPOSusesstandardInternetfunctionsandalgorithms,whatmeansitcanbeinstalledin any server or platform, regardless of the operating system or programme language. It has also beendesignedtobeviewedonbothdesktopbrowsers(standardPCs)andhandhelddevices(e.g. PDAs). Communications with the Virtual POS are always made using a secure SSL connection (seeannexV). 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), checktotals,canceltransactionsandmakepartialrefunds,amongstotheroptions.
Page 4
VIRTUAL POS EXTENDED MERCHANT MANUAL 2.SECURITYGUARANTEES3DSECURE

The Virtual POS has been designed to operate completely securely for sales transactions made overtheInternet,i.e.: 1. It will try to contact the card issuer to seek authorization of the cardholder (verification of identity)beforemakingtherelevantauthorizationrequest.Inthiswayitguaranteesthatonly thegenuinecardholdercanuseit. 2.ItusesSSLineverycommunication,preventingthirdpartiesfrominterceptingtheinformation. Therefore confidentiality is assured in every communication established during the transaction(seeannexV). 3.Italsofeaturesmechanismstotesttheauthenticityoforiginoftransactionsandtoprevent third parties from manipulating data. This guarantees the integrity of the transaction details. TheCaixaCatalunyaVirtualPOSincorporates,asamatterofcourse,aspaceforthecardsCVV2 tobeentered(thethreedigitsecuritycodeonthebackofthecard) asthishasproventobean effectivemeasureagainstcardfraud. 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, amongstothermeasures,the3DSECUREsystemwhichincorporatestheVERIFIEDbyVISA, MASTERCARDSECURECODEandJCBSecureprotocols. 3DSECURE is mandatory for transactions done with MAESTRO cards, except for domestic transactions,wheretheMaestrocardisissuedbyaSpanishbank. 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 MasterCardobligethecardissuertoacceptresponsibilityinthesecases. TheCaixaCatalunyaVirtualPOSiscertifiedbytheVISA,MASTERCARDandJCBcardsystemsasa secure virtual terminal and therefore you are guaranteed payment for all operations except inthefollowingcircumstances: 1. Themerchantcannotprovidedocumentaryproofthattheproductorservicehasbeensupplied tothecardholderinaccordancewiththetermsandconditionsofsale. 2. In the case of recurring payments, if on the initial payment the card issuer had not made a positiveauthenticationofthecardholder. 3. OperationscarriedoutwithVisaBusiness,VisaCorporateandVisaPurchasingcards. TheVirtualPOSwillbeupdatedwiththelatestsecurepaymentversionswhenthey are ordained byinternationalorganisations,thoughyoushouldbeadvisedthatmerchants willNOThaveto makethesemodificationsthemselvestheywillalwaysbeimplementedcentrally.
Page 5
VIRTUAL POS EXTENDED MERCHANT MANUAL 3.CROSSBORDERLICENSES

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 residenceisoutsideSpain. Each credit card company has independently demarcated the catchment area of their license. Givenbelowarethecountriesthatcurrentlymakeupthegeographicalcrossborderareaofeach creditcardcompany: VISA: Merchants resident in Germany, Andorra, Austria, Belgium, Bulgaria, Cyprus, Denmark, Slovakia, Slovenia, Spain, Estonia, Finland, France, Gibraltar, Greece, Greenland, Holland, Hungary,Iceland,FaeroeIslands,Ireland,Israel,Italy,Latvia,Lithuania,Luxembourg,Malta, Norway, Poland, Portugal, United Kingdom, Czech Republic, Romania, Sweden, Switzerland andTurkey. MASTERCARD:WesternEuropeRegion Merchants resident in Germany, Andorra, Austria, Belgium, Bulgaria, Cyprus, Vatican City, Denmark, Slovakia, Slovenia, Spain, Estonia, Finland, France, Gibraltar, Greece, Holland, Hungary,Iceland,Ireland,IsleofMan,ChannelIslands,Italy,Latvia,Liechtenstein,Lithuania, Luxembourg, Malta, Monaco, Norway, Poland, Portugal, Romania, United Kingdom, Czech Republic,SanMarino,Sweden,SwitzerlandandTurkey. JCB:Anymerchantresidentinanycountryintheworld.
Page 6
VIRTUAL POS EXTENDED MERCHANT MANUAL 4. OPERATINGFEATURES

4.1.TYPESOFAUTHORIZATIONREQUESTS
Dependingontheneedsof each merchant,theVirtualPOSoffersa widevariety ofauthorization requestoptionswhichthemerchantcancombineaccordingtohisrequirements. Authorization(Ds_Transaction_Type=0orA) Thisis the most general situation. The transactionisinstigated by the cardholder who is present duringthesalesprocess.Onceithasreceivedthepurchaserequestfromthemerchant,theVirtual POSaskstheclientforthedetailstoauthorizethetransaction. If the cardholders bank has an authentication system, the cardholder will be asked by the card issuertoprovidethenecessaryproofforauthentication. Therequestforauthenticationtakesplaceinrealtimeandtheamountischargedimmediatelyto thecardholdersaccount(creditordebit).Itshouldbenotedthattheguaranteesarethesamefor bothtypesofcard. The transaction is automatically recorded by the Virtual POS and sent on a daily basis for batch processingtobecreditedtothemerchant. Thecardholderreceivesareceiptofthepaymenthehasmade. Preauthorization(Ds_Transaction_Type=1) NOTE:inaccordancewithinternationalbrandregulations,thisoperationisrestrictedto businessesworkinginthefollowingareas:hotels,travelagenciesorcarhirecompanies. Thisoptioncanbeusedwhentheexactamountcannotbedeterminedatthetimeofpurchase,or if, for any reason, the merchant does not want the amount to be charged to the customers accountimmediately. 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, andreceivingtherelevantreceiptfromtheVirtualPOS. The request for preauthorization is carried out in real time, resulting in a retention of the sales amountfromthecardholdersaccount. The transaction is not recorded and therefore does not have any accounting impact on the cardholdersaccountandisnotpaidtothemerchant(inthecaseofdebitcards,someissuing entities debit the sum from the cardholders account, which is automatically cancelled afterafewdays). AllpreauthorizationsmustbesupportedbyaPreauthorizationConfirmationwithinamaximumof 7calendardays.Shouldthisnotbethecase,theywilllosetheirvalidityasapaymentguarantee. PreauthorizationConfirmation(Ds_Transaction_Type=2) Thisisanessentialcomplementtotheaboveoperation. Thecardholderisnotpresentandthereforethisisalwaysinstigatedbythemerchant.
Page 7

This operation should be done within 7 calendar days of the original preauthorization and the amountshouldbeLESSTHANorEQUALTOtheoriginalamount. Thistransactionisvalidforaccountingpurposesandisautomaticallychargedtothecardholders accountandsentforbatchprocessingandpaymenttothemerchant. The preauthorization confirmation guarantees payment and maintains the secure transaction conditionsoftheoriginalpreauthorization. TheVirtualPOSwillvalidatetheexistenceoftheoriginaltransactionandtheamountthatneedsto beconfirmed,rejectingthetransactionifthereisanerror. CancellationofPreauthorization(Ds_Transaction_Type=9) Thecardholderisnotpresentandthereforethisisalwaysinstigatedbythemerchant.Itshouldbe donewithin7daysoftheoriginalpreauthorization. The Virtual POS will validate the existence of the original transaction, rejecting the transaction if thereisanerror. PartialorTotalRefund(Ds_Transaction_Type=3) These are accounting transactions instigated by the merchant. The Administration Module of the VirtualPOScanalsobeusedtodothesemanually. TheVirtualPOScorroboratesthe existence of theoriginalauthorizationofthesumthatneedsto berefunded,andthatthisamountinnowayexceedstheoriginallyauthorizedamount. This is accounted for in the cardholders account (some card issuers may delay payment to the cardholder by a few days) and therefore is automatically recorded and sent for the settlementprocesswhichsubsequentlymakestherelevantchargetothemerchantsaccount. Recurringtransaction(Ds_Transaction_Type=5) Thisallowsthecardholdertosubscribetoaregularserviceofferedbythemerchant. Thetotalamountofthisserviceispaidbyapredeterminednumberofinstalments. Byusingthisoperation,themerchantnotifiesthetotalamounttobepaid,theminimumnumber of days at which the payment of the next instalment should be made, and the date of the final instalment. Theflowofthisoperationissimilartothatofanormalpurchaseauthorization.Thecustomermust be informed of the total amount payable and the instalments that make it up, and the authenticationisbasedonthesedetails. However,therequestforauthorization,whichwillbeaccountedfor,isonlydonefortheamountof theinitialinstalmentlikeanormalauthorizationrequest. Subsequently, the merchant sends successive authorization requests at the due date of every instalment.
Page 8

Successivetransactions(Ds_Transaction_Type=6) Theseformanessentialcomplementtotheaboveoperation. Thecardholderisnotpresentandthereforethistransactionisalwaysinstigatedbythemerchant. Thisoperationshouldbecarriedoutinlinewiththeconditionsoftheoriginalrecurringtransaction in terms of the amount, instalments and finaldate. These details will be validated by the Virtual POS,whichwillrejectthetransactionifitdetectsanyerrors. Thistransactionisaccountedforbyanentryinthecardholdersaccountforeachinstalment,and sentforthedailysettlementprocesstobecreditedtothemerchant. 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. Inordertoprocessthesetransactions,anew authorizationrequestwillneedtobesubmittedfor eachinstalment. Authentication(Ds_Transaction_Type=7) Thiskindofoperationcanbeusedbythemerchantwhenthesalesamountcannotbedetermined exactlyatthetimeofpurchase. Theoperationissimilartothatofthepreauthorization,thoughinthiscase onlythefirstpartof 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 deductedfromthecardholdersaccount. Subsequently, within the next 45 calendar days, the merchant should send an authentication confirmationwhichwillcompletetheoriginaltransaction. Confirmationofauthentication(Ds_Transaction_Type=8) Thisisaninseparablepartoftheaboveoperation. Thecardholderisnotpresentandthereforethisisalwaysinstigatedbythemerchant. Theamountmaybedifferenttotheoriginaloperation(andcanevenbeHIGHER). Thistransactionisimmediatelyaccountable,creatinganentryinthecardholdersaccountandsent tothesettlementprocessforcreditingthemerchant. Authenticationconfirmationshavethesamesecurityconditionsastheoriginalauthentication. TheVirtualPOSwillvalidatetheexistenceofthetransaction,rejectingitifthereareanyerrors.
Page 9

DeferredPreauthorization(Ds_Transaction_Type=O) These are similar operations to preauthorizations but are available for all sectors of activity. Authorizationisobtainedfromtheissuingbankinrealtimewhichwillneedtobeconfirmedwithin thenext72hoursifthetransactionisdefinitelygoingtogothrough. Ifconfirmationhas notbeen sent within 72hoursoftheday/timeoftheDeferred Pre authorization, the authorization will be cancelled automatically and thus cannot be confirmed. In contrast to traditional preauthorizations, the amount of the Deferred Preauthorizationmust beexactlythesameasitsrespectivepreauthorization. Therequestforpreauthorizationtakesplaceinrealtimeandresultsinawithholdingofthesales amountfromthecardholdersaccount. The transaction is not captured and therefore is neither deducted from the cardholders account nor credited to the merchant (in the case of debit cards, some issuing entities deduct it fromthecardholdersaccount,whichisthencancelledafterafewdays). To activate the Deferred Preauthorization service, it is necessary for the merchant to make a specificrequestathis/herCaixaCatalunyabranch. ConfirmationofDeferredPreauthorization(Ds_Transaction_Type=P) Thisisaninseparablecomplementtothepreviousoperation. Thecardholderisnotpresent,andthereforethisisalwaysinstigatedbythemerchant.Itshouldbe done within 72 hours of the original preauthorization and the amount must be exactly the sameastheoriginal. This transaction is accounted for, being automatically debited from the cardholders account and sentforbatchprocessingtobecreditedtothemerchant.Theconfirmationofthepreauthorization is a guaranteed payment and has the same conditions with regard to secure transactions as the originalpreauthorization. TheVIRTUALPOSwillvalidatetheexistenceoftheoriginaltransactionandtheamountthatneeds tobeconfirmed,rejectingthetransactionifthereisanykindoferror. CancellationofPreauthorization(Ds_Transaction_Type=Q) Thecardholderisnotpresentandthereforethisisalwaysinstigatedbythemerchant.Itcanonly bedonewithinthe72hoursfollowingtheoriginalpreauthorization. TheVIRTUALPOSwillvalidatetheexistenceoftheoriginaltransaction,rejectingthetransactionif thereisanykindoferror. RecurringDeferredPreauthorization(Ds_Transaction_Type=R) This is similar to the recurring transaction and allows the cardholder to subscribe to a regular serviceofferedbythemerchant.However,itdiffersinthatthefirstauthorizationwillnothaveany 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 DeferredPreauthorizationmustbeexactlythesameasitsrespectivepreauthorization.
Page 10

Ifconfirmationhas notbeen sent within 72hoursoftheday/timeoftheDeferred Pre authorization, the authorization will be cancelled automatically and thus cannot be confirmed. Thetotalamountofthisservicewillbepaidbyaspecificnumberofinstalments.Bymeansofthis transaction,themerchantshouldinformthetotalamountpayable,theminimumnumberofdays 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 Pre authorization (the first transaction) and the successive payments associated with this first authorization. Theseformaninseparablepartofthepreviousoperation.Anewauthorizationrequestneedstobe madeforeachinstalment.Thecardholderisnotpresentandthereforethisoperationisinstigated bythemerchant. Thistransactionisaccountedfor,beingdebitedfromthecardholdersaccountforeachinstalment andsenttothedailysettlementprocesstobecreditedtothemerchant. Successive transactions have the same security conditions as the original recurring transaction, exceptiftheoriginaltransactionwasregardedassecurebuttherewasnopositiveauthentication oftheclient.Inthiscase,thesuccessivetransactionswillnotberegardedassecure. Thetablebelowshowsasummaryofthemainfeaturesofeachoperation:
Typeofoperation Authorization Preauthorization Confirmationof preauthorization Cancellationof preauthorization Instigated by Cardholder Cardholder Merchant Merchant Accountable YES NO YES NO Preauthorization:7days Amount<or= Validationoforiginal transaction Guaranteeofsecure transaction Ifconditionsallow Ifconditionsallow Sameasoriginal
Preauthorization: 7 days Amount= Authorization: Sum of returned amounts <or= 120days Ifconditionsallow
Automaticrefund
Merchant
YES
Recurring Successive Authentication Confirmationof authentication Deferred Preauthorization Confirmationof Deferred Preauthorization
Cardholder Merchant Cardholder Merchant Cardholder
YES YES NO YES NO
Recurring: amount, If the original was instalmentsandfinaldate authenticated Authentication:45days Preauthorization: 72hoursmaximum Amount=
Page 11
Ifconditionsallow Sameasoriginal Ifconditionsallow
Merchant
YES
Sameasoriginal

Typeofoperation Cancellationof Deferred Preauthorization RecurringDeferred Preauthorization Confirmationof RecurringDeferred Preauthorization Successiveof RecurringDeferred Preauthorization Instigated by Merchant Accountable Validationoforiginal transaction Preauthorization: 72hoursmaximum Preauthorization: 72hoursmaximum Amount= Guaranteeofsecure transaction
NO
Cardholder
NO
Ifconditionsallow If the original was authenticated
Merchant
YES
Merchant
YES
Recurring If the original was Preauthorization: amount, authenticated instalmentsandfinaldate
4.2.OPERATINGRESTRICTIONS
Giventhatthesetransactionstakeplaceinavirtualenvironment,VirtualPOSoperationsaremore likelyto be subject to fraud, e.g. when itisnot actually the cardholder making the purchase. To reducetheriskinherentintheseoperations,CaixaCatalunyaoffersthepossibilityofimplementing a series of restrictions on the operating capacity of each merchant. These restrictions must be adaptedtovaluesthatdonothamperthemerchantssalesprospectsbutatthesametimeavoid exaggerateddeviationsinhisregularturnover(inmostcases,thiswouldmeanthatheissubject toattackfromstolenand/orfraudulentcards). Maximumnumberoftransactionsperday(authorizedanddeclined) Maximumamountpertransaction Maximumamountwhichcanbeaccumulatedinoneday Maximumnumberofdailytransactions(acceptedanddeclined)percard Maximumdailyamountpercard Maximumnumberofdailytransactions(acceptedanddeclined)peruser(IPaddress) Maximumdailyamountperuser(IPaddress) Ifthemerchantwishestomodifyanyoftheseparameters,heshouldsubmitarequesttoCaixade Catalunya.
4.3.ADDITIONALSECURITYMEASURES
Toprotecttheinterestsofthemerchantandreducethevolumeofincidentsasfaraspossible,we suggest adopting the following additional security measures whenever you accept payments with cards. SIGNSTODETECTINTERNETFRAUD 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 victimoffraud. 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.
Page 12

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 arent 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. TRANSACTIONSCONTROLS 1.ItisusefulthatthemerchantknowstheInternetProtocoladdress(IP)toidentifythecomputer 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 QUERYoptionseesection5.3.).Themerchantshouldcheckthat: a. The same user (same IP address) has not paid (or tried to pay) with more than two differentcards. b. The same user (IP) or the same card has not made multiple transactions in a short periodoftime. c. Purchases are not being made with generated cards (i.e. the first digits of the card numbersarethesamebutthelastoneschange). d. Whenmakingdifferentpurchases,thesameuser(IP)orthesamecardisnotrecorded onthewebsitewithdifferentdetails. 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.Bymeansoftheresponsemessage("Ds_Response"field)ortheADMINISTRATIONMODULEof 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 blockedduetoloss,robbery,falsificationorfraudulentuseofthecardnumber.Inthesecases, the merchant should block the user (identifiable by the IP address and registration details) to preventhimfromattemptinganynewpayments. 3.Thereisalsoafieldintheresponsemessageknownas"Ds_Card_Country"whichgivestheISO code of the country where the card was issued. By comparing this with the IP address of the buyer,youcanfiltersuspectedfraudulentbehavior(e.g.acardissuedinonecountrybutused fromanIPaddressinanothercountry). 4. Ifthemerchantcapturethecardnumber,itwouldbeusefultoimplementaMod10algorism thatquicklycheckthevalidityofthecardnumberpresentedforpurchase. 5. Checkthevalidityofthecustomersregistrationdata. a. Validatetelephonenumbersusingdirectorylookups. b. Useatelephonecodeandprefixtabletoensurethatenteredareaandtelephoneprefix arevalidfortheenteredcityandstate. c. Use a postcode table to verify that the entered postcode is valid for the entered city andstate. d. Testthevalidityoftheemailaddressbysendinganorderofconfirmation. 6. Establishvelocitylimits.Youcansignificantlyreduceriskexposurebyusinginternaltransaction controlstoidentifyhighrisktransactionspriortoauthorization.Thesecontrolshelpdetermine whenanindividualcardholderortransactionshouldbeflaggedforspecialreview. a. Set review limits based on the number and amount of transactions approved within a specifiednumberofdays.Adjusttheselimitstofitpriorpurchasingpatterns.
Page 13

b. Setreviewlimitsbasedonsingletransactionamount. c. Ensurethatvelocitylimitsarecheckedacrossmultiplecharacteristics,includingshipping address,telephonenumber,andemailaddress. d. Contact customers that exceed these limits to determine whether the activity is legitimateandshouldbeapproved,providingthattheissueralsoapprovesitduringthe authorizationprocess. e. Donotpermitcardholderstousemorethanoneaccountnumberperpurchasei.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,andcustomerpurchasingpatterns. 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 ordersbutdonotconfirm(thereforedoesnothaveanyaccountingimpactonthecardholders account)untiltheyhavepassedthemerchantantifraudcontrols. 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 requirementswillqualifyforchargebackblocking(seesection3). 9. UseCVV2codetoverifycardauthenticity. 10. If the merchant has active the daily report of incidences (chargebacks, confirmed fraud and retrievalrequests)seesection9,itwouldbesuitablethatthemerchantsecuritydepartment putincontactwiththeclientslisted,canceltheiraccountsorsubscriptions,addthemtotheir blacklistsortakeanyothermeasuretheydeemnecessary. If the transaction does not satisfactorily fulfill all the controls indicated, the merchant mustrefusethecardasamethodofpaymentandcancel,ifapplicable,thePOStransaction. Themerchantsmanagementandstaffmustbeawareofthesesecuritymeasuresandall employeesshouldbetrainedinhowtodealwithcardpayments,andregularlychecked 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 contractwithCaixaCatalunyarescinded.
4.4.REGULATIONS
The Virtual POS, by its very nature, is subject to certain regulations which stem from its use in internationalpaymentsystemsanditsmanagementbyCaixaCatalunya. These regulations appear in the Retail Establishments Contract signed between Caixa Catalunya andthemerchant. Someofthemoreimportantofthesearelistedbelow: 1. The merchant can only process transactions that originate from the website/s detailedin the contractwithCaixaCatalunya. 2. Thewebsitemustfeaturethefollowinginformation,amongother: 2.1 The merchants name and that of the websites owner, whether an individual or
Page 14

company,mustappearonthehomepageandthecardpaymentpageofthesite. 2.2Themerchantscancellationandproductreturnspolicy. 2.3Themerchantsshipmentanddeliverydatepolicy. 2.4Detailsofthecustomerservicedepartmentandhowtoaccessit 2.5Themerchantsprivacyandprotectionofpersonaldatapolicy. Themerchantshouldimmediatelycancelanycardtransactionwhenanunduechargehasbeen madeorthefullsalesanddeliveryprocessofthegoodshasnotbeencompleted. Themerchantmayundernocircumstancesstorethedetailsofcredit/debitcardsinhisfacility exceptwhenthisisnecessaryforoperationalpurposes,inwhichcasehewillbesubjecttothe VISA and MASTERCARD PCI/DSS Security Programme. Even in these circumstances, it is totallyforbiddentokeepCVV2numbers. Themerchantmayonlyprocesstransactionsunderthesameestablishmentnumberwhichare coveredbythebusinessactivitycodewithwhichheisregistered.Furthermore,incaseswhere 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 advancefromCaixaCatalunyasothatthebankcansubmitaproposaltothecardcompanies.
3. 4.
5.
Page 15
VIRTUAL POS EXTENDED MERCHANT MANUAL 5.ADMINISTRATIONMODULE
5.1.ACCESS
TheAdministrationModuleofCaixaCatalunyasVirtualPOSallowsthemerchanttomakerefunds, consultthedetailsoftransactionsmadeandthetotalamountspaidbycredit/debitcards. ToaccesstheAdministrationModule,themerchantshouldselecttherelevantoptionintheservice menu of Caixa Catalunyas Online Banking system (www.cconline.es), or go to the following Internetaddress: https://canales.sermepa.es
5.2.USERS
CaixaCatalunyawillprovidethemerchantwithausername/passwordtoaccesstheAdministration Module as an administrator. In the user management option it will be possible to register new userswithoneofthefollowingtwoaccessprofiles: 1. Informative:forcheckingmovementsandtotalsonly. 2. Administrative: as well as checking movements and totals, you can make total or partial refundsofsalestransactions. Forsecurityreasons,werecommendyouchangethepasswords. TheUserssectioncontainsthefollowingsubsections: 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, deregisteringandmodifyingmerchantusers. 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. Twokindsofuserscanberegistered: 1. Terminal:formanagingtransactionsmadeataspecificmerchantandterminal. 2. Merchant:formanagingtransactionsmadebyallamerchantsterminals.
5.3.CHECKINGTRANSACTIONS
Inordertochecktransactionsthathavetakenplaceduringthelast365calendardays,whether authorizedordeclined,youshouldselecttheQUERIESoptiononthemainpageandenterthestart andenddaterelatingtotheperiodforwhichyouwanttoobtainthisinformation. You can not send searches including more that 30 days. In case you need that you must send consecutivequeriesof30daysperiods.
Page 16

Ifyou wantto referto aspecifictransaction,andyouknowthepurchase referencenumber, you canalsogodirectlytothedetailsofthistransaction. WhenyouhaveclickedontheACCEPTbutton, ascreenwillappearlistingthetransactionsfound withinthesearchdates. Theresultofthesearch,aswellasbeingvisibleonthescreen,canbePRINTEDorEXPORTEDtoa textfilewithfieldsdemarcatedbythecharacter:
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. OnlyuserswhocanaccesstheAdministrationModulewithanadministrativeprofileareauthorized to make refunds. The transactions should be viewed by Merchant No. and Terminal No. (usually No.1,terminalinEuros). Tomakeapartialortotalrefundoftheselectedtransaction,youshouldclickontheredbuttonin 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 exceedtheamountoftheoriginaltransaction. WhenyouhaveclickedontheACCEPTbutton,apagewillappearshowingthereceiptoftherefund whichcanbeprintedorsaved.
5.5.CHECKINGTOTALS
By pressing the TOTALS button on the lefthand side of the homepage, a list of the last 45 sessionswillappear.SelecttherequiredsessionandpressACCEPT. Ascreenwillthenappearshowingthetotalamountsandnumberoftransactions.
Page 17
VIRTUAL POS EXTENDED MERCHANT MANUAL 6.INSTALLATION

Thisguideprovidestheinformationnecessaryforthemerchant/companyoritscomputersystems servicetoinstalltheVirtualPOSontheemerchantswebsite.Theinstallationbasicallyconsistsof entering certain computer instructions in the website which remotely execute the Virtual POS softwareresidentinCaixaCatalunyassecureserver.Werecommendthatthisinstallationisdone bythespecialistpersonnelwholookafterthemaintenanceofthemerchantswebsite. To carry out the first actual checks during the installation phase, we recommend using any fictitious16digit number sequence. If the installationhas 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 andthecardholder.Inthiscase,itisadvisabletodotherelevantrefundtransactiontoundothe accountingentriesintherespectiveaccountswhichalsooffersyoutheopportunityofcheckingthe refundfunction. To send the transactions to the Virtual POS of Caixa de Catalunya there are three different gateways.Eachoneofthemisconfiguredforadifferentwayofuse. realizarPago: thisis for HTML. This gateway is the most common asitis used when the merchantdoesnthaveanycontactwiththecarddata.Theinstallationbasicallyconsistsof entering certain computer instructions in the website which remotely execute the Virtual POSsoftwareresidentinCaixaCatalunyassecureserver. entradaXMLEntidad:thepurchaseformviathevirtualPOSwillconsistonasingleinput. The input value will be the XML document, which must be in the format of x-www-formurlencoded.ThisformwillbesentviaaPOST.Thisallowsthemerchanttocapturecarddata butalsoisabletoprocess3DSECUREtransactions. Operaciones:isfor HOSTtoHOSTtransactionsthatworkasanXMLconversation. Often used to send refunds, subscriptions, and other operations where the cardholder is not present.Itsnotpossibletoprocess3DSECUREtransactions. Merchants that dont want to get the card data themselves (and to avoid being PCIDSS compliant)mustusetherealizarpagooption. OncetheregistrationprocessoftheVirtualPOShasbeencompleted,themerchantwillreceivethe followinginstallationhelpfilesbyemail:
AsimulatorofthemerchantsVirtualPOSmadeupof: ApaymentformimplementedinHTML. ASHA1implementedinJavaScript. ExamplesofSHA1programmingimplementedin: C CGIinC JavaJSP JavaJSP+Bean JavaScript(notrecommendedifbeinginstalledinthemerchantsownwebsite) ASP Perl PHP IfthemerchantsInternetserverneedsotherlanguages,themerchant/companyshouldget incontactwithCaixaCatalunyasTechnicalInstallationSupportService.
Page 18
6.1.GATEWAYrealizarPago
Mark Up Language . . . . . . . . . . . . . . . . . . . HTML Is it 3DSecure available? . . . . . . . . . . . . . YES Can the merchant capture Card Data? . . . NO
HTMLlanguage.Thisgatewayisthemostcommonasitisusedwhenthemerchantdoesnthave 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 Catalunyassecureserver. Thepaymentpageofthemerchantswebsiteshouldincludeabuttonforthebuyertoassociatethe paymentwithhiscard. Thisbuttonshouldbelinkedtothehiddenpaymentformwhichisdetailedbelow.Whenthebuyer selects this button, the merchant should send the payment form for the transaction to the Caixa Catalunyaserveratthefollowingaddress:
https://sis.sermepa.es/sis/realizarPago Thewindow orframein whichtheVirtual POSopensmust havevertical andhorizontal movementbarssoitcanbeadaptedtothedifferentauthenticationpagesthatmaybeshownto thebuyerinsubsequentprocesses.ThecardholderwillinformhiscarddatadirectlyintheVirtual POSwebpageofCaixadeCatalunyasothemerchantswebsitedoesnthaveanycontactwithit. ThedetailswhichmustbeincludedinthepaymentformareshowninANNEXI. There is an additional field in the message where the main details relating to the purchase are transmittedincodebytheSecureHashAlgorithm(SHA1),seechapter6.4. Applicationstobeinstalled: MANDATORY:Apaymentforminstalledinthemerchantswebsite. MANDATORY:SHA1installedinthemerchantsInternetserver. OPTIONAL: Anapplicationforreceivingandprocessingonlineresponsestopayment authorizationrequests.
Once the cardholder has completed the payment process, the screen showing the result appears whichincludesa buttonsothecustomercanreturntoshoppingonthemerchantssite. Thewayinwhichthecustomercontinueshissessiononthemerchantswebsitewilldependonthe instructions associated with the button. These instructions, which the merchant will havegivenCaixaCatalunyainthequestionnaireprovidedwhenheregistered,mayinclude: CLOSEWINDOWinstruction:Onselecting ,thewindoworframeshowing the payment result closes and the session continues on the merchants web page which wasinthebackground. 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 havegivenCaixaCatalunyainadvance.ThisURLcanbedifferentdependingonwhether thepaymenthasbeenauthorized(URL_OK)ordeclined(URL_KO). Youshouldbearinmindthatifthecustomer closesthe windowusingthe
Page 19
buttonon

the browser, the URL_OK/URL_KO will not work and the session will continue on the webpageinthebackground. OptionformerchantswithONLINERESPONSEVIAURL:Aswellasthetwoprevious instructions, for merchants with the ONLINE RESPONSE VIA URL service, the session continuitycanbedonefromthemerchantsownwebsite,closingthepaymentwindowas soonastheonlineresponsehasbeenreceived.Seechapter7.1. Duringtheinstallationprocessif,whenyousendthepaymentformwhichremotelyexecutesthe VirtualPOSapplication,oneerrormessagesappears,thisindicatesthatoneoftheparametersin thefieldssentwaswrong. Tolocatetheincorrectfield,youshouldlookatthesourcecodeoftheerrorpageandsearchinthe HTML text for the SIS chain. The numerical value xxxx next to the <!SISxxxx:> instructionwillindicatethetypeoferror,asdescribedinANNEXIII. Also,ANNEXIIIincludesasecondtablewiththemessageshowntothecardholderinthecaseof thedifferenterrors.
6.2.GATEWAYentradaXMLEntidad
Mark Up Language . . . . . . . . . . . . . . . . . . . XML (single input) Is it 3DSecure available? . . . . . . . . . . . . . YES Can the merchant capture Card Data? . . . YES ThepurchaseformviathevirtualPOSwillconsistofasingleinput.TheinputvaluewillbetheXML 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 shouldprovide the information on the purchase to the following Web serveraddresssoitcanauthorizethetransaction: https://sis.sermepa.es/sis/entradaXMLEntidad Thewindow orframein whichtheVirtual POSopensmust havevertical andhorizontal movementbarssoitcanbeadaptedtothedifferentauthenticationpagesthatmaybeshownto thebuyerinsubsequentprocesses. ThedatathatcanbeincludedintheXMLdocument,andwhichareessentialforauthorization,are mainlydescribedinANNEXI. WecanidentifytwotypesofXMLdocument: 1.DATOSENTRADA:documentsentbythemerchant 2. NOTIFICACIONXML: document sent by the payment platform in response. For further details,seesection7.1ofthissection. Adescriptionofthefirstdocumentisgivenbelow:
Version1.<fuc_comercio> <!ELEMENTDATOSENTRADA (DS_VERSION, DS_MERCHANT_AMOUNT, DS_MERCHANT_CURRENCY, DS_MERCHANT_ORDER, DS_MERCHANT_MERCHANTCODE, Page 20

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?)> <!ELEMENTDS_VERSION(#PCDATA)> <!ELEMENTDS_MERCHANT_AMOUNT(#PCDATA)> <!ELEMENTDS_MERCHANT_CURRENCY(#PCDATA)> <!ELEMENTDS_MERCHANT_ORDER(#PCDATA)> <!ELEMENTDS_MERCHANT_MERCHANTCODE(#PCDATA)> <!ELEMENTDS_MERCHANT_MERCHANTURL(#PCDATA)> <!ELEMENTDS_MERCHANT_MERCHANTNAME(#PCDATA)> <!ELEMENTDS_MERCHANT_MERCHANTSIGNATURE(#PCDATA)> <!ELEMENTDS_MERCHANT_TERMINAL(#PCDATA)> <!ELEMENTDS_MERCHANT_TRANSACTIONTYPE(#PCDATA)> <!ELEMENTDS_MERCHANT_MERCHANTDATA(#PCDATA)> <!ELEMENTDS_MERCHANT_PAN(#PCDATA)> <!ELEMENTDS_MERCHANT_EXPIRYDATE(#PCDATA)> <!ELEMENTDS_MERCHANT_CVV2(#PCDATA)> Where: DS_VERSION:messageversion. DS_MERCHANT_AMOUNT:seeAnnexI DS_MERCHANT_CURRENCY:seeAnnexI DS_MERCHANT_ORDER:seeAnnexI DS_MERCHANT_MERCHANTCODE:seeAnnexI DS_MERCHANT_MERCHANTURL:seeAnnexI DS_MERCHANT_MERCHANTNAME:seeAnnexI DS_MERCHANT_MERCHANTSIGNATURE:seesection6.4 DS_MERCHANT_TERMINAL:seeAnnexI DS_MERCHANT_TRANSACTIONTYPE:seeAnnexI DS_MERCHANT_MERCHANTDATA:seeAnnexI DS_MERCHANT_PAN:seeAnnexI DS_MERCHANT_EXPIRYDATE:seeAnnexI DS_MERCHANT_CVV2:seeAnnexI <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>
Anexampleofthemessageisgivenbelow:
In response to the request made, Caixa Catalunyas 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 havingbeenputintotheformatxwwwformurlencoded. ThefieldsthisdocumentcanhaveareexplainedinANNEXI Exampleofnotificationformat:
Version1.<fuc_comercio> <!ELEMENTNOTIFICACIONXML Page 21

(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?)> <!ELEMENTDs_Version(#PCDATA)> <!ELEMENTDs_Amount(#PCDATA)> <!ELEMENTDs_Currency(#PCDATA)> <!ELEMENTDs_Order(#PCDATA)> <!ELEMENTDs_MerchantCode(#PCDATA)> <!ELEMENTDs_Terminal(#PCDATA)> <!ELEMENTDs_Response(#PCDATA)> <!ELEMENTDs_MerchantData(#PCDATA)> <!ELEMENTDs_SecurePayment(#PCDATA)> <!ELEMENTDs_Card_Number(#PCDATA)> <!ELEMENTDs_ExpiryDate(#PCDATA)> <!ELEMENTDs_Card_Country(#PCDATA)> <!ELEMENTDs_TransactionType(#PCDATA)> <!ELEMENTDs_AuthorisationCode(#PCDATA)> <!ELEMENTDs_Signature(#PCDATA)> <!ELEMENTDs_ErrorCode(#PCDATA)> Where: Ds_Version:versionofDTDtovalidateXMLmessage. Ds_Amount:amountoftransaction. Ds_Currency:transactioncurrency. Ds_Order:transactionorder. Ds_Signature:samefieldsasonlinenotificationofanormaltransaction. Ds_MerchantCode:merchantscodeofthetransaction. Ds_Terminal:POSterminalnumberofthetransaction. Ds_Response:figureshowingtheresultofthetransaction,indicatingwhetherithasbeenauthorizedornot.Its possiblevaluesarethoseofPRICE. Ds_AuthorisationCode:authorizationcode,ifapplicable. Ds_TransactionType:typeoftransaction. Ds_MerchantData:seetable. Ds_SecurePayment:seetable. Ds_Card_Number:cardnumber. Ds_ExpiryDate:monthandyearofcardexpirydateinYYMMformat. Ds_Card_Country:countryofcardissue. Ds_ErrorCode:optionalfieldwhichwillappearifanerrorisdetectedwhilethetransactionisbeingprocessed.
Anexampleofthemessageisgivenbelow:
<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>MisDatos</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> Page 22

In the same way that section 6.4. explains the procedure for calculating the signature which protectsthedataofthetransactiongeneratedbythemerchant.Ifthemerchantwishestoreceive anonlineresponsetoitsrequests,thesystemwillprovideasignaturewhich,inturn,guarantees theintegrityofresponses. Bydefault,theVirtualPOScancommunicatewithports80,443,8080and8081ofthemerchant. Otherportsneedtobeconsulted. Once the merchant has received the form, the response code (Ds_Response) will indicate whetherthetransactionhasbeenacceptedor,ifnot,thereasonforitsrefusal.Thepossiblevalues inthisfieldandtheirmeaningscanbereferredtoinANNEXII. It is important to notice that this option entails complying with the requirements of the PCIDSS securityprogrammeexplainedinsection11ofthismanual. If during the installation process one error messages appeared, it would indicate that one of the parametersinthefieldssentwaswrong.Tolocatetheincorrectfield,youshouldsearchthetext 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 withthemessageshowntothecardholderinthecaseofthedifferenterrors.
6.3.GATEWAYOperaciones
Mark Up Language . . . . . . . . . . . . . . . . . . . XML Is it 3DSecure available? . . . . . . . . . . . . . NO Can the merchant capture Card Data? . . . YES ItisforHOSTtoHOSTtransactionsworkingasanXMLconversation.Oftenusedtosendrefunds, subscriptions, and other operations where the cardholder is not present. Its not possible to process3DSECUREtransactions. It is very important to bear in mind that this resource is only valid for the following types of transactions(Ds_Merchant_TransactionType),becauseasthecardholderisnotpresenthecannot beauthenticated(3DSecureEnvironment): 1Preauthorization (only if the merchant is authorized to perform this type of operation andisworkinginnonsecuremode) 2Confirmationofpreauthorization 3Automaticrefund 6Successivetransactions 8Confirmationofauthentication 9Cancellationofpreauthorizations ANonsecure payment without authentication (by default, this operation is not permitted andcanonlybedonewithpriorauthorizationfromCaixaCatalunya). ODeferredPreauthorization PConfirmationofDeferredPreauthorization QCancellationofDeferredPreauthorization RDeferredRecurringPreauthorization SConfirmation of Deferred Recurring Preauthorization / Successive of Deferred Recurring Pre authorization ThecommunicationisdonebysendingtheXMLdocumenttotheaddressindicatedbytheVirtual POS.ThesystemwillinterprettheXMLdocumentandmaketherelevantvalidations,afterwhichit
Page 23

will process the transactions. Depending on the result of the transaction, a response XML documentissetupwiththeresult. TheXMLdocumentissentbyaPOSTdispatchtothefollowingaddress: https://sis.sermepa.es/sis/operaciones The document is sent by simulating the request made by a form whose only input is known asentrada. The value of the entrada isthe XML document, which should be inthefollowingformat:xwwwformurlencoded. It is important to notice that this option entails complying with the requirements of the PCIDSS securityprogrammeexplainedinsection11ofthismanual. Twotypesofmessagearedefinedasfollow: 1.DATOSENTRADA:Requestmessagesent. 2.RETORNOXML:Responsetorequest. ThefieldsthesemessagescancontainareexplainedinANNEXI 1.SpecificationoftheDATOSENTRADAdocument. ThismessageissenttotheVirtualPOSplatformtorequestatransaction: Version1.0:
<!ELEMENTDATOSENTRADA (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?)> <!ELEMENTDS_Version(#PCDATA)> <!ELEMENTDS_MERCHANT_AMOUNT(#PCDATA)> <!ELEMENTDS_MERCHANT_CURRENCY(#PCDATA)> <!ELEMENTDS_MERCHANT_ORDER(#PCDATA)> <!ELEMENTDS_MERCHANT_MERCHANTCODE(#PCDATA)> <!ELEMENTDS_MERCHANT_MERCHANTURL(#PCDATA)> <!ELEMENTDS_MERCHANT_MERCHANTNAME(#PCDATA)> <!ELEMENTDS_MERCHANT_CONSUMERLANGUAGE(#PCDATA)> <!ELEMENTDS_MERCHANT_MERCHANTSIGNATURE(#PCDATA)> <!ELEMENTDS_MERCHANT_TERMINAL(#PCDATA)> <!ELEMENTDS_MERCHANT_TRANSACTIONTYPE(#PCDATA)> <!ELEMENTDS_MERCHANT_MERCHANTDATA(#PCDATA)> <!ELEMENTDS_MERCHANT_PAN(#PCDATA)> <!ELEMENTDS_MERCHANT_EXPIRYDATE(#PCDATA)> <!ELEMENTDS_MERCHANT_CVV2(#PCDATA)> Where: - DS_MERCHANT_TRANSACTIONTYPE:onlyallowsthefollowingtypes:1,2,3,6,8,9,O,P,Q,R,S,A - DS_MERCHANT_AUTHORIZATIONCODE:onlyvalidforrefundsofrecurring/successivetransactions - DS_MERCHANT_TRANSACTIONDATE:onlyvalidforrefundsofrecurring/successivetransactions Page 24

SeeANNEXIforexplanationsofeachfield. Anexampleofthemessageisshownbelow: <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> ComerciodePruebas </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.SpecificationofRETORNOXMLdocument. Thismessageistheonesentbytheplatformasaresultofthetransaction.
<!ELEMENTRETORNOXML(Ds_Version?,CODE,(OPERACION|RECIBIDO))> <!ELEMENTDs_Version(#PCDATA)> <!ELEMENTCODE(#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)> <!ELEMENTDs_Amount(#PCDATA)> <!ELEMENTDs_Currency(#PCDATA)> <!ELEMENTDs_Order(#PCDATA)> <!ELEMENTDs_Signature(#PCDATA)> <!ELEMENTDs_MerchantCode(#PCDATA)> <!ELEMENTDs_Terminal(#PCDATA)> <!ELEMENTDs_Response(#PCDATA)> <!ELEMENTDs_AuthorizationCode(#PCDATA)> <!ELEMENTDs_TransactionType(#PCDATA)> <!ELEMENTDs_SecurePayment(#PCDATA)> <!ELEMENTDs_Reference(#PCDATA)> <!ELEMENTDs_Language(#PCDATA)> <!ELEMENTDs_CardNumber(#PCDATA)> <!ELEMENTDs_ExpiryDate(#PCDATA)> <!ELEMENTDs_MerchantData(#PCDATA)> <!ELEMENTRECIBIDO(#PCDATA)> Where: - Ds_Version:versionoftheDTDusedtovalidatetheXML. Page 25

- CODE: indicateswhether the transaction is corrector not (it does not indicatewhether it has been authorized, onlywhetherithasbeenprocessed).A0indicatesthattheoperationhasbeenprocessedcorrectly.Ifa0does notappear,theerrorcodewillappearbutnotanyinformationonthetransaction. CODEisnottheDs_ResponseatransactioncanhaveaCODE=0andstillbedeclined(Ds_Responsedifferent from0). - RECEIVED:thisisatextchainwhichcontainstheXMLthatthemerchantsentbyPOSTintheentryfield. TheDs_Versionfieldwillonlyappearifthetransactionhasbeenprocessedcorrectlyasitisavaluesentbythemerchant ifnotcorrect,thedatawillgointheRECEIVEDfield.
Threeexamplesofmessagesappearbelow:
1Transactioncorrectandauthorized: <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>MisDatos</Ds_MerchantData> </OPERACION> </RETORNOXML> 2Transactioncorrectbutdeclined(190Declinedbytheissuerbank): <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>2Ds_TransactionType> <Ds_SecurePayment>1</Ds_SecurePayment> <Ds_MerchantData>MisDatos</Ds_MerchantData> </OPERACION> </RETORNOXML> 3Transactionincorrect(051ordernumberrepeated).Thiswillneverbeauthorized: <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 Page 26

</DS_MERCHANT_AMOUNT> <DS_MERCHANT_MERCHANTNAME> ComerciodePruebas </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 parametersinthefieldssentwaswrong.Tolocatetheincorrectfield,youshouldsearchthetext 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 withthemessageshowntothecardholderinthecaseofthedifferenterrors.
6.4.DESIGNOFHASHALGORITHMININTERNETSERVER
Caixa de Catalunya will provide the merchant a code to be used to sign the details provided by him, which not only allows the merchants identification to be verified but also that the details havenotbeenchangedatanytime.ItwillbeusedasasecurityprotocolinthepublicSecureHash Algorithm (SHA1) which guarantees the minimum security requirements in terms of authenticationoforigin. This same algorithm is also used so the merchant can be assured of the authenticity of the responsedetailsintheeventthatthemerchantoptsforURLnotification. The SHA1 code is not available for PHP versions lower than 4.3.0. If your server uses a previousversion,pleasegetincontactwithCaixaCatalunyastechnicalsupportservicetofindan alternativesolution. Thecalculationofthealgorithmisdifferentdependingonthegatewayyoureworkingon: GATEWAYrealizarPago Therearetwopossiblecasesforcalculatingtheelectronicsignature: For transactions with Ds_Merchant_TransactionType 5 or R: the merchants electronic signatureshouldbecalculatedthus: Digest=SHA1(Ds_Merchant_Amount+Ds_Merchant_Order + Ds_Merchant_MerchantCode +
Ds_Merchant_Currency + Ds_Merchant_TransactionType + Ds_Merchant_MerchantURL + SECRET CODE)
FortransactionswithDs_Merchant_TransactionType=5orR(INITIALRECURRINGPAYMENT): themerchantselectronicsignatureshouldbecalculatedthus:
Page 27

Digest=SHA1(Ds_Merchant_Amount
+ Ds_Merchant_Order Ds_Merchant_Currency + Ds_Merchant_SumTotal Ds_Merchant_MerchantURL+SECRETCODE) + + Ds_Merchant_MerchantCode Ds_Merchant_TransactionType + +
If the merchant did not have an online URL notification, the Ds_Merchant_MerchantURL field shouldbeleftblank. Example
AMOUNT(Ds_Merchant_Amount)=1235(multipliedby100tocomeoutthesameastheDs_Merchant_Amount). ORDERNUMBER(Ds_Merchant_Order)=29292929 MERCHANTCODE(Ds_Merchant_MerchantCode)=201920191 CURRENCY(Ds_Merchant_Currency)=978 SECRETCODE=h2u282kMks01923kmqpo Resultingchain:123529292929201920191978h2u282kMks01923kmqpo SHA1result:c8392b7874e2994c74fa8bea3e2dff38f3913c46
GATEWAYSentradaXMLEntidadandoperaciones Themerchantselectronicsignatureshouldbecalculatedasfollows: 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 + SECRETCODE)
(1) (2)
IsveryimportanttonoticethatisforbiddentostoretheCVV2,evenifyoureplanningtouseitin the Successive Transactions (Ds_Transaction_Type = 6 or S) coming from the recurrent transactions(5orR).ForthisreasonyoudonthavetowritetheCVV2whenyouresendingthe Successivetransaction(6orS)andwhencalculatingthesignatureofthistransaction. Example(ofconventionalsignature):
AMOUNT=1235(multipliedby100soitisequaltotheDs_Merchant_Amount). ORDERNUMBER=29292929 MERCHANTCODE=999008881 CURRENCY=978 CARDNO=4548812049400004 MERCHANTURL=http://www.sermepa.es MERCHANTSIGNATURE=h2u282kMks01923kmqpo Resultingchain:1235292929292019201919784548810000000003 SHA1result:8cbd9137533846152fc3b8921d909742e6b87f8e
OnlyifitisthefirstofaRECURRINGpayment(Ds_Transaction_Type=5orR) OnlyiftheCVV2isgiven (3) OnlyforentradaXMLgateway
For these two gateways, the same algorithm will be used to assure the merchant of the authenticityoftheresponsedataifthemerchantusesaURLnotificationsystem.
IntheRETORNOXMLdocument
-Ds_Signature=SHA1(Ds_Amount+Ds_Order+Ds_MerchantCode+Ds_Currency+Ds_Response+ Ds_CardNumber+Ds_TransactionType+Ds_SecurePayment+SECRETCODE) TheDs_CardNumberfieldwillonlyformpartofthesignatureifthecardnumberissent.Ifthecardissent withanasterisk,theDs_CardNumberfieldwillalsoformpartofthesignaturewiththevalueasterisked.
Page 28

You should remember that: Oncethesignaturehasbeengenerated,youshouldnotmodifythedatainanywayasthe POSwilluseittovalidatethesignature.Iftheinformationreceivedisnotexactlythesame asthatusedtogeneratethesignature,theplatformwillrejectthetransaction. TheAmountwillbemultipliedby100,withnodecimalpointsandnozerostotheleft. Theordernumbershouldbedifferentforeachtransactionandthefirst4positionsshould benumerical.
The secret code must NEVER be divulged, nor should it appear in thesourcecodeofthemerchants website, nor should it be accessible in the website file structure. The calculation of the SHA-1 should beimplementedintheprivatepartofthemerchantsInternetserver. Ifthemerchantsdomainisinadifferentserver under a hosting or similar formula, he should get in contact with his supplier to find out the method of implementing the encryption algorithm.
CaixaCatalunyaprovidesexamplesofconnectionswiththePOSterminalindifferentprogramming languages. SHA1references: - StandardfortheSecureHashStandard,FIPSPUB1801.
- ListofDSAValidatedImplementations:
http://csrc.nist.gov/cryptval/shs.html
http://www.itl.nist.gov/fipspubs/fip1801.htm http://csrc.nist.gov/publications/fips/fips1801/fips1801.pdf http://csrc.nist.gov/cryptval/dss/dsaval.htm
- SpecificationsoftheSecureHashStandard(SHA1): - WhatareSHAandSHA1?
http://www.rsasecurity.com/rsalabs/faq/365.html
6.5.TECHNICALINSTALLATIONSUPPORTSERVICE
CaixaCatalunyaofferstomerchantsandcompanieswhowishtoinstallaVirtualPOStheservices of its Technical Installation Support Service, which will be delightedto help with anytechnical or operationalqueriesfreeofcharge.
(34) 93 479 9191
Tel. 902 110 558
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.
POSsupport@ap.caixacatalunya.es
Similarly, for any incidents concerning communications, system instability or similar problems, CaixaCatalunyaoffersthe24hour365dayhelplineontel.902198747.Thistelephonewillnot helpinanyotherincidenceorquestion.
Page 29
VIRTUAL POS EXTENDED MERCHANT MANUAL 7.OTHERTECHNICALINFORMATION
7.1.ONLINERESPONSE
Ifthemerchantwantstoseetheresultofthepaymentsimmediatelyaftertheyhavebeenmade, therearefourresponsemechanismswhichcancoexistsimultaneously: 1.BygoingtotheAdministrationModuleviatheInternet. Youcancheck,printorexporttofilesthetransactionsmadeinthelast45days. 2.Byreceivingafilewithalistoftransactions. Thefileisgeneratedonaregularbasis(usuallyeveryday)andsenttoanemailaddress inencryptedform. 3.ByconsultingSOAP. ThisallowsthemerchanttoconsulttransactionsusingSOAPXMLtechnology. 4. Only in the gateways entradaXMLEntidad and operaciones, a XML document is returnedtothemerchantwiththeresultoftherequest. 5.ByimplementingtheOnlineResponsesolution. This means that at the same time as the cardholder receives the response to the card paymentrequest,themerchantswebsitereceivesamessagewiththesameinformation. There are two possible ways of receiving the Online Response, which can be combined, either usingbothatthesametimeoroneofthemasabackupiftheotherfails: Viaemail:receptionoftheresponsetothepaymentauthorizationrequestattheemail addressprovidedbythemerchantonregisteringfortheVirtualPOS. ViaURL:receptionoftheresponseattheURLaddressgivenonthepaymentform.This option requires a simple computer adjustment on the merchants website to facilitate receptionoftheresponseandintegrateitinthemerchantsdatabase.Thisoptionisonly valid for merchants with an active verification field installed. This is our recommended option. ToimplementtheonlineresponseviaURL,aURLaddresswhereresponsesshouldbesent will need to be given on the payment request form (Ds_Merchant_MerchantURL field). ThisURLshouldbeaCGI,Servletorsimilarinthelanguageregardedasappropriatefor themerchantsservertobeabletointerprettheresponsesentfromtheVirtualPOS.This pagewillbetransparenttotheuser(i.e.itwillnotbeloadedonthebrowser).Onit, youwillbeabletoreceiveandcompiledetailsofonlineresponsesandaddthemtoyour database. TheprotocolusedforresponsesviaURLcanbehttporhttps.The messageformatisan HTMLformsentusingthePOSTmethodwiththefieldsshowninAnnexI. Asintherequesttopayforapurchase,theonlineresponseincludesanelectronicsignaturethat guaranteestheintegrityoftheresponses. Thealgorithmwillbethesame,andtheformulaforcalculatingitis:
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 optionallyactivateafiltertolimitthereceptionofonlineconfirmationsfromtheVirtualPOSonly.
Page 30

Bydefault,theVirtualPOScancommunicatewithports80,443,8080and8081ofthemerchant. OtherportswillneedtobediscussedwithCaixaCatalunyastechnicalsupportservice. When the merchant receives the form, the values of the response code indicate whether the transaction has been approved or declined,andinthelattercasethereasonfortherefusal.The listofvaluescanbefoundinANNEXII. 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 interruptedduetooneofthefollowingerrors: 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.RECURRINGTRANSACTIONS
A recurring transaction is one where the purchase is made in instalments, for example the paymentofregularsubscriptionsordeferredpayments. CaixaCatalunyasVirtualPOSterminaliscertifiedsothatrecurringtransactionsmadewithVisaor MasterCardcardsviatheInternetwhereapositiveauthenticationhasbeenmadeofthecardholder cannotbereversedbythecardholderifhe/shethenclaimsnottohavemadethepurchase. 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(recurringtransaction)orsubsequentinstalments(successivetransactions): FIELD NAME 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_MerchantData Ds_Merchant_Transaction_Type Ds_Merchant_DateFrecuency Ds_Merchant_ChargeExpiryDate Ds_Merchant_SumTotal
Rec. (value 5 or R)/Suc.(value 6 or S) Recurring Recurring Recurring
Page 31
MANDATORY
Recurring/Successive Rec. /Suc. Rec. /Suc. (same value for all transactions) Rec. /Suc.
OPTIONAL
NO INFORMATION
Rec. /Suc. Rec. /Suc. Rec. /Suc. Rec. /Suc. Rec. /Suc. Rec. /Suc.
Successive Successive Successive

IsveryimportanttonoticethatisforbiddentostoretheCVV2,evenifyoureplanningtouseitin the Successive Transactions (Ds_Transaction_Type = 6 or S) coming from the recurrent transactions(5orR).ForthisreasonyoudonthavetowritetheCVV2whenyouresendingthe Successivetransaction(6orS)andwhencalculatingthesignatureofthistransaction.
7.3.TESTENVIRONMENT
To carry out installation tests, Caixa Catalunya has enabled a test environment so the merchant canmaketransactionsinanenvironmentwhichisidenticaltotherealone,butwithoutthesales havinganyaccountingvalidity. Thecharacteristicsofthetestenvironmentaredetailedbelow: 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 contactwiththeTECHNICALINSTALLATIONSUPPORTSERVICE(seesection6.5).Thetest 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 accesstotheAdministrationModule,).
Page 32

In the test environment, payments in EUROS are authorized against the test server for Spanish SERVIREDcards.IfyouwanttorunatestinadifferentcurrencyorforanonSpanishcard, 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) whoadministertheauthorizationcentersforthisenvironment. Forthisreason,toavoidanydelaysincarryingoutthetests,werecommendthatyouonlydotest transactions in EUROS with the Spanish cards detailed above, reserving transactions in other currenciesorwithothercardsforarealsituation.
Page 33
VIRTUAL POS EXTENDED MERCHANT MANUAL 8.QUERIESONTRANSACTIONSVIASOAPXML

SOAP is a standard XMLbased protocol which allows communications with Web services. SOAP providesasimple,consistentmechanismforsendingXMLmessagestoanotherapplication. By using the SOAP protocol, Caixa Catalunyas virtual payment platform allows the merchant to obtaininformationonhistransactionsbytwopossiblemechanisms: Onlinequeries SOAPsynchronization
8.1.ONLINEQUERIES
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 informationonalltransactionsthathavebeeninitiated. There are two types of queries: by transaction and by monitor. The query by transaction allows youtoobtaininformationonacertaintypeoftransaction(e.g.Authorization)relatingtoanorder, while the query by monitor gives you information on all the transaction types (e.g. Authorization andRefund)associatedwithanordernumber. Thepossiblevaluesofaquerybytransactionare: <Ds_TransactionType>=0(normalpaymenttransaction) <Ds_TransactionType>=1(unconfirmedpreauthorization) <Ds_TransactionType>=4(paymentbyreference) <Ds_TransactionType>=5(recurringpayment) <Ds_TransactionType>=7(authentication) <Ds_TransactionType>=A(traditionalpayment) 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 transactionrequestedbythemerchant. Thepersonrequestingthisserviceshouldsubmitaquerywhichwillreturntheresultsofthedata requested.
8.1.a.SOAPCLIENT
DetailedbelowisanexampleofaSOAPclient.SOAPclientsshouldtakethefollowingsteps: A.GivetheURLoftheSOAPserviceyouwanttoaccess: B.CreateaSOAPMappingRegistryobject:

E.g. URL=newURL("http://smp3006/soap/rpcrouter")
C.CreateaCalltypeobjectwiththefollowingdetails:
SOAPMappingRegistry(previouslycreated) TargetObjectURI.URLofmessagingservice. Page 34
E.g. SOAPMappingRegistrysmr=newSOAPMappingRegistry()

MethodName.Methodyouwanttoaccess. EncodingStyleURI.Constant. Vectorwithqueryparameters. E.g.: Callcall=newCall() call.setSOAPMappingRegistry(smr) call.setTargetObjectURI("urn:mensajeriaCIBERPAC") call.setMethodName("procesaMensajeRecibido") call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC) Vectorparams=newVector() params.addElement(newParameter("Mensaje",String.class,xml_doc,null)) call.setParams(params)
D.InvoketheURLoftheSOAPservicewhichwillreturnaResponseobject:
E.g.: Responseresp=null resp=call.invoke(url,"") Parameterret=resp.getReturnValue() Objectvalue=ret.getValue()
ExampleofJAVASOAPclient(SERVLET)
importjava.util.* importjavax.servlet.* importjavax.servlet.http.* importjava.io.* Importjava.net.* importorg.apache.soap.* importorg.apache.soap.messaging.* importorg.apache.soap.transport.* importorg.apache.soap.util.xml.* importorg.apache.soap.encoding.* importorg.apache.soap.encoding.soapenc.* importorg.apache.soap.rpc.* publicclassSerSvlCIBERPACextendsHttpServlet { publicvoiddoPost(HttpServletRequestreq,HttpServletResponseres)throws ServletException,IOException { Stringrespuesta="" try { Stringxml_doc=req.getParameter("elXMLEnvio") respuesta=ejecutaCallRPCStyle(xml_doc) } catch(Exceptione) { e.printStackTrace() } } publicStringejecutaCallRPCStyle(Stringxml_doc)throwsServletException,IOException { Stringrespuesta="" StringencodingStyleURI=Constants.NS_URI_SOAP_ENC URLurl=newURL("http://smp3006/soap/rpcrouter") SOAPMappingRegistrysmr=newSOAPMappingRegistry() Callcall=newCall() call.setSOAPMappingRegistry(smr) call.setTargetObjectURI("urn:mensajeriaCIBERPAC") call.setMethodName("procesaMensajeRecibido") call.setEncodingStyleURI(encodingStyleURI) Vectorparams=newVector() params.addElement(newParameter("Mensaje",String.class,xml_doc,null)) call.setParams(params) Responseresp=null try { resp=call.invoke(url,"") } catch(SOAPExceptione) { e.printStackTrace() } Page 35

if(!resp.generatedFault()) { Parameterret=resp.getReturnValue() Objectvalue=ret.getValue() respuesta=(String)value } else { Faultfault=resp.getFault() respuesta=fault.getFaultString() } return(respuesta) } }
8.1.b.XMLSENDANDRESPONSE
This annex details how an XMLSCHEMA describes the incoming and outgoing messages of the Webservicefortransactionsqueries.
<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"> <elementname="Messages"> <complexType> <sequence> <elementref="t:Version"/> <elementref="t:Signature"/> </sequence> </complexType> </element> <elementname="Version"> <complexType> <sequencemaxOccurs="unbounded"> <elementref="t:Message"/> </sequence> <attributename="Ds_Version"type="string"use="required"/> </complexType> </element> <elementname="Message"> <complexType> <choice> <elementref="t:Transaction"/> <elementref="t:Monitor"/> <sequenceminOccurs="0"maxOccurs="unbounded"> <elementref="t:Response"/> </sequence> <elementref="t:ErrorMsg"/> </choice> </complexType> </element> <elementname="Transaction"> <complexType> <sequence> <elementref="t:Ds_MerchantCode"/> <elementref="t:Ds_Terminal"/> <elementref="t:Ds_Order"/> <elementref="t:Ds_TransactionType"/> <elementref="t:Ds_Merchant_Data"minOccurs="0"/> </sequence> </complexType> </element> <elementname="Monitor"> <complexType> <sequence> <elementref="t:Ds_MerchantCode"/> <elementref="t:Ds_Terminal"/> Page 36

<elementref="t:Ds_Order"/> <elementref="t:Ds_Merchant_Data"minOccurs="0"/> </sequence> </complexType> </element> <elementname="Response"> <complexType> <sequence> <elementref="t:Ds_MerchantCode"/> <elementref="t:Ds_Terminal"/> <elementref="t:Ds_Order"/> <elementref="t:Ds_TransactionType"/> <elementref="t:Ds_Date"/> <elementref="t:Ds_Hour"/> <elementref="t:Ds_Amount"/> <elementref="t:Ds_Currency"/> <choiceminOccurs="0"> <sequence> <elementref="t:Ds_CardNumber"/> <elementref="t:Ds_ExpiryDate"/> </sequence> <elementref="t:Ds_TelephoneNumber"/> </choice> <elementref="t:Ds_SecurePayment"/> <elementref="t:Ds_State"/> <elementref="t:Ds_Response"minOccurs="0"/> <elementref="t:Ds_Merchant_Data"minOccurs="0"/> </sequence> </complexType> </element> <elementname="Ds_MerchantCode"> <simpleType> <restrictionbase="int"> <minInclusivevalue="1"/> <maxInclusivevalue="999999999"/> </restriction> </simpleType> </element> <elementname="Ds_Terminal"> <simpleType> <restrictionbase="short"> <minInclusivevalue="1"/> <maxInclusivevalue="999"/> </restriction> </simpleType> </element> <elementname="Ds_Order"> <simpleType> <restrictionbase="string"> <minLengthvalue="1"/> <maxLengthvalue="12"/> </restriction> </simpleType> </element> <elementname="Ds_TransactionType"> <simpleType> <restrictionbase="string"> <lengthvalue="1"/> </restriction> </simpleType> </element> <elementname="Ds_Merchant_Data"type="string"/> <elementname="Ds_Date"> <complexTypemixed="true"/> </element> <elementname="Ds_Hour"> <complexTypemixed="true"/> </element> <elementname="Ds_Amount"type="long"/> <elementname="Ds_Currency"type="short"/> <elementname="Ds_CardNumber"> <simpleType> <restrictionbase="string"> Page 37

<minLengthvalue="13"/> <maxLengthvalue="19"/> </restriction> </simpleType> </element> <elementname="Ds_ExpiryDate"> <simpleType> <restrictionbase="string"> <lengthvalue="4"/> </restriction> </simpleType> </element> <elementname="Ds_TelephoneNumber"type="int"/> <elementname="Ds_SecurePayment"> <simpleType> <restrictionbase="short"> <minInclusivevalue="0"/> <maxInclusivevalue="1"/> </restriction> </simpleType> </element> <elementname="Ds_State"type="string"/> <elementname="Ds_Response"type="int"/> <elementname="ErrorMsg"> <complexType> <sequence> <elementref="t:Ds_ErrorCode"/> </sequence> </complexType> </element> <elementname="Ds_ErrorCode"> <complexTypemixed="true"/> </element> <elementname="Signature"type="string"/> </schema>
BasedonthisXMLSCHEMA,shownbelowisanexampleofanincomingmessageandanoutgoing message. EXAMPLEOFSENDMESSAGE: <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> EXAMPLEOFRESPONSEMESSAGE: <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>
Page 38

<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.CALCULATINGTHESIGNATURE
Tocalculatethesignatureforanoutgoingmessage,thefollowingdataareused: DataofoutgoingXML+merchantsecretcode Digest=SHA-1(<version...</version> + merchant secret code) Tocalculatethesignaturefortheresponse,thefollowingdataareused: DataofresponseXML+merchantcode. Digest=SHA-1(<version...</version> + merchant code)
8.1.d.WSDLOFSERVICE
TheURLsoftheWebservicesoftheVirtualPOSareasfollows: Testenvironment: https://sisi.sermepa.es:25443/aplSOAP/rpcrouter Realenvironment: https://sis.sermepa.es/aplSOAP/rpcrouter TheseURLsareusedasdestinationpointsoftheservice. TheWDSLwhichdescribesthetransactionqueryserviceoftheVirtualPOSisasfollows:

<?xmlversion="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:messagename="procesaMensajeRecibidoResponse"> <wsdl:partname="return"type="xsd:string"/> </wsdl:message> <wsdl:messagename="procesaMensajeRecibidoRequest"> <wsdl:partname="Mensaje"type="xsd:string"/> </wsdl:message> <wsdl:portTypename="SerClsConsultasSISPortType"> <wsdl:operationname="procesaMensajeRecibido"> <wsdl:inputmessage="tns:procesaMensajeRecibidoRequest"/> Page 39

<wsdl:outputmessage="tns:procesaMensajeRecibidoResponse"/> </wsdl:operation> </wsdl:portType> <wsdl:bindingname="SerClsConsultasSISBinding"type="tns:SerClsConsultasSISPortType"> <soap:bindingstyle="rpc"transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operationname="procesaMensajeRecibido"> <soap:operationsoapAction="urn:mensajeriaCIBERPAC#procesaMensajeRecibido"/> <wsdl:input> <soap:bodyuse="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:mensajeriaCIBERPAC"/> </wsdl:input> <wsdl:output> <soap:bodyuse="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:mensajeriaCIBERPAC"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:servicename="SerClsConsultasSISService"> <wsdl:portname="SerClsConsultasSISPort"binding="tns:SerClsConsultasSISBinding"> <soap:addresslocation="https://sis.sermepa.es/aplSOAP/rpcrouter"/> </wsdl:port> </wsdl:service> </wsdl:definitions>
8.1.e.SOAPERRORCODES
TheSOAPtransactionqueryservicehasitsownerrorcodeswhicharedetailedbelow: ERROR XML0000 XML0001 XML0002 XML0003 XML0004 XML0005 XML0006 XML0007 XML0008 XML0009 XML0010 XML0011 XML0012 XML0013 XML0014 XML0015 DESCRIPTION VariouserrorsintheXMLStringprocessreceived ErroringeneratingtheDOMfromthedefinedXMLStringandDTD NoMessageelementintheXMLStringreceived ThetypeofMessageintheXMLStringreceivedhasanunknownorinvalidvalue intherequest NoDs_MerchantCodeelementintheXMLStringreceived TheDs_MerchantCodeelementisemptyintheXMLStringreceived ThelengthoftheDs_MerchantCodeelementiswrongintheXMLStringreceived TheDs_MerchantCodeelementdoesnothaveanumericalformatintheXML Stringreceived ThereisnoDs_TerminalelementintheXMLStringreceived TheDs_TerminalelementisemptyintheXMLStringreceived ThelengthoftheDs_TerminalelementiswrongintheXMLStringreceived TheDs_TerminalelementdoesnothaveanumericalformatintheXMLString received ThereisnoDs_OrderelementintheXMLStringreceived TheDs_OrderelementisemptyintheXMLStringreceived ThelengthoftheDs_OrderelementiswrongintheXMLStringreceived ThefirstfourpositionsoftheDs_OrderelementarenotnumericalintheXML
Page 40

ERROR Stringreceived XML0016 XML0017 XML0018 XML0019 XML0020 XML0021 XML0022 XML0023 XML0024 XML0025 XML0026 XML0027 ThereisnoDs_TransactionTypeelementintheXMLStringreceived TheDs_TransactionTypeelementisemptyintheXMLStringreceived ThelengthoftheDs_TransactionTypeelementiswrongintheXMLString received TheDs_TransactionTypeelementdoesnothaveanumericalformatintheXML Stringreceived TheDs_TransactionTypeelementhasanunknownorinvalidvalueinthe transactionmessage ThereisnoSignatureelementintheXMLStringreceived TheSignatureelementisemptyintheXMLStringreceived Thesignatureisnotcorrect TherearenotransactionsintheTZEforthedatarequested TheresponseXMLisnotproperlyformulated ThereisnoDs_fecha_inicioelementintheXMLStringreceived ThereisnoDs_fecha_finelementintheXMLStringreceived DESCRIPTION
8.2.SOAPSYNCHRONIZATION
Thisnewsynchronizationmethodallowsthemerchantto receivenotificationoftransactions bya SOAP service. To activate this service, the merchant needs to get in contact with the Technical SupportServiceofCaixaCatalunya. IftheSOAPsynchronizationoptionisenabledforamerchant,thismeansthattheplatformwill 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 merchants configurationforonlinenotifications. The unique factor of this notification is that Caixa Catalunyas 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 duringthenotificationprocess,theplatformwillcancelthetransactionandpresentthecardholder withareceiptshowingaKOresult,i.e.theplatformconditionstheresultofthetransactiontothe responseobtainedfromthemerchantinthenotification.
Page 41
VIRTUAL POS EXTENDED MERCHANT MANUAL 9.REGULARINFORMATIONFILES

CaixaCatalunyahascreatedasystemforsendingfilesonaregularbasistocomplementtheusual 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(retrievalrequests)thathavebeenmade. Thesefilescanbesentinvariousways: Email:toanagreedaddress. FTP:eitherbypostingthefileontheclientsFTPserverorallowingtheclienttoaccess Caixa Catalunyas FTP server to download it. The communication is secured by OpenSSHprotocol. EDI(inSpain,theEditranprotocol). CaixaCatalunyaalsocarriesoutweeklychecksonthenumberofchargebacksandconfirmedfraud cases. If the merchant has exceeded the permitted limits, he will receive a warning email containingthisinformation.
9.1.SETTLEMENTOFACCOUNTABLETRANSACTIONSFILE
This file provides information on transactions processed by the merchant which have been duly accounted forinhisfinancialaccount.Thefrequencyofthisfilecanbedaily,weeklyor monthly, although for merchants with a very high volume of transactions we particularly recommend it is sentdaily. Itshouldbenotedthatthisfiledoesnotdetailthetransactionsthathavebeenprocessedonthat day but the transactions actually settled. Usually, Caixa Catalunya settles transactions processed upto06.00onthesettlementday.Thesetimingsareapproximateasitwilldependonthevolume ofcomputerprocessesonanygivenday. The total of the transactions listed in each file will match the amount deposited daily in the merchantsfinancialaccount. Whenachargebackisrequestedbyacardholder onanyofthemerchantssales,the staffinour PAYMENT METHODS department will carry out a manual validation to check whether the claim is validornot.InthecaseswherethetransactiondoesnotmeettheregulationsofVisa,MasterCard or JCB, it will be returned to the issuing bank in the form of a representment without being chargedtothemerchantsaccount.Inothercases,itwillbechargedtothemerchant. Formerchantswhohaveaveryhighvolumeoftransactionsorwhoseofficeisalongwayfroma Caixa Catalunya branch, there is a remote management service available (via email) for requestingarepresentmentofchargebackschargedtotheiraccounts.ANNEXIIDISPUTING ACHARGEBACKshowstheprocessforthis. ThesettledtransactionsfilealsoincludeschargebacksthathavepassedtheCaixaCatalunyafilters and need to be charged to the merchant. These are identified by the field TRANSACTION TYPE (POS.71[2]=15).ThecodeforthereasonforeachChargebackisgiveninpos.178[2].
Page 42

Theformatofthefilewillbeasfollows: FILEHEADERRECORD INITIALPOS.
1 3 13 23 33
LENGTH
2 10 10 10 168 RECORD TYPE: 10
DESCRIPTIONOFFIELD
PROCESSING DATE (DD-MM-YYYY) START DATE OF TRANSACTIONS (DD-MM-YYYY) END DATE OF TRANSACTIONS (DD-MM-YYYY) FILLER
MERCHANTHEADERRECORD INITIALPOS.
1 3 21 31 49 53 63 73 83
LENGTH
2 18 10 18 4 10 10 10 118 RECORD TYPE: 00
DESCRIPTIONOFFIELD
MERCHANTSCONTRACTNUMBER MERCHANTSCODE ASSOCIATED ACCOUNT NUMBER MERCHANTSBRANCHOFFICE PROCESSING DATE (DD-MM-YYYY) PROCESSING DATE (DD-MM-YYYY) END DATE OF TRANSACTIONS (DD-MM-YYYY) FILLER
DETAILRECORD INITIALPOS.
1 3 13 18 21 25 47 48 49 59 65
LENGTH
2 10 5 3 4 22 1 1 10 6 6 RECORD TYPE: 01
DESCRIPTIONOFFIELD
SETTLEMENT DATE (DD-MM-YYYY) REMITTANCE NUMBER INVOICE NUMBER REMITTANCE BRANCH CARD NUMBER CARD TYPE D- DEBITCARD/C- CREDIT CARD TRANSACTION DATE TRANSACTION TIME (HHMMSS) AUTHORIZATION NUMBER
Page 43

DETAILRECORD INITIALPOS. LENGTH DESCRIPTIONOFFIELD
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 TYPE OF CAPTURE TRANSACTION AMOUNT (WITH 2 DECIMALS) DISCOUNT PERCENTAGE (WITH 2 DECIMALS) DISCOUNT AMOUNT (WITH 2 DECIMALS) PAYMENT AMOUNT (WITH 2 DECIMALS) POS NUMBER FILLER CURRENCY CODE TRANSACTION NUMBER CHARGEBACK REASON CODE
(ONLY GIVEN FOR CHARGEBACKS (pos.71[2] = 15))
71
73 76 87 92 101 114 125 163 166 178 180 191 194
3 11 5 9 13 11 38 3 12 2 11 3 7
PAYMENT AMOUNT (WITH 2 DECIMALS) IN ORIGINAL CURRENCY ORIGINAL CURRENCY OF PAYMENT FILLER
TOTALMERCHANTRECORD INITIALPOS.
1 3 28 37 51
LENGTH
2 25 9 14 150 RECORD TYPE: 99 FILLER
DESCRIPTIONOFFIELD
TOTAL TRANSACTIONS TOTAL AMOUNT IN EUROS (WITH 2 DECIMALS AND +/- SIGNS) FILLER
FILETOTALRECORD INITIALPOS.
1 3 12 37 46 60
LENGTH
2 9 25 9 14 141 RECORD TYPE: 90
DESCRIPTIONOFFIELD
TOTAL NUMBER OF MERCHANTS FILLER TOTAL TRANSACTIONS TOTAL AMOUNT IN EUROS (WITH 2 DECIMALS AND +/- SIGNS) FILLER
Page 44

9.2.CHARGEBACKFILE
Achargebackisthetoolthecardholdercanusetorequest,throughhis/herfinancialentity(issuing bank), the return of the purchase amount. Chargebacks must comply withthe regulations of the cardcompanyinquestion. CaixaCatalunyaverifiesthatthechargebacksreceivedcomplywiththeserules,directlynotifying the issuing bank of any chargebacks it believes do not comply, and charging the merchants 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 documentationfortherepresentmentandthushaveagreaterchanceofsuccess.Inthesecases, themerchantwillreceivearequestfordocumentation(retrievalrequest)asperthefiledescribed insection5.4. CaixaCatalunyawillsendadailyfileofthechargebacksreceived,whethertheyhavebeencharged totheaccountornot,tonotifytheestablishmentofwhichclientsareaskingforchargebacks.In this way, the merchants 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 filethusdoesnotcontainaccountinginformationbutissolelyforinformationpurposes. Theformatofthefileisasfollows:
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
ShownbelowaretwolistsoneforVISAandtheotherforMasterCardshowingeachcodewitha descriptionofthereasonforthechargeback: 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
Page 45

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

4846 4847 4849 4850 4853 4854 4855 4857 4859 4860 4862 4863 Correct transaction currency code not provided Requested/required Authorization not obtained and fraudulent transaction Questionable merchant activity Credit posted as a purchase Cardholder dispute defective/not as described Cardholder dispute not elsewhere classified Nonreceipt of merchandise Card-activated telephone transaction Services not rendered Credit not processes Counterfeit transaction magnetic stripe POS fraud Cardholder does not recognize potential fraud
To differentiate the card type (Visa or MasterCard) you can refer to field pos. 47[2] in the settlementfile.
9.3.CONFIRMEDFRAUDFILE
ConfirmedFraudisthetoolusedbytheissuingbanktonotifythatatransactionhasbeensubject tofraud(thecardholderhasneithermadenorauthorizedthetransaction). This notification is completely independent of the existence of a previous or subsequent chargeback,orwhetherithasbeenchargedtothemerchantorarepresentmentissued.Thisisa 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 happensoverseveralconsecutivemonths,thecardcompaniesmaydemandthecancellationofthe contractwiththatestablishmentand,onoccasions,mayevenheavilypenalizetheestablishment. The maximum permitted level of Confirmed Fraud is regarded as three times the average confirmedfraudindexforEuropeanmerchants.Atpresent,theEuropeanfraudaverageisaround 0.3% of monthly turnover. Therefore, any merchant whose monthly Confirmed Fraud figure exceeds0.9%willbeabovethepermittedlevel. AsinthecaseofChargebacks,CaixaCatalunyasendsadailyfileofConfirmedFraudtransactions reportedbythedifferentcardcompanies.Thisfile,asinthepreviouscase,issolelyforinformation purposesanddoesnothaveanyaccountingvalidity.Itspurposeistoinformtheestablishmentof the cards with which fraudulent transactions are being made so that its security department can getincontactwiththeclientslisted,canceltheiraccounts,addthemtotheirblacklistsortakeany othermeasuretheydeemnecessary. TheformatisverysimilartothatoftheChargebackfile:
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)
Page 47

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.RETRIEVALREQUESTFILE
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 notrecogniseit,orforanyotherreason. Everyonewhomakesapurchase(whetherinpersonornot)usingafinancialcardhastherightto ask for documentation from the merchant to justify the payment. The maximum period for this requesttobehonoredis12monthsfromthedateofthetransaction. Thisrequestisnormallymadebecausethecardholdercannotrememberthetransaction,orwants moredetailsofit,ormaintainshehasnotmadeitandwantsarefund.Insomecasesitisbecause hecannotassociatethenameofthemerchantwiththewebsiteonwhichhemadethepurchase. Caixa Catalunya will send the merchant a daily information file showing a single block of records (withoutheadings)withthefollowingfields,separatedby: LENGTH
10 10 17 10 5 3 2 10 19 9 1 6 8 23 12
DESCRIPTIONOFFIELD
PROCESSING DATE (DD-MM-YYYY) MERCHANT IDENTIFICATOR (MID) MERCHANT NAME SETTLEMENT DATE (DD-MM-YYYY) REMITTANCE NUMBER SETTLEMENT ORDER NUMBER REQUEST ORDER TRANSACTION DATE (DD-MM-YYYY) CARD NUMBER TRANSACTION AMOUNT (999999,99) SETTLEMENT CURRENCY CODE: E (EUROS) REQUEST TYPE ENVIRONMENT REFERENCE TRANSACTION ID
This documentation can also be requested by Caixa Catalunya when it considers it necessary to eitherdefendormakearepresentmentonatransaction,andmustbeprovidedbythemerchantif he/shewishestoavoidachargeback. The merchant is obliged to present this receipt. The deadline for its presentation is 7 workingdays.
Page 48

Ifgoodshavebeensent,thedeliverynoteissuedbythecompanythatmadethedeliveryshould beattached.Itisimportanttonotethatthisdeliverynotemustbesignedbythecardholder andnotbysomeoneelse. Asanexception,andonlyforthosecaseswhereitisnotpossibletodeliverthemerchandisingto the cardholder (either because he cannot be at the agreed place and time, either because its a present)thedeliverancecanbedonetoathirdperson.Inthiscase,itmustbestatedthisoption attheorderformthatcardholderdidatthemerchantwebsite,filledwithnextinformation: Authorized person, identified by name a personalidentity document (DNI, Passport, etc.). The order must be delivered only to this person and the delivery note must include the signatureofthereceiveraswellasastatementasthepersonalidentitydocumenthasbeen checked. Hotels Reception, identified by name, hotels address, name and document of the guest who must receive the delivery. The delivery note must be signed by a perfectly identified hotels employee and stamped by the hotel. Moreover, on the delivery note it must be statedthatithasbeencheckedthatthereceiverisaguestofthehotel. In the case of a merchant which offers services and not products, i.e. there is no goods delivery involved,themerchantshouldprovidethefollowingdetailsonthereplyform: Merchantsname MerchantsCIF/NIF Merchantscode(FUC) Authorizationnumber Dateoftransaction Cardnumber Websiteaddress(URL) Amountoftransaction Currency NameofBuyer Descriptionofpurchase Descriptionofthemerchantsreturnspolicy,ortheURLwhereuserscanfindthis 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 CaixaCatalunya. 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.
Page 49
VIRTUAL POS EXTENDED MERCHANT MANUAL 10.MONITORINGPROGRAMMESANDPENALTIES

Both Visa and MasterCard have chargeback monitoring programmes for merchants and penalize thosethatexceedthemaximumpercentages. Thefiguresthatgiverisetoapenaltyareasfollows: a)ForVISA,iftherearemorethan200chargebacksandthepercentageismorethan2% ofthetotalmonthlytransactions. b)ForMASTERCARD(ECMExcessiveChargebackMerchant),iftherearemorethan50 chargebacks and during two consecutive months the percentage of chargebacks receivedishigherthan1%ofthepreviousmonthstransactions. Inadditiontotheabove,since1October2006VisaandMasterCard havesetupprogrammesto identify merchants who, though not exceeding the maximum penalty parameters, are very close tothem.Thewarningparametersare: a) For VISA, if there are more than 100 chargebacks and the percentage is higher than 1%ofthetotalmonthlytransactions. b)ForMASTERCARD(CMMChargebackMonitoredMerchant),iftherearemorethan50 chargebacks and the percentage of chargebacks is higher than 0.5% of the previous monthstransactions. 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 demonstratethatheistakingallthenecessarystepstopreventthisfromhappeninginthefuture. IftheActionPlansentbythemerchantisregardedasinsufficientbythecardcompanies,theycan ask for up to a onemonth temporary suspension of card processing to be imposed on the merchant.Ifamerchantrepeatedlyappearsonawarningfile,VisaorMasterCardmaytakemore 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 merchantscommercialactivities. Sothatmerchantscanmonitortheirturnoverandanyincidentsgeneratedontheirwebsites,Caixa CatalunyacansendaWordfilecontainingaperiodicreport(byweek,monthandcurrentfinancial year) of the merchants turnover volume and the number of incidents received (Retrieval Requests,ChargebacksandConfirmedFraud).Thisreportwillbegeneratedwheneveranyof the merchantsmonthlyincidentparametersexceed0.5%.
Page 50
VIRTUAL POS EXTENDED MERCHANT MANUAL 11.PCIDSSPAYMENTCARDINDUSTRYDATASECURITYSTANDARD

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 whichvarydependingonthenumberoftransactionstheyprocessperyear. 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 canbescanned).Ifthisisnotthecase,theconditionsofthisprogrammearedetailedbelow. 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 whichthemerchantobviouslyhastofulfillmoreconditions. Theclassificationisasfollows: Level Selection criteria
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. Any e-merchant which processes more than 150,000 and less than 6,000,000 transactions per year. Any e-merchant which processes more than 20,000 and less than 150,000 transactions per year Other merchants
Requirement
Validated by
Independent security consultant or the company itself, if signed by a representative of the company. ----By a specialist company
Annual Security Audit ----Quarterly scan
Annual self-assessment questionnaire ----Quarterly scan Annual self-assessment questionnaire
By the merchant ----By a specialist company By the merchant
Therequirementsintheabovetablearemandatory.Theseare: 1SELFASSESSMENTQUESTIONNAIRE:ThisisknownastheSAQ(AISinSpain)andconsistsofa questionnaireonthemerchantscomputersystemarchitectureandhowitprocessesandstores dataoncards.ItisdoneonanANNUALbasis.CaixaCatalunyahasthequestionnaireaswellas itsinstructionsandfrequentlyaskedquestions. 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).ThisscanisdoneonaQUARTERLYbasis. 3 SECURITY AUDIT: This is an IN SITU audit which must be done by a company certified by VISA/MASTERCARDasaQualitySecurityAssessor(QSA),whichwillassessthesecurityofthe 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 Catalunyacanprovidealistofthem).ThisauditisdoneonanANNUALbasis.
Page 51
VIRTUAL POS EXTENDED MERCHANT MANUAL ANNEXES

ANNEXI.DescriptionofPaymentandResponseForms
DETAIL
Amount
FIELD NAME
Ds_Merchant_Amount
LENGTH
12 N
COMMENTS
Mandatory. The last two positions are regarded as decimals except for yen. Mandatory. 978 Euros 840 Dollars 826 Pounds 392 Yen TheresanagreementbetweenSpanishbankswhere its said that Spanish cards that want to process in Spanish merchants, the only available currency it is Euros. 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. This field will be shown to the cardholder on the purchase confirmation page. This field will be shown to the cardholder on the purchase confirmation page. Mandatory. Fixed code assigned by Caixa Catalunya. Mandatory if the merchant wants online notification. ThemerchantsURLwhichwillreceiveaPOSTwith the transaction details. Optional. If sent, it will be used as URLOK, ignoring what has been configured in the Administration Module, if applicable. Optional. If sent, it will be used as URLKO, ignoring what has been configured in the Administration Module, if applicable. Optional. This will be the name that appears on the clients payment page, if there is one. Optional. 0 Client 1 Spanish 2 English 3 Catalan 4 French 5 German 6 Dutch 7 Italian Mandatory. See section 6.4. Mandatory. Optional. Optional information from the merchant to be sent in 8 Swedish 9 Portuguese 10 Valencian 11 Polish 12 Galician 13 Basque
Currency
Ds_Merchant_Currency
4N
Order code
Ds_Merchant_Order
min. 4N max.12 AN
Product description Name and surname/s of cardholder Merchant ID code FUC URL
Ds_Merchant_ProductDescription
Max.125 AN
Ds_Merchant_Titular
Max. 60 AN
Ds_Merchant_MerchantCode Ds_Merchant_MerchantURL
9N 250 AN
URLOK
Ds_Merchant_UrlOK
250 AN
URLKO
Ds_Merchant_UrlKO
250 AN
Merchantsname
Ds_Merchant_MerchantName
25 AN
Cardholders language
Ds_Merchant_ConsumerLanguage
3N
Merchants signature POS terminal number
Ds_Merchant_MerchantSignature
40 AN
Ds_Merchant_Terminal
3N
Details of merchant
Ds_Merchant_MerchantData
1024 AN Page 52

DETAIL FIELD NAME
LENGTH
COMMENTS
the online response (via URL or e-mail). Optional(bydefaultequalto0). 0 Standard payment (realizarpagoand entradaXMLEntidadgateways) A StandardPayment(onlyoperacionesgateway) 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 Preauthorization / Successive of Deferred Recurring Pre-authorization GATEWAY operaciones only allows the followingtypes:1,2,3,6,8,9,O,P,Q,R,S,A
Type of transaction
Ds_Merchant_TransactionType
1N
Total Amount
Ds_Merchant_SumTotal
12 N
MandatoryifTransactiontype5 This represents the sum total of the instalment amounts. The last two positions are decimals. (see 7.2) MandatoryofTransactiontype5 This gives the minimum interval in days between the instalment charges of a recurring payment (see 7.2) MandatoryifTransactiontype5 Date of the final instalment of a recurring payment (see 7.2) Format: YYYY-MM-DD Optional. This is the authorization code necessary to identify recurring/successive transactions in the case of refunds. 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.
Frequency of a recurring transaction Expiry date of a recurring transaction
Ds_Merchant_DateFrecuency
3N
Ds_Merchant_ChargeExpiryDate
10 AN
Authorization code
Ds_Merchant_AuthorisationCode
6N
Date of the successive recurring transaction
Ds_Merchant_TransactionDate
10 AN
Described below are the fields relating to the card details, given thepossibility thatthey 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 requirementsofthePCIDSSsecurityprogrammeexplainedinsection11ofthismanual). DATA
Card number Expiry date CVV2
(*)
FIELD NAME
<Ds_Merchant_Pan> <Ds_Merchant_ExpiryDate> <Ds_Merchant_CVV2>
LENGTH/TYPE
COMMENTS
Card number (*). This has the YYMM format (*). CVV2/CVC2 code on the card sent (*)
16-19/Num. 4 /Num. 3/Num.
Thetransactiontypes2/3/6/8/9/P/Q/Sdonotrequirethatthecardnumber,expirydateandCVV2 was informed. In these cases the order (Ds_Merchant_Order) has to be the same that the original transaction. Page 53

Fieldsoftheresponsetothemerchant. LENGTH/TYPE DATA DATA NAME
Version <Ds_Version> -N
COMMENTS
Version of the message. Not available for gateway RealizarPago. Format 1.xxxxxxxx where xxxxxxxx is the Merchant Code. Date of transaction (DD-MM-YYYY). Only available in gateway RealizarPago. Time of transaction (HH:MM). Only available in gateway RealizarPago. Same amount as request. Same as request. Four is regarded as the maximum length. Same as request. Same as request. Same as request. Three is regarded as the maximum length. Mandatory. See section 6.4. See ANNEX II Optional information sent by merchant in the payment form 0 if the payment is NOT secure 1 if the payment is secure
Date Time Amount Currency Order no. Merchant code Terminal no. Merchants signature Response code Merchant data
<Ds_Date> <Ds_Hour> <Ds_Amount> <Ds_Currency> <Ds_Order> <Ds_MerchantCode> <Ds_Terminal> <Ds_Signature> <Ds_Response> Ds_Merchant_MerchantData
10 A 5A 12 N 4N min. 4N max. 12 AN 9N 3N 40 AN 4N 1024 AN
Secure Payment
<Ds_SecurePayment>
1N
Note: in the case of pre-authorizationsonly,a0isreturnedif it is authorized and the cardholder has been authenticated with his/herbank,anda1ifitisauthorizedbutthecardholderhas not been authenticated with the issuer bank. Type of transaction sent in the payment form Card number sent in the payment form. This is returned masked. Not available for gatewayRealizarPago. The expiry date on the card sent in the payment form. Not available for gatewayRealizarPago. Country of issue of the card used for the payment. See ANNEX IV. Alphanumerical code of the authorization given by the card issuer or the Authorization Centre to which it has delegated this service. Value 0 indicates that the language of the client has not been determined(optional).OnlyingatewayRealizarPago. Two possible values: C Credit D Debit
Transaction type Card number Expiry date Card country Authorization code Language of Cardholder Type of Card
<Ds_TransactionType> <Ds_Card_Number> <Ds_ExpiryDate> <Ds_Card_Country>
1N 16-19/Num 4/Num 3/Num
<Ds_AuthorisationCode>
6N
<Ds_ConsumerLanguage> <Ds_Card_Type>
3N 1 AN
InthefieldsDs_Currency,Ds_TerminalandDs_ConsumerLanguage,thelengthisregardedasthe maximumsoitisnotessentialtocompletethemwithzerosonthelefthandside. The signature willbegeneratedwiththefieldsexactlyassent.
Page 54

ANNEXII.TABLEOFRESPONSECODES(Ds_Response)
Responsecodessentbythecardissuingbank
RESPONSE CODES INDICATING THAT THE TRANSACTION HAS BEEN APPROVED
CODE 000 BRIEF DESCRIPTION TRANSACTION APPROVED TRANSACTION APPROVED SUBJECT TO IDENTIFICATION OF CARDHOLDER TRANSACTION APPROVED REFUND / CONFIRMATION APPROVED COMMENTS Transaction authorized by the card issuer. 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. Transaction authorized by the card issuer. Transaction authorized for Refunds and Confirmations
001
002 - 099 0900
RESPONSE CODES INDICATING THAT THE TRANSACTION HAS BEEN DECLINED

CODE 101 102 104 107 109 110 114 116 118 125 129 BRIEF DESCRIPTION CARD EXPIRED CARD BLOCKED TEMPORARILY OR UNDER SUSPICION OF FRAUD TRANSACTION NOT PERMITTED CONTACT THE CARD ISSUER INVALID IDENTIFICATION BY MERCHANT OR POS TERMINAL INVALID AMOUNT CARD CANNOT BE USED FOR THE REQUESTED TRANSACTION INSUFFICIENT CREDIT NON-REGISTERED CARD CRAD NOT EFFECTIVE CVV2/CVC2 ERROR COMMENTS Transaction declined because the expiry date on the card used for payment has already passed. Card has been blocked temporarily by the card issuer or suspected of being used fraudulently. Transaction not permitted for this type of card. The card issuer does not permit automatic authorization. You need to contact the authorization centre by telephone for approval. Declined because the merchant is not properly registered with international card systems. The amount of the transaction is unusual for the type of merchant seeking payment authorization. This kind of transaction is not permitted for this type of card. The cardholder does not have enough credit to make this payment. Card does not exist or has not been cleared by the issuing bank. Theresaproblem(undetermined)withthecard. 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. 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. This transaction is not permitted for this type of card. We remember that theres an agreement between Spanish banks where itssaidthatSpanish 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. Card temporarily blocked by the issuer bank. Exclusive code for Verified by Visa or MasterCard SecureCode transactions. ----The transaction has been declined because the card issuer cannot properly authenticate the cardholder. Page 55
167
CONTACT THE CARD ISSUER SUSPECTED FRAUD
180
CARD OUT OF SERVICE
181 - 182
CARD WITH CREDIT OR DEBIT RESTRICTIONS
184
AUTHENTICATION ERROR

RESPONSE CODES INDICATING THAT THE TRANSACTION HAS BEEN DECLINED
CODE 190 191 BRIEF DESCRIPTION REFUSAL WITH NO SPECIFIC REASON EXPIRY DATE INCORRECT COMMENTS Transaction declined by the card issuer with no explanation given as to the reason. 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 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. Card blocked temporarily by the card issuer or suspected of being used fraudulently. ----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. 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. The card issuer does not permit automatic authorization. You need to contact the authorization centre by telephone for approval. ----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. Card blocked by the card issuer because the cardholder has reported it as being lost or stolen. ----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. 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. ----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. Transaction declined by the card issuer with no explanation given as to the reason. ----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.
201
CARD EXPIRED
202
CARD BLOCKED TEMPORARILY OR UNDER SUSPICION OF FRAUD
204
TRANSACTION NOT PERMITTED
207
CONTACT THE CARD ISSUER
208 - 209
LOST OR STOLEN CARD
280
CVV2/CVC2 ERROR
290
DECLINED WITH NO SPECIFIC REASON
Page 56

RESPONSE CODES RELATING TO CANCELLATIONS OR PARTIAL REVERSALS (Ds_Merchant_TransactionType = 3 or Q)
CODE 400 480 BRIEF DESCRIPTION CANCELLATION ACCEPTED ORIGINAL TRANSACTION NOT LOCATED, OR TIME-OUT EXCEEDED CANCELLATION ACCEPTED COMMENTS The cancellation or partial reversal of the transaction has been accepted by the card issuer. 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. 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.
481
RESPONSE CODES RELATING TO RECONCILIATIONS OF PRE-AUTHORIZATIONS OR PRE-AUTHENTICATIONS (Ds_Merchant_TransactionTypes = 2, 8, P or S )

CODE 500 501 - 503 BRIEF DESCRIPTION RECONCILIATION ACCEPTED ORIGINAL TRANSACTION NOT LOCATED, OR TIME-OUT EXCEEDED COMMENTS The reconciliation transaction has been accepted by the card issuer. 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)
CODE 9928 BRIEF DESCRIPTION CANCELLATION OF DEFERRED PREAUTHORIZATIONS DONE BY THE SYSTEM CANCELLATION OF DEFERRED PREAUTHORIZATIONS DONE BY THE MERCHANT COMMENTS The system has cancelled the Deferred Preauthorization after 72 hours. The cancellation of the Deferred Preauthorization has been accepted.
9929
ResponsecodessentbytheCAIXACATALUNYApaymentplatform:
RESPONSE CODES INDICATING THAT THE TRANSACTION HAS BEEN DECLINED BY THE CAIXA CATALUNYA PAYMENT PLATFORM
CODE 904 909 912 913 916 928 940 BRIEF DESCRIPTION MERCHANT NOT REGISTERED AT FUC SYSTEM ERROR ISSUER NOT AVAILABLE DUPLICATE TRANSMISSION AMOUNT TOO LOW TIME-OUT EXCEEDED TRANSACTION CANCELLED PREVIOUSLY AUTHORIZATION OPERATION ALREADY CANCELLED BY A PREVIOUS CANCELLATION COMMENTS There is a problem in the configuration of the MID (Merchant Identification). Contact Caixa Catalunya to solve. Error in the stability of the Caixa Catalunya payment platform or the Visa or MasterCard exchange systems. The authorization centre of the card issuer is not operational at this particular time. A transaction has recently been processed with the same order number (Ds_Merchant_Order). Itsnotacceptedtooperatewith this amount. The card issuer has not responded to the authorization request within the pre-established time-out. A cancellation or partial reversal is being requested for a transaction that has already been cancelled. 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. Page 57
941

RESPONSE CODES INDICATING THAT THE TRANSACTION HAS BEEN DECLINED BY THE CAIXA CATALUNYA PAYMENT PLATFORM
CODE 942 BRIEF DESCRIPTION ORIGINAL AUTHORIZATION TRANSACTION DECLINED DIFFERENT DETAILS FROM ORIGINAL TRANSACTION SESSION ERROR DUPLICATE TRANSMISSION CANCELLATION OF TRANSACTION WHILE IN PROGRESS DUPLICATE TRANSMISSION WHILE IN PROGRESS POS INOPERATIVE REFUND NOT POSIBLE CARD NUMBER INCORRECT NO PAYMENT METHOD AVAILABLE NON-EXISTENT CARD RECURE TRANSACTIONS IN BAD GATEWAY CHECK-DIGIT INCORRECT PREAUTH. NOT ALLOWED FOR MERCHANT PREAUT. NOT ALLOWED FOR CARD OPERATING LIMIT EXCEEDED ISSUER NOT AVAILABLE CONFIRMATION ERROR KO CONFIRMATION DEFERRED PRE-AUTH. CANCELLED DEFERRED PRE-AUTH. CANCELLED COMMENTS The confirmation of a transaction is being requested with an order number (Ds_Merchant_Order) which corresponds to a transaction that has been declined. A confirmation is being requested which is incorrect. 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). A transaction has been processed recently with the same order number (Ds_Merchant_Order). A request is being made to cancel or partially reverse an original transaction which is still being processed and pending a response. 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. The merchant code (Ds_Merchant_MerchantCode) or the terminal code (Ds_Merchant_Terminal) are either not yet registered or not operative. The refund is not accepted by regulation The number of positions in Card Number is incorrect 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. Non-existent card. The merchant is not allowed to make Secure Transactions using gateway operaciones The check-digit of the card does not match up (position 16 of the card number calculated according to the Mod 10 algorithm). The merchant is not allowed to make Preathorizations The card is not allowed to make Preauthorizations The transaction exceeds an operating limit established by Caixa Catalunya The authorization centre of the card issuer is not operational at this time. Error in the confirmation sent by the merchant to the Virtual POS (this only applies with the SOAP synchronization option). KO confirmation of the merchant (this only applies with the SOAP synchronization system) Cancellation of deferred preauthorization made by the system (more that 72 hours) Cancellation of deferred preauthorization made by the merchant
943
944 945 946
947 949 950 9064 9078 9093 9218 9253 9256 9257 9261 9912 9913 9914 9928 9929
Other response codes different from the previous list can be shown starting with 9 (9xxx). To knowtheresponsereasonitwouldbenecessarytofindthecodewithoutthefirst9andtoloockof thexxxcodeinthepreviouslist.
Page 58

ANNEXIII.TABLEOFERRORS
ThefollowingtableliststhepossibleerrorvaluesyoumayreceiveintheresponsefromtheVirtual POS,the fieldtheyaffect(ifapplicable)andwhattheymean. Italso specifiestheerrormessage thatwillbeseenbytheclient(buyer)foreachoftheseerrors. SISxxxx
SIS0007 SIS0008 SIS0009 SIS0010 SIS0011 SIS0014 SIS0015 SIS0016 SIS0018 SIS0019 SIS0020 SIS0021 SIS0022 SIS0023 SIS0024 SIS0025 SIS0026 SIS0027 SIS0028 SIS0031 SIS0040 SIS0041 SIS0042 SIS0043 SIS0046 SIS0051 SIS0054 SIS0055
FIELD AFFECTED
Ds_Merchant_MerchantCode Ds_Merchant_MerchantCode Ds_Merchant_Terminal Ds_Merchant_Terminal Ds_Merchant_Order Ds_Merchant_Currency Ds_Merchant_Currency Ds_Merchant_Amount Ds_Merchant_Amount Ds_Merchant_Signature Ds_Merchant_Signature Ds_TransactionType Ds_TransactionType Ds_ConsumerLanguage Ds_ConsumerLanguage Ds_Merchant_MerchantCode Ds_Merchant_Currency Ds_Merchant_MerchantCode Ds_Merchant_TransactionType Ds_Merchant_Signature Ds_Merchant_Order Ds_Merchant_Order Ds_Merchant_Order
REASON
ErrorondismantlingentryXML Fieldismissing Formaterror Fieldismissing Formaterror Formaterror Fieldismissing Formaterror Fieldismissing Formaterror Fieldismissing Nodatainfield Formaterror Unknownvalue Valuehigherthan3digits Formaterror Merchant/terminal notexist sent
MESSAGE
MSG0008 MSG0008 MSG0008 MSG0008 MSG0008 MSG0008 MSG0008 MSG0008 MSG0008 MSG0008 MSG0008 MSG0008 MSG0008 MSG0008 MSG0008 MSG0008
does MSG0008 MSG0008 MSG0008 MSG0000 MSG0008 MSG0008 MSG0008 MSG0002 MSG0001 MSG0008 MSG0008
Currency does not coincide with theoneassignedtothisterminal Merchant/Terminal is no longer registered Methodofpaymentnotdefined Merchant/Terminal has methodofpaymentassigned Error in algorithm calculating no
HASH
Errorduringonlinenotification The card BIN has not yet been cleared Repeatedordernumber There is no transaction on which tomakearefund Theres more than one payment withthatDs_Merchant_Order
Page 59

SISxxxx
SIS0056 SIS0057 SIS0058 SIS0059
FIELD AFFECTED
Ds_Merchant_Order Ds_Merchant_Amount Ds_Merchant_Order
REASON
The transaction you wish to refundisnotauthorized The amount to be refunded is higherthanpermitted Inconsistent data in validating a confirmation The transaction you wish to confirmdoesnotexist There is already a confirmation associated with this pre authorization Thepreauthorizationyouwantto confirmisnotauthorized The amount to be confirmed exceedsthepermittedamount Errorincardnumber
MESSAGE
MSG0008 MSG0008 MSG0008 MSG0008
SIS0060
Ds_Merchant_Order
MSG0008
SIS0061 SIS0062 SIS0063 SIS0064 SIS0065 SIS0066 SIS0067 SIS0068 SIS0069 SIS0070 SIS0071 SIS0072 SIS0074 SIS0075 SIS0076 SIS0078 SIS0089 SIS0092 SIS0093 SIS0094 SIS0112 SIS0114 SIS0115
Ds_Merchant_Order Ds_Merchant_Amount
MSG0008 MSG0008
MSG0008
Errorincardexpirydate
MSG0008
Ds_Merchant_Order Ds_Merchant_Order Ds_Merchant_Order Ds_Merchant_Order Ds_TransactionType Ds_Merchant_Expirydate Ds_Merchant_Expirydate
Cardexpired Transactioncannotbecancelled Fieldismissing The value has fewer than 4 positionsormorethan12 Thevalueisnotnumerical Unknownvalue Thevaluehasnot4positions Valuenotaccepted Card cannot be found in range table
MSG0000 MSG0000 MSG0008 MSG0008 MSG0008 MSG0005 MSG0008 MSG0008 MSG0006 MSG0004 MSG0008 MSG0000 MSG0008
Ds_TransactionType Ds_Merchant_Order
Card has not been authenticated as3DSecure Valuenotpermitted A GET has been called instead of aPOST There is no transaction on which topaytheinstalment The transaction on which you want to pay an instalment is not valid The transaction on which you want to pay an instalment is not authorized
Page 60
SIS0116
Ds_Merchant_Order
MSG0008
SIS0117
Ds_Merchant_Order
MSG0008

SISxxxx FIELD AFFECTED REASON
The total number of instalments indicated in the first transaction of a recurring transaction has beenexceeded Formaterror Formaterror Formaterror Format error in one of the two fields The date limit indicated in the first transaction of a recurring transactionhasbeenpassed Theminimumfrequencyindicated in the first transaction of a recurring transaction has been exceeded The date of the authorization confirmationcannotbemorethan 7daysafterthepreauthorization The date of the authentication confirmation cannot exceed the priorauthenticationbymorethan 45days The initial recurring payment has beenduplicated Time for payment has been exceeded Theamountisoverthepermitted limitforthismerchant The number of transactions exceeds the permitted limit for thismerchant The cumulative amount exceeds the permitted limit for this merchant This merchant does not accept refunds The CVV2 has more than three digits FormaterrorofCVV2 The merchant is not able to do Secure Transactions in operacionesgateway The number of card transactions exceeds the permitted limit for thismerchant The cumulative amount of the card exceeds the permitted limit forthismerchant Error.TheCVV2ismandatory
Page 61
MESSAGE
SIS0118
Ds_Merchant_Amount
MSG0008
SIS0119 SIS0120 SIS0121 SIS0122
Ds_Merchant_DateFrecuency Ds_Merchant_ChargeExpiryDate Ds_Merchant_SumTotal Ds_Merchant_ChargeExpiryDate Ds_Merchant_SumTotal Ds_Merchant_ChargeExpiryDate
MSG0008 MSG0008 MSG0008 MSG0008
SIS0123
MSG0008
SIS0124
Ds_Merchant_DateFrecuency
MSG0008
SIS0132
MSG0008
SIS0133
MSG0008
SIS0139 SIS0142 SIS0198
MSG0008 MSG0000 MSG0008
SIS0199
MSG0008
SIS0200
MSG0008
SIS0214 SIS0216 SIS0217 SIS0218
MSG0008 MSG0008 MSG0008
SIS0219
MSG0008
SIS0220 SIS0221
MSG0008 MSG0008

SISxxxx
SIS0222
FIELD AFFECTED
REASON
There is already a cancellation associated with the pre authorization Thepreauthorizationyouwantto cancelhasnotbeenauthorized The merchant does not accept cancellations as there is no extendedsignature There is no transaction available tobecancelled Inconsistentdatainthevalidation ofacancellation Invalidvalue There is no code forthedeferred paymentrequest The merchant does not allow the cardtobesent The cards checkdigit does not matchup ThenumberoftransactionsperIP exceeds the maximum permitted forthismerchant The cumulative IP amount exceeds the limit permitted for thismerchant The merchant cannot do pre authorizations The card does not allow pre authorizations Inconsistentconfirmationdetails The transaction exceeds an operating limit established by CaixaCatalunya TransactionTypenotactivatedfor thismerchant Unknown transaction Type or not allowedforthisgateway
MESSAGE
MSG0008
SIS0223
MSG0008
SIS0224
MSG0008
SIS0225 SIS0226 SIS0227 SIS0229 SIS0252 SIS0253
Ds_Merchant_TransactionDate
MSG0008 MSG0008 MSG0008 MSG0008 MSG0008 MSG0008
SIS0254
MSG0008
SIS0255
MSG0008
SIS0256 SIS0257 SIS0258 SIS0261
MSG0008 MSG0008 MSG0008 MSG0008
SIS0270 SIS0274
Ds_Merchant_TransactionType Ds_Merchant_TransactionType
MSG0008 MSG0008
Page 62

Table of messages that the buyer receives when an error occurs in the transaction together with theirmeanings.
CODE MSG0000 MSG0001 MSG0002 MSG0003 MSG0004 MSG0005 MSG0006 MSG0007 MSG0008 Ordernumberrepeated
MESSAGE Thesystemisbusy,pleasetrylateron ThecardBINhasnotbeenclearedwithFINANET Thesystemisstartinguppleasetryagaininafewminutes Authenticationerror Thereisnovalidpaymentmethodforthiscard Cardoutofservice Somedetailsaremissingpleasecheckwhetheryourbrowseracceptscookies Errorindetailssent.Pleasecontactyourmerchant.
Page 63

ANNEXIV.LISTOFCOUNTRYCODES
004 008 010 012 016 020 024 028 031 032 036 040 044 048 050 051 052 056 060 064 068 070 072 074 076 084 086 090 092 096 100 104 108 112 116 120 124 132 136 140 144 148 152 156 158 162 166 170 174 Afghanistan Albania Antarctic Algeria American Samoa Andorra Angola Antigua and Barbuda Azerbaijan Argentina Australia Austria Bahamas Bahrain Bangladesh Armenia Barbados Belgium Bermuda Bhutan Bolivia Bosnia-Herzegovina Botswana Bouvet Island Brazil Belize Mauritius Solomon Islands British Virgin Islands Brunei Bulgaria Burma Burundi Byelorussia Cambodia Cameroon Canada Cape Verde Cayman Islands Central African Sri Lanka Republic Chad Chile China Taiwan Christmas Island Cocos Islands Colombia Comoros 178 180 184 188 191 192 196 203 204 208 212 214 218 222 226 230 233 234 238 242 246 250 254 258 260 262 266 268 270 280 288 292 296 300 304 308 312 316 320 324 328 332 334 336 340 344 348 352 356 Congo Zaire Cook Islands Costa Rica Croatia Cuba Cyprus Czech Republic Benin Denmark Dominica Dominican Republic Ecuador El Salvador Equatorial Guinea Ethiopia Estonia Faeroe Islands Falkland Islands Fiji Finland France French Guyana French Polynesia French Southern territories Djibouti Gabon Georgia Gambia Germany Ghana Gibraltar Kiribati Greece Greenland Granada Guadeloupe Guam Guatemala Guinea Guyana Haiti Heard and McDonald Islands Vatican City Honduras Hong Kong Hungary Iceland India 360 364 368 372 376 380 384 388 392 398 400 404 408 410 414 417 418 422 426 428 430 434 438 440 442 446 450 454 458 462 466 470 474 478 480 484 492 496 498 500 504 508 512 516 520 524 528 530 533 Indonesia Iran Iraq Ireland Israel Italy Ivory Coast Jamaica Japan Kazakhstan Jordan Kenya North Korea South Korea Kuwait Kyrgyzstan Laos Lebanon Lesotho Latvia Liberia Libya Lichtenstein Lithuania Luxembourg Macao Madagascar Malawi Malaysia Maldives Mali Malta Martinique Mauritania Mauritius Mexico Monaco Mongolia Moldavia Montserrat Morocco Mozambique Oman Namibia Nauru Nepal Holland Dutch Antilles Aruba
Page 64

540 548 554 558 562 566 570 574 578 580 581 582 583 584 586 591 598 600 604 608 612 616 620 624 626 630 634 638 642 643 New Caledonia Vanuatu New Zealand Nicaragua Niger Nigeria Niue Norfolk Island Norway Northern Mariana Minor (US) Islands Pacific Micronesia Marshall Islands Pakistan Panama Papua-New Guinea Paraguay Peru Philippines Pitcairn Poland Portugal Guinea-Bissau Timor Puerto Rico Qatar Reunion Rumania Russia 646 654 659 662 666 670 674 678 682 686 690 694 702 703 704 705 706 710 716 720 722 724 736 740 744 748 752 756 760 Rwanda St. Helens Anguilla St. Lucia St. Pierre and Miquelon St. Vincent and the San Marino Grenadines Sao Tome and Principe Saudi Arabia Senegal Seychelles Sierra Leone Singapore Slovakia Vietnam Slovenia Somalia South Africa Zimbabwe Yemen Tokelau Islands Spain Sudan Surinam Svalbard and Jan Mayen Swaziland Sweden Switzerland Syria 762 764 768 776 780 784 788 792 795 796 798 800 804 807 818 826 834 840 849 850 854 858 860 862 876 882 886 891 894 Tajikistan Thailand Togo Tonga Trinidad and Tobago United Arab Emirates Tunisia Turkey Turkmenistan Turks and Caicos Islands Tuvalu Uganda Ukraine Macedonia Egypt United Kingdom Tanzania United States miscellaneous (US) US Virgin Islands Burkina Uruguay Uzbekistan Venezuela Wallis and Futuna Samoa Yemen Yugoslavia Zambia
Page 65

ANNEXV.SECURITYDIGITALCERTIFICATESSSL/TLS
Duetotheheydaythatinthelasttimeshashadtheelectroniccommerce,merchantsandService 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 confidentialityandintegrityoftheinterchangedinformation. ItisthiscontextwherethereappeartheprotocolsSSLandTLS.
The server's certificate SSL of the merchant must be expressed by a public recognized CA. Autosignedcertificatesarenotaccepted. Thecertificateslistedbelowhavebeentestedinoursystemandworkcorrectly.Thesecertificates ofCAareloadedinthecontainersofcertificatesofconfidenceofourapplications. IncasethemerchantwantstomakeuseofacertificateexpressedbyapublicrecognizedCAthat is not in the list, it will have to get in touch with Caixa de Catalunya to verify his validity and interoperabilitywiththedifferentapplications. In case the CA is accepted, it will be loaded in the applications and will be included in this documentandthemerchantwillbeinformedoftheacceptance. In case it should not be accepted the merchant will be informed so that it should obtain one expressedbythelist. TheaveragenecessarytimetoanalyzethevalidityornotofaCAforrequestofamerchantitwill be2weeks.

RECOGNIZEDENTITIESOFCERTIFICATION NextthereappearsthelistofcertificatesofCARootandIntermediateCAloadedinthecontainers ofcertificatesofoursystem.ItisimportantthatthemerchantverifiesthathishierarchyofCAsis includedinthefollowingstage. RootCAs

ID. R1 COMPANY ACE/Verisign SUBJECT
OU=Class3PublicPrimaryCertification Authority O=VeriSign,Inc. C=US CN=GTECyberTrustGlobalRoot OU=GTECyberTrustSolutions,Inc. O=GTECorporation C=US CN=UTNUSERFirstHardware OU=http://www.usertrust.com O=TheUSERTRUSTNetwork L=SaltLakeCity S=UT C=US CN=EquifaxSecureGlobaleBusinessCA1 O=EquifaxSecureInc. C=US E=info@valicert.com CN=http://www.valicert.com/ OU=ValiCertClass2PolicyValidationAuthority O=ValiCert,Inc. L=ValiCertValidationNetwork E=premiumserver@thawte.com CN=ThawtePremiumServerCA OU=CertificationServicesDivision O=ThawteConsultingcc L=CapeTown S=WesternCape C=ZA E=servercerts@thawte.com
SERIALNUMBER
70BAE41D10D92934 B638CA7B03CCBABF
CADUCITY
02/08/2028
R2
Cybertrust
01A5
14/08/2018
R3
Usertrust
44BE0C8B500024B4 11D3362AFE650AFD
09/06/2019
R4 R5
Geotrust/Equifax Valicert
01
21/06/2020 26/06/2019
01
R6
Thawte
01
01/01/2021
R7
Thawte
01
01/01/2021
Page 66

ID. COMPANY SUBJECT
CN=ThawteServerCA OU=CertificationServicesDivision O=ThawteConsultingcc L=CapeTown S=WesternCape C=ZA
SERIALNUMBER
CADUCITY
R8 R9
Verisign IPSCA
OU=SecureServerCertificationAuthority O=RSADataSecurity,Inc. C=US E=ips@mail.ips.es CN=IPSSERVIDORES OU=Certificaciones O=IPSSeguridadCA L=BARCELONA S=BARCELONA C=ES CN=ECACC OU=JerarquiaEntitatsdeCertificacioCatalanes OU=Vegeuhttps://www.catcert.net/verarrel (c)03 OU=ServeisPublicsdeCertificacio O=AgenciaCatalanadeCertificacio(NIFQ 0801176I) C=ES OU=FNMTClase2CA O=FNMT C=ES OU=EquifaxSecureCertificateAuthority O=Equifax C=US CN=AddTrustExternalCARoot OU=AddTrustExternalTTPNetwork O=AddTrustAB
02AD667E4E45FE5E 576F3C98195EDDC0 00
08/01/2010 30/12/2009
R10
AgenciaCatalanade Certificacin
EE2B3DEBD421DE14 A862AC04F3DDC401
08/01/2031
R11 R12 R13
FNMT Equifax AddTrustAB
36F11B19
18/03/2019 22/08/2018 30/05/2020
35DEF4CF
01
IntermediatesCAs
ID I1 COMPANY ACE/Verisign SUBJECT
I1OU=www.verisign.com/CPSIncorp.byRef. LIABILITYLTD.(c)97VeriSign OU=VeriSignInternationalServerCA Class3 OU=VeriSign,Inc. O=VeriSignTrustNetwork CN=ComodoClass3SecurityServicesCA OU=(c)2002ComodoLimited OU=TermsandConditionsofuse: http://www.comodo.net/repository OU=ComodoTrustNetwork O=ComodoLimited C=GB CN=DigiSignCADigiSSLXp OU=TermsandConditionsofuse: http://www.digisign.com/repository O=DigiSignLimited L=Dublin S=Dublin C=IE E=practices@starfieldtech.com CN=StarfieldSecureCertificationAuthority OU= http://www.starfieldtech.com/repository O=StarfieldTechnologies,Inc. L=Scottsdale S=Arizona C=US CN=ThawteSSLDomainCA O=ThawteConsulting(Pty)Ltd. C=ZA CN=VeriSignClass3SecureServerCA OU=Termsofuseat https://www.verisign.com/rpa(c)05 OU=VeriSignTrustNetwork O=VeriSign,Inc. C=US E=ips@mail.ips.es CN=CLASEB3ipsCAIPSSeguridad2005 OU=Certificaciones O=IPSSeguridadCA L=Barcelona S=Barcelona C=ES
ISSUER
R1
SERIALNUMBER
254B8A853842CCE3 58F8C5DDAE226EA4 78EE48DE185B2071 C9C9C3B51D7BDDC1 0200029A
CADUCITY
25/10/2011
I2
Comodo
R2
28/08/2008
I3
Digisign
R3
0B41F1C471626DD1 D35542AFC562BBCB
09/06/2019
I4
Starfield Technologies
R5
0104
09/06/2024
I5 I6
Thawte
R7
30000001 75337D9AB0E1233B AE2D7DE4469162D4
ACE/Verisign
R1
19/01/2015
I7
IPSCA
R9
009033
31/12/2009
Page 67

ID I8 COMPANY
Agencia Catalanade Certificacin
SUBJECT
CN=ECAL OU=AdministracionsLocalsdeCatalunya OU=Vegeu https://www.catcert.net/verCIC2(c)03 OU=ServeisPublicsdeCertificacioECV2 L=PassatgedelaConcepcio1108008 Barcelona O=AgenciaCatalanadeCertificacio(NIFQ 0801176I) C=ES CN=UTNUSERFirstHardware OU=http://www.usertrust.com O=TheUSERTRUSTNetwork L=SaltLakeCity S=UT C=US
ISSUER
R10
SERIALNUMBER
3D97D3930439622A 3E1C4DA6BED1730E
CADUCITY
08/01/2019
I9
UserTrust
R13
26211BF52AEB51B0 0BFS9FDD8D36DA9E
30/05/2020
URLofthecompanieslistedabove: 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 StarfieldTechnologies http://www.starfieldtech.com Thawte http://www.thawte.com IPSCA http://www.ipsca.com AgenciaCatalanade http://www.catcert.net Certificacin CyberTrust http://www.cybertrust.com
Page 68

ANNEXVI.DISPUTECIRCUIT
Page 69

ANNEXVII.DISPUTINGACHARGEBACK
Page 70

ANNEXVIII.RETRIEVALREQUESTSCIRCUIT
Page 71

TPV Virtual - Extended Merchant Manual July09

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TPV Virtual - Extended Merchant Manual July09

Uploaded by

Copyright:

Available Formats

Virtual POS

EXTENDED MERCHANT MANUAL

LATEST UPDATE July 2009

VIRTUAL POS EXTENDED MERCHANT MANUAL

INTRODUCTION SECURITY GUARANTEES 3DSECURE CROSS-BORDER LICENSES OPERATING FEATURES

OTHER TECHNICAL INFORMATION

QUERIES ON TRANSACTIONS VIA SOAP-XML

REGULAR INFORMATION FILES

VIRTUAL POS EXTENDED MERCHANT MANUAL

ANNEX VI. DISPUTE CIRCUIT ANNEX VII. DISPUTING A CHARGE-BACK

ANNEX VIII. RETRIEVAL REQUESTS CIRCUIT

VIRTUAL POS EXTENDED MERCHANT MANUAL 1.INTRODUCTION

VIRTUAL POS EXTENDED MERCHANT MANUAL 2.SECURITYGUARANTEES3DSECURE

VIRTUAL POS EXTENDED MERCHANT MANUAL 3.CROSSBORDERLICENSES

VIRTUAL POS EXTENDED MERCHANT MANUAL 4. OPERATINGFEATURES

VIRTUAL POS EXTENDED MERCHANT MANUAL

VIRTUAL POS EXTENDED MERCHANT MANUAL

VIRTUAL POS EXTENDED MERCHANT MANUAL

VIRTUAL POS EXTENDED MERCHANT MANUAL

Cardholder Merchant Cardholder Merchant Cardholder

YES YES NO YES NO

Ifconditionsallow Sameasoriginal Ifconditionsallow

VIRTUAL POS EXTENDED MERCHANT MANUAL

Ifconditionsallow If the original was authenticated

Recurring If the original was Preauthorization: amount, authenticated instalmentsandfinaldate

VIRTUAL POS EXTENDED MERCHANT MANUAL

VIRTUAL POS EXTENDED MERCHANT MANUAL

VIRTUAL POS EXTENDED MERCHANT MANUAL

VIRTUAL POS EXTENDED MERCHANT MANUAL 5.ADMINISTRATIONMODULE

VIRTUAL POS EXTENDED MERCHANT MANUAL

VIRTUAL POS EXTENDED MERCHANT MANUAL 6.INSTALLATION

VIRTUAL POS EXTENDED MERCHANT MANUAL

VIRTUAL POS EXTENDED MERCHANT MANUAL

VIRTUAL POS EXTENDED MERCHANT MANUAL

VIRTUAL POS EXTENDED MERCHANT MANUAL

VIRTUAL POS EXTENDED MERCHANT MANUAL

VIRTUAL POS EXTENDED MERCHANT MANUAL

VIRTUAL POS EXTENDED MERCHANT MANUAL

VIRTUAL POS EXTENDED MERCHANT MANUAL

VIRTUAL POS EXTENDED MERCHANT MANUAL

Ds_Merchant_Currency + Ds_Merchant_TransactionType + Ds_Merchant_MerchantURL + SECRET CODE)

VIRTUAL POS EXTENDED MERCHANT MANUAL

+ Ds_Merchant_Order Ds_Merchant_Currency + Ds_Merchant_SumTotal Ds_Merchant_MerchantURL+SECRETCODE) + + Ds_Merchant_MerchantCode Ds_Merchant_TransactionType + +

GATEWAYSentradaXMLEntidadandoperaciones Themerchantselectronicsignatureshouldbecalculatedasfollows: Digest = SHA1(Ds_Merchant_Amount + Ds_Merchant_Order + Ds_Merchant_MerchantCode+ Ds_Merchant_Currency + Ds_Merchant_Pan + Ds_Merchant_MerchantURL(3) +

OnlyifitisthefirstofaRECURRINGpayment(Ds_Transaction_Type=5orR) OnlyiftheCVV2isgiven (3) OnlyforentradaXMLgateway

VIRTUAL POS EXTENDED MERCHANT MANUAL

CaixaCatalunyaprovidesexamplesofconnectionswiththePOSterminalindifferentprogramming languages. SHA1references: - StandardfortheSecureHashStandard,FIPSPUB1801.

http://www.itl.nist.gov/fipspubs/fip1801.htm http://csrc.nist.gov/publications/fips/fips1801/fips1801.pdf http://csrc.nist.gov/cryptval/dss/dsaval.htm

(34) 93 479 9191

Tel. 902 110 558

for international calls

VIRTUAL POS EXTENDED MERCHANT MANUAL 7.OTHERTECHNICALINFORMATION

VIRTUAL POS EXTENDED MERCHANT MANUAL

Successive Successive Successive

VIRTUAL POS EXTENDED MERCHANT MANUAL

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

VIRTUAL POS EXTENDED MERCHANT MANUAL

VIRTUAL POS EXTENDED MERCHANT MANUAL 8.QUERIESONTRANSACTIONSVIASOAPXML

DetailedbelowisanexampleofaSOAPclient.SOAPclientsshouldtakethefollowingsteps: A.GivetheURLoftheSOAPserviceyouwanttoaccess: B.CreateaSOAPMappingRegistryobject:

VIRTUAL POS EXTENDED MERCHANT MANUAL

VIRTUAL POS EXTENDED MERCHANT MANUAL

VIRTUAL POS EXTENDED MERCHANT MANUAL