Electronic payment put in context

Transcription

Electronic payment
put in context
Bill payment, electronic
commerce and exploitation of
electronic products
(Deliverable D0.1b)
Colophon
Date :
March 4, 2002
Version :
3.0
Change :
2.0
January 24, 2001
2.6
November 29, 2001 Separated general backgrounds from
Start of update GigaABP/2000/D1.1
payment in specific contexts
2.7
January 10, 2002
Version for (external) review
3.0
March 4, 2002
Final version
Project reference :
GigaABP/2001/D0.1b
TI reference :
TI/RS/2001/081
Company reference :
URL :
http://gigaabp.telin.nl
Access permissions :
Public
Status :
Final
Editor :
Sander Hille
Company :
Telematica Instituut
Author(s) :
Sander Hille, Petra van der Stappen
Synopsis:
This document puts electronic payment in the
contexts of bill payment, electronic commerce
and exploitation of electronic products such as
content or electronic services. It takes mainly a
business and functional perspective on this
topic. As illustration we provide examples of
commercial products and services that are
available in the Netherlands to realise
electronic payment in these contexts.
COPYRIGHT © 2002 TELEMATICA INSTITUUT
PERSONAL USE OF THIS MATERIAL IS PERMITTED. HOWEVER, PERMISSION TO REPRINT/REPUBLISH THIS MATERIAL FOR ADVERTISING OR
PROMOTIONAL PURPOSES OR FOR CREATING NEW COLLECTIVE WORKS FOR RESALE OR REDISTRIBUTION TO SERVERS OR LISTS, OR TO REUSE ANY
COPYRIGHTED COMPONENT OF THIS WORK IN OTHER WORKS MUST BE OBTAINED FROM OR VIA TELEMATICA INSTITUUT (HTTP://WWW.TELIN.NL).
Preface
This document reports on the second part of research on payment systems that has been
conducted within the context of GigaPort Applications (http://www.gigaport.nl/), in particular
the Giga Accounting, Billing and Payment project (GigaABP, see http://gigaaabp.telin.nl).
It contains information on electronic payments systems in three contexts:
1. Bill payment (Electronic Bill Presentment and Payment – EBPP),
2. Electronic commerce (in particular: web-shops), and
3. Exploitation of electronic products (content, electronic services).
We take the perspective of a decision maker in a company that wants to make use of
electronic payment in any of the three contexts. We describe the aspects that (s)he should
take into account when deciding upon systems to deploy. Our focus is on the situation in the
Netherlands, sometimes extended when this may illustrate the domestic situation in
comparison to other countries. We have tried to keep the discussions as less technical as
possible, mainly taking a business and functional view on matters. The material presented
here is extensive but not a complete encyclopaedic work containing all available commercial
systems. Mentioning and discussion of the latter systems has been meant as illustration of the
general line of discourse.
The first part of research on payment systems was a survey of the current Dutch overall
payment system as provided by the financial sector, i.e. the commercial banks, De
Nederlandsche Bank, Interpay and credit card organsations (see [HiSt01]). This first part
serves as background for the material presented in this document.
The document also contains some material that was obtained from the GigaPort project on
Transaction Services, GigaTS. We would like to thank Wil Janssen and Petra van der
Stappen for providing this information. Moreover, we would like to thank Arnold Sneijers and
Ivo Heemskerk (Interpay Nederland, Business Unit e-Commerce) for valuable discussions on
electronic bill presentment, Roel Stap (TNO FEL e-Business), Henk Jonkers and Andrew
Tokmakoff (Telematica Instituut) for their contributions in preparing this document.
Finally we would like to thank the reviewers, Ivo Heemskerk, Wim Nouwens, Petra van der
Stappen and Andrew Tokmakoff for their valuable suggestions and comments as reviewers of
earlier versions of this document.
More information with regard to the content of this report or on the GigaABP project can be
obtained from the project manager, Sander Hille (email: [email protected], or by phone:
+31-(0)53 4850485). Other reports that resulted from the project are available at
http://gigaabp.telin.nl (‘Publications’), or through the GigaPort web site: http://www.gigaport.nl.
Dr. Sander C. Hille
Project manager GigaABP.
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
V
Table of Contents
1 Introduction
11
1.1
Document scope
11
1.2
Related project research and information
13
1.3
Document structure
14
2 Payment over public communication networks
17
2.1
The issues
17
2.1.1
Trust
17
2.1.2
Cross-border payments
18
2.1.3
Direct payment
18
2.2
Misconceptions on Internet payment
19
2.3
The roles of mobile communication in payment
20
2.3.1
Payment terminal in the physical world
21
2.3.2
Payment terminal in the virtual world
22
2.3.3
Direct payment channel
22
2.4
Merging of payment flows
23
3 Overview of bill presentment and bill payment
25
3.1
Introduction
25
3.2
A functional reference model for billing and bill payment
26
3.3
Differences between B2C and B2B billing
26
3.4
Instruments for bill payment
27
3.5
Bill distribution and presentment: print and mail services
28
3.6
Developments in bill presentment and bill payment
28
3.6.1
A digital acceptgiro
29
3.6.2
Electronic Bill Presentment (e-Billing)
30
3.6.3
Bill consolidation and payment services
30
4 Electronic Bill Presentment and Payment
33
4.1
Introduction
33
4.2
The impact of cultural aspects
33
4.3
Models for EBP
34
4.4
US players
37
4.5
Dutch providers of EBP solutions and services
38
4.5.1
Anachron: ‘Pulse Suite’
38
4.5.2
Bluem
39
4.5.3
TNT Post Group: ‘Privver’
39
Intrum Justitia
39
4.5.4
4.6
Standards
40
4.6.1
Open Financial Exchange (OFX)
40
4.6.2
GOLD message standard
41
4.6.3
Interactive Financial Exchange (IFX)
42
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
VII
4.7
Examples of Electronic Bill Presentment systems
42
4.7.1
BillCast (Avolent)
42
4.7.2
WorkOut (Alysis)
43
4.7.3
4.8
Oracle’s Bill Presentment and Payment Solution
44
Trends and developments
44
5 Payment in e-commerce context
47
5.1
Issues in the virtual world
47
5.1.1
Direct payment
47
5.1.2
International reach
48
5.2
Examples of dedicated account-based systems
48
5.2.1
PayPal
48
5.2.2
Jalda-based Safetrader
49
5.3
Example of international collection: GlobalCollect
50
5.4
Generic system architecture
51
5.5
Payment Service Providers (PSPs)
53
5.5.1
Bibit Internet Payment Services
54
5.5.2
NetGiro
55
5.5.3
TWYP - The Way You Pay
56
6 Electronic wallets: shopping and payment assistants
57
6.1
Introduction
57
6.2
Basic wallet functions
58
6.3
Product examples
58
6.3.1
ABN-AMRO’s e-Wallet
59
6.3.2
Microsoft Passport
59
6.3.3
Novell’s Digitalme
60
6.3.4
6.4
Xiring: the Wireless Wallet concept
60
Wallet standards and frameworks
61
6.4.1
Electronic Commerce Modelling Language (ECML)
61
6.4.2
Java Wallet
62
6.5
The future of e-wallets
63
7 Adaptation of real world payment instruments
65
7.1
Introduction
65
7.2
Credit cards
65
7.2.1
Secure Socket Layer (SSL)
66
7.2.2
Secure Electronic Transactions (SET)
67
7.2.3
I-Pay – Interpay’s Dutch SET payment platform
68
7.2.4
The Three Domain Model (3D SET)
69
7.2.5
Virtual Credit Cards
69
7.3
7.3.1
7.3.2
7.4
VIII
Debit cards
70
Rabo Direct Betalen
70
On-line use of Maestro
71
Card-based electronic money
71
G
I G A
P
O R T
7.4.1
Proton on Internet
72
7.4.2
Chip-Secure Electronic Transaction (C-SET)
72
7.5
73
8 Exploitation of electronic products
75
8.1
Introduction
75
8.2
Characteristics
75
8.3
Potential payment scenarios
76
8.3.1
Example: ISP – Trivnet’s WiSP
77
8.3.2
Example: Access network operator
79
8.3.3
Example: ISP and Network operator – KPN’s SwitchPoint
79
8.4
Total solutions for content-exploitation
80
8.4.1
Magex
80
8.4.2
Qpass
81
8.4.3
NetBill
81
8.5
Network-based electronic money schemes
82
8.6
Evaluation of discussed payment systems
84
9 Micropayment systems
85
9.1
Introduction
85
9.2
The problems to solve
85
9.3
Potential players
86
9.4
Commercially available micropayment systems
87
9.4.1
NewGenPay’s Micropayment solution (former IBM)
88
9.4.2
Millicent (Compaq) – a token-based system
90
9.5
9.5.1
9.5.2
9.6
Micropayment standards and standardisation efforts
91
A Common Markup for micropayment per-fee-links
91
(Draft) Micro Payment Transfer Protocol (MPTP)
92
The future of micropayment systems
93
10 Conclusions
95
10.1 Coverage of on-line payment transactions
95
10.2 Cultural impact
95
10.3 Introduction of new payment services and instruments
96
10.4 Telco-finance integration
96
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
IX
1 Introduction
The Internet offers new business opportunities. New electronic products and services can be
delivered. In order to get the services operational, substantial investments in technology and
marketing must be made by those who endeavour in this new business. These companies
require return on investments. The sooner, the better. The crucial question is how to realise
(financial) return.
First there is the question of selecting the appropriate exploitation strategy and business
model. Various types exist and may look promising. However, an important issue in many
cases may be the level of support provided by ICT systems for these strategies and models.
The second issue therefore is to select systems, strategy and model in such a way that the
company retains flexibility towards future developments – with regard to all three: changes in
systems, strategy or business model.
There are however two functions that are needed in any case: (1) measurement of the sales
figures or individual usage (metering and accounting) and (2) the settlement of financial
claims that the service provider holds on the service user or a third party that result from
usage sessions or online order transactions (billing and payment). Money must change hands
somehow.
1.1
Document scope
The main objective of the research within the GigaABP project is providing insight into the
divers ways in which the commercial exploitation of network-based services could be realised.
This document focuses on the second main function: billing and payment, in a business-toconsumer (B2C) setting. These functions, complemented with the delivery of goods and
services for which the consumer is paying, realise the settlement phase of a B2C transaction
(see Figure 1). We do not consider the Business-to-Business (billing and payment)
relationship between the merchant or service provider and his supplier(s). Moreover, we do
consider only situations in which monetary value is exchanged for the goods and services.
The support of barter, i.e. the exchange of products (goods or services) for other products, is
beyond our scope.
Delivery:
Goods and services
B2C transaction
Consumer
B2B
Transfer:
Money
Beyond
scope
Merchant,
Service
Provider
Supplier
Figure 1: The Business-to-Consumer setting
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
11
Various factors influence which payment systems and services are available or which players
are involved in the transfer of monetary value, in the full payment transaction process. One
factor is the international extent of the economic transaction. If goods, services and money
need to cross national borders, then typically different players, processes and systems are
encountered than in a national (‘domestic’) setting. Legislation and regulations vary over
countries. In this document we focus on a domestic setting, on the Netherlands. The
consumers and merchants or service providers are located in the Netherlands. We treat the
services and systems that they have at their disposal for effecting payments over public
electronic communication networks. These generally differ from those provided in other
European countries, the US or other parts of the world.
A second factor is the context in which payment transactions (the transfer of money) take
place, i.e. the type of economic transactions in which they are used. We identify three
fundamental contexts (see also Figure 2):
1. Bill payment,
Typically used when there is a trust relationship between consumer and vendor, often on a
long-term basis. The average transaction value ranges from about € 15 upwards to very
large amounts. Bill payment is often used to aggregate small value amounts.
2. Electronic commerce,
By which we mean here the selling of physical goods or services through electronic
communication channels. The trust-relationship between consumer and vendor may be
less established than in the bill payment context because of occasional buyers contacting
the vendor though the indirect communication channels, such as phone, email or the Web.
The transaction value in this type of transactions ranges somewhere between € 5 and €
500. Vendors may require direct payment, before delivery takes place.
3. Exploitation of electronic goods and services,
That is, a context in which intangible, electronic products are sold and directly distributed
through electronic communication networks with hardly any human activity involved in the
selling and delivery process, if at all (‘unattended points-of-sale’). The transaction value in
this context will be low, in the range of approximately € 0.10 to € 5.
Bills
Invoice
‘Subscription, post-paid,
long(er) term
relationship…’
Utilities
Telecom
B2B
B2C
€0
0.10
€5
Digital products
€ 15
€ 500
Physical goods
Content
‘Per item, direct,
Books
Electronic services
Transaction
value
Clothing
CDs/DVDs
short term
relationship…’
Figure 2: Payment contexts: ‘What are we paying for on-line?”
12
G
I G A
P
O R T
Each context has different characteristics and has different requirements on payment systems
that can be used in these situations. Consequently companies offer payment products and
services that target special usage context. It is the objective of this report to provide insight
into the relationships between payment contexts, requirements and players involved.
Furthermore, we sketch and analyse current developments in e-payment and billing.
The settlement of Business-to-Consumer transactions as presented in Figure 1 attracts
various players; from the financial sector, the telecom and Internet sector and from the
transport & logistics sector (see Figure 3). Some players target the Consumer; others the
Merchant/Service Provider. Some target both.
In this document we focus on the role that the Telecom and Internet sector plays in electronic
payment, together – or in competition – with the financial sector that traditionally has been the
provider of payment services. The latter is involved in the processing, clearing and settlement
of payment transactions even if dedicated Internet solutions are used. In fact, consumer’s
money resides initially mainly in bank accounts. Therefore the relation between the financial
sector’s overall payment system and these dedicated solutions is important to understand.
For that purpose backgrounds on the overall payment system in the Netherlands are provided
in [HiSt01].
Scope of [HiSt01]
Central banks
Credit card
organisations
Financial
networks
Banks
Clearing Houses
Financial sector
Service
Bureaus
Fixed
Banks
ISPs
Wallet
SPs
Consumer
Network
money issuers
Financial
networks
e-Bill
presenters
PSPs
Transaction
Processors
Merchant or
Service Provider
Telecom and Internet
Mobile
ISPs
Mobile network
operators
Fulfillment
companies
Mobile
Parcel delivery
firms
Scope of this
document
Transport & logistics
Non-electronic
ISP: Internet Service Provider
SP: Service Provider
PSP: Payments Service Provider
Figure 3: Positioning of this document in the field of retail payment transactions
1.2
Related project research and information
The GigaABP project was tasked to study the functionality, systems and business
relationships that are required to establish an end-to-end solution for the financial exploitation
of network-based services. The basis for all research activities is a functional architecture for
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
13
1
financial exploitation that has been developed in the project [JBHS01] . In [JBHS01],
examples have been worked-out: a webshop, a video-on-demand service and payment for
electronic services through billing and pre-paid systems of a mobile network operator.
Other research activities in the project, including those that resulted in this document, are
related to this architecture (see Figure 4):
· Metering and reporting of application usage,
see [JST+01],
· Demonstrator implementation,
for demonstration purposes, and for obtaining ‘hands-on’ experience, see [ToWi00] and
[Wibb01].
[JBHS01]
describes
Functional reference model
Commercial e xploitation support
use r info
Information
prov isioning
a cco unting
data
charging
data
me ter
input
Usage data
acquisition
usage
da ta
Data & process
manage me nt
reconcilia tion
data
pro vide r
info
bill
Financial
Se ttle me nt
payme nt
i nititiatio n
paym ent
indicatio n
Aspects
covered
Approaches to
metering, report
mechanisms;
implementations
Demonstrator
implementation
Backgrounds
on the Dutch
payment system
Payment in
various contexts
e.g. Internet, mobile
e-billing
[HiSt01]
This doc
describes
[JST+01]
[ToWi00]
[Wibb01]
Project report: see references
Figure 4: Overview of research activities in GigaABP, delivered reports, and their relations
References to related research outside the GigaABP project are included in the text. We
would like to point the reader however to [ECP00] (or its planned up-date) with regard to
electronic payment systems in the Netherlands for e-commerce and [JSB+00] where
electronic payment is considered in the context of on-line transaction services. [Webe98]
provides a technical overview of various electronic payment systems (internationally).
1.3
Document structure
The rest of this document is structured as follows:
1
A reader interested in the development of this model over time may consult the subsequent versions of the model in
[JHTW00], [JHTW01a], [JHTW01b]. [JBHS01] contains the final version.
14
G
I G A
P
O R T
Chapter 2 provides a general overview of payment over public communication networks. It
highlights differences with payment in the physical world, at points-of-sale, in situations where
buyer and vendor ‘know each other’. It discusses issues and misconceptions with regard to
payment over Internet. It treats mobile payment from a high-level.
Chapters 3 and 4 continue with treating the context of bill payment. Chapter 3 serves as an indepth introduction to Chapter 4 on Electronic Bill Presentment and Payment (EBPP). In the
latter chapter we discuss various models for EBPP (Section 4.3) and examples of commercial
providers of such services in the Netherlands (Section 4.5). We pay attention to the
differences between the US and European market for EBPP.
Chapters 5, 6 and 7 discuss the context of electronic commerce, in particular the integration
of web-shops with Internet payment systems and the provisioning of outsourcing and valueadding services by Payment Service Providers (Chapter 5, Section 5.4 and Section 5.5
respectively). Chapter 5 thus concentrates on merchant support. In contrast, Chapter 6
considers support for consumers in e-commerce transactions: electronic wallets. In Chapter 7
the bridge between the merchant side (cash register) and customer side (electronic wallet) is
laid by discussing payment instruments that can be used for on-line electronic payment
transactions, in the context of e-commerce. We discuss credit cards, debit cards and cardbased electronic money.
Chapter 8 and 9 continue the discussion by considering the third payment context:
exploitation of electronic products (content, services). Chapter 8 concentrates on the specific
characteristics of this context that are relevant to payment (Section 8.2). Next it discusses
various scenarios for payment for such products by means of examples (Section 8.3).
Network-based electronic money is briefly discussed. Chapter 9 treats micropayment
systems.
Chapter 10 ends the document with overall conclusions.
For the reader’s convenience we have included a list explaining acronyms at the end of the
document, as well as an index of key words.
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
15
2 Payment over public communication networks
2.1
The issues
Initiating and executing payment over public communication networks poses various
challenges to the systems and operator’s of these systems, as well as challenges to human
factors as trust, security and fraud prevention and detection, and also to the organisation of
business processes. Various aspects will be treated throughout this document. Let us
highlight a few in the following.
2.1.1
Trust
When payment is executed over public communication networks, there is a physical
separation between buyer and vendor, between consumer and service provider. The two
cannot see each other. It is hard to establish an indication that the buyer is trustable, or that
the vendor will deliver the ordered products. It is hard to establish a trust relationship similar to
the one at the physical point of sale, where the two parties can see one another.
Buyer and vendor not only need to trust each other, they also need to trust the payment
instrument used to effectuate the money transfer. Considering payment over
telecommunication networks, they should trust the technology that implements a particular
electronic payment system and the operator(s) of that payment system.
Various companies and organisations have put quite some effort in creating and using new
technology that enables the establishment of the two types of trust relationships just
mentioned. One can think of the development of Public Key Infrastructure (PKI), quality
certificates for on-line merchants like the Webtrader-initiative of the Dutch consumer
organisation ‘Consumentenbond’ and new authentication mechanisms introduced by banks
(e.g. ABN-AMRO’s e.dentifier, Rabobank’s random calculator and Postbank’s mobile banking
initiative).
Trust is not only a matter of technology. On the contrary, trust is a human attribute, which is
hard to establish, differs among people and should be carefully managed. Branding is a
marketing instrument that plays an important role in creating and maintaining adequate trust
relationships. Technology can help in creating trust, but is not the main instrument for doing
so. As trust is a human attribute, technology is able to create trust only if the target group of
users of the technology is able to understand the level of security that the technology is
providing.
For example, consider the situation of a payment system operator that requires a pre-paid
deposit on a special account, like e.g. PayPal (see Section 5.2.1). Apart perhaps from early
adopters, users need top trust the organisation and its business operation in order to deposit
a (substantial) amount of money in such an account. If there are not sufficient legal
guarantees as to what happens to these deposits in case of bankruptcy of the operator, then
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
17
this may influence the trust users will have in the system. Offering adequate service to the
customers is yet another means to establish a trust relationship.
2.1.2
Cross-border payments
Focussing on Internet as a public communication network and electronic commerce and
service provisioning over Internet, we arrive at the next issue: cross-border payments. Internet
is a global initiative. Companies involved in commercial activities over Internet should
therefore consider the possibility of consumers from any location in the world, willing to
consume their products. It is a strategic – and individual – decision whether to accept all
customers (based upon trust…). If a company decides to also accept ‘foreign’ customers,
payment for products will involve cross-border payments.
There are essentially three types of solutions for cross-border payment:
· International bank transfer,
which is costly and cannot be initiated on-line (See [HiSt01] for more details on crossborder bank transfers).
· Credit cards,
which are less costly, have a substantial penetration in various countries, and are quite
effective in conducting online payment transactions (see Section 7.2). Large consumer
groups are principally excluded from their usage however (youth, lower incomes), and
those that can use them may not trust these instruments for use on-line.
· International collection services,
which let consumers pay using their domestic payment instruments (e.g. cash, domestic
bank transfer), often at delivery (see Section 5.3). Their support for on-line payment is
limited, if possible at all.
The variation in cross-border payment systems can be improved, as well as the efficiency of
available systems. It may be for this reason that cross-border payments currently attract quite
some attention from banks and firms outside the financial sector. The latter see an opportunity
in offering easy-to-use instruments and payment services that are more efficient than those
offered by the financial sector.
2.1.3
Direct payment
Guarantees – for payment and for product delivery – are closely connected to trust. The
higher the level of trust between buyer and vendor, the lower their need for guarantees. One
way of circumventing the offering of extensive guarantees is reducing the time frame in which
the full economic transaction takes place (recall Figure 1). If the exchange of product and
goods immediately follows each other or is even concurrent (‘pay-as-you-play’), then the
financial risks are smaller, and they are shared.
Direct payment, i.e. payment with immediate finality and immediate feed-back to both buyer
and vendor, would be a solution for circumventing guarantees or costly trust-enabling
technology. However, direct payment is hard to realise on a large – national or even
18
G
I G A
P
O R T
international – scale, when making use of the overall payment system as provided by the
financial sector. The very nature of the processing, clearing and settlement system in this
sector currently prohibits this (cf. [HiSt01]).
The only way in which direct payment can be realised at the moment is by using dedicated
closed payment systems, like pre-paid accounts at mobile operators, at banks (as in ‘Rabo
Direct Betalen’, see Section 7.3.1) or at special ‘Internet Payment Providers’ (as in the Jalda
model, see Section 5.2.2). This approach inevitably reduces the reach of such systems.
Large, internationally operating telecom operators such as Vodafone could play a role here
however, exploiting further their reach in communication services. Thus they could play a role
in cross-border payments as well.
It should be kept in mind however, that consumers typically have most of their purchasing
power, their money, on bank accounts. Trust is then an important issue (again) to incite them
to transfer funds from these accounts to the dedicated accounts in control of the operators of
direct payment systems. It is still an open question whether consumers are willing to do so.
Moreover, reloading the account directly when its balance reaches zero still requires direct
on-line payment systems, although the trust situation in this case is expected to be better than
on the open global Internet.
2.2
Misconceptions on Internet payment
We start with a discussion of a number of commonly heard assertions with regard to Internet
payments that require some moderation, because they are not always true. We based this
discussion on [Böhl01], Section 2.1.
1. Internet payments can evolve independently from the bank’s retail payment systems
This statement is not true. As will become clear from examples we present below, Internet
payment systems rely on bank retail payment systems at some phase, e.g. for making a
deposit in the case of account-based systems. Thus, understanding the financial sector’s
overall payment system is a prerequisite for a proper treatment of Internet (and mobile)
payments. [HiSt01] provides a detailed discussion of the Dutch bank payment system.
2. E-commerce requires Internet-specific payment systems
This statement does not hold in general. Some e-commerce applications, like selling content
or on-line games, may require small-value payments (or even micropayments), which cannot
be handled by current electronic retail payment systems. Often this will concern selling and
delivery of electronic – information – goods. However, if e-commerce is understood as selling
physical goods over an electronic channel (e.g. Mail Order/Telephone Order – MOTO or
Internet), then often ‘traditional’ electronic and even non-electronic payment systems are
sufficient. These systems may be even more popular than electronic (Internet) payment
systems. Take for example the popularity of the ‘acceptgiro’ in the Netherlands for settlement
of ordering and delivery of physical goods at web shops.
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
19
Retailers of physical goods that sell over the Internet and serve an international market, may
use Internet payment systems to facilitate cross-border payment, which is still a bottleneck for
international retail (e-) commerce. However, such retailers will often set-up an international
distribution network as well, including accounts at various national banks. Thus they reduce
the issue of cross-border payments to domestic payments. Various payment service providers
emerge that support localisation – both on Internet, e.g. Bibit Internet Payment Services and
NetGiro (see Section 5.5.1and 5.5.2 respectively) and in the physical world, e.g. GlobalCollect
(see Section 5.3).
3. Security is a fundamental problem for Internet commerce and payment systems
This is almost true. It is not security however that should be discussed, but the risk that each
party involved in a commerce transaction is willing to run. Having established an amount of
risk that is agreeable by both parties, this will have implications for both security measures
that need to be taken, as well as for payment systems that are appropriate in such a situation.
Moreover, a joint study performed by central banks has revealed, that the level of security of
Internet payment systems could be at the same level as that for existing payment instruments,
provided the designers and implementers take the necessary precautions ([LGKV00, p.44],
[BIS96]).
4. Credit cards are an insecure payment instrument on the Internet
This is not entirely true. Cardholder authentication is relatively weakly secured: only a sixteen
digit card number, expiry date and (in some cases) a Card Validation Code (CVC; see Section
7.2) are required. The most risky factor for loosing this data to criminals is not the network
2
(Internet) but the merchant . Note however, that credit card transactions at POS in the
physical world create a risk of loosing the valuable card number and expiry date as well: these
numbers, and the cardholders name, are also present on the printed receipt from the POS
terminal. The Internet transaction protocols SET and its weaker form 3D SET have been
designed to hide this valuable data for the merchant.
2.3
The roles of mobile communication in payment
We identify three major roles that mobile communication networks and devices can play in
payment:
1. the mobile device as a payment terminal in the physical world,
where the device replaces the terminals for electronic funds transfer at points-of-sale
(EFTPOS).
2. the mobile device as a payment terminal in the virtual world,
for the payment of electronic service delivered over a channel different from the mobile
network (like Internet, cable…).
2
According to discussions at the ‘Telco-Finance Integration’ workshop preceding the IIR Conference ‘Next
Generation Billing Systems’, December 2000, in Rome. It is hard to obtain exact figures on credit card fraud.
20
G
I G A
P
O R T
3. the mobile network as a direct payment channel,
for electronic content and services consumed on the mobile device.
2.3.1
Payment terminal in the physical world
In order to fulfil the first role, terminals need to be able to interface with existing payment
instruments for retail transactions at points-of-sale, such as debit cards, credit card and smart
cards containing electronic money. Conceptually, there are two options: (1) use an external
multi-purpose card reader, or (2) integrate a card reader into the mobile device. The first
option comes within range of realisation through the development of a European standard for
card readers, FINREAD, see [HiSt01] for details. The second conceptual option has been
rejected by the mobile phone manufacturing industry. According to [Mobe01, p.18] the major
phone manufacturers (e.g. Nokia, Ericsson and Siemens) have indicated that they will not
produce dual slot phones. One of the suggested reasons is that the integration of a card
reader into phones puts too many limitations on phone design and size. In this way the
discussion whether there will be dual-slot (i.e. with reader) or dual-chip phones has been
finished in favour of dual-chip phones.
Another possibility would be using the mobile phone or – more generally – the mobile device
as the platform for a secure electronic wallet that contains payment instrument details, such
as card numbers. It is an issue however, who is in control of what part of the device. The SIM
(for communication) in a mobile phone is provided and owned by the network operator. The
wallet could reside on a separate chip in the mobile phone under the control of the issuing
financial institution(s), provided the mobile phone manufacturers are willing to produce dualchip phones. If such functionality is incorporated into the SIM (as Postbank has done in its
mobile banking application in co-operation with Telfort and Siemens), the financial institutions
need to have various bi-lateral agreements with the mobile network operators.
Example: refuelling a car using the mobile phone
Nedap, KPN Mobile and BP are currently running a pilot in the Netherlands with Nedap’s
‘Mobile Pay’ mobile phone payment system. The pilot started in October 2001 with 1500 users
and three BP petrol stations, in co-operation with KPN Mobile. The mobile phone (GSM) is
3
used for refuelling a car , i.e. for identifying and authenticating the customer of the petrol
station.
The customer has to dial a special number and enter the number of the petrol pump and a
PIN code on his mobile phone. After successful authentication the filling station is authorised
to provide fuel. The charge is collected from the customer’s bank account by means of direct
debit. The customer can get a statement of his transactions via the Internet.
4
3
According to De Volkskrant, ‘Experiment met tanken betalen via mobieltje’, October 20, 2001, Economy
supplement.
4
See also http://www.bp.nl/
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
21
2.3.2
Payment terminal in the virtual world
In this case the mobile device is used as an instrument for authentication and authorisation of
the payment transaction, as a relatively secure device for entering payment information.
Systems typically use a ‘call-back’ scenario. The user provides his mobile phone number after
which the mobile device can be contacted through e.g. a voice response system, SMS, or –
with the arrival of ‘always on’ Internet connectivity through GPRS and UMTS – by means of
instant messaging techniques. The user then receives information on the payment transaction
that was initiated through a communication channel different from the mobile channel. The
mobile phone number and entering a PIN code authenticates the user. A confirmation by
pressing a button on the mobile device finally establishes payment authorisation.
The actual transfer of money can be realised through various ‘traditional’ payment
instruments, such as direct debit or a credit card charge, or from a dedicated account.
Example: Paybox
Paybox is a mobile payment system offered by Paybox.net AG that was launched in Germany
5
in May 2000. Major shareholder is Deutsche Bank (50%) . The system supports real and
virtual point-of-sale transactions as well as person-to-person transactions.
The system requires new users to register with Paybox, after which they obtain a PIN code.
When using Paybox in a payment transaction, the user communicates his phone number to
the vendor. The latter communicates this number and the price of the product to be
purchased to Paybox, after which Paybox calls the buyer and asks for payment authorisation
by means of the PIN code. The vendor’s name and amount are mentioned in this request.
After authorisation Paybox informs Deutsche Bank to settle the payment transaction through a
type of direct debit.
2.3.3
Direct payment channel
In this case the product delivery channel and payment channel coincide. Both actions take
place over the mobile network. Concurrently or almost immediately after each other. The
situation is similar to that on fixed Internet, where consumption and payment may take place
through a single Internet connection from the user’s personal computer. The difference with
fixed Internet is the limited computational capabilities of the terminal and the varying location
(roaming) of the user.
Example: payment over WAP – KPN Mobile and Bibit
KPN Mobile and Bibit Internet Payments jointly developed a payment method for WAP, and
announced it in May 2000. The system is used in the M-info service of KPN, in the online
shop. Upon ordering, Bibit offers the customer choice between several payment systems. By
5
According to the electronic Payment System Observatory’s Inventory database:
http://epso.jrc.es/cfapp/invent/details.cfm?uid=80
22
G
I G A
P
O R T
now, the assortment is close to that on the Internet. When Bibit has handled the payment, it
signals the shop that delivery can go ahead. First retailer to use the system is hotorange.com, who has offered WAP payment from June 2000.
2.4
Merging of payment flows
The consumer seems to be surrounded by providers that offer the basic services in western
life, such as gas, electricity, water, cable television, Internet and telecommunication of various
types (e.g. PSTN, ISDN, GSM, GPRS, …), financial, insurance, governmental and municipal
services, etcetera. During the past few years in the Netherlands, many of these providers
have joined forces with regard to billing and payment collection, e.g. cable television and
municipality in collecting charges and taxes.
Each of the mentioned providers with recurring customer contact can seek the opportunity to
offer their customer contact as a contact opportunity to other (on-line) service providers or
vendors. They can start to act as an intermediary with regard to billing and payment between
buyers and vendors. The payment flows of service providers with recurring frequent customer
contact can merge with those failing such an opportunity. They first need to be aware,
however, of the credit risk that accompanies such an approach.
Development: Open Service Access (OSA) – Parlay platform
6
The Parlay Group , which is an open multi-vendor consortium of ICT companies including
(among many others) Alcatel, Compaq, Cisco Systems, Ericsson, IBM and Lucent
Technologies, is developing a platform for Open Service Access. That is, developing
Application Programming Interfaces (APIs) that enable applications to operate across multiple
networking platform environments. One of the developed APIs enables the reservation and
capture of funds in e.g. pre-paid accounts, and charging to the cost of a telecom billing
system (e.g. see [ETSI01]). Note that this applies to new applications or services provided by
third parties that leverage (or operate over) the mobile network.
6
See http://www.parlay.org
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
23
3 Overview of bill presentment and bill payment
3.1
Introduction
The bill or invoice represents a financial claim of a company on a customer. It is associated
with a payment that is due. The latter part distinguishes a bill from a statement or notice: a bill
must be paid within the prescribed time period, or other (legal) measures will be taken in order
to establish payment.
7
Bill/Invoice :
An electronic or paper document sent to a customer associated with a payment
due.
Statement/Notice:
An electronic or paper document sent to a customer/agent that does not have a
payment due associated with it.
‘A bill should be paid in time’ is probably a better wording: late payment is part of a country’s
payment culture and varies over countries (see Figure 5). According to the European
8
Payment Survey that was executed for Intrum Justitia , the main causes for late payment are
(1) intentional delay as a cheap means of obtaining credit (‘supplier credit’, in 35% of the
considered cases), (2) financial difficulties of the debtor (33%), and (3) administrative
inefficiency (e.g. errors; 16%). Another cause of late payment is disputes over the bill (5%).
The first and second main cause for late payment cannot be addressed by means of billing
technology, because they depend on the way firms do business. A reduction of supplier credit
is harder to achieve: it requires a change in attitude. The others can.
Source:European Payment Survey (1995, NOP for Intrum Justitia.www.intrum.com )
Figure 5: Late payment in Europe
7
8
From ‘Glossary of Terminology’ of eBilling.org: http://www.ebilling.org/glossary/default.htm
See http://www.intrum.com
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
25
A well-designed and executed billing process may reduce both the number of disputes and
administrative errors. The latter can be achieved by limiting the number of human interactions
in the bill payment process, e.g. the act of copying payment details from the bill to an input
facility of a financial management system or e-banking application. The number of disputes
that result in late payment can for example be reduced by offering various Customer (Self-)
Care services.
3.2
A functional reference model for billing and bill payment
Figure 6 presents a functional model for the financial settlement of economic transactions by
means of billing and bill payment. It is based upon [JBHS01]. Billing consists of the
preparation of the bill, tailored to the customer by adding personal information or providing
special discounts, and the bill presentment function that realises that the payer will receive
and review the bill. Sent bills and incoming payments are matched in the reconciliation
function. This is a highly important function. Much inefficiency in the billing and bill payment
process is created by exception handling in the reconciliation function, because often this
requires manual labour. Payers could for example have made a mistake in copying the
appropriate payment references.
Payer’s
financial
handling
Financial Settlement
Billing
Bill
preparation
charging
data
billing
data
Bill
presentment
bill
bill
Authorisation
billing info
to account
& process
management
Reconciliation
payment
info
Bill
payment
payment
initiation
payment
indication
Legend:
Function
Input
Output
Information duplication
Figure 6: Functional reference model for billing and bill payment (after [JBHS01]).
The “Payer’s financial handling” function may be simple, e.g. placing a physical signature, but
can also be complicated: the administrative functions and policies within a company that deal
with accounts payable. The precise content of this function is beyond our scope. For the
discussion in this document it suffices that the function results in payment authorisation and
initiation, based upon the bill as input.
3.3
Differences between B2C and B2B billing
Billing, or invoicing, faces different requirements in the business-to-consumer market than in
the business-to-business market. Legislation and regulations differ in these two markets, for
example with regard to tax handling (e.g. Value Added Tax – VAT). In the Netherlands tax
26
G
I G A
P
O R T
regulations regarding B2B invoices are much stricter than those for B2C bills. However, the
regulations (for B2B and B2C) vary over various European countries, thereby complicating
international billing. The European Union is currently considering harmonisation of these
regulations among its member states.
Also the complexity of the administrative processes differs substantially, together with the
relative number of disputes over received bills. In B2B situations there is much more need for
exception handling. It is estimated that 40% of B2B billing requires resolution or adjustment
[Mari00]. Moreover, in a B2B setting bill processing may cross various intra-organisational
boundaries, and may cross the hands of multiple employees as well. Authorisation of
payments is typically confined to a small number of employees however, which complicates
the interaction between the payer’s financial handling function (Figure 6) and bill presentment
and payment. Consumers do not have a complex financial administration in general. This
makes bill processing much easier.
The importance of the distinction between B2B and B2C is further stressed by the use of
different terminology. In the literature the term ‘bill’ mainly refers to the B2C setting while
‘invoice’ indicates a B2B setting. See for example [CEBP01] and [Mari00]. It should be noted
that this subtle distinction may be less apparent in product offerings by commercial service
providers or system vendors.
3.4
Instruments for bill payment
Currently in the Netherlands there are three common ways for paying paper bills: (1) by
means of credit transfer between bank accounts, (2) by means of ‘acceptgiro’ (now ‘euro9
acceptgiro’) and (3) by means of direct debit. In the B2C market segment, acceptgiro and
direct debit are particularly popular. The acceptgiro is convenient in situations where there is a
one-time customer relationship or when the merchant or service provider is willing to give the
customer the initiative for starting the payment transaction. In a periodic, recurring customer
relationship direct debit is often used. It is also used in situations where the vendor prefers to
keep the initiative in payment initiation. Banks prefer the use of direct debit as it is the
cheapest instrument for bill payment.
Both acceptgiro and direct debit have the advantage over bank transfers as they reduce the
number of administrative errors. The first because of the pre-printed payment information that
it contains; the second because the process of sending the collection requests to Interpay can
be automated. Credit transfer between bank accounts is more costly in the end than
acceptgiro or direct debit, because reconciliation may be complicated by incomplete or
missing payment information, like payment reference or an incorrect amount.
The bill payment instruments differ further in transactions costs (for the biller), in the payer’s
convenience, payment finality and who initiates and controls the payment process. In the first
9
The payment instruments are discussed in detail in [HiSt01].
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
27
two methods the payer initiates and controls payment. In the last the biller initiates payment,
while biller and payer have shared control: the payer has the so-called ‘Right of Reversal’
within a time frame depending of the type of direct debit used (see [HiSt01] for details, Table 1
provides an overview). Of these three methods, only the acceptgiro is directly linked to bill
presentment, since often the acceptgiro is physically attached to the paper bill.
Table 1: Comparison of payment methods for physical bills
Payment
method:
Payment
initiator:
Control: Payment
finality:
Payer’s
convenience:
Credit transfer
Payer
Payer
After processing
Low
Acceptgiro
Payer
Payer
After processing
Medium
Direct debit
Biller
Shared
After 5-30 days
High
3.5
Bill distribution and presentment: print and mail services
Firms that frequently send out large mailings or many invoices in short time periods often
outsource these activities at providers of so-called print and mail services. Examples of such
large volume recurring billers are telecom and utilities, banks (account overviews) and charity
organisations. The providers of print and mail services have the equipment to print large
volumes of paper, prepare the mailings, add promotional material, et cetera. They often also
print acceptgiros, which are attached to the bill and sent to the payer.
There are several hundreds of print and mail service providers active in the Netherlands. PTT
Post Print & Mail, part of the TNT Post Group is one of them. Another is AddComm Direct
B.V., which has a long-term strategic partnership with Bluem, a Dutch provider of Electronic
Bill Presentment solutions (see Section 4.5.2).
3.6
Developments in bill presentment and bill payment
Recall that a billing approach to the financial settlement of economic transactions creates the
problem of late payment (Section 3.1), mainly because of the attitude of companies (‘supplier
credit is easy and cheap…’), but also because of administrative errors and disputes over the
bill. The central problem is that billing moves the initiative for payment initiation to the payer
instead of the biller. The payer waits till he finds it convenient to pay. The payer makes
mistakes in the payment information that is attached to the payment order, or the payer waits
with payment until the dispute has been settled.
Thus late payment may be reduced by using a payment instrument for bill payment that
leaves the initiative with the biller: direct debit. Changing from acceptgiro to using direct debit
also creates a cost reduction for large volume, recurring billers. In fact, printing acceptgiros is
subject to precise conditions (set and verified by Interpay and Postbank) in order to establish
efficient automated processing. Specialist knowledge and high quality equipment is needed.
Therefore it is more costly than normal printing.
28
G
I G A
P
O R T
When using direct debit a statement is still sent. Therefore it is then only a small step to
perform electronic presentment of this statement. The number of administrative errors can
also be reduced by means of direct debit. Currently banks are also looking at the possibility of
using digital signatures for signing electronic mandates for direct debit (cf. [HiSt01]), on-line.
In that way direct debit becomes more convenient for on-line payment of bills as well.
3.6.1
A digital acceptgiro
Direct debit seems to be the ultimate solution for bill payment. However, many consumers
seem to value the concept of the acceptgiro as well, which gives the consumer the initiative of
payment initiation, thereby keeping them ‘in control’. The acceptgiro concept also includes the
idea of pre-printed payment information, which reduces the number of administrative errors.
Moreover, the payment reference on the acceptgiro facilitates the reconciliation process. The
acceptgiro is paper-based however. As the trend is towards electronic paper-less payment
systems, the acceptgiro – with its sense of control – needs an electronic substitute.
Currently there are no (de facto) standards for the electronic representation of the payment
information contained in a bill, like the acceptgiro for paper bills. The Dutch banks and
Interpay have the initaive to come with a standard however: the digital acceptgiro, or
@cceptgiro. The idea is that the payment information is sent to the payer electronically
through intermediaries (banks) in the financial sector, while the bill or statement is sent to the
payer through any other channel of the biller’s choice (see Figure 7). That is, the bill may still
be paper-based if that is more convenient. Electronic Bill Presentment (EBP) may be an
electronic option.
Bill Payment Service Provider
Payment
service
Digital accepgiro
Digital
accepgiro
(optional)
Customer
Payment channel
hyper linking
Biller
Bill presentment
channel
Electronic
bill presentment
service
Electronic Bill
(Electronic) Bill Presenter
Legend
Role
Data flow
Data object
Service Provisioning
Figure 7: The envisioned scheme for the digital acceptgiro
The digital acceptgiro need not end-up in the domain of the payer: it may remain on a server
within the domain of control of a bank, providing special services for bill payment (including
feed-back to the biller on an @cceptgiro’s payment status). The EBP service and the bill
payment service are crosslinked, such that Customers can easily switch between bill details
and payment details, while these two are coming from different sources (web sites). If
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
29
required however, the digital payment information in the form of the @cceptgiro may be
loaded into financial administration software or home-, web- and e-banking applications.
3.6.2
Electronic Bill Presentment (e-Billing)
Electronic Bill Presentment (EBP) allows consumers
10
to receive and review their bills
electronically, in particular over the Internet. ‘Electrifying’ paper bills in itself does not
contribute much to reducing late payment. It may reduce the operational cost of printing paper
bills, but an electronic biller needs to maintain an additional ICT system for EBP instead.
Moreover, consumers will not instantly move towards the use of this new technology. In fact,
[Mari00] states that ‘…billers have spent much effort getting bills online, but less on
developing online bill payment as a consumer habit. … The …expenses required to
implement online presentment of bills represent perhaps only 20 percent of the effort required
to make it a consistent practice.’
The main value-adding aspects of EBP are in its combination with other functions, to the
benefit of both EBP and these functions, e.g.: (1) Customer Relations Management (CRM),
(2) bill consolidation and (3) online payment services. The combination of EBP with a
payment function is commonly called Electronic Bill Presentment and Payment (EBPP). The
combination of EBP with CRM is sometimes referred to as e-billing. Experiences with EBP
show that there are less late payments due to convenience in payment: the payer only has to
click a button to pay.
Providing good Customer (self-)Care services through the EBP channel may reduce the
number of disputes and thus late payment. An example of e-billing is the Web site of KPN
Telecom, where subscribers can review their current and past phone bills. The service offers
additional functionality for analysing a bill (e.g. call with the longest duration, most called
phone numbers, et cetera).
Moreover, EBP provides new means for maintaining customer attention to corporate web
sites, enable interactive marketing and establish extended customer care. EBP can offer a
single point of entry for all financial and related transactions with customers, offering the
company a unified customer view. This point of entry can be personalised as well.
3.6.3
Bill consolidation and payment services
Bill consolidation and payment sites offer consumers the opportunity of organising the
received bills. Some consolidators even scan paper bills and include those in their list of
electronic bills. Users can schedule bill payment. In this way late payment is reduced by
providing better administrative facilities to consumers. The payment function reduces
administrative errors and the usage of paper-based instruments.
10
The corresponding concept in the Business-to-Business market is referred to as Electronic Invoice Presentment
(EIP).
30
G
I G A
P
O R T
Bill consolidation and payment services are particularly popular in the US. According to
predictions, US consumers would like to pay all their bills at one web site. According to
Yankee Group the main arguments for US consumers are the convenience of not having to
11
write checks (28.7%) and saving time (14.9%) . Candidates for such primary sites (in the
12
13
U.S.) are Internet portals like America Online (AOL) and Yahoo! , and OnMoney .
AOL and Citigroup formed an alliance that makes AOL a candidate for a primary bill payment
web site. Citigroup’s payment services are made available through all channels of AOL
(AOL.com, CompuServe, Digital City, Netscape Netcenter and AOLTV). Citigroup will act as a
clearinghouse for online purchases, but also for person-to-person money transfer. The billpaying services provided at Yahoo! and OnMoney, which are web sites that allow users to pay
14
bills using a web interface, are powered by Paytrust’s technology .
Paytrust.com provides users with an on-line bill payment service that allows them to instruct
Paytrust.com to handle all of their paper-based bills. When such bills arrive at Paytrust.com,
they are scanned and entered into the system. Using a web-based interface, users may
nominate bills to be paid by specific accounts. The system allows users to completely
automate bill payment, while also allowing conditions to be attached to bill payment. For
example one could imagine a scenario such as: ‘if the source of the bill is a restaurant and the
cost is less than US$ 100, then pay it automatically’. Paytrust can also interface with many
major banks, thereby allowing the system to obtain e.g. the user’s account balances for a
complete overview of personal finance. The payment data created by Paytrust may be
imported into personal financial software such as: MS Money, MS Excel and Quicken.
In the Netherlands ‘Privver’ is a bill consolidation and payment service (see Section 4.5.3 for
more details).
In the following chapter we treat EBP in further detail.
11
Nora Macaluso, ‘Report: Online Payment Gaining Ground’, in E-Commerce Times, October 15, 2001. Available at
http://www.ecommercetimes.com/perl/printer/14151/
12
‘BillPay’, see http://bills.yahoo.com/
13
‘BillCenter’, see http://www.onmoney.com/banking/billpay/
14
According to the banners’Powered by PayTrust’ on these sites.
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
31
4
Electronic Bill Presentment and Payment
4.1
Introduction
Recall that the business market for bill presentment differs from the consumer market
(Section 3.3). Accordingly, we follow the distinction between ‘bills’ and ‘invoices’, and between
EBP or Electronic Bill Presentment and Payment (EBPP) and their counterparts in the
business market: Electronic Invoice Presentment (EIP), and Electronic Invoice Presentment
and Payment (EIPP) (following [CEBP99], [CEBP01]). Our focus is on the consumer market,
on EBP and EBPP. EBP can also be seen within a broader setting: as a specific variant of
electronic document or legal document presentment. We do not pursue this approach in the
sequel.
4.2
The impact of cultural aspects
Providing EBP services on-line is a growing field of commercial activities in which many large
companies participate. Organisations, like the Global Billing Association (telecom sector) and
the National Automated Clearing House Association (NACHA – US financial sector), have put
the subject on their agendas for research, standardisation and discussion. As the market is
growing, new firms enter the market. The competition is growing.
The uptake and level of success of EBPP services is closely related to the payment culture
and payment infrastructure of the countries in which it is applied. A solution – or model – for
EBPP that is successful in one country need not be successful in another. US providers of
EBPP services have experienced this observation in reality. Their entrance on the European
market has not been as easy as they expected. Currently these companies tend to co-operate
with European counterparts in order to get a grip on the cultural differences of which they
were not fully aware initially.
15
The US market for EBP(P) differs from the European market. To mention a few differences:
· The efficiency of the overall payment system;
EBP combined with electronic payment functions reduces costs when compared with
paper-based instruments: invoicing and cheques in the US. The payment system offered
by the financial sector in the US is less efficient than many systems in Europe, the
Netherlands in particular. The Dutch payment infrastructure is one of the most efficient in
the world. Therefore the realisation of cost reductions by means of EBP(P) is less apparent
to billers.
15
According to Anachron,at IIR Conference ‘E-billing and Customer Care Management, Schiphol, The Netherlands,
March 20-21, 2001.
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
33
· The availability of convenient bill payment instruments;
In the Netherlands there are sufficiently many convenient payment instruments (from the
payer’s perspective) that can be used for bill payment. There are direct debit services in
various variants (see [HiSt01] for details) and the acceptgiro. In the US inconvenient paper
cheques are commonly used still.
· Heterogeneity in language, culture regulations and currency;
The European market is a heterogeneous market because of the various languages,
cultural differences, variations in legislation and regulations and different currencies,
although the arrival of the euro in a large part of Europe will greatly remove the latter
obstruction.
· Security requirements;
In Europe users, financial institutions and legislators have different security requirements
on EBP systems than in the US. For example, a simple login and password would be
sufficient protection for US user’s and banks, while in Europe this type of user
authentication is considered not sufficiently secure. Additional techniques are required to
obtain a higher level of security (e.g. one-time passwords, challenge-response systems
using the bankcard and PIN-code).
Figures (for the U.S.A.):
Manually sending bill (cost):
$1.00 - $1.50
Manually sending bill with error (cost):
$2.00 - $3.00
Number of bills/month that consumer receives:
17
Manually paying bill by consumer:
10 minutes
Total time/month for consumer:
3 hours
Manually processing payment (cost):
$1.00
Savings of EBPP on bill of $100:
$1.90
Total cost of U.S. payment system:
3% of Gross Domestic Product
Cost of check transaction:
50-100% more than electronic
payment
U.S. number of C2B billing transactions 1998
15 billion
U.S. number of B2B billing transactions 1998
12 billion
Sources: Wall Street Journal, March 1999; Banking Strategies, November 1998, and McKinsey & Co.
4.3
Models for EBP
Some EBP players try to control all aspects, like architecture and service provisioning by
using proprietary interfaces with billers. In the U.S., CheckFree used such a closed-system
approach. It had a leading position in the past (1997), with an 80 percent share of the
electronic bill payment market [OSS+98]. Others are developing and using open systems,
based on standards. OFX (see Section 4.6.1) and GOLD (see Section 4.6.2) are two
standard-based EBPP consortia operating in the U.S. They are now being replaced in favour
34
G
I G A
P
O R T
of IFX (see Section 4.6.3). In the middle there are companies that control the overall
architecture of the EBPP system, but let others players exploit parts of the EBPP value chain.
Parties in this value chain are e.g. billers, biller service providers, banks and customers.
TransPoint, a company owned by Microsoft and First Data Corporation, follows this strategy.
Apart form the system approaches (open or closed), several models for EBP(P) have been
developed, which we shall now discuss. We base our exposition on [OSS+98], [NACH99],
[CEBP99], [Mari00], [HJTW00], [CEBP01], and [AuKi01] (chronological order). Terminology
16
differs among the various sources. We followed that of eBilling.org .
Commonly, the following elementary roles are identified:
· Biller,
A company or organisation that sends a bill or statement to a Customer.
· Customer,
An individual or company that receives goods or services which are subject to bills or
statements.
· Bill Receiver,
A person or company that receives a bill or statement for goods or services ordered by a
Customer. A Bill receiver and Customer may be different.
· Biller Service Provider (BSP),
An agent of the Biller that provides EBP services to the Biller.
· Customer Service Provider (CSP),
An agent of the Customer that provides a single point of entry (or one interface) for
Customers, e.g. for enrolment, for reviewing bills and payment status.
· Bill Consolidator,
A Biller Service Provider that consolidates bills from other Biller Service Providers or Billers
and delivers them for presentment to the Customer Service Provider or directly to the
Customer.
The following models have been identified:
Direct Model
In this model, a single firm (in the role of Biller) offers online bill presentment and payment
directly to a customer (see Figure 8). Thus, the Biller incorporates an electronic bill
presentment capability into its corporate web site. Consumers have to enrol into the EBP
service of each of the billers with which they are involved separately. A Customer Service
Provider may take care of the enrolment process for the various billers. The Biller may
outsource the EBP service itself to a third party, the Biller Service Provider. Outsourcing is
typically transparent for the Customer.
16
G
See http://www.ebilling.org/glossary/default.htm
I G A
A B P / 2 0 0 1 / D 0 . 1
B
35
Biller
EBP customer services
(review, customer care)
In-house
Customer
Outsourcing
Biller
EBP system
outsourcing
Biller Service
Provider (BSP)
Service provisioning
Service payment (money flow)
Figure 8: Direct Model for Electronic Bill Presentment
Direct billing helps maintain contact with Customers and provides advertising and crossselling opportunities without an intermediary. A Direct Model is likely to be successful in a
biller-to-business relationship where the biller represents a large part of the total volume of
bills the customer (payer) receives. Opinions differ on whether this makes direct models most
suited for Business-to-Business billing [OSS+98], or for Business-to-Consumer payments.
Service Provider Consolidation Model
In this model a central service provider collects (‘consolidates’) bills from various Billers so
that a Customer of each of these Billers has a single point of access to all bills of all Billers
(see Figure 9). There are two versions of this model, depending on the level of bill detail
information stored at the central service provider, the Bill Consolidator:
· Thin Consolidation Model,
Where only a bill summary (‘thin’) is available at the Bill Consolidator, while the bill details
remain at the Biller, and can be presented to the Customer on request. Thus the Bill
Consolidator act as a ‘portal’ to bills from various billers with added administrative
functions for organisation or payment scheduling. The Biller still has the opportunity of
direct interaction with the Customer, which is useful for CRM for example. A bill summary
may be distributed to (multiple) Bill Consolidators and/or CSPs.
· Thick Consolidation Model,
This model is similar to the Thin Consolidation Model, except for the Biller forwarding both
bill summary and detail to the Bill Consolidator. In the Thick Provider Consolidation Model
it is also possible that the remaining printing services are taken over from the Biller.
(enrolment, high level review)
Biller
Bill
Consolidator
Customer
Biller
(details, customer care)
EBP system
outsourcing
Biller Service
Provider (BSP)
Service payment (money flow)
Figure 9: Thin Service Provider Consolidation Model for EBP
36
G
I G A
P
O R T
Customer Consolidation Model
In this model the Biller directly delivers the electronic bill directly to the Customer, i.e. the bill
data is transferred to the Customer’s domain of control, for example through email. After
reception the Customer is able to import the bill data into their Personal Financial
Management System (PFMS) or home-banking application for further processing.
A comparison of models
Looking only at current practices in the US the Direct Model and the Thin Provider
Consolidation Model seem to be used (see [Mari00]). These observations hold for the
Netherlands – and Europe – as well. Most players in the US are using the Thin Consolidation
Model. The Direct Model is only feasible for large companies with a large enough volume of
recurring bills and customer base willing to use the electronic services to justify the
investments required for in-house deployment of bill presentment systems.
The Thick Provider Consolidation Model has the drawback that the biller loses much of the
potential interaction with its customers and hands-over (too) much control to the BSPs and
CSPs. It offers opportunities to develop the market however (examples in Norway). As soon
as the market is more mature – i.e. EBPP facilities at the biller’s site – the BiSP can make a
shift to the Thin Model.
The problem with the Customer Consolidation Model may be the electronic delivery of the bill
and the bill’s integration into the PFMS. Open and commonly used standard bill formats or
electronic formats for payment information are required in that case, and the availability of
PFMSs conforming to these formats.
It is also possible for a firm to feature aspects of both the Direct Model and the Consolidation
Model in its service offerings. A Dutch example of such a combined offering is Bluem (see
Section 4.5.2). The Consolidator and combined model are more complex than the Direct
Model. The factors affecting this complexity centre around: who "owns" the customer
relationship (biller, consolidator or CSP – e.g. the Internet portal), who processes the
payment, who manages the data, how do consolidators interoperate, and how do
consolidators translate bill data in multiple formats?
4.4
US players
In the U.S. EBP is quite successful. The providers of EBP services there can be divided into
two groups: (1) financial institutions (banks) and (2) non-financial institutions [AuKa01]. The
Spectrum consortium
17
is leading in the first group. Recently, also MasterCard entered the
EBPP scene [Mari00]. CheckFree and TransPoint are the main players in the second group.
Players in this group offer EBP services to e.g. Internet portals as Yahoo! and America
Online, which act as bill consolidators for consumers. These portals obtain payment services
from other players in order to realise electronic bill payment and full EBPP functionality.
17
G
Consisting of Chase Manhattan, First Union and Wells Fargo; see http://www.spectrumebp.com
I G A
A B P / 2 0 0 1 / D 0 . 1
B
37
Competition comes from home banking software companies (Home Financial Network, Edify)
that aim at customers of small to medium-sized banks, bill publishing companies
(International Billing Services, Princeton Telecom, Electronic Funds and Data) that offer paper
and electronic bill publication, and others that mostly use third-party payment (EDOCS,
Netdelivery, Intuit, Novazen, BlueGill, NCR, Electronic Data Systems).
The second group of non-financial institutions is currently leading in the market. A survey
performed in late 1999 by Gartner Group among 173 large U.S. companies indicated
however, that these companies would prefer their banks to act as EBP service provider. They
seem to be turning to the non-financial institutions for solutions instead ([AuKa01], [Lita00]).
Table 2: US providers of EBP solutions.
System vendors:
Application Service Providers (ASPs):
Alysis
Iplanet
BillServ.com
CheckFree
Avolent
Checkfree
Derivion
Pinceton eCom
Edocs
Portal
TransPoint
Solant
TransPoint
YourAccounts.com
4.5
Dutch providers of EBP solutions and services
In this section we focus on the players active in EBP in the Netherlands. Anachron and Intrum
Justitia are such players that are also active throughout Europe. Bluem and the TNT Post
group with Privver focus on the Netherlands.
4.5.1
Anachron
Anachron: ‘Pulse Suite’
18
is a Netherlands-based company, founded in 1999, that specialises in e-Billing
and customer interaction solutions. They state that “Web-enabling … customers’ financial and
personal information” is their core business. It offers the ‘Pulse Suite’ of electronic bill
presentment and customer care solutions, both for B2B (Pulse Business Advantage) and B2C
(Pulse Consumer Advantage).
Their solution is platform-neutral. For example they showed EBP over a mobile platform
developed by AtoBe
19
at the CeBit in Hannover in March 2001. The system uses 1024-bit
Virtual Private Networks for the transfer of data to and from customers. Sensitive data is
completely encrypted before it is stored. Anachron's solutions are based on open standards
(e.g. XML, J2EE, 3DES, X.509).
18
19
See http://www.anachron.com
Press release, Anachron-AtoBe, ‘Anachron and AtoBe Deliver Mobile e-Billing’, March 22, 2001.
38
G
I G A
P
O R T
4.5.2
Bluem
Bluem
20
is a Netherlands-based company founded in 2000. It acts as an Application Service
Provider (ASP) of EBPP and Interactive Customer Care (ICC) solutions to medium to large
size enterprises, with a focus on the first category. Bluem uses Avolent’s Billcast™ software
suite for the realisation of its bill presentment services (see Section 4.7.1 for a product
description). Bluem supports both the Biller Direct and the Thin Consolidation Model.
Bluem also launched a bill payment service. Initially it was conceived to use PayNet, a Swiss
system for Internet payments. As PayNet met problems in reaching a sustainable business,
21
that initiative was ‘unplugged’ however (april 2001) . Currently, Bluem’s payment service
supports credit card payments and direct debits. Their system automatically sends payment
reminders.
4.5.3
TNT Post Group: ‘Privver’
Privver
22
is a digital mail box of the Dutch PTT Post (part of the TNT Post Group – TPG) that
targets the consumer market. In the past, companies could direct their flow of mail, like bills
and statements, through PTT Post Print & Mail. Based upon data delivered in digital format
this mail was printed and sent physically to the recipient. Privver offers the possibility to send
this mail electronically as well.
The recipient receives an e-mail notification from Privver if a new piece of electronic mail
arrived in their Privver mail box. This mail box resides on a secure server in the TPG domain.
The mail can then be accessed on-line (thus also from abroad). Apart from receiving
electronic documents, the recipient can archive mail and pay bills as well with form of direct
debit. To that end Privver uses direct debit with electronic authorisation. When subscribing to
Privver, the mail box holder authorises Privver (in relation to his bank) to debit his bank
23
account after clicking the ‘Pay’ button . With this solution Privver is part of the money flow. It
runs through Privver to the biller, because Privver is the party that requests the collection of
the direct debit.
A similar initiative has been launched in Austria: ‘bezahlen.at’, by the Őstereichische
Postsparkasse ([Böhl01], footnote 9, p 22).
4.5.4
Intrum Justitia
Intrum Justitia
24
is a Europe oriented provider of Receivables Management Services. In
particular they offer sales ledger services, debt collection (consumer, commercial and
international) and debt surveillance. The company was founded in Sweden in 1923. In the
20
See http://www.bluem.nl
See Innonet New, April 9, 2001: ‘Aus für PayNet’, http://new.innonet.ch/all_active/sp_d/news/news.asp?ID=597
22
See http://www.privver.nl
23
According to the press release, http://www.tpg.nl/pressoffice/pressreleases/070501_pttpost_privver.html
24
See http://www.intrum.com
21
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
39
1980s and 1990s it expanded its activities into Scandinavia and the rest of Europe. Currently
it has a presence in over 20 European countries.
As part of the sales ledger services they offer (among others) invoicing and payment
matching (with bills). Intrum Justitia has a strategic partnership with NetGiro (see Section
5.5.2) for expansion in Europe with regard to EBPP. Intrum Justitia uses NetGiro’s ‘G-Bill’
solution.
4.6
25
Standards
In the (outsourced) Direct Model and the Service Provider Consolidation Model bill data needs
to be exchanged between the Biller and the organisations that fulfil the roles of Biller Service
Provider or Bill Consolidator (see Figure 9). In this section we discuss three standards are
used for this purpose: OFX, GOLD and their successor IFX. The scope of these standards is
broader however: the integration of systems of financial institutions with those of their
customers. It should further be remarked, that these standards have been developed in the
US with its Anglo-Saxon approach to financial affairs. This may make these standards less
suitable outside the Anglo-Saxon world.
4.6.1
26
supports a broad range of financial services by defining a
framework for directly exchanging financial data and instructions between financial institutions
and their customers. Customers can be individual consumers and businesses. Financial
institutions can be any organisation that provides some kind of financial services, such as
banks, financial advisors, government agencies (e.g. Tax Office), information providers,
transaction processors, et cetera.
For each financial service, OFX defines the format of financial data exchanged, the set of
instructions (messages) and the way the data and the instructions are interpreted. The
financial data and instructions are specified in SGML. The interpretation of data and
instructions is realised by implementing OFX server and client applications.
The OFX specifies a client-server architecture. The server implements financial services or
has access to such, and the client can request such services. The communication between
the client and server is carried out in HTTP (see Figure 10).
25
26
See http://www.netgiro.com
http://whww.ofx.net/
40
G
I G A
P
O R T
Server Application
Web -server
Client application
OSF-server
Legacy format
OFX reply
OFX reply
OFX request
HTTP
(appl/x-ofx)
OFX request
Web-client
Legacy system
(implementing service 2)
Service 1
Service 2
OFX client
...
Service n
Figure 10: OFX Architecture
This section has been sourced from [Stef00].
4.6.2
GOLD message standard
The GOLD message standard
27
28
was created by the Integrion Financial Network , an industry-
based consortium owned by fifteen Major International Financial Institutions that joined
resources to positively impact the electronic delivery channel.
The GOLD Message Standard is an interface protocol used to enable financial institutions,
technology vendors and third party processors to connect to one another more efficiently and
with enriched functionality. The standard has the following functions:
·
enables various end user products to connect to financial institutions core systems in an
extendable protocol.
·
defines a broad range of messages and transactions embodying the complete set of
banking functions.
·
shields the financial institution from the variety of end user devices, networks and
protocols, as well as shielding the end user from the peculiarities of the financial
institutions' core systems.
In summary, GOLD defines an open, cross-platform standard messaging interface which
facilitates the secure electronic exchange of data between financial institutions, their partners,
and their customers.
27
28
http://www.integrion.net/gold/
http://www.integrion.net/
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
41
4.6.3
Interactive Financial Exchange (IFX)
The Interactive Financial Exchange (IFX) specification
29
provides a robust and scalable
framework for the exchange of financial data and instructions independent of a particular
network technology or computing platform. It was developed as a co-operative industry effort
among major financial institutions, service providers and information technology vendors
serving these institutions and customers in the small business and consumer markets. IFX
builds on the industry experience of the Open Financial Exchange (OFX) (see section 4.6.1)
and Integrion GOLD (see section 4.6.2) specifications, which are currently implemented by
major financial institutions and service providers.
According to [Mari00], US banks seem to like version 1.0.1 of IFX, in particular because of the
included account-management features that it includes. These features enable the seamless
integration of EBPP with online banking services. For example the Spectrum bank consortium
has accelerated its schedule to implement IFX.
Electronic bill delivery and payment messages are highlighted in the IFX Specification. These
messages were developed to support the open, interoperable and secure exchange of
electronic bills and the reliable delivery of payment and remittance information.
4.7
Examples of Electronic Bill Presentment systems
In this Section we treat EBP systems (products) that are being used by some of the providers
of EBP services mentioned in Section 4.5.
4.7.1
BillCast (Avolent)
BillCast is a product of Avolent (formerly of ‘Just in Time solutions’)
30
that provides Internet
billing and interactive customer care. Customers can view, analyse, and get details on current
and past bills. User profiles, together with an integrated business rules engine, are used to
provide personalised billing. The engine is also used to realise the system’s flexibility:
changes to the business logic can be made by adjusting business rules. No (re)coding is
required. As part of customer care, a ‘home page’ is generated around bill presentment. From
this page users can e.g. make scheduled payments.
BillCast uses XML-based definitions of back-end systems. Therefore it is claimed that easy
31
integration with e.g. accounting systems is possible . The billing service is delivered through
web-based and email channels. Personal digital assistants (PDAs) can be used to access the
service. Figure 11 shows the BillCast Architecture.
29
30
31
http://www.ifxforum.org/
http://www.justintime.com/home.html
http://www.justintime.com/productsTechnology/billCastArch.html
42
G
I G A
P
O R T
BillCast seems to be the back-end system for both Bluem’s service (see Section 4.5.2) as well
32
as Intuit's billing site .
Figure 11: BillCast Architecture
4.7.2
WorkOut (Alysis)
Alysis positions their WorkOut™ product as a ‘standard e-billing component’. It comes in three
flavours: (1) one for Busines-to-Business (B2B) e-billing, (2) one for B2B e-billing tailored for
Utilities, and (3) Business-to-Consumer (B2C) e-billing. The system is based upon Enterprise
Java Beans (EJB) technology. Thus it runs on EJB application servers. Currently, WorkOut
version 2.0 supports the two leading EJB-compliant application servers: IBM WebSphere®
and BEA WebLogic®. It supports both Oracle8i and IBM DB2 database management
systems, both on UNIX and Windows NT.
Alysis participates in IBM’s Solution Investment Initiative in order to bundle its WorkOut
software with IBM’s e-business solutions, in particular the above mentioned WebSphere and
33
DB2 Universal Database. . Moreover, Alysis signed a joint marketing agreement with Bibit
Internet Payment Services (see Section 5.5.1) in order to offer Bibit’s bill payment methods in
combination with its WorkOut e-billing solution.
34
32
http://www.techweb.com/wire/story/TWB19980521S0002
According to Alysis’ press release of September 20, 2000: ‘Alysis Technologies Teams with IBM to Provide
Electronic Bill Presentment and Payment’.
34
According to Bibt’s press release of December 18,2000: ‘Alysis teams with Bibit to target European e-billing
market’.
33
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
43
4.7.3
Oracle’s Bill Presentment and Payment Solution
Oracle Bill Presentment and Payment allows customers to perform multiple functions such as
view bill summary, view bill details, pay bills, dispute bills and set-up auto payment rules. All
these functions are achieved through a browser-based interface that is customisable. Its
features include:
· Bill-delivery support through browser, e-mail to PFMS (through Open Financial Exchange OFX) and other clients;
· Support of direct-biller, consolidator and combined models;
· Interoperability with CheckFree via OFX and TransPoint;
· Customisable billing look-and-feel for customers, customer service representatives, billers
and administrators;
·
·
·
·
·
Rules-based e-mail notifications (new bill, auto-paid, etc.) and payment functions;
Payment queues (real-time and batch);
SSL (Secure Socket Layer) security
Integration with partners for targeted marketing;
Simple sign on.
Bill Presentment and Payment is part of an Oracle portfolio of e-commerce product and
service offerings. Oracle's e-commerce consulting solutions cover three main areas: Buy Side
(Supply Chain Management), Sell Side (Customer Relationship Management) and In Side
(Strategic Enterprise Management). Each offering incorporates Oracle's underlying Internet
Platform and encompasses products and services for building comprehensive, scalable,
extensible and integrated e-commerce solutions. Additionally, these solutions allow existing
applications to incorporate e-commerce functionality so that an organisation's current
investments in information technology can be leveraged.
4.8
Providers of EBP services compete with providers of print and mail services. It is also
important to note that the EBP concept assumes that the biller and customer have a good
trust relationship. Thus Billers will benefit most from extended customer (self) care functions
offered in conjunction with EBP services, and from economies of scale because of the
efficient payment system. Therefore EBP seems to be most suitable for large volume billers,
with recurring customers and bills: so-called ‘recurring billers’. Typical companies are: telecom
operators, utilities, financial institutions, insurance companies, mail order companies, charity
organisations and governmental institutions, like the Tax Office and municipalities.
The initial focus for bill presentment services has been on the business-to-consumer market,
because of the relative simplicity of integrating EBP with consumers’ financial management
systems when compared to the internal administrative processes for invoice handling
encountered in firms. However, attention is now shifting towards business-to-business
applications. B2B bill recipients, like consumers, benefit from the availability and
personalisation, but are also interested in the possibilities of analysis and reporting. Hence,
B2B systems must offer this functionality. Furthermore, they need to be scalable to handle
44
G
I G A
P
O R T
large (amounts of) bills, multi-part bills, and must integrate with existing financial and
accounting software (for example offer data integration from various sources, access control,
cost item allocation, and dispute resolution).
Both in the B2C and B2B market the uptake depends on the penetration of Internet among
households and firms. The rate of penetration is growing for both cases (e.g. consult [CBS01]
for figures on the Dutch situation over the past few years). EIP requires much more than
Internet connectivity however. For EIP Internet should reach to the workstation of the relevant
employees. Business processes may need to be redesigned and these changes must be
made operational. Currently this Customer’s point of view seems to be somewhat neglected.
Most discussions stress the benefits for providers in the scheme: for billers, banks and other
service providers. Paradoxically, the current schemes for activation of EB/IPP services (the
enrolment) are Customer-driven.
The benefits for the Customers are not always clear. [AuKa01] draws the conclusion from a
Gartner Group survey (see [Lita00]), that it ‘suggests that consumers are only likely to sign up
for EBPP if they are able to get most - if not all - of their bills online’. In the Netherlands the
banks investigated the possibility of providing access to electronic bills of various billers for
their customers: the bank as trusted party for the consumer. More light should be shed on
Customer benefits – both consumers and businesses – before more can be said on the
uptake of EBP and EIP services.
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
45
5 Payment in e-commerce context
5.1
Issues in the virtual world
Recall that we consider e-commerce in this document in the narrow sense of selling physical
goods or services through an electronic communication channel, in particular Internet. There
are various differences between this context and selling at physical points-of-sale.
Firstly, the virtual ‘counter’ is unattended. In principal there is no human-to-human interaction.
This makes trust an issue. Is the consumer really who he says he is? Is the merchant (part of)
a decent organisation? Direct payment, like cash or debit card transactions in the real world,
may be an option to assure the virtual cash flow.
Secondly, Internet is international and accordingly the merchant can expect that his web shop
will attract also consumers from abroad. If he is willing to sell to those consumers as well, he
must make sure that there are appropriate payment systems available in the web shop that
support cross-border payments. And he must also make sure that he is able to deliver the
goods internationally…
Let us consider direct payment and international reach in further detail.
5.1.1
Direct payment
Direct payment is hard to achieve, primarily because of the inherent delay in payment
transaction processing caused by the retail payment infrastructure as provided by the financial
sector (see [HiSt01]). In the Netherlands, payments involving bank accounts of different banks
are centrally processed at the Automated Clearing House (Interpay in the Netherlands) and
settled once a day in the books of the Central Bank (De Nederlandsche Bank). Only after
settlement the payment transaction is final (with exceptions, e.g. for direct debit. See
[HiSt01]).
Therefore, direct payment can only be realised (1) in systems that make use of bank accounts
and the internal account management system of a single bank, (2) in systems that manage
special accounts for Internet payments, (3) in systems that exchange monetary value similar
to cash: electronic money schemes, or (4) simply using cash, on delivery.
The first solution imposes the restriction that both consumers and the merchant hold a bank
account at the same bank. Rabo Direct Betalen (discussed in Section 7.3.1) is an example.
The second solution shifts the problem to another point in the overall process: loading of the
special account on fore hand or when there are insufficient funds, or post-payment using a
billing approach. Section 5.2 treats commercial examples of such systems in further detail:
PayPal (Section 5.2.1) and the Jalda-based Safetrader (Section 5.2.2). Electronic money
schemes are discussed in further detail in Section 7.4. See also [HiSt01]. Cash-on-delivery is
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
47
a solution that works both domestically and internationally. GlobalCollect offers this service on
an international scale (see Section 5.3).
5.1.2
International reach
For an Internet merchant it is hard to predict the national origin of customers on its Web site.
Worldwide there is a huge number of different Internet payment systems operational. The
selection and subsequent implementation of these payment systems is therefore hard, costly
or even impossible.
There are only a few ‘general purpose’ international payment instruments available: (1) credit
cards, (2) cross-border bank transfers, and (3) international collection services. We discuss
the issues regarding on-line credit card usage in Section 7.2. The second instrument, crossborder bank transfers, is highly inefficient (see [HiSt01]). This makes them unsuitable for
payment of products with a small margin. Currently they are not supported on-line in
electronic banking applications as well. International collection is an option. We discuss
GlobalCollect as an example in Section 5.3.
5.2
Examples of dedicated account-based systems
In this section we discuss the PayPal system and Jalda, which is an Application Programming
Interface to a central account management system proposed by EHPT, an Ericsson and
Hewlett Packard joint venture. Before we discuss the system details, a few words from a
business perspective.
The operator of a dedicated account-based system has special concerns. In the pre-paid
situation a consumer should have sufficient trust in the operator. Otherwise he will not deposit
money into the account. Possibly the operator needs a banking licence as well, because he is
attracting funds from the public. In the post-paid scenario the operator is having a credit risk.
Loading will involve other (electronic) payment systems. Thus such a system may solve the
direct payment issue, but the consumer may still be faced with the necessity of using various
payment instruments over the Internet. By its very nature, such a system is perfectly suited for
exploitation by intermediaries.
5.2.1
PayPal
PayPal
35
is an account-based payments system that is exploited by a US company with the
same name. In the US it is quite successful, partially because the biggest Internet auction
site, eBay, uses PayPal [Econ01], partially because the system also supports person-toperson payment transactions. The latter functionality is rare among Internet payment systems
(because of risk and fraud management). The only other payment system that currently
supports this functionality is the card-based electronic money scheme Mondex (see [HiSt01]).
35
See http://www.paypal.com/
48
G
I G A
P
O R T
Initially the service was free of charge for consumers en merchants. The initial business
model was claimed to be based upon selling personal financial details to third parties. As of
June 2000, PayPal changed its strategy. This change coincided with the introduction of new
rules in the USA ‘curbing’ these activities. From that point in time PayPal asked 1.9% of the
value of purchases from vendors [Econ01]. This is about two percent less than credit card
companies charge for transactions. Moreover, PayPal has encouraged more Internet buyers
away from using credit cards, by starting to pay interest on deposits in PayPal accounts.
PayPal has a transaction monitoring system that is capable of identifying unusual money
flows, e.g. from several accounts loaded by using stolen credit cards to a single PayPal
account, where the money is collected. The system uses email addresses as account
identifiers.
Not all information on PayPal is positive: various users seem to have complained about the
system in relation to fraud [Cave01]. Moreover, the European deployment of PayPal has been
postponed, because the company should either obtain a banking licence or co-operate with a
commercial bank, according to the European regulations. The ING Group was envisioned as
European partner, but there is not much news on the deployment process.
5.2.2
Jalda
Jalda-based Safetrader
36
is a ‘secure, flexible Internet payment method’ developed by EHPT. A Jalda system
has three major participants: the customer, the e-commerce service provider and a payment
service provider (or Internet Payment Provider – IPP). Jalda uses the concept of a ‘tick’ to
represent a payment transaction. The value associated with one or more ticks is defined by
the e-commerce service provider and agreed to by the customer in a digitally signed ‘contract’
or order confirmation. The ‘tick’-concept offers flexibility by supporting both single transactions
(a web shop pursuit) and session-based ‘sliced’-payments (as IP-telephony, streamed video,
music and on-demand services, discussed in detail in Chapters 8 and 9). Moreover it enables
the support of payment transactions of almost any value.
The system works as follows. Both the consumer and service provider hold an account in a
Jalda compliant payment server, e.g. the ‘Safetrader’ payment server of EHPT that is
managed by the IPP. Using the Jalda API the service provider’s application sends ticks to the
server that charges the appropriate account and updates the service provider’s account. Ticks
can be generated by any part of the service provider’s application: that is, the client, the
server or an intermediary proxy. Thus it is possible to integrate the functions of a payment
system into a web server or a client application that runs on the customer’s computer.
In practice, the system works like this:
1. An agreement is made between the client and the service provider with regards to costing
of the services that will be provided (e.g. based on time or per click, etc.)
36
G
See http://www.jalda.com/.
I G A
A B P / 2 0 0 1 / D 0 . 1
B
49
2. With this agreement in place, the IPP is contacted by the service provider application
(which may be a web server or an application running on the customer’s machine) and a
secure connection is made between the two parties.
3. Using this secure connection, as the client utilises the services (as detected by the
service provider application), the client’s account is billed as the service provider
application sends ‘ticks’ over the secure connection to the IPP.
At the IPP, a payment server maintains a database of pricing information (i.e., different rates
for recurring customers etc.) and also customer profile information. When each tick is
received by the IPP server, it must be analysed. This process involves determining:
·
who sent the tick,
·
the product it refers to,
·
the price,
·
the currency to be used,
·
any applicable discounts,
·
who is paying,
·
how to bill the customer.
The charging information generated by the IPP may then be utilised by a billing system – i.e.
for monthly bills or direct debit from an account.
This system seems to be quite attractive since it allows service providers a flexible way to
charge for Internet services. Its accounting model is somewhat like a taxi cab meter. Both
the rate at which the meter ticks, and the value associated with each tick are customisable by
the service provider. Since the payment functionality may be integrated into a web server, the
impact of adding this technology to existing systems is lessened. The ability to integrate the
Jalda payment API into a client-side application is also an attractive feature of the system.
5.3
Example of international collection: GlobalCollect
GlobalCollect
37
is a service of the TNT Post Group (TPG) that offers ‘…an integrated,
transparent and secure solution for worldwide cross-border collection of consumer payments’.
Their slogan is ‘Act Global, Collect Local’. Accordingly it supports the production and
despatch of invoices and reminders to customers abroad, in the local language and the
currency of payer’s choice, following the local customs. The invoice recipient can pay the bill
with various local payment instruments. By means of GlobalCollect’s network of associated
banks the payer may even use a domestic credit transfer for settlement, instead of a costly
cross-border transaction (cf. [HiSt01]).
The payee receives detailed reconciliation reports regularly. Other (value-adding) services
offered are fraud detection and debt collection. It seems that the company aggregates single
37
See http://www.globalcollect.nl
50
G
I G A
P
O R T
cross-border payments from each foreign country that it operates in, into single intra-company
transactions with larger value. Thus it reduces the relative cost of the cross-border
transactions. It is not clear if they also reduce the delay involved in cross-border payments.
5.4
Generic system architecture
In Figure 12 we present an architectural overview of a typical Internet-based electronic
payment solution for an e-commerce site, a web shop. This picture results from an analysis of
various products of e-commerce system vendors and service offerings from service providers.
In the overall picture we distinguish between the systems that realise (1) the primary service,
i.e. the web shop, (2) the Internet-based electronic payment system and its integration with (3)
the overall payment system provided by the financial sector (which is described in [HiSt01]).
This distinction is made visible in Figure 12 as the three horizontal layers. Furthermore we
distinguish between systems that are consumer oriented (left-hand side) and merchant
oriented (right-hand side). Looking at the consumer side as example, systems, e.g. an ewallet, resides either physically in the domain of control of the consumer or their functions
may be used as a service from a party of the consumer’s choice. That is, the hardware
devices and the software on it that make up these systems are in the consumers personal
environment or in a trusted environment of his choice, for example his bank or telecom
operator. A similar distinction holds for the merchant oriented systems.
Consumer
oriented
Web shop
application
Web shop
application
Merchant
oriented
(server side)
(client side)
Primary service
Internet payment
system
Interface
Device
Internet
Internet
Cash
Register
e-Wallet
e-Purse,
debit card
payment instruments
Public
communication
network
‘issues’
(client-side)
Payment
Gateway
Banking
application
Issuer’s
bank
system
Financial sector’s
payment system
Public
communication
network
(server-side)
Financial
network
Acquirer’s
bank
system
Figure 12: The generic overall architecture of an e-commerce payment system
Outsourcing of system functions to an external service provider is common practice. For
example there are various providers of an Internet Cash Register that offer this function as a
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
51
service over Internet. These are the so-called Payment Service Providers (discussed in
Section 5.5). The white horizontal spacing in Figure 12 between the merchant’s web shop
application and the Internet Cash Register represents the possibility of outsourcing the latter
function over a public communication network. The Merchant may also implement the Cash
Register in his own domain of control however.
The equivalent of the Cash Register in the consumer domain is the electronic wallet or ewallet. Among others it functions as organiser of the various Internet payment instruments, i.e.
of the client-side applications that implement these systems. E-wallets are discussed in detail
in Chapter 6. Various Internet payment instruments that are supported in the Netherlands are
discussed in Chapter 7.
The ‘Banking application’ in Figure 12 may be any application that the consumer’s bank uses
for communication with its customer, the consumer. For example, it can be a home- or webbanking application that the consumer may use for entering a bank transfer order, or obtain
balance information.
Payment gateway
The payment gateway requires more attention because of the potential security problem it
creates. Essentially a gateway links two different communication networks, in our case a
public communication network (e.g. Internet, cable, PSTN, GSM, GPRS) and a financial
network. The gateway implements the mapping of the different communication and security
protocols on the two networks that it connects. This typically implies that it is an end-point in
the security protocols that are used on both networks. Thus, decrypted transaction information
may be present inside the payment gateway system. Therefore, the financial sector requires
that the payment gateway is located inside the domain of control of a party that they trust and
where they can supervise the system’s security.
A variant of this security problem with gateways is encountered in the situation of mobile
payment. The WAP- or IP-gateway in the GSM and GPRS/UMTS network respectively
connects the Internet to the mobile operators internal network and finally the air ‘interface’
(see Figure 13). Payment information that is securely sent over the latter mobile network is
decrypted in these gateways before it is encrypted and securely sent over the public Internet
to the relevant financial institution. Therefore, unauthorised persons may be able to obtain
sensitive transaction information from the gateway. It is hard for financial institutions to
supervise these gateway systems.
Air interface
Internal network
WAP- / IP-gateway
Internet
• GSM
• GPRS
• UMTS
To financial
institution
Mobile network
operator
Figure 13: Simplified view on data flow through network and devices for mobile payment
52
G
I G A
P
O R T
5.5
Payment Service Providers (PSPs)
Payment Service Providers (PSPs) assist merchants in the realisation of an Internet Cash
Register and the merchant part of electronic payment instruments (see Figure 14). They
enable outsourcing of Internet cash register functionality and typically implement various
payment instruments. Thus PSPs act as particular Application Service Providers (ASPs).
They support the integration of primary applications with payment systems.
Web shop
application
(server side)
Merchant
oriented
Internet
Internet
Internet
Cash
Register
payment
instruments
Public
communication
network
(server-side)
Payment
Gateway
Figure 14: Scope of Payment Service Providers
Additionally PSPs may offer not only the domestic payment systems, but also instruments
used in other countries. Merchants are offered the opportunity to select the national and
international instruments that they are willing to except. This set of accepted systems can be
customised to the local, national situation of the payer. Individual buyers can then select their
favourite instruments from the merchant’s list. In this way cross-border payments are
facilitated (recall Section 2.1.2) and the merchant can take care of the local payment culture
(see [HiSt01] for comments on payment culture and its importance). Moreover, PSPs may
also accept multiple currencies and provide instant exchange services, as well as risk
management (e.g. fraud detection, check of creditworthiness).
Currently there are various companies that offer these ‘payment services’ to Internet
merchants. In the Netherlands three PSPs are now active: Bibit Internet Payments B.V.,
TWYP (‘The Way You Pay’ from the ING group) and NetGiro (related to the debt collection
firm Intrum Justitia). The Privver service from the TNT-Post Group (TPG) also offers a
payment service for electronic bills, but is essentially a document (mail, bill, …) presentment
service.
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
53
5.5.1
Bibit Internet Payment Services
38
Bibit B.V. is a Netherlands-based company with international operations in Europe and the
U.S.A. that provides easy access to an extensive choice of payment services, for commercial
Internet sites. Their services allow Internet merchants to conduct business with consumers
without having to manage their own payment systems. The payment service is targeted
towards individual customers that purchase items or services over the Internet.
The main service that Bibit provides is a front-end to a large number of payment instruments
(e.g. all major credit cards, bank transfers, direct debit). At the moment they offer more than
50 payment systems, of which various are limited to local use, within countries in Bibit’s
domain of operation. Their payment services are tailored to the local customs of the payer: for
each country a different suite of payment systems is available, following the countries
payment culture. Bibit’s focus is on the support of Internet merchants: sellers can accept a
diversity of payment instruments, without the necessity of implementing the systems
themselves. The number of Internet businesses using the Bibit payment service is steadily
growing.
The services are supported by Bibit’s self-developed secure Internet payment platform. Apart
from supporting international and country-specific payment applications, this platform also
enables the use of multiple currencies and languages. Bibit takes care of conversion of for
example customer currency to merchant’s currency.
A typical use of the Bibit payment service function consists of the following steps:
· A customer makes a choice of, e.g., the products on sale in a virtual shop.
· For payment, the customer can choose one of the available payment methods. The seller
determines which of the payment methods are made available, and also provides the
interfaces.
· For the actual payment transaction, either the seller contacts the Bibit server, or the buyer
is redirected to the Bibit server.
· Bibit contacts the acquirer associated with the payment method for the necessary
authorisations etc.
· After a successful payment authorisation (and possibly also a settlement, depending on
e.g. the payment method and policies), Bibit notifies the seller, after which e.g. shipping or
service provisioning can commence.
· The acquirer and the issuer of the payment method take care of the actual settlement,
without the involvement of Bibit.
· All the payment transactions conducted through Bibit are centrally stored in Bibit’s
transaction database.
38
See http://www.bibit.com/
54
G
I G A
P
O R T
Figure 15 illustrates the Bibit payment process. Note that the highly centralised structure of
this system puts high demands on the availability, performance, scalability and reliability of
the Bibit servers.
buyer
redirect
BIBIT
acquirer
issuer
seller
transaction
database
Figure 15: Bibit payment
Bibit and Alysis, a vendor of EBPP software, signed a joint marketing agreement. This
alliance allows Alysis to offer Bibit’s payment services to their European customers.
39
Pay-it-now
Pay-it-now
40
is a product of e.Trade, a supplier of a series of Internet products that should
cover the requirements of Dutch SMEs with regard to e-commerce. e.Trade resells products
of other companies and offers consulting and integration services. Pay-it-now is powered by
Bibit and started in June 2000. Its first customer is zibb.nl.
5.5.2
NetGiro
Netgiro International
41
was founded in Sweden in Autumn 1997 as the prinicipal processor of
all credit card transactions in Scandinavia for the bank PariBas. Netgiro Sweden counts
companies like SJ (Swedish Railways), Ericsson and Telenordia (telecom) among its
customers. Currently it is active in about 25 countries in Europe. In the Netherlands NetGiro
42
serves ‘BelBios’ , a service for ordering cinema tickets.
NetGiro operates an Internet payment platform that supports various payment instruments,
like all major credit cards, Rabo Direct Betalen, direct debit and micropayments through
various wallets. Apart from payment processing, NetGiro is also part of the money flow from
the issuer’s bank to the merchant account.
They offer additional services for transaction reporting and analysis (the Online Transaction
Tool – OTT). Moreover, they also have an electronic bill presentment service.
39
According to Bibit’s press release of December 18, 2000: ‘Alysis teams with Bibit to target European e-billing
market’.
40
See http://www.pay-it-now.nl/.
41
See http://www.netgiro.nl/
42
See http://www.belbios.nl/
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
55
5.5.3
TWYP
TWYP - The Way You Pay
43
- The Way You Pay is an ING subsidiary that acts as Payment Service Provider for
on-line merchants and consumers. It processes the on-line payment transactions and
provides the merchant with real-time transaction information. TWYP offers Internet Cash
Register and Payment Gateway functionality (recall Figure 12) as service for payment
systems such as credit cards (EuroCard/MasterCard, VISA, Diners Club), debit card
(Maestro), single transaction direct debit (see [HiSt01]), credit transfer, acceptgiro and cashon-delivery.
Moreover, it provides on-line access to a site with management information, like a transaction
overview ordered e.g. on payment status or transaction date.
43
See http://www.twyp.nl/
56
G
I G A
P
O R T
6 Electronic wallets: shopping and payment assistants
6.1
Introduction
An electronic wallet or e-wallet is generally understood to be an application or service that
assists consumers in conducting online transactions, e.g. by allowing them to store billing,
shipping, payment and preference information, and to use this information to automatically
complete a merchant’s check-out page. Electronic wallets are not payment instruments
themselves. Like their physical counterparts they contain information and (software of)
payment instruments, e.g. software-based purses to store electronic money or software that
implements the consumer part of security or payment protocols such as credit card payment
with SET (so-called SET wallets;; see Section 7.2). In the latter sense many payment systems
use an electronic wallet: a piece of software that is installed in the consumers domain, on his
PC, to implement the consumer-part of a payment application. Systems that only store
electronic money are called electronic purses or e-purses. These are discussed in [HiSt01].
E-wallets link together consumers, web shop applications and various payment instruments
(see . They come in two main types: client-side and server-side. Server-side wallets are also
called ‘thin wallets’. Initially there were only client-side wallets. These require users to obtain
and install software on their PC. The information stored in the wallet, i.e. on the PC’s hard
drive, is protected by means of encryption. Server-based wallets enable usage of the wallet’s
functions from any location on the Internet.
Browser
Application server
Internet
Consumer
Webshop application
Primary service
Wallet
application
Mediation
Secundary services
(supporting:
payment)
Card reader
IC Card
Bank system
PSP platform
E-Money system
(PSP: Payment Service Provider)
Figure 16: The role of electronic wallets
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
57
6.2
Basic wallet functions
We identify three main functions for electronic wallets, which we shall illustrate by commercial
products. These products realise a partial combination of the functions, typically not all of
them. Basically an e-wallet may function as:
1. Shopping assistant,
for filling in forms at webshops. Currently, many users find the manual filling out of these
forms – typically specific to merchants – confusing and tedious. The process is errorprone. According to industry figures, consumers abandon more than 60% of online
purchasing prior to completion. The Electronic Commerce Modelling Language (ECML)
facilitates this function (see Section 6.4.1). The wallet stores the personal data and
preferences that are used for these forms, like preferred billing or shipping address. Some
wallets offer far more advanced options, like storing cloth sizes, and even body shapes.
Benefits are in entering the data only once (and when necessary, changing only once) and
protection of the information by encryption.
2. Means of identification and authentication in the virtual world,
which is encountered in products as MicroSoft Passport and the mentioned SET wallets.
The wallet may contain one or more digital certificates to identify the user, and which may
be used for encrypting messages and placing digital signatures. It may also check the
validity of certificates received from merchants. Merchants benefit from these functions by
receiving better protection against fraud.
3. Payment instrument organiser,
that is, the wallet contains the data on the cards and other payment instruments that it
supports as well as the client software that is required for the operation of network-based
payment instruyments. This functionality is encountered in the Wireless Wallet concept
that was conceived at Ericsson and that has now been acquired by Xiring (see Section
6.3.4)
An e-wallet could further be used for storing information on electronic transaction, like status
and transaction receipts.
6.3
Product examples
44
A list of SET-wallets is available at the SETco website . Table 3 presents a list of commercial
wallets that we shall discuss below. The table also presents the functions that each wallet
supports and whether it uses a thick or thin client approach.
The Nokia 6310 is a mobile phone that has been equipped with an ECML compliant wallet for
use in m-commerce transactions. Because of the inconvenience for users of mobile phones to
enter data, this wallet focuses on the shopping assistant and payment instrument organiser
functions.
44
See http://www.setco.org/cgi-bin/vsm.cgi.
58
G
I G A
P
O R T
Product name
Provider
e-Wallet
ABN-AMRO Bank
Thick
Passport
Microsoft
Thin
Wireless Wallet
Xiring (was: Ericsson)
Thick
Digitalme
Novell
Thin
X
Nokia 6310
Nokia
Thick
X
6.3.1
Payment
instrument
organiser
Identification,
authentication
Shopping
assistant
Approach
(thin/thick)
Table 3: A comparison of some commercially available wallets on their functionality and approach.
X
X
X
X
X
ABN-AMRO’s e-Wallet
ABN-AMRO has developed a wallet, called ‘e-Wallet’, for use on the Internet. The software
must be installed on the user’s personal computer. Access is obtained by entering your ABNAMRO bank account and bankcard card number, followed by a challenge-response initated
by the e-wallet. This challenge-response uses a small hardware cardreader, the ‘e.dentifier’,
in which the same bankcard must be inserted and the user’s PIN entered. Based upon the
challenge provided by the e-Wallet, the e.dentifier computes the response, which must be
entered into the e-Wallet. The response is verified by an authentication server in the ABNAMRO domain.
The wallet currently supports only Eurocard/MasterCard and Maestro. It is SET-compliant: the
e-Wallet can be used at Internet merchants that have implemented a SET-based cash register
supporting these two brands, or use a Payment Service Provider (Section 5.5) that has. In
particular, the user can shop at the merchants connected to Interpay’s I-Pay payment
gateway (to be discussed in Section 7.2.3).
6.3.2
Microsoft Passport
Microsoft Passport
45
is a server-based wallet. It offers two basic services: (1) a ‘single sign-in’
by means of log-in name and password that provides single access to a growing number of
participating Web sites, and (2) a payment service that allows users to make fast online
purchases. The single sign-in service allows a user to sign in to any participating Passport site
and have their personal details (which are stored in a user profile) automatically available to
that site. The user profile contains personal data (such as the user’s name, address, phone
number and e-mail address) and payment information (such as credit card number and
expiration date). Passport can only be used for credit card payments.
45
G
http://www.passport.com/
I G A
A B P / 2 0 0 1 / D 0 . 1
B
59
The passport wallet is stored on a secure Microsoft server and whenever passport information
is sent over the Internet, it is encrypted, then sent using a secure connection (SSL). The
wallet service supports ECML (see Section 6.4.1). The system utilises cookies for user
tracking.
Passport offers additional services that have nothing to do with payment: the ‘Kids Passport’
service that lets parents control the personal information that their children convey and the
‘public profiles’ service that allows to create a public page of information about the user.
6.3.3
Novell’s Digitalme
Novell offers a data storage service, called Digitalme. Internet-users can store their personal
data, like shipping info and clothing sizes, at a special website, and use it when ordering
goods. The data can also be send as a business card. The service was introduced quickly in
October 1999 to be ahead of Microsoft’s Passport.
6.3.4
Xiring: the Wireless Wallet concept
Xiring acquired this concept from Ericsson. It is unclear whether an implementation is
currently commercially available.
The Wireless Wallet is a product that provides
convenient access to any smart card based
service. Using Bluetooth, WAP and an integrated
46
smart card reader , the Wireless Wallet enables
smart card transactions over the mobile
Internet.
47
The Wallet can communicate with any Bluetooth
device, such as a mobile phone, PDA or personal
computer. According to Ericsson, mobile phones
will be the first to come out in “Bluetoothenabled”
48
versions.
A secure payment, e.g. for an airline travel ticket, is made following several steps:
49
1. You get on the Internet, using wireless or fixed-line access, and contact a travel agency or
airline
2. You choose the route and times and make a reservation.
3. The travel agency asks you how you want to pay.
46
More on card readers can be found e.g. in [HiSt01].
http://www.ericsson.com/wirelesswallet/
48
http://www.bluetooth.com/
49
http://www.ericsson.com/wirelesswallet/How.htm
47
60
G
I G A
P
O R T
4. On your Wireless Wallet's home page, you can see all the smart cards currently in your
wallet.
5. Your Bluetooth device, for example your phone, displays your Wireless Wallet’s home
page.
6. You choose the smart card to use for this transaction. Let's say you select a credit card.
7. The card communicates via the wallet over the fixed wireless Internet connection.
8. The transaction then goes from your bank to your travel agency’s bank.
9. Your travel agency registers the payment.
10. The ticket is immediately downloaded to your smart card which will be read at the airport.
11. Finally you can get information about your flight or change your reservation 24 hours a
day via your WAP phone, palm or personal computer. The ticket is already stored on a
smart card in your Ericsson Wireless Wallet.
The code for making ticket reservations and payments are stored on an application server at
the travel agency or airline. The phone, notebook PC or desktop used for the reservation
contains a WAP browser, while the Wireless Wallet contains a WAP server. The Wireless
Wallet communicates with the cards using their normal interface and application software (see
[HiSt01] for more information on these interfaces and on standards for chip cards). The
communication goes over the Internet via your Bluetooth device and the wallet to the Smart
Cards.
6.4
Wallet standards and frameworks
The e-wallets standards that are currently available do not cover all three main wallet
functions that we mentioned in Section 6.2. The shopping assistant function is supported by
means of the Electronic Commerce Modelling Language (ECML) and there is a framework
that describes a reference system architecture for the payment instrument organiser function:
the so-called ‘SWAPEROO’ Digital Wallet Architecture [DBG+98]. This is the result of
academic research however, of the ‘Digital Wallets’ project at Stanford University (U.S.A.).
50
We are not aware of commercial implementation of this framework.
A wallet framework that is commercially used is the Java Wallet framework. We briefly treat
this framework below.
6.4.1
Electronic Commerce Modelling Language (ECML)
The IETF and W3C’s Electronic Commerce Modelling Language [EaGo99] is the product of
51
the ECML Alliance , which consists of a number of major industry leaders including American
50
51
See http://www-db.stanford.edu/~daswani/wallets/
See http://www.ecml.org/.
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
61
Express, AOL, Brodia, Compaq, CyberCash, Discover, FSTC, IBM, Mastercard, Microsoft,
Novell, SETCo, Sun Microsystems, Trintech and VISA.
The ECML specification simplifies the exchange of payment, shipping and billing information
between consumer and merchants – in particular, between consumer wallet applications and
merchant servers – by providing standard labels and formats for attributes of web-forms in
HTML pages. These labels include (among others) credit card, billing and shipping address
information. Standardisation of these labels enables the automatic completion of electronic
order forms at web shops, where electronic wallets act as shopping assistant. Thus ECML
aims at simplifying online shopping for consumers and thus increasing merchant’s revenues
52
by reducing the high percentage of abandoned shopping carts . A full description of ECML is
53
given in the IETF’s RFC 2706 .
54
The ECML standard is adopted the wallet vendors in the ECML alliance: Brodia, CyberCash ,
55
56
57
IBM , Microsoft Passport , and Trintech . Nokia introduced a mobile phone, the Nokia 6310
that contains an ECML-based electronic wallet for use in mobile commerce transactions. The
use of ECML does not require a licence, being an open IETF standard.
We conclude with an important observation made in the introduction of RFC 2706, by the
IESG. Namely, that the ‘…data model [of ECML] is heavily biased towards conventions used
in the United States, and the English language. As such it is unlikely to be suitable for
international or multilingual use in the global Internet.’
6.4.2
Java Wallet
The Java Wallet is a client-side architecture designed to bring together pluggable commerce
components to enable complex and secure online transactions of value and information in a
platform-independent environment. The Java Wallet, as an open platform for purchasing,
banking, and finance, is extensible, providing a framework whose functionality can be
extended to accommodate the needs of a variety of institutions and end users.
The Java Wallet framework incorporates:
·
the Java Commerce Client (JCC) - a client side solution for secure electronic commerce
transactions. JCC users are provided with a Wallet-like user interface, a database, and an
extensible platform that enables the use of a variety of payment instruments and protocols,
·
Commerce JavaBeans components which plug into the JCC and extend its functionality
(new protocols etc.),
52
Jupiter's February, 1999 Consumer Survey indicates 27% of online buyers abandon orders prior to purchase due
to the hassle of filling out forms.
53
Available at http://www.ietf.org
54
http://www.instabuy.com/
55
http://www.software.ibm.com/
56
http://www.microsoft.com/wallet/
57
http://www.trintech.com/
62
G
I G A
P
O R T
·
the Gateway Security Model - a system of gates and permits that restricts access among
Beans and between Beans and the JCC according to the Limited Trust Model of security.
·
and Java Commerce Messages - a format in which commerce servers communicate with
the JCC.
6.5
The future of e-wallets
Adoption of e-wallets by consumers is not widespread, while wallet vendors such as Brodia,
CyberCash, IBM, Microsoft and Trintech provide them free of charge to consumers. The
obstruction may lie in the charges merchants have to pay for making use of wallets and the
current absence of sufficient standards. The uptake has been slower than expected also
because of the initial choice for client-side (‘thick’) wallets, which requires consumers to obtain
and install software on their personal computer. In fact, there are hardly any client-side wallets
that were successful.
The future of e-wallets will be in server-based solutions, such as Microsoft’s Passport (Section
6.3.2) or AOL’s ‘Quick Checkout’. These make downloading and installation of wallet software
obsolete, and will offer multi-channel functionality: the same service can be accessed from
any location over any communication channel.
58
A multi-channel server-based wallet also
solves synchronisation problems by its centralised approach. Client-based solutions may coexist however for end-user devices with restrictive technical attributes, such as mobile
phones. These solutions are then purpose-built for these devices.
We expect that e-wallets will meet larger consumer acceptance if they provide the full set of
basic functions that we described in Section 6.2:
·
·
·
Shopping assistant,
Means of identification and authentication, and
Payment instrument organiser.
Offering these three services in a combined ‘package’ could be the value-adding role of a
Wallet Application Service Provider (WASP) - from the consumer’s perspective. Payment
Service Providers (Section 5.5) seem to target the Internet merchants instead of the
consumers. Therefore, there seems to be a role for a party serving consumers. Microsoft
seems to take this approach with its Passport concept.
The organising function for payment instruments is especially important in the still diverse
(international) world of Internet payment systems, not only in electronic commerce, but also in
the exploitation of electronic products (content and services) over fixed and mobile Internet.
We continue by treating this particular payment context.
58
G
See also ‘Forrester on e-wallets’: http://www.ecml.org/Forester1012.htm: ‘Server-based wallets will prevail’.
I G A
A B P / 2 0 0 1 / D 0 . 1
B
63
7 Adaptation of real world payment instruments
7.1
Introduction
Consumers are accustomed to using particular electronic payment instruments for
transactions in the real world, at physical points-of-sale. Instruments like credit card, debit
card and card-based electronic money. [HiSt01] discusses how these instruments work in that
context – from a business and technology point of view.
The providers and operators of these systems are firms in the financial sector: banks and
clearing houses like Interpay (recall Figure 3). They are adapting these instruments to the
special characteristics and requirements of public communication channels: fixed and mobile
Internet. Special care is taken of the issues with payment over such public networks (Section
5.1).
In this chapter we treat the adaptations and special protocols that have been devised for the
use of the ‘traditional’, real world electronic payment systems on fixed and mobile Internet.
7.2
Credit cards
Credit cards are the most popular payment instrument on the Internet right now. [Econ01]
estimates that in the US about 50% of Internet transactions are paid for by means of credit
card.
59
They are simple to use and they also provide a relatively easy and efficient way of
implementing cross-border payments (see [HiSt01] for details on cross-border payments).
Looking at this popularity it may seem that there are hardly any drawbacks to its usage. The
opposite is true however. Credit card transactions on the Internet meet a high rate of fraud.
This fraud is mainly caused by consumers that use stolen or false card details (card number
and expiry date), fraudulent merchants that provide these details to others, or hackers
obtaining these details by cracking the security of the appropriate servers. Only a small
amount of details is obtained by ‘sniffing’ the network traffic.
Various security protocols for credit cards have been devised to solve this problem. Secure
Socket Layer (SSL) takes care of the communication, while Secure Electronic Transactions
(SET) makes sure that only those parties that really need to have particular transaction
information (like the card details) actually are able to access this information. Between these
extremes with regard to security there are various variants, like Three Domain SET (3D SET).
A completely different approach is that of ‘one-time card numbers’. Here the cardholder
obtains card details that are valid during a specified period of time, often only for a single
transaction. The cardholder can obtain this one-time card number on-line from his card issuer.
59
This is only 2% of all credit card business, most of which takes place at Point of Sale (POS), e.g. in shops,
restaurants and hotels [Econ1].
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
65
It should be noted that the merchant runs the largest risk when accepting on-line credit card
payments (except when using SET): the risk of charge-backs and fines when this happens too
often. The credit card organisations consider a credit card transaction over Internet as a ‘cardnot-present’ transaction. In that case the merchant has the burden of proof that the consumer
has actually ordered the goods that he paid for (and that these were delivered). In principle
the consumer is directly refunded. Currently credit card organisations are making an
exception for sex sites and on-line gambling.
Apart from security risks there are also some non-technical objections to the use of credit
cards for online payment. These may impose even stronger restraints on the applicability of
credit cards on Internet:
1. Penetration of credit cards in the consumer population,
Not every consumer may have a credit card, or is able to obtain a credit card. For
example, people in the age of 15-18 years old are often surfing the Web. They cannot
have a credit card to make payments on the Web, however. Others may not have a
sufficient income to obtain a credit card. Therefore, credit card as a universal payment
instrument on the Internet is not feasible.
2. Payment culture,
Outside the Anglo-Saxon world credit cards may be less popular. This situation depends
on the payment culture (see e.g. [HiSt01]). In the Netherlands about 4 million credit cards
are in circulation, but they are not commonly used.
3. Consumer perception of security,
Technically a system may be sufficiently secure, form the perspective of the operator, but it
is also important that the users have the perception that it is secure. Credit cards on
Internet now suffer from a lack of consumer confidence, at least in the Netherlands, in
particular user groups of the Internet, e.g. the starters.
For further backgrounds on the credit card system, like business model, technology, players
involved and statistics the reader may consult [HiSt01]. We continue with a discussion of
security schemes for credit card payments over Internet.
7.2.1
Secure Socket Layer (SSL)
The Secure Socket Layer
60
(SSL) is a general-purpose protocol that secures every dialogue
between applications across a ‘socket’ communication mechanism. If a client and a server
communicate using this protocol, the server is always authenticated and the client may be
authenticated. SSL is implemented above TCP and is independent of the higher-level
application protocol that layers on top of it. For the web, this means that SSL sits in between
the HTTP protocol and the TCP protocol. The protocol was developed by Netscape
Corporation in 1994, and is widely used. It is approved as a standard of the Internet
Engineering Task Force (IETF).
60
An interesting source of information on SSL is http://webopedia.internet.com/TERM/S/SSL.html.
66
G
I G A
P
O R T
SSL’s main application is securing credit card transactions on the World Wide Web. All of the
application protocol data is transmitted encrypted. SSL uses RSA for key exchange and a
choice of protocols for further encryption. One of the limitations is that it offers no means of
determining the identity of the receiver. The receiver may be an illegal collector of credit card
details. More limitations are discussed in [Stei98].
MasterCard International requires the use of the Card Validation Code (CVC) for Internet
61
credit card transaction over SSL, starting April 1, 2001 . This is a 3-digit code that is printed
on the credit card in addition to the card number and expiry date.
The Private Communications Technology protocol is the Microsoft equivalent of SSL. PCT is
compatible to SSL, but servers that implement both protocols can distinguish between PCT
and SSL clients. The most important difference between the protocols is the increased
security, including the repair of bugs in SSL. The repairs concerned the authentication of a
client when a broken session is reconnected. Furthermore, the possibilities to negotiate
cryptography were extended. Several other systems, such as Point to Point Tunnelling
Protocol (PPTP) and Layer 2 Forwarding (L2F) work on similar lines to create a secure
channel between the parties.
7.2.2
Secure Electronic Transactions (SET)
Secure Electronic Transactions is a payment protocol for credit card payments. Its
development started in January 1996 as a joint initiative of MasterCard, Netscape
Corporation, IBM (all three formerly involved in SEPP – Secure Electronic Payment Protocol),
Visa, Microsoft and others (the latter two involved in STT – Secure Transaction Technology)
[OMPT97]. The alliance is referred to as SETco
62
and is tasked with the management of the
SET specification and the promotion and support for use of SET on the Internet.
SET assumes the existence of a transaction processing and information distribution
infrastructure within the card organisation. The protocol covers the communication between
Payer (cardholder), Payee (merchant) and the Payment Gateway Provider (which role may be
played by a party other than the Acquirer, for example a Payment Service Provider; see
Section 5.5 below). The main purpose of the protocol is to secure this communication in such
a way that neither the Payee, nor the Payment Gateway Provider can access all purchase
transaction details. In fact, the Payee has access to the order information, but not to the
payment information which contains the credit card details, while the Payment Gateway
Provider has access to the payment information, but not to the order information.
63
The SET uses various encryption mechanisms to realize this , but the main role is plaid by
public-private key mechanisms. To that end a Public Key Infrasture (PKI) is incorporated. The
corresponding Certificate Authority (CA) hierarchy consists of a Root CA that signs the
61
62
63
G
See http://www.i-pay.com/aanbieders/pags/cvc2.htm
See http://www.setco.com
Consult e.g. [OMPT97] for a detailed treatment of the security aspects.
I G A
A B P / 2 0 0 1 / D 0 . 1
B
67
certificates of the each of the Brand CAs using a 2,048 bit key (one Brand CA per credit card
brand). The Brand CA signs certificates for the Cardholder CA (the Card Issuer), Merchant CA
(the Customer Acquirer) and the Payment CA. The latter three CAs then sign the certificates
for the cardholder, merchant and payment gateway provider respectively. Apart from the Root
CA all use 1,024 bit keys. The certificates use the X.509 version 3 format ([OMPT97], Section
4.9).
As additional security, neither cardholder’s name, nor card number are shown in the
certificates. Instead a numeric quantity is used that has been computed from the credit card
number and other input. This number is stored in the issuer domain and is used for the
duration of the certificates’ validity.
Simplified, the protocol works as follows. It starts after the cardholder has indicated that he
wants to initiate payment for his order. The merchant then identifies himself with his certificate
and provides the cardholder with the public key of the payment gateway provider. The
cardholder can then encrypt the payment information using the latter key, such that the
merchant cannot access this information. The merchant forwards the payment information to
the payment gateway provider in his Authorisation request.
7.2.3
I-Pay
64
I-Pay – Interpay’s Dutch SET payment platform
is the Internet payment infrastructure that was jointly introduced by Dutch banks in
1996. It has been developed by Interpay, which also operates the platform. The infrastructure
aims at enabling credit card and debit card payments on the Internet. Currently only the
Eurocard/MasterCard and Maestro brands are supported, probably because Interpay is
involved in the transaction processing for transactions of both brands made in the physical
world (see [HiSt01]).
The platform is an implementation of the SET protocol for credit card payment (see Section
7.2.2). There is a payment gateway for the Eurocard/MasterCard credit card brand and for
Maestro debit cards, which is operated by Interpay. The Maestro debit card payment
instrument can only be used at Internet shops that have a bank account in the Netherlands.
The credit card instrument should be usable at any SET-enabled merchant worldwide.
Interpay functions as Certification Authority for SET in the I-Pay system ([LGKV00], Box 3.1,
p. 40), and also as software provider: it offers (unbranded) SET wallet software that needs to
be installed on the payer’s PC and an Internet Cash Register application (Internet Centrale
Kassa – ICK) for the merchant’s domain, which implements the merchant’s part of the SET
protocol. The Internet Cash Register can be connected to the merchant’s Web shop or any
other application through a special API.
64
See http://www.i-pay.com
68
G
I G A
P
O R T
65
The Payment Gateway does not support all SET messages . In fact, the system only
processes authorise and capture requests for the credit card scheme and ‘Sale’ transactions
for Maesto. The capture request has the additional constraint that the captured amount must
be equal to the authorised amount (see [HiSt01] for details on the credit card payment
process). Moreover, the system only deals with Dutch guilder and euro as currency.
Currently only by ABN-AMRO, ING Bank, Postbank and SNS Bank support SET payments as
card issuer, using the I-Pay platform. At the moment merchant support for SET consist of
66
about 215 Dutch merchants . ABN-AMRO has developed a special (branded) SET wallet,
called ‘e-Wallet’, which makes use of the I-Pay infrastructure
67
(see Chapter 6). [BöRR99,
p.49] assumes ‘…that it is seldom used.’ It mentions 20,000 reported users. No official usage
statistics are available however.
7.2.4
The Three Domain Model (3D SET)
The ‘Three Domain Model’ (3D) is more a philosophy than a technology. The idea is to split
responsibility for security, for identification and authentication, over the various parties
involved. Three domains can be identified (cf. [HiSt01]): (1) the issuer-cardholder domain, (2)
the acquirer-merchant domain and (3) the interoperability domain, between the previous two.
In the 3D approach each player within a domain (an issuing bank, an acquiring bank and the
card brand organisation respectively) decide the security technology to be used, based upon
his or her own risk assessment. The Three Domain Model ensures that the distributed
systems can co-operate. More importantly, it prescribes the legal aspects, the responsibilities
and liabilities of the various parties involved.
7.2.5
Virtual Credit Cards
In 1998 VISA first issued a virtual credit card. This ‘card’ in fact is a SET certificate. The
system is based on the SET protocol and uses a wallet that stores the certificate. The wallet
can also contain certificates of other credit card brands. Consumers that want to apply for a
VISA virtual card, should already have a VISA account. Merchants that want to accept the
virtual card need SET software and need to have this software verified by VISA.
GiSMo
GiSMo is a GSM-based virtual credit card. It uses the customer’s mobile phone as an
authentication tool. Before use, a customer must register at GiSMo’s web site. When
purchasing at a merchant who accepts GiSMo, the customer clicks on the GiSMo button and
enters his pass codes. The system generates a random number, which is sent to the
65
According to http://www.i-pay.com/aanbieders/index.htm
According to http://www.i-pay.com/winkels/abnamro/winkels/allshops.htm. The I-Pay ‘Internetwinkel boulevard’, on
the I-Pay web site (http://www.i-pay.com/winkels/index.html) mentions only 90.
67
See http://www.abn-amro.nl/frameset.html?/particulier/producten/indexframe-ewa
66
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
69
customer by SMS. The number must be entered on the purchase interface within two minutes.
Bills are sent by email.
GiSMo was released commercially in Sweden November 1999. Plans were to roll out to other
parts of Europe in 2000. Using GiSMo is free to the customer, but asks a substantial fee from
the merchant: 5000 Swedish Kronas for launch, a monthly fee of 400 Kronas, and a cut of
3.5% per transaction. GiSMo is a subsidiary of Millicom International Cellular, a Luxembourg
wireless carrier.
7.3
Debit cards
The debit card offers direct access to the cardholders bank account for the purpose of
payment to merchants in point-of-sale transactions. There, the payment terminal interacts with
the magnetic stripe on the bankcard and the cardholder for entering the PIN-code on the
terminal’s console. The terminal then transmits the data securely to the issuing bank’s
systems (through Interpay as ‘data switch’). These systems respond with the payment
authorisation.
The main concern (from the banks’ perspective) for use over public communication channels
is in proper security and authentication. The banks consider the consumer’s PC as an
insecure device, as opposed to the payment terminal at the physical shop. Therefore the
banks use a secure intermediary device for reading the debit card, entering the PIN code and
computing a response in a challenge-response type of authentication scheme.
For example, ABN-AMRO uses a calculator, the ‘e.dentifier’, for authenticating access to a
web-banking application or their e-Wallet (discussed in Section 6.3.1). The Rabobank uses a
similar approach with their ‘Random Calculator’. Both calculators require that the user inserts
the debit card and enters a PIN-code, after which a response is computed based upon a
challenge. An authentication server in the bank’s domain of control provides verifies the
response.
The systems in the above mentioned examples implement an authentication system for
access to some other (primary service) application. If this is a payment organiser like an
electronic wallet, the user experience of accessing this wallet is quite similar to a debit card
payment transaction at a point-of-sale. Technically the schemes use different systems
however.
7.3.1
Rabo Direct Betalen
The Rabobank offers the Direct Betalen service (‘Direct payment’), which enables directly
charging payments to the payer’s standard bank account. The service is only offered to
customers of the Rabobank who already use Rabo Internetbankieren or Telebankieren. The
Rabo Direct Betalen system is valid for payments up to Fl. 5000 per day. Merchants are not
required to have a Rabobank account. They must open a shop at a virtual marketplace called
‘Trefpunt’ however. This is a Rabobank initiative; the charge is Fl. 100 a month. Thus, Rabo
70
G
I G A
P
O R T
Direct Betalen can only be used by payers and merchants that have an account within the
Netherlands. The payer must have an account at Rabobank.
Initially the so-called digipasswas used for authentication. This system generated a one-time
password (a number) for every transaction, based upon a provided challenge and the
personal digipass. Now the digipass is replaced by the debit card and Random Calculator (as
discussed above in Section 7.3). The calculator is not personal, unlike the digipass. Therefore
consumers may use each other’s calculator with their private debit card and PIN-code if that is
necessary.
Transfer to Rabo accounts is direct as this type of payments is processed internally, within
Rabobank’s back-office systems. Transfer to an account held at a different bank involves the
interbank payment infrastructure. This consequently takes more processing time (1-2 days).
7.3.2
On-line use of Maestro
Maestro was conceived initially as a scheme that enables the international usage of debit
cards in payment transactions at physical points-of-sale [HiSt01]. The I-Pay SET payment
platform (Section 7.2.3) supports online payment with debit card using the Maestro scheme.
Such payments are restricted to (1) merchants within the Netherlands that have an I-Pay
compliant cash register, and (2) consumers having a debit card issued by a Dutch bank that
supports I-Pay (ABN-AMRO, ING Bank, Postbank and SNS Bank).
The transactions are finally processed through the debit card payment system of Interpay and
the Dutch commercial banks.
7.4
Card-based electronic money
According to experts card-based electronic money is best applicable in situations where there
is no human-to-human interaction required, at so-called unattended points-of-sale [HiSt01].
Examples of such points are vending machines, parking meters, public transport ticketing and
also web shops on the Internet. Rabobank seems to be working on an Internet-‘version’ of the
ChipKnip [BöRR99]. Abroad, in Germany, the Zentraler KreditAusschuß announced in June
1999 that German electronic purses could be used on Internet. The system uses a card
reader plus additional software at the consumer side. In Belgium the Proton card, which is the
same technology as the ChipKnip, can be used on Internet (Section 7.4.1 below).
Purse schemes cannot directly be applied for on-line use, as this implies high security risks.
Moreover, the chip cards on which the electronic money resides must be coupled to the
devices and applications that realise the service for which the consumer should pay. Card
readers are required. [HiSt01] provides a discussion on card readers. Here we focus on
security schemes for card-based electronic money schemes. One option is using an
enhancement of SET, realised in SET version 1.0.Another option is C-SET (Section 7.4.2
below).
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
71
7.4.1
Proton on Internet
Proton has met with limited success on the Internet, although Banksys was clearly aware of
the potential of chip cards for payment on the Internet at the start of Proton. It upgraded their
C-ZAM POS terminals from the Bankcontact/Mister Cash debit card network and made it
available to the public as card reader in December 1997 (for 1,999 BEF, i.e. € 49.55). In
December 1999 some 8,000 readers had been sold, far under the target of 20,000 [Hove00].
Almost one year after the start-up there were only six online shops – all Belgium – that
accepted Proton payments over Internet. Currently there are 26 e-merchants accepting
68
Proton payments over Internet , still not very much. The cost for merchants were the
following: participating merchants pay a commission of 3% of the transaction value to
Banksys and 1% to the Internet access provider EUNet [Hove98].
7.4.2
Chip-Secure Electronic Transaction (C-SET)
One possible protocol to secure purse schemes for use on the Internet is Chip-Secure
Electronic Transaction (C-SET). C-SET is based on the SET protocol (see Section 7.2.2). CSET was tested in a nation wide project in France and is now an approved SET extension.
C-SET requires a number of hardware devices:
·
·
a chip card, containing a special area reserved for Internet payments;
a secured card reader (supporting several types of cards, secured against replacement of
internal software, supporting RSA, and certified by the card issuing bank)
·
·
an ‘electronic commerce black box’: a secured encryption unit
an ‘Internet Remote Payment Controller’: a payment gateway.
The consumer must obtain and install dedicated software.
The C-SET protocol operates as follows:
1. The consumer starts the payment procedure through the browser.
2. The consumer inserts his chip card into the card reader. The card reader works as a
payment terminal: the customer enters his PIN.
3. The Internet data in the chip plus the order data are encrypted with DES using the secret
key stored in the chip. The result is transmitted to the merchant.
4. The merchant forwards the data to the Internet Remote Payment Controller, who performs
security checks, and forwards the data to the banking network.
5. The result of the authorisation is returned to the merchant, who in turn notifies the
customer and finishes the sale.
6. The customer receives a receipt from his card reader.
68
According to the ePSO datatbase, see http://epso.jrc.es/
72
G
I G A
P
O R T
The customer can view the state of the payment. Additional hardware is available to
guarantee secure international money transfers and to translate SET to C-SET and vice
versa.
7.5
Most developments with regard to adapting real world payment instruments to the virtual
world seem to be devoted to the credit card system. The main developments are (1) adapting
credit cards for usage over mobile communication networks and (2) increasing the security of
credit card payments, e.g. by using chip card technology.
With regard to mobile developments, Visa and Nokia announced in a press release
69
that they
plan to co-operate on a project that aims to develop ways of making it easier to buy goods
and services over a mobile phone. The two parties reached an agreement to look for simple,
‘click-through’ payment methods for use with the Wireless Application Protocol (WAP), so - in
theory - users could activate payment to a provider of goods or services simply by choosing
an option onscreen.
Nokia indicated that they intend to add a second SIM card to their handsets to be used for
storing payment data. MasterCard and Motorola are working on a standard for wireless
buying. They announced their plans in July 2000. The standard will allow payment from a
Motorola Internet phone or other wireless device using a MasterCard. The agreement is part
of MasterCard’s Global Mobile Interoperability Group.
The development of the Nokia 6310 (recall Section 6.3) can be viewed in the light of enabling
mobile e-commerce (m-commerce) as well.
American Express issued the Blue Card, a credit card that besides the magnetic strip includes
a chip for payment on the Internet. The chip holds a certificate used for the authentication of a
wallet. The system further consists of a card reader, a PIN code, and software. American
Express guarantees against ghost payments, offers refund possibilities, guarantees delivery,
exchange and return possibilities. Blue was issued in Europe in Fall 2000.
69
G
See http://www.totaltele.com/view.asp?ArticleID=25811&Pub=tt.
I G A
A B P / 2 0 0 1 / D 0 . 1
B
73
8 Exploitation of electronic products
8.1
Introduction
In this chapter we discuss in further detail issues that arise when providers of digital content
and electronic services let consumers pay for the consumption of these products on a perusage basis, possible combined with direct payment. Of particular interest is the support for
payment transactions with a value in the range of about € 0.10 to € 5 (recall Figure 2). Thus
the exploitation strategy is ‘sliced payments’, ‘pay-per-view’ or ‘pay-as-you-play’.
We assume that the products are delivered electronically: CDs and DVDs contain digital
content, but they have a physical carrier. Delivery of such goods consequently takes place
through physical channels. Moreover, their value typically exceeds € 5. Payment issues
concerning the selling of physical goods in an electronic shop have been discussed in
Chapter 6.
8.2
Characteristics
First of all it should be noted that a usage-based exploitation strategy and direct payment, that
is payment just before or while consuming, introduce functional requirements that are less an
issue in a per-transaction, shop-like situation:
· Usage must be accurately measured,
That is, measured per consumer or consumer group. Then it is rated (charged) and
aggregated before payment can take place. This involves dedicated measurement
systems and more computational effort than in a fixed-price, transaction-based context.
Furthermore, if direct interpretation of the measured usage data is a requirement, then
there are various consequences for the architecture of the supporting system. For
example, the system must support (semi) real-time data processing for large data volumes
in that case.
· Payment and delivery systems are closely integrated,
If direct payment is used, the Operation Support System that controls the electronic
delivery of content or services will be connected to the payment system, or to the Business
Support System of which the payment function is a part (see Figure 17): if a (partial or
sliced) payment fails, delivery is stopped or not even started. Obtaining real-time feedback
on the transaction status (‘paid’) is hard when using the banks’ retail payment
infrastructure. The overall system design with aggregation, clearing and once-a-day
settlement is prohibiting such functionality (cf. [HiSt01].
Client
application
Product request
Product delivery
Delivery
application
‘Controls’
Operation
Support
System
Usage
Authorisation
Payment
request
Business
Support
System
Figure 17: Relations among payment and delivery systems
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
75
Other characteristics of content exploitation find their origin in the nature of the products that
are sold, and the distribution channel:
·
Prices per unit are low,
Resulting in small charges up-front, during or after consumption. The supporting systems
must be designed to be cost-efficient with regard to the expected charge amounts.
·
Marginal costs are low,
Meaning that the cost of producing an additional copy of an electronic good or providing an
electronic service to an additional customer is low. This makes copyright protection, or
more general Digital Rights Management, an issue.
·
Support for economies of scale,
Systems that implement DRM functions are costly when compared to the low prices per
unit. Thus high initial investments must be recouped by means of large volumes of
products. The system that handle the payment functions must therefore be able to support
such large volumes.
·
Support for ‘impulse buying’,
We expect content and service consumption in the consumer domain to be more subject to
‘impulse buying’ than in an e-commerce setting (partially because of the higher prices in
the latter situation). Consumers feel a need for information, entertainment or special
services and would like to see this need fulfilled in short notice. Subscriptions are an
obstacle for such ‘once-stop-shoppers’. This makes exploitation strategies such as ‘postpaid billing’ for the content or service provider less feasible, unless these providers
outsource these functions to parties that have a long lasting, recurring customer
relationship. In fact, the use of a billing concept when small charges are expected is
feasible only in a situation where users will frequently return for new purchases within a
billing cycle, i.e. the time-period between to subsequent invoices. Moreover, late- or nonpayers may causer debt collection costs that heavily outweigh the aggregated charges on
the bill.
There is an ongoing discussion about user’s willingness-to-pay in the context of content
exploitation. Most experts seem to agree that users are willing to pay for value-adding
services concerning content and content distribution, but that they are not for the content in
itself. We are not aware of scientific or market studies that address this topic however.
8.3
Potential payment scenarios
The value system of firms involved in the distribution of electronic products over
communication networks (see Figure 18) provides insight in the potential payment scenarios
for electronically delivered products. In fact, in this value system there are the Content
provider (starting-point) and Consumer (end-point), and in between various service providers
that together realise the distribution of the electronic data. There are the Access Network
Operators. They operate the co-called ‘local loop’, i.e. the telecommunication network that
connects the Consumer and Content Provider to the ISP, e.g. fixed phone (PSTN) and hired
line, cable, or mobile networks (GSM, GPRS, UMTS). The ISPs are connected through high
capacity (broadband) backbone networks for IP-traffic.
76
G
I G A
P
O R T
Content
provider
Consumer
Network access
Access
Network
Operator
Internet access & services
ISP
Network access,
transport
Network access,
transport
ISP
Network access,
transport
High capacity
interconnectivity
Access
Network
Operator
Backbone Network
Operator(s)
Legend:
Role player
Figure 18: Basic content distribution value system
In practise, those service providers that are involved in the distribution process and have a
direct relationship with the Consumer may also be involved in systems that realise payment
for the distributed content: the ISPs or the Access Network Operator. There are also providers
that are not involved in the electronic distribution, and that act as independent service
providers for (micro-)payment services or total solutions (including Digital Rights
Management). They target the Content provider as customer.
Thus there are various scenarios for payment for content distribution. We continue by
providing examples of scenarios where other parties than then the content provider realise the
collection of the content provider’s charges.
8.3.1
Example: ISP – Trivnet’s WiSP
Trivnet Ltd.
70
is a company with headquarters in Israel (founded in 1997) that develops
paymenet systems for IP environments. In particular they enable ISPs to charge transactions
to accounts held at that ISP or at a telecom network operator. This payment processing
system is called ‘WiSP’. The patented technology enables the system to automatically identify
the subscriber’s identity and billing information from the dynamically allocated IP number,
regardless of proxies ‘or other barriers…’.
The intended customers are merchants, ISPs, mobile service providers and billing companies.
WiSP allows to bill online purchases through multiple channels, like mobile telephone bills,
ISP bills, telephone bills, and credit cards. The WiSP payment solution has been operational
since February 1999. Trivnet’s business model is based on revenue sharing, in which
commissions paid by the merchant per transaction are shared between Trivnet and the
ISP/telco. For merchants there is no minimum charge per transaction, allowing the sale of
low-cost digital content.
70
G
See http://www.trivnet.com
I G A
A B P / 2 0 0 1 / D 0 . 1
B
77
To the user, the look-and-feel of a WiSP-enabled site is similar to a free web site. Consumers
do not need to download software or to register. WiSP jumps into action only when the user
clicks on the product he wants to purchase. At this point, Trivnet identifies the user by his ISP.
If the ISP is WiSP-enabled, the user sees a Purchase Authorization form created by Trivnet.
The form is based on details supplied by the merchant, such as product name and price. To
complete the purchase, the user must click Approve in the Purchase form. The user will be
charged on his next ISP/telco bill. Every transaction is also recorded in the Trivnet database.
At the end of the month, Trivnet transfers the transaction details to various ISPs so that they
can charge their users. The payment flow and transfer of funds between all parties involved in
the purchase process runs from user to ISP to Trivnet to merchant.
Users can track their WiSP purchases through the Personal Account Manager (PAM). They
may define a PIN for their WiSP account, to enhance the feeling of security and to prevent
WiSP purchases by unauthorized people who may have access to the user’s PC and ISP
account. Users can choose when WiSP will ask for the PIN from a number of options: when
purchasing an item, when purchasing an item from an adult-oriented merchant, or when
accessing the PAM.
Users connected to the Internet through ISPs that are not WiSP-enabled, can still use the
WiSP technology by using the WiSP Credit Card (WiSP CC). WiSP plans to support multiple
currencies and languages. Prices will then appear both in the user’s and the merchant’s
currency and purchase details in the user’s language. Each WiSP account has a credit limit of
$100/month; this limit can be adjusted by the ISP and Trivnet. The Traveler feature allows the
users to make WiSP purchases when he is not connected through his standard ISP, by
previously setting up a traveler username and password through the PAM.
We now describe the architecture of WiSP. To manage all the interactions between the
software and data, WiSP uses four servers:
The Central WiSP Server, responsible for synchronizing the flow of identification,
authorization, and billing, serves as the central authorizing agent for all WiSP transactions.
The Central WiSP Server is located near the Internet backbone and maintained by Trivnet.
The WiSP Identification Server interfaces with the ISP’s authentication servers to allow the
automaticidentification of the user.
The WiSP FTM Server serves as the gateway between WiSP transactions and the financial
world. The server tracks charges and payments, distributes revenues, and serves as a frontend for financial customer service. It is located near the Central WiSP Server and maintained
by Trivnet.
The WiSP Merchant Interface integrates with the merchant site and is responsible for
initiating the transactions, and managing pricing and authorisation for products.
Integration with the merchant’s site is established by the WiSP merchant API.
78
G
I G A
P
O R T
8.3.2
Example: Access network operator
The access network operator already has a payment relationship with the consumer: pre-paid
or post-paid, by means of billing. Content and electronic service providers could make use of
this relationship for their purposes. Their charges may be added to the operator’s bill or may
be made to the cost of the consumer’s pre-paid account. This approach will be facilitated by
the development of Open Service Access platforms such as Parlay (recall Section 2.4).
There are various problems that need to be solved in this case however:
·
Credit risk
By including charges of third parties in his bill the operator is running a larger credit risk. It
may even be the case that disputes over third party charges may delay payment for the
operator’s services that are on the same bill.
·
Banking licence
When an operator let ‘arbitrary’ service providers charge pre-paid accounts, operators are
starting to attract funds from the public and require a banking licence.
·
Payment on company’s account
The company for which the consumer works may pay for his (mobile) communication
costs. They may be less willing to pay also for the employee’s consumption of electronic
products outside working hours. Libertel offers ‘split billing’ to its customers: the bill is split
between company and employee. Calls and SMSs sent during working hours are charged
to the company’s bill. Other events appear on the employee’s private bill.
·
Transfer of transaction information
Information on the transaction needs to be transferred between content or service provider
and the network operator, such that this data can be incorporated into the operators billing
process. There are no standards for that (yet).
·
Technical support by commercial billing systems
It is not clear to what extent commercially available, telco-grade billing systems are
technically able to support the scenario that is presented above.
8.3.3
Example: ISP and Network operator – KPN’s SwitchPoint
KPN Telecom offers a service to Internet content and service providers, called ‘SwitchPoint’
that enables charging consumers of content or services through the consumer’s phone bill at
KPN Telecom. The service is able to support to types of charging policies: per-minute with an
upper bound of € 0.70 per minute, and per-visit (session), with a maximum of € 1.15 per
visit.
71
KPN guarantees payment to the provider, also when the consumer is late in paying the
phone bill.
For the consumer the service comes in three flavours: (1) SwitchPoint Connect, (2)
SwitchPoint Direct and (3) SwitchPoint PayTV (the latter focussing on payment for streaming
video and/or audio over Internet). In the first case, the consumer needs to install specific
71
G
According to KPN Telecom, http://www.kpn.com/
I G A
A B P / 2 0 0 1 / D 0 . 1
B
79
software on his PC. This is required only once. The software can be obtained from any site
that supports SwitchPoint as Internet payment instrument. The Connect service works as
follows. The consumer clicks on a special ‘SwitchPoint’ button on the web site. The
SwitchPoint software then disconnects the existing Internet connecting and establishes a
direct connection with a server on which the content (or service) resides for which the
consumer must pay. The consumer is informed on fore hand about the tariff. After leaving the
site the initial Internet connectivity is restored.
In the Direct service, no software needs to be installed. The consumer clicks a SwitchPoint
Direct button on the web site. He then obtains a phone number, tariff and access code. The
consumer calls this number (using any phone, e.g. mobile phone) and enters the access
code. If the provided information is correct, he gains access to the web site.
The PayTV service also supports charging a fixed fee during a pre-defined period, e.g. a
charge of € 1.00 for using the service for four hours. There is also a variant in development,
SwitchPoint Prepaid’ in which consumers obtain an access code to a site in advance, e.g. by
purchasing a scratch card.
The Connect service is most appropriate for consumers that have Internet connectivity
through a analogue modem, while the Direct service is specially designed for consumers that
have ‘always-on’ connectivity, e.g. using cable, ADSL or company LANs.
8.4
Total solutions for content-exploitation
In this section we mention systems that provide wide support for content-exploitation, i.e. they
integrate payment functionality with Digital Rights Management (DRM) and copy protection
mechanisms.
8.4.1
Magex
Magex is a company
72
and a product name. The company positions itself as a ‘commerce
enabler’ for mobile network operators, interactive TV (iTV) operators and financial institutions.
It started with a financial clearing service for digital goods (and micropayments) that is
discussed below. Currently they also target physical goods. Magex is backed by the Royal
bank of Scotland Group and has (among others) Mitsubishi and the Universal Music Group as
its customer.
Magex - the product - is essentially a copyright protection system for content distribution
combined with (micro-)payment functions and clearing. That is, Magex collects payments from
various consumers of content, from different content providers, in an international setting.
Magex acts as a Clearing House in the sense that it pays the content providers or copyright
72
See http://www.magex.com/
80
G
I G A
P
O R T
holders the net amounts. Moreover, it charges each consumer for his total consumption of
content.
Consumers are currently charged using credit card payments. From a consumer perspective,
the major drawback of the Magex system is the requirement to provide Magex with your credit
card details.
The content protection scheme in Magex consists of a secure DigiBox® container in which the
content object is placed. This container can only be opened using a Magex Wallet. The wallet
communicates with the Magex clearing house, for the purchase of a key for opening the
container. The wallet software is freely available. Third parties that want to access the content
also need this wallet software. At time of downloading this software, consumers need to
register with Magex, including the provision of credit card details.
8.4.2
Qpass
The company Qpass offers the Digital Commerce Service for the sale of content and services
over IP networks. This includes Internet, broadband and mobile networks, and the use of
several devices, such as personal computers, wireless phones, PDAs and interactive
television. Qpass offers a platform that can be used for marketing, sale, and distribution of
digital content and services online. This end-to-end solution includes product management
and merchandising, campaign management and promotion, distribution, customer care, and
transaction processing, billing, reporting and remittance. Customers can outsource these
activities to Qpass.
The Qpass Digital Commerce Service supports multiple payment options, including all major
credit cards, debit cards, ISP-billing, and some network-based electronic money. Qpass
integrates this service with its own wallet technology.
Qpass claims to have over 500,000 registered, regular users. Among their customers are
some influential publishers on the Web, like The New York Times, The Wall Street Journal,
the Los Angeles Times, USA Today, Forbes.com and Factiva (a Dow Jones/Reuters
Company).
8.4.3
NetBill
NetBill
73
was a trial system of Carnegie Mellon University of which CyberCash acquired the
commercial rights [Corc99]. The system is account-based: users must first create a NetBill
account from which money is debited after a purchase. The purchase itself is recorded in a
transaction log of the ‘Money Tool’, client software that verifies whether goods were received
intact and that sends a verification message of this to the merchant’s server.
73
G
http://www.netbill.com/
I G A
A B P / 2 0 0 1 / D 0 . 1
B
81
A generic scenario looks as follows:
1. The merchant’s server sends goods (electronically and) encrypted to the consumer’s
machine.
2. The Money Tool checks whether the goods arrived intact. It sends a verification message
to the merchant’s server.
3. The merchant’s server sends the verification message, account information and
decryption key to the NetBill server.
4. The NetBill server verifies if there is enough money in the consumer’s account. If so, it
transfers funds, stores encryption key and sends a report back to the merchant’s server.
5. The merchant sends the decryption key to the Money Tool upon successful payment.
If the merchant’s server fails before the completion of the last step, the decryption key can be
retrieved form the NetBill server.
8.5
Network-based electronic money schemes
Electronic money has been introduced in the 1990s in various forms: as card based electronic
cash issued by banks, and as so-called network money, issued by commercial non-financial
companies. The first type is discussed in [HiSt01]. It could be used in principal both on
Internet and in the physical world. We deliberately say ‘in principal’, since the issuers - the banks - have primarily focussed on the use of electronic money in real life. Only recently, after
the failure of the introduction for the physical world (consumers were not eager to use it
[FaEc98]), the organisations behind the card-based electronic money schemes are thinking of
application of card-based money on the Internet. Network money is electronic money that can
only be used on Internet.
The success story of network-based money is not impressive: various solutions have been
invented and introduced, but hardly any has been able to attract a large user base outside a
special early adopter community. DigiCash was an interesting system that enabled
anonymous electronic payment. The company filed for bankruptcy however and the
technology was taken over by eCash Technologies.
Several electronic cash companies went out of business, were taken-over (like CyberCash
that dissolved into VeriSign) or sought refuge in another type of business. Ecash is one of the
few operational electronic money schemes with a relatively long history. It is used in the
74
Online shop of the Deutsche Bank . Therefore we spend some attention to this type of
network-based electronic money below.
There is a list of initiatives in the section ‘Payments on the Internet’ in [BöRR99].
74
See http://public.deutsche-bank.de/global/ui/nav_ec.nsf/frameset/DMEL-47ULWU?OpenDocument
82
G
I G A
P
O R T
Ecash
Ecash is fully anonymous secure electronic cash for payment on the Internet. Since 1995
several banks and ISPs issue Ecash coins in various currencies. It was initially developed by
the Netherlands-based company DigiCash B.V., which filed for bankruptcy in 1998. In 1999
eCash Technologies Inc
75
76
acquired DigiCash’s ‘blind signature’ technology and other assets .
eCash Technologies is still operational, although they seem to have broadened their scope.
eCash is an open, non-exclusive system, available for implementation by any bank, or use by
any bank customer or merchant. An open approach is intended to facilitate wide acceptance
by banks, merchants, and consumers. The claim of openness suggests that eCash
Technologies has added interbank clearing or exchange of coins from different banks to solve
this problem. eCash Technologies provides the payment protocols. For example, they offer
the ‘Monneta’ payment suite, which is used by Deutsche Bank 24. The payment service
77
provider Bibit (see Section 5.5.1) will include this product in its platform . Providers make
money on eCash by processing transactions and by competing on value-added products and
services.
In the eCash system, the customer withdraws coins against his bank account. The customer
generates the coins. The bank signs the issued coins to make their validity visible to the
merchants. The bank subtracts the amount the coins represent from the customer’s bank
account. The bank can not see the serial number of the coin it signs. (It is encrypted with the
bank’s secret key and can be decrypted with the bank’s public key.) The bank uses a distinct
signature for each coin value. The coins are stored in the wallet software on the customer’s
computer. The wallet manages the coins and keeps a transaction log.
The customer transfers coins from the wallet to the merchant. During the transaction the
merchant forwards the coins to the bank to ensure they are valid and not double spent. The
coins are then deposited into the merchant’s account. The bank enables the check of double
spending by recording all coins that are deposited. Giving each coin an expiry date controls
the size of the database, and deleting all expired coins from the database.
An extra feature is the possibility of automatic payments, to specific merchants or for specific
sums. The payment mechanism is not only suitable for payments from customer to merchant,
but also the other way round (refund and payout). Payments from individual to individual are
possible, but must go through the bank. The system is not efficient enough for micropayments
(see Section 8.6).
The system guarantees anonymity of the customer; even merchant and bank together can not
identify the customer. To guarantee anonymity, however, it is required to pay exact. The
merchant does not remain anonymous; her identity is needed to prove the payment if
75
See http://www.ecashtechnologies.com/
According to ePSO’s Inventory Database: http://www.jrc.es/cfapp/invent/details.cfm?uid=30
77
According to Bibit’s press release of January 3, 2000: ‘Bibit joins Deutsche Bank in suporting payment solutions
from eCash Technologies’.
76
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
83
necessary. The protocol includes the sending of a payment request that contains the order;
this request is insecurely sent.
Customer and merchant must be registered with the same bank. Future developments might
include interbank clearing or exchange of coins from different banks to solve this problem. In
future a scalability problem might arise.
8.6
Evaluation of discussed payment systems
We treated various payment systems for use in different contexts in the previous chapters. In
this section we briefly evaluate the applicability of the major systems in the current context of
exploitation of electronic products, of low value payments (under € 5, recall Figure 2).
The payment instruments offered by the financial sector seem to be hardly appropriate for
these type of transactions, either by processing and settlement delay, their transaction cost or
that they seem to have been designed for a particular payment context. As an example, credit
cards are not suitable for adult sites or on-line gambling because card organisations have
banned such merchants. The risk for fraud or charge-backs for transactions from such
merchants is too large.
The most promising solutions are those developed by the telecom sector and ICT industry, for
example TrivNet’s WiSP (Section 8.3.1), PayPal (Section 5.2.1) and the Open Service Access
platforms in development, like Parlay (Section 2.4), that allow service and content providers to
charge to the telecom operator’s billing and pre-paid systems. The latter solution is certainly
useful on the mobile Internet. It has not been specifically designed for use on the fixed
Internet.
We consider KPN’s SwitchPoint Connect service (recall Section 8.3.3) as an intermediate
solution as it is most appropriate in situations where consumers have Internet connectivity
through a dial-in phone number. The trend is towards always-on solutions. SwitchPoint Direct
offers a good solution in that situation. From a consumer’s point-of-view that latter has the
benefit that not special software needs to be downloaded and installed. Charging in the
SwitchPoint services is limited however to time- and session-/visit-based policies.
Electronic money may be playing an important role in establishing payment for low-value
electronic content and services in future. To some extent, network-based money has been
designed with commercial exploitation of content in mind. Card-based money could play a
role if a sufficiently large number of cardholders has card readers and applications that can
use the readers and cards for conducting payments over the Internet. Currently, both types of
electronic money do not have a promising usage history on Internet (recall Sections 7.4 and
8.5).
84
G
I G A
P
O R T
9 Micropayment systems
9.1
Introduction
Apart from network-based electronic money (Section 8.5) developers have designed and
implemented various types of systems that can handle low- and micro-value payments, i.e.
payments in the range of about € 0.10 to € 5, over the Internet (recall Figure 2). These are
typically called micropayment systems. The driver behind these developments was the
commercial potential of on-line content in relation to ‘sliced payments’, ‘pay-per-view’, or ‘payas-you-play’ type of exploitation strategies [Herz98].
Let us consider these systems in more detail.
9.2
The problems to solve
Designers and operators of micropayment systems must face and solve various problems:
Technical challenge
The main technical problem is to realise a system that is able to process micro-value
transactions with as little delay as possible, with an appropriate level of security, typically
depending on the value of the transaction. Therefore, the cost per transactions should be as
low as possible. Moreover, any micropayment system must be able to handle a large number
of concurrent users. Establishing large transaction volumes is an essential part of a
sustainable business case for micropayment systems.
A sustainable business case
In fact, the main problem with low-value payment systems and micropayment systems in
particular has a business nature: making a sustainable business case. The margins on sales
will be small for content and service providers. Therefore, the potential revenue per
transaction or the price for a periodic fee that an operator of a micropayment system can ask
for its payment services is small as well. The fee will be charged to the merchant primarily:
consumers are accustomed to payment transactions being free of charge.
From the point of view of such an operator, establishing a large customer base in short time
(consisting of both providers and consumers) and sustaining this base is essential for its
financial well-being. The operator (and the providers) must also seek to create a large active
customer base: transaction volume is essential.
It seems that the most appropriate business model would be to charge merchants a fixed fee,
say per month, combined with a per-transaction charge based upon a percentage of the
transaction value. Even if the technical system is able to reduce the cost per transaction to a
few cents or even fractions thereof, the operator of the system needs to create huge
transaction volumes in order to create some revenue in this way.
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
85
On the other hand, micropayment systems are fairly complex, from a technical point of view.
Therefore they are expensive to develop and operate. [Jong00] mentions a yearly recurring
operational cost of about € 50,000. The initial investments to get the system operational will
be of an order of magnitude € 500,000. Thus the operator needs a large number of users and
a long time period in order to get return on his investments.
The operational quality of service problem
Micropayment systems must be combined with high quality content delivery services. If
delivery is not successfully established, then any call of the consumer to a helpdesk or
customer care center will cost a factor 10 to 1000 more than the value of the content that was
sold. As Steve Crocker [Croc99] puts it: ‘Customer service becomes a serious burden in the
micropayment world.’ If the primary service or content provider decides to provide poor
customer care facilities instead, then this may harm his long-term revenue as well. In fact,
customers that receive bad quality or want to complain may distribute negative advertisement
in their environment, because the appropriate customer care facilities are lacking. This may
discourage potential customers or stop established customers from recurring.
Thus, it is uncertain whether a large customer base paying a micro-fee is able to provide less
cost (and generate return on investment) than the same customer base using the same
services or content for free. In the first case the initial fixed costs and recurring costs are
higher, because of the more complex ICT systems needed to realise micropayment and
optimal quality of service. The expected ‘killer’ for the micro-fee case is the customer care
cost however. They potentially wash away any profits the service or content provider could
have made so far.
It should be noted however, that the absence of significant volume in any of the available
micropayment systems makes it hard to predict the actual size of customer care costs and
see whether assured delivery is an important way to reduce these costs [Croc99].
9.3
Potential players
Recall that aggregation is the key to any micropayment system. Aggregation of transactions
can take place at the content or primary service provider, for example in the token-based
systems, or aggregation takes place at the payment system operator, i.e. in the account
management system. In the latter case the operator has the choice between pre-paid
deposits or post-paid billing solutions for collection from the consumer.
In both cases a fairly good relationship between payer and payment system operator is
required. The payer must trust the operator in order to make a deposit upfront. In case of
post-payment the operator must have some means to act appropriately if the consumer pays
late or does not pay at all. In fact, the operator is providing credit. Banks and network
operators may be best suited as operators. Deposit taking may even imply that the payment
system operator must have a banking licence. Thus network operators must either collaborate
with banks or effectively become banks themselves.
86
G
I G A
P
O R T
Telecom operators have the advantage over banks and other potential players that they
already have systems operational that can be viewed as micropayment systems. The pre-paid
and billing systems for fixed and mobile voice communication handle low value telephone call
and SMS ‘transactions’.
With the advent of 2.5 and 3G mobile networks these systems are adjusted for processing
data traffic as well. We expect that the operators of these new networks will play a crucial role
in the processing of micro- and low-value payments related to services that third parties
deliver over these networks. The development of the OSA Parlay platform (see Section 2.4)
supports this expectation. This platform allows these third party service providers to use the
operator’s billing and pre-paid systems (among others), which can regarded as quite effective
micropayment systems when considering the relatively small charges for phone calls and
SMSs.
9.4
Commercially available micropayment systems
The technical challenge as mentioned in Section 9.2 can be solved. Various systems have
been devised. The most important to mention are IBM Micropayment ([HeYo97], formerly
called MiniPay, now part of a spin-off company called NewGenPay), Millicent
78
(from DEC,
now Compaq [GMA+95]), and Jalda™ (from EHPT). The latter is more a general purpose API
for payment over the Internet that enables to charge an account held at a central Jaldacompliant server, such as Safetrader™ from EHPT (recall Section 5.2.2). CyberCash also
developed a micropayment system, called CyberCoin. It slowly disappeared from the market
however at the end of the 1990s.
None of these system have been really successful. The main problem has been devising a
sustainable business model. Only NewGenPay’s micropayment solution seems to be used. A
79
micropayment service provider in the Netherlands, Cartio , is active with pilots within
companies. Employees can use the system to pay for content. Although hardly successful we
still provide details on the most promising systems, because of the general interest of content
and service providers in the capabilities of these systems and helping to understand further
the possible reasons for lack of their success.
Aggregation is the key to designing a micropayment system [Croc99]. It is therefore key to
any of the products mentioned above. Small charges are aggregated before they are settled
with payment systems that are efficient in the medium transaction value range, for example
credit cards, bank transfers or paper-based invoicing and bill payment. The basic approaches
to micropayments are:
78
79
See http://www.millicent.com/home.html
See http://www.cartio.nl
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
87
1. centralised account management,
in which a central system efficiently processes (micro-) transfer orders between accounts.
These micropayment accounts may be loaded on forehand (pre-paid) or account holders
may be charged afterwards. The Jalda-based Safetrader payment server (from EHPT) and
the CyberCash system are based on this approach;
2. electronic tokens,
which simulate physical coins. The tokens represent (micro-) buying power. The exchange
of tokens between user en service provider systems implements the payment function. In
this approach the payer needs to buy tokens first. The vendor collects the tokens over time
and changes them back to cash or bank money. Millicent is a micropayment system that
uses this approach. Network-based electronic money provides another class of examples.
3. credentials,
that show that the buyer is able to pay his debts later on. Transactions are logged and
forwarded in batch to dedicated (distributed) processing and clearing systems, which also
administer the payment obligations for individual payment system users. Aggregation thus
takes place at the merchant and in these clearing systems.
For many micropayment systems the level of security is such that fraud is more expensive
than a purchase.
9.4.1
NewGenPay’s Micropayment solution (former IBM)
NewGenPay
80
is a small spin-off company of IBM that continued the development of payment
systems and infrastructure for the Internet. They are continuing the development of the former
‘IBM Micropayment’ solution [HeYo97]. We shall call NewGenPay’s solution simply
‘Micropayment’ in the sequel.
The following description of the system is partly taken from [Herz98]. The basic idea behind
the system is that the bottleneck is communication, not encryption/decryption, and hence
communication is minimised. Over 10 transactions per second are supported at the
merchant’s; the delay for the buyer is very small compared to the normal time for following a
link. The system has a unique architecture that does not require a central organisation or
server. Thus it tries to maximise acceptability.
The Micropayment protocol distinguishes three types of entities: the content provider, the
customer, and billing systems. Content provider and customer may have their own billing
systems: a typical billing system for the customer is the Internet Access Provider, a typical
one for the content provider his bank or Internet Service Provider. Micropayment allows an
additional ‘gateway’ billing server to connect between their billing servers, for scalability.
The Micropayment protocol involves two periodic - typically daily - processes. At the
beginning of every day, the buyer's wallet exchanges with its billing server the total spending
80
See http://www.newgenpay.com
88
G
I G A
P
O R T
for the previous day and once the balance is synchronised, the billing server provides the
wallet with a ‘daily credential’. This daily credential proves that the customer is a good
customer as of that day; one could think of it as a new plastic card sent from the bank once
every day rather than every year or so as common today.
When the customer reaches a page with a ‘per-fee link’, this link will display on the browser
using the Micropayment plug-in, which makes it appear a bit different from ‘regular’ links - in a
rectangle rather than underlined. Furthermore, when the cursor moves over a per-fee link, its
shape changes to reflect the fee - to either a cent sign or a dollar sign, where the cent is an
amount under a user-defined threshold, and a dollar indicates an amount over that. Other
currencies can be used as well. When the user clicks on the per-fee link, the Micropayment
plug-in piggybacks a signed payment order, and the daily credential, on the regular request
for the link. Note that no new window opens - the user experience is very similar to normal
browsing.
The Seller software verifies the daily credential and the signature from the buyer. Following
that, the seller software decides whether to perform an on-line confirmation with the billing
server of the buyer. This decision is based on the total spending by this customer on this day,
and a parameter set by the merchant.
At the end of the day, an efficient deposit and clearance protocol is run between the seller and
the seller's billing server, and among all billing servers.
Figure 19 illustrates the protocol.
buyer’s
billing
daily deposits
service
daily
credentials
seller’s
billing
service
daily
deposits
overspending
prevention
buyer
seller
payment order
Figure 19. IBM Micropayment protocol.
Micropayment allows for prepaid as well as credit accounts. It does not offer refund
functionality. Micropayment uses an automated compiler tool that transforms HTML to turn
normal links into Micropayment links. The seller may therefore use any HTML editor, and may
change links from non-paid to paid. The authentication is based on peer-to-peer relationships.
It is effective in reducing overheads associated with transactions since it is not compulsory to
verify all transactions. This leads to the risk of customer ‘overspending’ since it is possible for
a wallet to become empty without the transaction being verified. The developers’ viewpoint is
that every party should take its own risks. Hence, a company that wants to prevent
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
89
overspending must set its own rules for preventing losses such as, for example, checking
limits online.
Utilising a deposit and clearance protocol which requires all servers to interact could be
vulnerable to network outages. Widespread availability of compatible billing systems may also
be an issue, as with many billing/payment systems.
9.4.2
Millicent (Compaq) – a token-based system
Millicent
81
is a micropayment system developed by Digital Equipment Corporation (DEC),
which has been taken over by Compaq. It supports payments ranging from $0.001 to $5.00. It
offers functionality for per-access purchase, subscriptions, promotional incentives, advertising
rebates, tiered service levels and loyalty programs.
It aims at three market segments:
1. Software developers and distributors.
Millicent supports sale and rental of Java applets, ActiveX controls, software add-ons and
games.
2. Information marketplace.
E.g. for selling stock quotes, database queries, articles, research, cartoons, clip art, music
and video.
3. Corporate intranets.
Meter access to applications, services, databases and information resources.
The system uses prepaid accounts that are managed by a so-called ‘broker’, thus reducing
credit risk. A user can debit their account in return for so-called ‘broker scrip’, electronic
coupons representing a prepaid value. These coupons are stored in a special Millicent wallet
in the consumer domain: client software that is part of a Web browser as a plug-in. The
consumer can change broker scrip into vendor or service provider specific ‘scrip’ and visaversa at the broker. The wallet also stores the changed scrip before spending.
Thus, scrip is comparable to usual cash: both have an intrinsic value, however scrip can only
be used with one vendor, unlike cash. Because scrip lacks general acceptance, it cannot be
regarded as electronic money however. It should be viewed as ‘tickets’. Brokers will generally
sell the scrip of various – but a limited number of – different vendors. The vendor scrip can
either be generated by the vendor or by the broker. In the first case, the broker buys a large
chunk of vendor scrip and stores it. In the second case, the broker has a license for the
production of a specific amount of vendor scrip. The broker makes his money by buying at
discount from the vendor and selling at full price to the customers. The broker role can be
fulfilled for example by banks or ISPs.
81
http://www.millicent.digital.com/
90
G
I G A
P
O R T
In a transaction the customer sends a purchase request to the vendor, and sends the
obtained vendor scrip along. The vendor can validate the payment. This includes a double
spending check. For this action he does not need the involvement of a third party. After
approval, the vendor returns the purchase and sends the change along (in vendor scrip). The
customer can use the change in another transaction with the same vendor. The acquired scrip
is stored in the customer’s wallet.
The system reduces processing and communication costs by using light-weight encryption: it
uses symmetric encryption and a one-way hash function. There are three levels of security
during transfer. The protocol for the desired level of security can be chosen. The first level is
unsecured, on the second the connection is encrypted, and the third level does not guarantee
privacy but protects against theft. Furthermore, verifying accounts through coupons at the
vendor’s site reduces the need for a validation server at the broker’s site. Scrip is not fully
anonymous: it shows serial numbers.
82
For more information, see the following resources: a paper on the Millicent Protocol , an
83
executive summary , [GMA+95], and also [MaPT97]. We found no information on recent
usage of the system in a commercial setting.
9.5
Micropayment standards and standardisation efforts
There are only a few standards available, or better: ‘almost standards’, because the activity
on their development seem to have been placed on hold at the end of the 1990s. We mention
the two most important initiatives in the following sections. Both were initiated by the World
84
Wide Web Consortium (W3C) . Currently W3C has closed its Ecommerce/Micropayment
Activity.
85
9.5.1
A Common Markup for micropayment per-fee-links
The W3C defined a micropayment task
86
as part of its e-commerce activity. A Micropayment
Markup Working Group was created that worked out a specification for the encoding of perfee links in HTML pages [W3C99]. Per-fee links are hyperlinks in a web page that require
(micro-) payment in order to be activated. In the W3C’s vision, if a customer clicks on a link
requiring a payment, the browser would look for an electronic wallet. The starting point is then
a standard way to represent payment information for following hypertext links from Web
pages. The ‘Common Markup for micropayment per-fee-links’ specifies especially such a
representation.
82
http://www.research.digital.com/SRC/personal/steveg/millicent/millicent.html
http://www.millicent.com/works/index.html
84
See http://www.w3.org/
85
According to http://www.w3.org/Ecommerce/Activity.html
86
See http://www.w3.org/ECommerce/Micropayments/Overview.html
83
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
91
The browser can interpret the embedded information to show the cost of each link to the user,
and to ask the wallet to make a payment when the user clicks on a link. The browser
communicates with the wallet via an Applications Programming Interface (API). When the
user makes a payment via the browser, the browser talks to the wallet, and the wallet initiates
the payment. This may involve a third party payment server. Some kind of token, or other
form of recognition of payment, is sent to the Web server, and the document, image, or other
Web resource, is made available to the user. Furthermore, the wallet will keep track of
payments and credit.
Customer side
Wallet 1
Wallet 2
User agent
Merchant side
Internet (WWW)
Per-Fee-Link
Handler
Web
server
Wallet 3
Browser
Common Markup for
per-fee-links
Browser-to-wallet API
W3C’s focus
Figure 20: W3C’s basic micropayment architecture (after [W3C99]).
A browser should be able to use multiple wallets in order to support several payment systems.
A consumer should be able to access each wallet independently of the browser. Some
systems may involve loading of the wallet. This is beyond the scope of the presented
architecture. The specification [W3C99] focuses specifically on the flow of information from
the Merchant server to the Per Fee Link Handler/Browser, in particular the mark-up of
payment information embedded in the HTML page (see Figure 20). The Per Fee Link Handler
is a common module that may be implemented as an applet or a browser plug-in.
The W3C Micropayments API Working Group aimed to produce an API to transfer the
micropayment information, defined in the Web page, to the wallet for processing. The API
would be browser- and payment scheme-neutral, thus allowing for different payment
mechanisms to be dropped into place as needed. Users would be able to download new
payment schemes without further changes to their browsers. No further information on the
results of this Working Group were available.
9.5.2
(Draft) Micro Payment Transfer Protocol (MPTP)
Already in 1995 the W3C initiated the development of the Micro Payment Transfer Protocol
(MPTP). Philip Hallam-Baker created a working draft. After the release of this document
87
on
November 22, 1995, no further progress seems to have been made. MPTP implements a
variation of the Pay-Word scheme for micropayments proposed by Rivest and Shamir (finally
published in [RiSh97]).
87
http://www.w3.org/TR/WD-mptp-951122/
92
G
I G A
P
O R T
Pay-Word uses an account-based approach. Thus, the protocol involves three parties: a
Customer who makes the payment, a Vendor who receives the payment and a Broker who
keeps the accounts for the parties concerned. The draft only considers a single broker model,
implying that both customer and vendor must share the same broker. For further details
please consult the W3C working draft.
9.6
The future of micropayment systems
Establishing a sustainable business model for the exploitation of dedicated micropayment
systems is a major obstacle in the way to success of these systems. Another is the
consumer’s willingness to pay per-item, to be ‘nickelled and dime-ed’. Subscriptions compete
with a pay-per-item approach. In particular for the content or service provider subscriptions
have two major benefits: (1) a guaranteed income, hence predictability, and (2) information on
the provider’s customer base. The concept of a micropayment system seems to be biased
towards impulsive consumption (recall Section 8.2) and consumer ‘anonymity’ (although not
completely).
We already pointed out that a large transaction volumes needs to be established before a
micropayment system can be exploited profitably. Micropayment systems thus face the typical
‘chicken-and-egg’ type of problem that payment systems in general face: consumers will use
the system only if there are sufficiently many interesting products to purchase, while providers
of these products will await the moment that the system has a sufficiently large user base. A
fundamental question therefore is, ‘…are there sufficiently many interesting products on the
Internet (content, services) for which consumers are willing to pay?’ (cf. also [Jong00]).
According to [Ston01] there are various reasons why the micropayment concept has not taken
up so far. Experts say that consumers do not want it, because they want predictability, i.e.
subscriptions, similar to the content and service providers. They also stress the role of the
‘operational quality of service problem’, or ‘customer service trap’ (recall Section 9.2) that
makes a profitable business hard to establish.
There are also possible sounds to hear however. In France, Minitel is extensively used for
about 10 years now, including micropayments. It seems that the SwitchPoint approach
(Section 8.3.3) is also quite successful, especially in the adult entertainment segment. Both
systems have in common that they are closed systems. There already exists a customer
relationship with regard to other services than payment and payment is only possible for
content and services of providers that have a specific business relationship with the provider
of the payment system. They are not general purpose payment systems within the context of
Internet payments. Also Cartio (Section 9.4) seems to first target closed user groups, inside
specific companies.
The dedicated payment systems that we discussed in this chapter were targeting special
payment service providers, focussing on micropayment transactions for general users on the
Internet (like the Internet Payment Provider in the Jalda model, Section 5.2.2). We feel
inclined to conclude from the discussions above that such a model is not economically
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
93
feasible in the short or medium term. It will become feasible only when consumers gradually
get used to paying for content or electronic services on Internet. We see two ways in which
this might happen, which can occur concurrently [HiBi01].
Firstly, card-based electronic money may find its way to Internet for micropayments using
general-purpose card readers, e.g. complying to the FINREAD standard (see [HiSt01]). Since
financing the distribution of card readers is a major obstruction in getting card-based
electronic money on-line, the general-purpose aspect of the card reader is essential in
achieving a sufficiently large customer base. It opens an opportunity for other parties than the
consumer or financial institutions to subsidise card readers, as they can also be used for e.g.
loyalty programmes or authentication on special web sites.
Secondly, third party service providers, such as telecom operators, may open their billing (and
pre-paid) systems for others. We already mentioned the OSA Parlay initiative at various
points. In fact, their billing systems can already be considered as special purpose
micropayment systems. It is still a challenge for billing system developers to design and
implement systems that are able to deal with charges from various providers, for various
services and content. The first steps in this direction have already been made however, and
they look promising.
94
G
I G A
P
O R T
10 Conclusions
10.1
Coverage of on-line payment transactions
Recall the three payment contexts with which we started this document (Section 1.1, Figure
2): bill payment, electronic commerce and exploitation of electronic products (content and
services).
The advent of the digital acceptgiro (Section 3.6.1) and the current developments with regard
to digital signatures that will enable signing mandates for direct debit on-line, will result in a
rather complete set of payment instruments for bill payment that can be used on-line. These
instruments will be provided by the financial sector.
In electronic commerce there are various payment instruments currently available.
Bottlenecks are still formed by cross-border payments and support for ‘direct payment’. The
credit card is the main instrument in the first type of transactions, and is also the main
instrument in domestic transactions initiated through Internet. However, not all Internet user
groups have or even can have a credit card. Other instruments are thus required as well, in
particular instruments that realise ‘direct payment’.
The architecture of the overall payment system as provided by the financial sector currently
inhibits the development of general direct payment systems. The systems that are available
use dedicated accounts: consumer and merchant needs to have such an account at the
payment system operator, typically a bank. In lower value e-commerce transaction also nonfinancial institutions may be going to play a role. There will be a role for value-adding
Payment Service Providers as well: for currency exchange, localisation of the set of payment
instruments offered by the merchant to the consumer, for out-sourcing Internet cash register
functionality and fraud and risk management functions.
Currently there are hardly any Internet payment instruments that support the exploitation of
low-value content or services on a per-use basis. General-purpose micropayment services
provided by a payment provider are not economically feasible on the short and medium term.
We expect card-based electronic money issued by the commercial banks and connected to
the Internet by means of a general-purpose card reader to fill the gap, together with
(relatively) open access to billing and pre-paid systems of (mobile) network operators.
[Hove00] and [FuWr00]argue that ‘on the Internet, the market of interactive pay-per-use
services is underdeveloped because of the lack of an efficient payment mechanism for these
applications. Stored value systems would provide the payment mechanism required to
facilitate payment for such services’
10.2
Cultural impact
Cultural aspects are very important to take into account. Differences in payment culture
influence to a large extent the success of introduction of new payment services in a specific
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
95
country. It may also influence the success of introduction of payment enabling services such
as electronic bill presentment. For example, successful US players in the EBP market turned
out not to be successful (initially) on the European market. Moreover, a payment service
provider as Bibit Internet Payments and a credit management company as Intrum Justitia
stress the importance of tailoring their services towards the local, national culture. ‘Think
global, act local’.
System developers and integrators should also be aware of the cultural differences in
executing financial transactions and reporting over such transactions. For example, standards
such as ECML, OFX and IFX have been developed with the Anglo-Saxon way of doing
business in mind. This may make these standard less suitable for use in other cultural
regions, or may even inhibit their use.
10.3
Introduction of new payment services and instruments
Application of technology may create new payment instruments. The design and
implementation of such new instruments is one, but creating a substantial user base is
another problem. According to [BIS99] (Section 4.2), it is the demand from a body of users
that drives the development of the payment markets; not the technology however.
The challenge with regard to the introduction of new payment services, both on the Internet
and the real world, is to predict and promote a change in user behaviour [Econ01]. Such
changes seem to be triggered as if by accident: successful examples are the pre-paid mobile
phone and the mobile-phone text messaging (SMS).
A change in user behaviour does not only relate to the use of the payment instruments
themselves, but also usage of the services for which the user has to pay. We mentioned the
necessity of a change in user behaviour in order to make electronic bill presentment (and
payment) a success (Section 3.6.2). We also mentioned the importance of a change in
customer behaviour with regard to payment for content on Internet in relation to
micropayments (Section 9.6).
10.4
Telco-finance integration
‘Telco-finance integration’ is a term that has been dropped to indicate the potential merging of
the roles of provider of telecommunication services with that of financial services, in particular
(mobile) payment. It seems that financial institutions and telecom network operators are
competing in this field, with the initiative with the operators.
The situation is not as simple as that however. Looking at the various payment contexts that
we considered (Section 1.1, Figure 2), competition only seems to take place in the electronic
commerce context, and in that context only in the lower end of the transaction value. Medium
and high-value transactions will remain to be handled by the financial sector. Consumers do
not buy a car with their hand-held. It is a matter of trust. Thus bill payment and the higher end
96
G
I G A
P
O R T
of electronic commerce transactions will be paid for by means of instruments provided by the
financial sector.
The payment instruments that the telecom sector is currently developing aim at supporting
content exploitation and low-value commerce transactions. There is hardly any competition
with financial institutions in that field, perhaps only with regard to electronic money. The
operators may gain an additional source of revenue from such value-adding services. The
revenue for financial institutions from processing such low-value transactions is marginal
compared to their other business operations. It may even be only a source of additional costs.
The only competition that we see is on attracting funds from the public, when using pre-paid
accounts for payment of services from other parties than the operator. It may cause
consumers to move substantial funds from a bank account to an operator’s pre-paid account.
However, the current banking legislation in the Netherlands would see such an activity – using
pre-paid deposits for general purpose payments – as an activity for which a banking licence is
required. The telecom operator is required to become a bank. In this scenario, there will not
be a competition between banks and telecom operators, but between new banks owned by
telecom operators and the banks that have been operational for decades.
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
97
Acronyms
ADIF
Accounting Data Interchange Format
CDR
Call Detail Record
CEPS
Common Electroni Purse Specification
DNB
De Nederlandsche Bank N.V.
EBP
Electronic Bill Presentment
EBPay
Electronic Bill Payment
ECML
Electronic Commerce Modelling Language
EIP
Electronic Invoice Presentment
EIPP
Electronic Invoice Presentment and Payment
EJB
Enterprise Java Beans
EPF
Electronic Payment Forum
GBA
Global Billing Association
IETF
Internet Engineering Task Force
IFX
Interactive Financial Exchange
IPDR
Internet Protocol (IP) Detail Record
JEPI
Joint Electronic Payment Initiative
IRTF
Internet Research Task Force
M3I
Market Managed Multiservice Internet
NACHA
National (U.S.A.) Automated Clearing House Association
OFX
Open Financial eXchange
PFMS
Personal Financial Management System
PIN
Personal Identification Number
VAT
Value Added Tax
W3C
World Wide Web Consortium
98
G
I G A
P
O R T
References
[AuKa01] Au, Y.A., and R.J. Kauffman, ‘Should We Wait? Network Externalities and
th
Electronic Billing Adoption’, Proceedings of the 34 Hawaii International
Conference on System Sciences, 2001.
[BIS96]
Bank of International Settlements, ‘Security of Electronic Money’, Basle, August
1996.
[BIS99]
Committee on Payment and Settlement Systems, ‘Retail payments in selected
countries: a comparative study’, Bank of International Settlements (BIS), Basel,
September 1999.
Available at: http://www.bis.org/.
[Böhl01]
Böhle, K., ‘The Potential of Server-based Internet Payment Systems – an attempt
to asses the future of Internet payments –‘, Background Paper No. 3, Electronic
Payment Systems Observatory (ePSO), March 2001 (Working draft).
http://www.jrc.es/pages/projects/epso/Docs/Background-3.pdf
[BöRR99] Böhle, K., M. Rader, and U. Riehm, ‘Electronic Payment Systems in European
Countries; Country Synthesis Report’, IPTO/ESTO, September 1999.
http://www.jrc.es/pages/projects/docs/ESTOCSRfinal.pdf.
[Cave01] Cave, D., ‘Losing faith in PayPal’, Salon.com, February 23, 2001.
Available at: http://www.salon.com/tech/feature/2001/02/23/pay_pal/print.html.
[CBS01]
‘De digitale economie 2001’, Centraal Bureau voor de Statistiek, Voorburg, The
Netherlands, 2001 (in Dutch).:
http://www.cbs.nl/nl/producten/artikelen/bedrijfsleven/algemeen/p-34-01.pdf
[CEBP99] NACHA’s Council for Electronic Billing and Payment, ‘An Overview of Electronic
Bill Presentment and Payment Operating Models; Process, Roles,
Communications, and Transaction Flows’, white paper, National Automated
Clearing House Association, April, 1999.
Available at http://cebp.nacha.org/.
[CEBP01] NACHA’s Council for Electronic Billing and Payment, ‘Business-to-Business EIPP:
Presentment Models and Payment Options’, white paper, National Automated
Clearing House Association, January 2001.
Available at http://cebp.nacha.org/.
[Croc99]
Crocker, S., ‘The Siren song of Internet micropayments’, iMP (The Magazine on
Information Impacts), April 1999.
http://www.cisp.org/imp/april_99/04_99crocker.htm
[DBG+98] Daswani, N., D. Boneh, H. Garcia-Molina, S. Ketchpel, and A. Paepcke,
‘SWAPEROO: A Simple Wallet Architecture for Payments, Exchanges, Refunds,
rd
and Other Operations’, 3 USENIX Workshop on electronic commerce, Boston,
Massachusetts, U.S.A, August 31 – September 3, 1998.
Available at: http://www-db.stanford.edu/~daswani/wallets/.
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
99
[EaGo99] Eastlake, D. and T. Goldstein, ‘ECML v1: Field Names for E-Commerce’, IETF
RFC 2706, October 1999.
http://www.ietf.org/rfc/rfc2706.txt
[ECB98]
European Central Bank. “Report on Electronic Money”, August 1998.
http://www.dnb.nl/betalingsverkeer/index.htm.
[ECB01]
European Central Bank, Payment and securities settlement systems in the
European Union, Blue Book, European Central Bank, June 2001.
Available at: http://www.ecb.int/pub/bluebook/bluebook.htm.
rd
[Econ01] Anonymous, ‘Dreams of a cashless society’, The Economist, May 3 2001.
Available at: http://www.economist.com/
[ECP00]
‘Betalen op Internet: Keuzemogelijkheden met de Nederlandse betaalsystemen’,
Electronic Commerce Platform Nederland (ECP.NL) / Nationaal Chipcard Platform,
Leidschendam, January, 2000.
http://www.ecp.nl/publicatie/publicaties/betalen_op_internet.pdf
[ETSI01]
European Telecommunication Standards Institute, Open Service Access;
Application Programming Interface; Part 12: Charging, Draft ETSI ES 201 915-12
V0.0.0, August 2001.
[FaEc98] ‘Keep the change’, The Economist, November 21, 1998, pp. 77-78.
[FuWr00] Furche, A., and G. Wrightson, ‘Why do stored value systems fail?’, Netnomics, Vol.
2, Nr. 1, 2000, pp. 37-47.
[GMA+95] Glassman, S., M. Manasse, M. Abadi, P. Gauthier, and P. Sobalvarro. ‘The
Millicient protocol for inexpensive electronic commerce’, in World Wide Web
Journal, Fourth International World Wide Web Conference Proceedings, O’Reilly,
December 1995, pp. 603-618.
[Herz98]
Herzberg, A., ‘Safeguarding Digital Library Contents – Charging for Online
Content’, D-Lib Magazine, January 1998, (ISSN 1082-9873). Available at:
http://mirrored.ukoln.ac.uk/lis-journals/dlib/dlib/dlib/january98/ibm/01herzberg.html
[HeYo97] Herzberg, A. and H. Yochai, ‘IBM Micropayment: Charging per Click on the Web’,
th
6 WWW Conference, Santa Clara, California, April 1997.
[HiBi01]
Hille, S.C. and F. Biemans, ‘Elektronische dienstverlening zit vast op
betalingsprobleem’, Automatisering Gids, jrg. 35, nr. 48, November 30, 2001, p.15
(in Dutch).
[Hill00]
Hille, S.C., ‘Legal and regulatory requirements on accounting, billing and payment’,
GigaABP project deliverable D1.4, Telematica Instituut, November 2000.
Available at: https://extranet.telin.nl/docuserver/dscgi/ds.py/View/Collection-1259
[HiSt01]
Hille, S.C. and P. van der Stappen, ‘Backgrounds on the Dutch payment system;
Organisations, infrastructure, systems and services’, GigaABP project deliverable
D0.1a, Telematica Instituut, Enschede, December 2001.
Available at: http://gigaabp.telin.nl/ (‘Publications’).
100
G
I G A
P
O R T
[Hove00] Hove, L. van, ‘Electronic Purses: (Which) Way to Go?’, First Monday (Peerreviewed journal on the Internet), Vol. 5, Nr. 7, July 2000.
http://www.firstmonday.org/issues5_7/hove/index.html
[Hovi01]
Hovinga, M., “Betaalmiddelen op Internet: Cruciale schakel voor e-commerce”,
Controllers Magazine, January/February 2001.
[JBHS01]
Jonkers, H. (ed.), A. Bakker, S.C. Hille, R. Stap, ‘A fexible architecture for interdomain accounting, billing and payment’, GigaABP project deliverable D1.1,
Telematica Instituut, Enschede, work in progress.
[JHTW00] Jonkers, H. (ed.), S.C. Hille, A. Tokmakoff, and M. Wibbels, ‘Taxonomy of
Accounting, Billing and Payment Concepts’, GigaABP project deliverable D1.2,
Telematica Instituut, Enschede, April 18, 2000. (TI/RS/2000/021).
Available at: http://gigaabp.telin.nl/ (Publications).
[JHTW01a] Jonkers, H. (ed.), S.C. Hille, A. Tokmakoff, and M. Wibbels, ‘A functional
architecture for the financial exploitation of network-based services’, GigaABP
project deliverable D2.1, Telematica Instituut, Enschede, January 12, 2001.
(TI/RS/2000/132). Available at: http://gigaabp.telin.nl/ (Publications).
[JHTW01b] Jonkers, H. (ed.), S.C. Hille, A. Tokmakoff, and M. Wibbels, ‘A functional
architecture to support commercial exploitation of Internet-based services’, in W.
Winiwarter, S. Bressan and I.K. Ibrahim (eds.), Third International Conference on
Information Integration and Web-based Applications and Services (iiWAS 2001),
Linz, Austria, September 2001, pp. 277-288.
[JST+01]
Jonkers, H. (ed.), R. Stap, A. Tokmakoff, A. Bakker, S.C. Hille, and M. Wibbels,
‘Metering and Reporting of Application Usage’, GigaABP project deliverable D1.2,
Telematica Instituut, Enschede, work in progress
[Jong00]
Jongeneel, Ch., ‘Microbetalingen schuiven stilaan uit beeld’, MNET, Number 14,
September 2000, pp. 30-33.
[Krue01]
Krueger, M., ‘The Future of M-Payments – Business Options and policy Issues’,
Institute for Prospective Technological Studies (IPTS), first draft of Background
Paper No.2, Electronic Payment Systems Observatory (ePSO), March 2001.
http://epso.jrc.es/Docs/Background-2.pdf
[LGKV00] Lelieveldt, S., J.M. Groeneveld, S. Kaatee, A. Visser, Elektronisch betalen,
e
Afrekenen met een verleden, Financiële & Monetare Studies, 18 jaargang, Nr.2,
Wolters Noordhoff, 2000. (ISSN 1383-7656)
[Lita00]
Litan, A. ‘Consumer E-Bill-Payment: Built, But When Will They Come?’, Gartner
Group Research Note, February 28, 2000.
[MaPT97] O’Mahony, D., M. Peirce and H. Tewari, Electronic Payments Systems, Artech
House, Boston, 1997. (ISBN 0-89006-925-5)
[Mari00]
Marino, J. ‘Online Bill Payment: Not If but When’, in Network Magazine: strategies
and solutions for the network professional. Vol. 15, 2000, afl. 11, pp. 62-69
G
I G A
A B P / 2 0 0 1 / D 0 . 1
B
101
[Mobe01] Kanniainen, L.(ed.), ‘The Preferred Payment Architecture; Technical
Documentaition. Requirements for manufacturers and standardization bodies’,
Mobey Forum, Version 1.0, July 2001.
Available at: http://www.mobeyforum.org.
[OMPT97] O’Mahony, D., M. Peirce, H. Tewari, Electronic Payment Systems, Artech House,
Boston, 1997. (ISBN 0-89006-025-5).
[OSS+98] Ouren, J., M. Singer, J. Stephenson, and A.L. Weinberg, Electronic bill payment
and presentment. The options for banks are becoming clear. The McKinsey
Quarterly 1998, number 4, pp. 98-106.
[RiSh97]
Rivest, R.L. and A. Shamir, ‘PayWord and Micro-Mint – Two Simple Micropayment
Schemes’, Lecture Notes in Computer Science, Vol. 1189, 1997, pp. 69-88.
[SFPW99] Stiller, B, G. Fankhauser, B. Plattner and N. Weiler. Charging and Accounting for
Integrated Internet Services. INET’98 Proceedings,
http://www.isoc.org/inet98_proc/3e/3e_2.htm.
[Stef00]
Stefanova, M., ‘OFX - Description of Open Financial Exchange Standard’, Giga
Transaction Services, 2000.
[Stei98]
Stein, Web Security – A Step by Step reference Guide, Addison Wesley
Longman,1998.
[Ston01]
Stone, A., ‘Paying for Stuff (Part Two): Why Micropayments Won’t Work’,
Internet.Com, April 30, 2001.
http://www.mcommercetimes.com/Industry/117
[ToWi00] Tokmakoff, A. (ed.), and M. Wibbels, ‘Description of experimental results’,
GigaABP project deliverable D3.1, Telematica Instituut, Enschede, November 17,
2000. (TI/RS/2000/101).
Available at: http://gigaabp.telin.nl/ (Publications).
[ViGo97]
th
Visser, H. and L. van Goor. Inleiding tot het geld- en bankwezen. 4 edition,
Academic Service, Schoonhoven, 1997. (ISBN 90 5261 197 1).
[W3C99]
W3C Micropayment Markup Working Group, ‘Common Markup for micropayment
per-fee-links’, W3C Working Draft, 25 August 1999. (Editor: Thiery Michel).
http://www.w3.org/TR/1999/WD-Micropayment-Markup-19990825
[Webe98] Weber, R., ‘Chablis – Market Analysis of Digital Payment Systems’, Technical
University Munich, Munich, August 1998 (TUM-I9819).
Available as on-line HTML document:
http://medoc.informatik.tu-muenchen.de/Chablis/MStudy/
[Wibb01] Wibbels, M.,‘Design and implementation of a generic accounting, charging and
billing system’, GigaABP project deliverable D4.2, Telematica Instituut, Enschede,
2001, work in progress.
102
G
I G A
P
O R T
Index
Definition
IP gateway
A
Acceptgiro
Digital
29
25
52
J
Java Wallet
61, 62
B
Bill
Definition
27
25
L
70
94
67
47
30
66
M
Late payment
Local loop
25
76
C
Calculator
Card reader
Card Validation Code
Cash on delivery
Customer Relations Management
CyberCash
D
Digipass
Direct payment
Dual-chip phones
Dual-slot phones
71
18
21
21
Magex
Micropayment system
Millicent
Mobile Pay
Mobile payment
Paybox
WAP
80
85
90
21
96
22
22
O
One-time card number
Open Financial Exchange
Open Service Access
65
40
23
E
e.dentifier
70
E-billing
30
EBPP
33
Ecash
83
ECML
61
EIP
33
EIPP
33
Electronic Bill Payment
30
Electronic Bill Presentment
30
Electronic Bill Presentment and Payment 30, 33
Electronic Commerce Modelling Language 61
Electronic Invoice Presentment
33
Electronic Invoice Presentment and Payment33
Electronic money
47
Electronic purse
57
Electronic wallet
57
Architecture
61
Standards
61
e-purse
57
E-wallet
see Electronic wallet
F
FINREAD
94
G
Gateway issues
GiSMo
GlobalCollect
52
69
50
P
Parlay
Paybox
Payment
Streaming media
Payment gateway
Payment Service Provider
Private Communications Technology
Purse
23
22
79
52
52, 53
67
57
Q
Qpass
81
R
Reconciliation
Recurring biller
26
44
S
Secure Socket Layer
66
SET Wallet
57, 58
Split billing
79
SSL
See Secure Socket layer
Statement
25
SWAPEROO
61
SwitchPoint
79, 84
T
Telco-finance integration
96
I
Invoice
G
I G A
A B P / 2 0 0 1 / D 0 . 1
27
B
103
U
Unattended point-of-sale
71
WAP gateway
52
WASP see Wallet Application Service Provider
WiSP
77
W
Wallet Application Service Provider
104
63
G
I G A
P
O R T

Electronic payment put in context

Transcription

Similar documents

Private Label Card Management Software

Bob Cox, Publisher, Winnipeg Free Press

Validated Parking at Autopark at Gallery Mall

Avisena - Sevocity

CreditDebit Card Dispute Form

Price schedule- 24 Hour Meter

Recommended Billing Codes for the Anatomotor Table For Cervical

PCI Compliance Instructions

PCI Compliance Instructions