Datatrans ecom General Information

December 2015 Datatrans ecom General Information About the payment process with Datatrans V 7.3.2 01.12.2015 PHA 1 / 23

To guarantee a proper implementation of the Datatrans Payment Solution make sure to read the following documents carefully: General Information Technical Implementation Guide Please use only the latest version of these documents. Both are available at https://www.datatrans.ch/showcase/documentations/technical-documentation 01.12.2015 PHA 2 / 23

Table of contents 1. INTRODUCTION... 6 1.1 About this document... 6 1.2 Relation to other documents... 6 2. PAYMENT PROCESS OVERVIEW... 7 2.1 Check-Out Process... 7 2.2 Role of the PSP... 8 3. PLANNING / CONCEPT OF PAYMENT INTEGRATION... 9 3.1 Which payment methods do I want to offer to my customers?... 9 3.2 Which acquirer contract types do I need?... 9 3.3 Do I want to offer local currencies to my customers?... 9 3.4 How do I avoid fraud?... 9 3.5 How do I avoid erroneous transactions, i.e. double bookings or missing transactions?10 3.6 How will I match the bank payments with my receivables?... 10 3.7 Do I need 3-D Secure?... 10 3.8 What is the CC Alias feature and why would I need it?... 11 3.9 How can I process deferred settlement?... 11 3.10 What is the Post URL?... 11 3.11 What are merchant specific parameters?... 11 4. PREREQUISITES AND RESTRICTIONS... 12 4.1 Supported Internet browsers... 12 4.2 Prerequisites... 12 4.3 Requirements / restrictions... 12 4.4 3-D Secure (Verified by Visa, MasterCard SecureCode)... 12 4.5 PCI and Acquirer contracts... 12 4.6 Security regulations (PCI)... 13 4.7 TLS Certificate... 14 4.8 XML authorisation... 14 4.9 Other requirements... 14 5. PAYMENT PROCESS STEP BY STEP... 15 5.1 Authorisation... 15 5.2 Settlement... 15 5.3 Reconciliation/ data consolidation... 16 01.12.2015 PHA 3 / 23

6. DIFFERENT TYPES OF PAYMENT PROCESSES... 17 6.1 Web Shop Payment Process... 17 6.2 Recurring billing / XML Authorisation... 18 7. PAYMENT METHODS... 19 7.1 Credit card brands and acquirers... 19 7.2 Credit card contract types... 19 7.3 Swiss PostFinance... 20 7.4 Loyalty Cards... 20 7.5 Other payment methods... 21 8. FRAUD RISK MANAGEMENT... 22 8.1 Process of fraud management... 23 01.12.2015 PHA 4 / 23

Revision Control Version Date Changed by Comments / nature of change 5 05.06.09 Katja Schlegel Complete revision In Version 5 the whole document has been restructured, ClickandBuy has been removed from the whole document and all graphics have been changed 1.2 Add Chapter 1.2 Relation to other documents 3.7 Explanation Liability Shift 3.9 Add graphic 4.4 Response code 02, response code U 4.5 Add chapter PCI 5.1 Note:...should be settled within the period agreed with the acquirer 6 Add chapter 7.5 Other payment methods 8 Update Anti Fraud Management 6 Katja Schlegel 6.3 add Call Center Solution II 7.5 add ideal and Sofortüberweisung 8.1 add Fraud management process 6.1 07.06.10 Katja Schlegel 6.2 cosmetic changes 6.3 cosmetic changes 7 Katja Schlegel Change of several links 7.1 14.02.13 Katja Schlegel All graphics have been updated 7.2 07.03.14 Katja Schlegel 7.3 15.09.14 Christoph Ryser 4.1 Remove Exception for PostFinance 7.3.1 30.03.15 Dominik Mengelt Updated company address 7.3.2 01.12.15 Patrick Hagmann Complete revision 01.12.2015 PHA 5 / 23

1. Introduction 1.1 About this document This document provides detailed information about the payment process in general and with Datatrans, about important settings, options and thoughts about a proper payment process. 1.2 Relation to other documents Document title Desciption Audience Technical Implementation Guide Information about the technical implementation of Developer the Datatrans interface General Information About the payment process with Datatrans Description of payment process Merchant, developer It s strongly recommended to read the documents Technical Implementation Guide and General Information about the payment process with Datatrans carefully to guarantee a proper implementtation and payment process. 01.12.2015 PHA 6 / 23

2. Payment Process overview The most common problems with the payment process are doubled or missing transactions in the merchants system. This kind of problem is in most of the cases the consequence of improper payment process implementation. 2.1 Check-Out Process Step 1 Shopping process; presentation of order details and billing amount Step 2 Save of customer name and address details as well as all order details before the payment process This step is very important because it helps recovering order information if the payment process fails for some reason; this is particularly important for all external payment methods (e.g. PostFinance, PayPal and paysafecard) Step 3 Show payment page Step 4 Return of transaction status via success, error, cancel or Post URL; allows status update of previously saved transaction (see step 2) Step 5 Order confirmation to customer with Success URL and/or E-Mail sent by merchant Step 6 If required: settlement via XML or Datatrans Web Admin Tool Merchant Datatrans 01.12.2015 PHA 7 / 23

2.2 Role of the PSP In order to offer the consumer one or more payment methods E-Commerce merchants need to choose a PSP. The PSP... enables the processing of various payment methods with one unified E-Commerce shop interface provides reporting tools for payment data analysis and reconciliation ensures that the E-Commerce merchant complies with the security regulations of the major credit card organisations (PCI DSS) provides integrated anti fraud options The payment interface from Datatrans supports all levels of complexity an E-Commerce business can possibly comprehend. 01.12.2015 PHA 8 / 23

3. Planning / Concept of Payment Integration The planning of the payment process should start by answering the following questions. 3.1 Which payment methods do I want to offer to my customers? The most common payment method in the E-Commerce world is the credit card. It is appropriate for medium and high amounts. For the Swiss local market the Swiss PostFinance payment methods are very popular, too. 3.2 Which acquirer contract types do I need? If you are only selling via the Internet you just need a Secure E-Commerce Contract (SEC). Important: SEC contracts require that the buyer is present during the payment process because he might have to enter his 3-D Secure password. Therefore, if you also accept orders by mail or phone, or if you do recurring billing, you need a Mail / Phone contract (MPO) too. 3.3 Do I want to offer local currencies to my customers? If yes, please arrange according contracts with your acquirers. Datatrans supports all currencies provided by the acquirer. 3.4 How do I avoid fraud? If you accept Visa and MasterCard, fraud is no longer an issue like it was in the past because the merchants normally have 3-D Secure contracts nowadays. Nevertheless, it is inevitable to check the CVV code, because many card issuers and acquirers do no longer authorise transactions without it. As with all other credit card brands the liability shift does not apply, fraud prevention should be taken into consideration. We recommend the following fraud prevention measures: country verification / country filter check of CVV / CVC limitation of maximum amount and / or maximum transactions per day and cardholder limitation of maximum amount and / or maximum transactions per day and IP address limitation of maximum amount and / or maximum transactions per day and origin IP address Black list with credit card number ranges and individual card numbers In case of fraud, the liability can vary. It is a merchants duty to require information about fraud settings and liability shifts from their acquirer, also to know about the terms and conditions in the acquirer contract. For further details about the Fraus Prevention Options click here and refer to chapter 6.5. 01.12.2015 PHA 9 / 23

3.5 How do I avoid erroneous transactions, i.e. double bookings or missing transactions? As the E-Commerce shop application is forwarding the customer to the payment page of Datatrans it loses control about the payment process. If the customer s browser session stops or hangs for any reason during the payment it can occur that his credit card is charged, but the e-shop does not get the success message and therefore, the merchant does not fulfil the order. Another case could be that a customer sends a fake HTTPS post form to Datatrans with an invalid amount. This kind of problems can be avoided as follows: split of authorisation and settlement (deferred settlement) storage / registration of the order before the start of the payment process; generation of a discrepancy report with all transactions which did not complete the payment process use of the sign parameter (see Technical Specification for details); avoids the acceptance of modified or faked HTTPS post forms use of the Post URL; provides feedback from the Datatrans payment gateway even if the customer s browser session has been terminated daily check / match of processed transactions (see chapter Reconciliation ) use the unique refno check (can only be activated by Datatrans upon request) 3.6 How will I match the bank payments with my receivables? As a merchant you have to decide how you will compare the bank payments with the actually processed transactions. This task is absolutely essential, and it has to be done on a daily basis. It helps to discover missing or erroneous transactions in time, and it can prevent major damage in the beginning. For details please refer to the chapter Reconciliation / Data Consolidation. 3.7 Do I need 3-D Secure? Yes, the Swiss acquirers do no longer offer other Internet contracts. Datatrans features a certified 3-D Secure interface which is fully included into the payment process. There is no additional implementation work required. Our payment application automatically determines whether the customer has a 3-D Secure enrolled card or not. If he has one, the payment application automatically opens the 3-D Secure authentication page of the card issuer. Important We recommend to contact your acquirer concerning the liability shift in combination of a charge back. Also, please be aware of your duty to use fraud protection settings. If there is no liability shift on a transaction it is marked in the Web Administration Tool with this sign: 01.12.2015 PHA 10 / 23

3.8 What is the CC Alias feature and why would I need it? With the Datatrans payment application the merchant has the option to add credit card information to his customer profiles without offending against the data security regulations of MasterCard and Visa (PCI DSS). This can be achieved by using the credit card alias (CC Alias) feature offered by Datatrans. The CC Alias is generated with the authorisation process. The E-Commerce application of the merchant submits the card number and gets back a numeric value (Token) which can be added to the customer s profile. 3.9 How can I process deferred settlement? As mentioned earlier in this document, authorisation and settlement can be processed separately. The authorisation has to be submitted to the payment page. With deferred settlement the transactions can be submitted for payment (settlement) manually with the Datatrans Web Admin Tool (http://payment.datatrans.biz) or automatically with the XML interface. For details about the XML settlement please refer to the detailed technical specifications. 3.10 What is the Post URL? This feature guaranties that the shop application gets the actual status of all transactions even if the consumer cancels the browser session while the payment process is running. For details about the Post URL please refer to the detailed technical specifications. 3.11 What are merchant specific parameters? The merchant can invent and submit own parameters. These parameters are returned to the Success-, Error- and Post URL. However, they are not visible in the Web Administration Tool from Datatrans. 01.12.2015 PHA 11 / 23

4. Prerequisites and Restrictions 4.1 Supported Internet browsers ecom supports the newest versions of all Internet browsers. 4.2 Prerequisites The following is required for payment processing with Datatrans ecom : Valid contracts with one or more acquirers Processing contract with Datatrans (for details please refer to www.datatrans.ch) 4.3 Requirements / restrictions Datatrans reserves the right to add new return parameters and response codes without notification; any merchant application has to ignore undocumented fields and response codes; existing parameters and response codes will not be changed. 4.4 3-D Secure (Verified by Visa, MasterCard SecureCode) 3-D Secure is a security standard introduced by Visa and MasterCard in order to protect cardholders and merchants against any kinds of unauthorised use of credit cards. If a merchant has a 3-D Secure (SEC) contract the liability shifts from the acquirer to the issuer, no matter if the cardholder is 3-D Secure enrolled or not. If the cardholder is 3-D Secure enrolled he is redirected to a dedicated web page of his issuer where he has to enter a password for authentication. For more details please refer to one of the following links: Verified by Visa: MasterCard SecureCode: www.verifiedbyvisa.com www.mastercardmerchant.com/securecode/. In our Web Admin Tool we show all response codes clearly. Make sure to have a special look at transactions with Response code 02: You will receive a response code 02, if the issuer doesn t claim liability. In case of a charge back the merchants will have the liability. You can decline transactions with a response code 02. Activate this setting in our Web Admin Tool in the menu UPP Administrator. Response code U: The issuer doesn t claim liability. Datatrans must decline such transactions by default, exept you can show a written confirmation from the acquirer, that he accepts to authorise such transactions. 4.5 PCI and Acquirer contracts With the closure of an acquirer contract you commit to follow the PCI Security Standards, which say that only PCI-certified merchants are allowed to process and store credit card data. 01.12.2015 PHA 12 / 23

4.6 Security regulations (PCI) All credit card acquiring contracts are subject to the PCI DSS (Payment Card Industry Data Security Standards). Therefore all merchants accepting credit cards have to comply with the security regulations issued by the PCI Security Standards Council (www.pcisecuritystandards.org). From a PCI DSS point of view merchants basically have two options: Processing credit card details by storing or passing card numbers through their own application host; requires PCI DSS certification Level C or D Using terminals or external payment forms offered by PCI DSS compliant payment service providers (PSP); requires PCI DSS certification Level A As the PCI DSS certification process is very complex and expensive most of the merchants prefer the second option. The Datatrans payment services are fully PCI DSS certified. However, the merchant is responsible for the proper integration of the Datatrans payment service interface. The main goal is to avoid credit card number storage or processing by a merchant application host. Therefore, credit card details have to bypass the merchant application. PCI compliance can be achieved with the following features offered by Datatrans: Universal Payment Page (UPP) All payment details are posted to the Datatrans payment page; the payment process including 3-D Secure authentication is processed in the Datatrans payment form. At the end of the payment process the status of the transaction is returned to the shop application. XML Settlement Service Authorised transactions can be settled via our XML settlement interface; as no card number is required this process is fully PCI compliant. The same interface also supports credit notes and status requests. Datatrans Alias Service This service offers to the merchant a fully PCI DSS compliant way to store credit card information. The Alias is a numeric value which is replacing the card number. It is not subject to the PCI DSS and can therefore be stored and assigned to customer profiles like the card number. The merchant can submit the Alias instead of the card number with each UPP or XML authorization request. 3-D Secure transactions are supported, too. For further details refer to https://www.pcisecuritystandards.org/. 01.12.2015 PHA 13 / 23

4.7 TLS Certificate We also recommend the TLS Certificate. The consumer is redirected from our Payment Page, which is TLS certified to the error or success URL. If these are not TLS certified, the browser may generate a pop-up, which informs the consumer that he s redirected to a non-secure page. A lot of consumers get irritated by this message and cancel it, not knowing that the transaction has already been done. 4.8 XML authorisation You must have a Mail / Phone Order Contract with your acquirer and use the alias service from Datatrans. If these conditions are not given, you must not do XML authorizations. The XML authorization does not support 3-D Secure, also you have higher commission rates and no liability shift. The XML authorization must not be used for E-Commerce. These conditions are not made up by Datatrans but by the PCI Security DSS, which say, that merchants are no longer allowed to store OR process credit card data through their system. PCI certification is a data security measure safeguarding the processing of credit card payments over the Internet. The aim is to avoid the theft and missuse of credit card data. Moreover, it does not support external payment methods like PostFinance, and PayPal. 4.9 Other requirements The payment must be processed with a minimum size of 390 x 400 pixels. Also note that PayPal doesn t work in a frame, you have to use the whole window for a PayPal transaction. Authorised PayPal transactions expire within 30 days. Please contact PayPal is you wish to re-authorise a payment which is older than 30 days. 01.12.2015 PHA 14 / 23

5. Payment Process Step by Step 5.1 Authorisation Datatrans offers the following authorisation interfaces: Datatrans Mail / Phone Tool (http://payment.datatrans.biz) for mail / phone order business only; does only support credit cards Datatrans ecom Payment Page for standard and secure E-Commerce contracts Datatrans ecom XML authorisation for mail / phone order business only; does only support credit cards and can only be used with the Alias; for details please contact the Datatrans support team. Basically, credit card transactions are always split into authorisation and settlement. The following parameters are checked with the authorisation: BIN and checksum (LUHN check) status of the card (ok or blocked) monthly allowance of the cardholder (monthly limit) CVV or CVC (Card Verification Code or Card Verification Value); last three digits in the signature field on the back of the credit card With the authorisation the monthly allowance of the cardholder is reduced by the authorised amount, no matter whether the transaction will be settled later or not. The authorised amount is reserved for the merchant and should be settled within the period agreed with the acquirer. The issuer returns an authorisation code which serves as the reference of the authorisation. Once a transaction has been successfully authorised it can be settled. Important: the cardholder will not be charged without settlement. Authorisation and settlement can be processed in one step (direct debit) or as two separate tasks (deferred settlement). 5.2 Settlement The settlement process is only required if the merchant chooses deferred settlement. Only successfully authorised transactions can be settled. Datatrans offers the following settlement interfaces: Datatrans Web Admin Tool Datatrans ecom XML Settlement Both interfaces support most of the payment methods and contract types offered by Datatrans. 01.12.2015 PHA 15 / 23

5.3 Reconciliation/ data consolidation We suggest using the following tools and reports for payment reconciliation: Electronic Transaction Report offered by Datatrans; available by e-mail or FTP; for details please refer to the Datatrans support team Summarised or itemised payment statement offered by all acquirers; available on paper or as PDF file by e-mail Electronic Payment Advice (EPA) offered by most of the credit card acquirers; fixed length text files downloadable via FTP; for details please refer to your acquirer External Service Providers Some tools that are helpful for reconciliation o o Matchbox Moneytracker For more details please refer to Datatrans. 01.12.2015 PHA 16 / 23

6. Different Types of Payment Processes As described in chapter 4.5.1 all merchants accepting credit cards have to comply with the security regulations issued by the PCI Security Standards Council (www.pcisecuritystandards.org). Find in this chapter the payment processes for the different types of online payment from Datatrans which are fully PCI-compliant. 6.1 Web Shop Payment Process Your customer has the possibility to enter his credit card number and purchase something on the internet. Order Payment Confirmation Settlement / Reconciliation Web Shop Presentation of shopping cart / start of payment process Launch of Payment Page (HTTPS post) Landing Page (success, error, cancel URL) Order confirmation Settlement process (with XML or Web Admin Tool) Reconciliation process Payment Service Fraud screening 3D secure process Online authorisation Payment data submission Acquiring Service 3D secure service (Visa/ MasterCard issuer) Acquirer Payment to merchant Electronic payment advice merchant Datatrans Overview payment process for web shops: https post request to Datatrans payment form (UPP) Fraud screening by Datatrans payment service 3-D Secure process Online authorization Return of transaction status to merchant return URL Optional: settlement process by the merchant application (the settlement can also be integrated into the authorization process) 01.12.2015 PHA 17 / 23

6.2 Recurring billing / XML Authorisation Process description of an authorization from a mail / phone order with the already existing Alias. E.g. for recurring transactions. This must be used with the alias service. This service must not be used for transactions done on the internet. The XML authorization must only be used for e.g. recurring transactions. Order Payment Confirmation Settlement / Reconciliation Web Shop Customer order from merchant order processing application XML Authorisation with ALIAS Authorisation response Shipping or fulfillment Settlement process (with XML or Web Admin Tool) Reconciliation process Payment Service Online authorisation Payment data submission Acquiring Service Acquirer Payment to merchant Electronic payment advice Overview recurring mail / phone order or automatic billing process Submission of Alias via Datatrans XML authorization service Conversion Alias credit card number Online authorization Conversion credit card number Alias Return of transaction status to merchant application Optional: settlement process by the merchant application (the settlement can also be integrated into the authorization process) 01.12.2015 PHA 18 / 23

7. Payment Methods 7.1 Credit card brands and acquirers Credit Cards are the most popular of all payment methods in the Internet. Datatrans supports the following credit card brands and acquirers: Brand MasterCard, Visa American Express Diners Club / Discover JCB Maestro Acquirers supported by Datatrans SIX Payment Services, Aduno, B+S Card Service, ConCardis, AirPlus Acceptance, card complete Service Bank, Deutsche Postbank, Elavon Merchant Services, European Merchant Services EMS, hobex, J.P. Morgan, Nets Holding A/S, Paylife, Société Générale, WorldPay Swisscard AECS, American Express International SIX Payment Services, Elavon Merchant Servies, DC Bank SIX Payment Services, B+S Card Services, card complete Service Bank AG SIX Payment Services, ConCardis, card complete Service Bank, Elavon Merchant Services, European Merchant Services EMS, Société Générale, WorldPay Meastro is not yet available in Switzerland. For contact details of the acquirer banks mentioned above please refer to www.datatrans.ch 7.2 Credit card contract types In order to be able to process credit card transactions a merchant first of all needs a credit card contracts with one or more acquirer banks (in this document referred to as acquirer). The acquirer is the link between the merchant s bank account and the credit card issuer (in this document referred to as issuer). The acquirers offer the following contract types: 1. 3-D Secure (SEC); used for E-Commerce; good protection against charge-back; the issuer or card holder has the liability. 2. Mail / Phone Order (MPO); used for mail-order business (order by phone, mail or fax.); the merchant has the liability. 3. Card Present; used in shops with physical Point of Sales (POS) systems; the card has to be read with a card reader, the cardholder has to sign the credit card slip; good protection against charge-back. 01.12.2015 PHA 19 / 23

7.3 Swiss PostFinance Datatrans supports the following PostFinance methods: PostFinance Card (ex Debit Direct) PostFinance E-Finance (ex Yellownet) TWINT For details about these payment methods please refer to www.yellowpay.ch. The PostFinance payment methods can be processed like credit cards. Authorisation and settlement can either be split, or they can be done in one single step. Both, PostFinance Card and E-Finance, offer guaranteed payment upon successful authorisation. For signing up a PostFinance contract please send an e-mail to merchanthelp@postfinance.ch. 7.4 Loyalty Cards The Datatrans payment application supports Jelmoli Bonus Card and Manor MyOne Card. These payment methods can be processed like credit cards. Loyalty Cards can only be accepted by partners of Jelmoli or Manor. 01.12.2015 PHA 20 / 23

7.5 Other payment methods Payment method Description Countries PayPal Easy and quick payment method where the consumers needs Worldwide a PayPal account SOFORT Banking Online Banking-payment method Europe Skrill Direct Online Banking-payment method Worldwide ideal Online Banking-payment method Netherland Easypay from Swisscom Solution to mobile online payment Switzerland SEPA Direct Debits (SDD) Preferably used by consumers without credit card. Bank account from consumer is debited directly. If the option credit is wished, you have to contact your acquirer Germany Dankort Very popular payment method (debit card) Denmark CRIF Deltavista Credit assessment service if a merchant accepts payment Switzerland by invoice. creditpass Optional extension by additional creditpass checks Europe Accarda Purchase on account / hire purchase Switzerland Billpay Purchase on account / hire purchase Europe curabill Purchase on account / hire purchase Switzerland PowerPay Purchase on account / hire purchase Switzerland SwissBilling Purchase on account / hire purchase Switzerland Migros Bank E-Pay Collection for the online shop Switzerland paysafecard Prepaid Card, opens a range of new consumers, especially Europe for micro-billing Skrill (Moneybookers) Similar to PayPal. Worldwide UATP Various Lodge Cards (Airplus etc.) Worldwide Amex BTA American Express Business Travel Account Worldwide 01.12.2015 PHA 21 / 23

8. Fraud Risk Management Datatrans offers a variaty fraud prevention options. All these options can be set in the Web Administration Tool by the customer/merchant and have to be activated by Datatrans first. Limit of the maximum number of authorization requests per card number in a specific time range (0 1440 min.). Limit of the maximum number of authorization requests per client IP address, in a specific time range (0 1440 min.). Limit of the maximum amount per credit card in a specific time range (0 1440 min.). Combination of points 1 to 3. Blacklist blocking of individual card numbers or entire ranges of numbers (BIN). Card numbers that have been registered as blocked remain on our blacklist files. Every transaction is crosschecked against this blacklist before data is forwarded to the financial institute. If the system comes across such an entry, the transaction is rejected immediately. Whitelist with choice of countries (based on BIN). The merchant can include or exclude countries via Datatrans Web interface. Customers from risk regions: Experience has shown that orders from troubled regions may harbour increased risk. Datatrans lets you reduce this risk by not accepting customer orders from such regions (IP addresses, card numbers). Validation of the country of origin of the card based on the ISO country code. The customer also enters the country of origin of the card. The transaction will only be authorized if the country was correctly specified For more details refer to the presentation Portrait of Datatrans. 01.12.2015 PHA 22 / 23

8.1 Process of fraud management The sequence of the Fraud query looks like following. 01.12.2015 PHA 23 / 23