Datatrans ecom General Information

Datatrans eCom

General Information

About the payment process

with Datatrans

V 7.3.2

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

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

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

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

_‎

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 the Datatrans interface

Developer

General Information

About the payment process with Datatrans

Description of payment process Merchant, developer



Information about the payment process with Datatrans” carefully to guarantee a proper implement-tation and payment process.

2. Payment Process overview



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



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

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.

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



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.



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.

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 authori-sation 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 auto-matically 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.

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: www.verifiedbyvisa.com

MasterCard SecureCode: 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



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.

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 there-fore 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.

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.

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.



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

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 Matchbox

o Moneytracker

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.

W e b S h o p P a y m e n t S e rv ic e A c q u ir in g S e rv ic e Presentation of shopping cart / start of payment process Launch of Payment Page (HTTPS post) Order Fraud screening 3D secure process 3D secure service (Visa/ MasterCard issuer) Online authorisation Landing Page (success, error, cancel URL) Order confirmation Confirmation Payment Settlement process (with XML or Web Admin Tool) Payment data submission Payment to merchant Electronic payment advice Reconciliation process Settlement / Reconciliation Acquirer 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

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.

W e b S h o p P a y m e n t S e rv ic e A c q u ir in g S e rv ic e Customer order from merchant order processing application XML Authorisation with ALIAS Order Online authorisation Acquirer Authorisation response Shipping or fulfillment Confirmation Payment Settlement process (with XML or Web Admin Tool) Payment data submission Payment to merchant Electronic payment advice Reconciliation process Settlement / Reconciliation

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

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 Acquirers supported by Datatrans

MasterCard, Visa 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 American Express Swisscard AECS, American Express International

Diners Club / Discover SIX Payment Services, Elavon Merchant Servies, DC Bank

JCB SIX Payment Services, B+S Card Services,

card complete Service Bank AG

Maestro SIX Payment Services, ConCardis, card complete Service Bank, Elavon Merchant Services, European Merchant Services EMS, Société Générale, WorldPay



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.

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 [email protected].

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.

7.5 Other payment methods

Payment method Description Countries

PayPal Easy and quick payment method where the consumers needs

a PayPal account

Worldwide

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 by invoice.

Switzerland

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 for micro-billing

Europe

Skrill (Moneybookers) Similar to PayPal. Worldwide

UATP Various Lodge Cards (Airplus etc.) Worldwide

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 cross-checked 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.

8.1 Process of fraud management