Datatrans eCom General Information · Technical Implementation Guide ... 4.8 XML authorisation ... provides feedback from the Datatrans payment gateway even if the customer’s

10.08.2017 DME 1 / 25 Datatrans Ltd, Kreuzbühlstrasse 26, CH - 8008 Zurich, Tel. +41 44 256 81 91, Fax +41 44 256 81 98, www.datatrans.ch

Datatrans eCom

General Information

About the payment process with Datatrans

V 7.3.4

August 2017


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

https://www.datatrans.ch/showcase/documentations/technical-documentation


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 are the most common payment methods by country?............................................. 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 difference between Standard and Hidden Mode? .......................................... 11

3.9 What is the CC Alias feature and why would I need it? ...................................................... 11

3.10 How can I process deferred settlement? ......................................................................... 11

3.11 What is the Post URL? ....................................................................................................... 12

3.12 What are merchant specific parameters? ........................................................................ 12

4. PREREQUISITES AND RESTRICTIONS .................................................................................... 13

4.1 Supported Internet browsers ................................................................................................ 13

4.2 Prerequisites ........................................................................................................................... 13

4.3 Requirements / restrictions ................................................................................................... 13

4.4 3-D Secure (Verified by Visa, MasterCard SecureCode) .................................................... 13

4.5 PCI and Acquirer contracts ................................................................................................... 13

4.6 Security regulations (PCI) ..................................................................................................... 14

4.7 TLS Certificate ........................................................................................................................ 15

4.8 XML authorisation .................................................................................................................. 15

4.9 Other requirements ................................................................................................................ 15

5. PAYMENT PROCESS STEP BY STEP ....................................................................................... 16

5.1 Authorisation .......................................................................................................................... 16

5.2 Settlement ............................................................................................................................... 16

5.3 Reconciliation/ data consolidation ....................................................................................... 17


6. DIFFERENT TYPES OF PAYMENT PROCESSES ..................................................................... 18

6.1 Web Shop Payment Process ................................................................................................. 18

6.2 Call Center process (https post request) ............................................................................. 19

6.3 Recurring billing / XML Authorisation .................................................................................. 20

7. PAYMENT METHODS ................................................................................................................. 21

7.1 Credit card brands and acquirers ......................................................................................... 21

7.2 Credit card contract types ..................................................................................................... 21

7.3 Swiss PostFinance ................................................................................................................. 22

7.4 Loyalty Cards .......................................................................................................................... 22

7.5 Other payment methods ........................................................................................................ 23

8. FRAUD RISK MANAGEMENT .................................................................................................... 24

8.1 Process of fraud management .............................................................................................. 25


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

7.3.3 25.01.16 Urs Kipfer 3.1 Most common payment methods per country

3.4 Fraud management

3.7 3-D Secure

3.8 PCI restriction with hidden mode

6.2 Call center process with Pay-by-E-Mail

7.3.4 10.08.2017 Dominik Mengelt New Domains


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

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 implement-

tation and payment process.

https://admin.sandbox.datatrans.com/showcase/doc/Technical_Implementation_Guide.pdf

https://admin.sandbox.datatrans.com/showcase/doc/Technical_Implementation_Guide.pdf/showcase/doc/General_Information.pdf




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

M erchant

D atatrans


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 are the most common payment methods by country?

Switzerland:

Mastercard, Visa, PostFinance, Invoice, PayPal

Germany:

Sepa ELV, PayPal, Sofortüberweisung, MasterCard, Visa

Austria:

MasterCard, Visa, PayPal, Sofortüberweisung

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?

Fraud prevention can be implemented on the following 3 levels:

1. Payment method specific security features (card number, expiry date, cvv, 3-D Secure etc.) 2. Basic fraud prevention tools from Datatrans (black- or whitelisting, country validation, velocity checks) 3. External service provider (e.g. Cybersource Decision Manager)

In case of fraud, the liability can vary. It is a merchant’s 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 Fraud Prevention Options click here and refer to chapter 6.5.

https://admin.sandbox.datatrans.com/showcase/doc/User_Manual_english.pdf


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?

The financial institutions are recommending 3-D Secure. It’s also the default contract type issued by the acquirers.

However, if you as a merchant can explain plausibly that you are carefully dealing with potential fraud the acquir-

er might be prepared to issue a non-3-D Secure contract.

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:


3.8 What is the difference between Standard and Hidden Mode?

- Standard Mode: All web forms for payment method selection and entry of credit card details are pro-

vided and hosted by Datatrans requires PCI DSS SAQ A

- Hidden Mode: All web forms for payment method selection and entry of credit card details are provided

and hosted by the merchant requires PCI DSS SAQ A-EP

3.9 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.10 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 (https://admin.sandbox.datatrans.com) or

auto-matically with the XML interface. For details about the XML settlement please refer to the detailed technical

specifications.

https://admin.sandbox.datatrans.com/


3.11 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.12 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

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.

http://www.datatrans.ch/

http://www.verifiedbyvisa.com/

http://www.mastercardmerchant.com/securecode/


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.

For further details refer to https://www.pcisecuritystandards.org/.

http://www.pcisecuritystandards.org/


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 (https://admin.sandbox.datatrans.com) 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.

https://admin.sandbox.datatrans.com/


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

For more details please refer to Datatrans.


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.

We

b S

ho

pP

aym

en

t

Se

rvic

eA

cq

uirin

g

Se

rvic

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

ConfirmationPayment

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 (the settlement can also be integrated into the authorization process)

http://www.pcisecuritystandards.org/


6.2 Call Center process (https post request)

Call center workspaces with credit card processing are automatically in the PCI DSS scope. This means that all PCs

and servers have to be fully PCI compliant. As call center transactions are generally decreasing we recommend

refraining from gathering and storing credit card details.

As an alternative we offer “Pay-by-E-Mail”. This service is complimentery to all our customers. The merchant can

generate time-limited payment links through the Datatrans Back Office Tool. The individual payment link can be

forwarded to the customer and include his available payment options.

The individually generated payment link contains all information relevant for the payment such as curren-cy, amount and reference. The link is embedded in the offer, which is delivered to the customer via e-mail.

If the customer accepts the offer and clicks on the payment link to pay, he is passed directly to the pre-configured Datatrans payment page which already holds amount and currency. The customer chooses his preferred method of payment and enters his payment information to confirm the payment.

Right after the payment process (incl. 3-D Secure) is completed by the customer, the merchant receives an e-mail confirmation from Datatrans.

Pay-by-E-Mail is the ideal solution to keep your mail / phone order business out of the PCI scope.


6.3 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.

We

b S

ho

pP

aym

en

t

Se

rvic

eA

cq

uirin

g

Se

rvic

e

Customer order

from merchant

order processing

application

XML

Authorisation with

ALIAS

Order

Online authorisation

Acquirer

Authorisation

response

Shipping or

fulfillment

ConfirmationPayment

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 (the settlement can also be integrated into the authorization process)


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

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.

http://www.datatrans.ch/


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.

http://www.yellowpay.ch/

mailto:[email protected]


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

Amex BTA American Express Business Travel Account 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

Advanced Fraud Screening with Cybersource Decision Manager (CDM) is the solution for merchants and service providers with a considerable fraud exposure. It requires a separate agreement with Cibersource. For more details about CDM please refer to our support team.


8.1 Process of fraud management

The sequence of the Fraud query looks like following.

Documents

Datatrans eCom General Information · Technical Implementation Guide ... 4.8 XML authorisation ... provides feedback from the Datatrans payment gateway even if the customer’s