Electronic payment put in context

Bill payment, electronic commerce and exploitation of electronic products

(Deliverable D0.1b)

Colophon
Date : Version : Change :

March 4, 2002 3.0 2.0 2.6 2.7 3.0 January 24, 2001 Start of update GigaABP/2000/D1.1 payment in specific contexts January 10, 2002 March 4, 2002 Version for (external) review Final version November 29, 2001 Separated general backgrounds from

Project reference : TI reference : Company reference : URL : Access permissions : Status : Editor : Company : Author(s) :

GigaABP/2001/D0.1b TI/RS/2001/081 http://gigaabp.telin.nl Public Final Sander Hille Telematica Instituut 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: sander.hille@telin.nl, 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

Table of Contents

1 Introduction 1.1 1.2 1.3 Document scope Related project research and information Document structure

11 11 13 14 17 17 17 18 18 19 20 21 22 22 23 25 25 26 26 27 28 28 29 30 30 33 33 33 34 37 38 38 39 39 39 40 40 41 42
VII

2 Payment over public communication networks 2.1 2.1.1 2.1.2 2.1.3 2.2 2.3 2.3.1 2.3.2 2.3.3 2.4 The issues Trust Cross-border payments Direct payment Misconceptions on Internet payment The roles of mobile communication in payment Payment terminal in the physical world Payment terminal in the virtual world Direct payment channel Merging of payment flows

3 Overview of bill presentment and bill payment 3.1 3.2 3.3 3.4 3.5 3.6 3.6.1 3.6.2 3.6.3 Introduction A functional reference model for billing and bill payment Differences between B2C and B2B billing Instruments for bill payment Bill distribution and presentment: print and mail services Developments in bill presentment and bill payment A digital acceptgiro Electronic Bill Presentment (e-Billing) Bill consolidation and payment services

4 Electronic Bill Presentment and Payment 4.1 4.2 4.3 4.4 4.5 4.5.1 4.5.2 4.5.3 4.5.4 4.6 4.6.1 4.6.2 4.6.3
G
I G A

Introduction The impact of cultural aspects Models for EBP US players Dutch providers of EBP solutions and services Anachron: Pulse Suite Bluem TNT Post Group: Privver Intrum Justitia Standards Open Financial Exchange (OFX) GOLD message standard Interactive Financial Exchange (IFX)
A B P / 2 0 0 1 / D 0 . 1
B

4.7 4.7.1 4.7.2 4.7.3 4.8

Examples of Electronic Bill Presentment systems BillCast (Avolent) WorkOut (Alysis) Oracles Bill Presentment and Payment Solution Trends and developments

42 42 43 44 44 47 47 47 48 48 48 49 50 51 53 54 55 56 57 57 58 58 59 59 60 60 61 61 62 63 65 65 65 66 67 68 69 69 70 70 71 71
G P

5 Payment in e-commerce context 5.1 5.1.1 5.1.2 5.2 5.2.1 5.2.2 5.3 5.4 5.5 5.5.1 5.5.2 5.5.3 Issues in the virtual world Direct payment International reach Examples of dedicated account-based systems PayPal Jalda-based Safetrader Example of international collection: GlobalCollect Generic system architecture Payment Service Providers (PSPs) Bibit Internet Payment Services NetGiro TWYP - The Way You Pay

6 Electronic wallets: shopping and payment assistants 6.1 6.2 6.3 6.3.1 6.3.2 6.3.3 6.3.4 6.4 6.4.1 6.4.2 6.5 Introduction Basic wallet functions Product examples ABN-AMROs e-Wallet Microsoft Passport Novells Digitalme Xiring: the Wireless Wallet concept Wallet standards and frameworks Electronic Commerce Modelling Language (ECML) Java Wallet The future of e-wallets

7 Adaptation of real world payment instruments 7.1 7.2 7.2.1 7.2.2 7.2.3 7.2.4 7.2.5 7.3 7.3.1 7.3.2 7.4
VIII

Introduction Credit cards Secure Socket Layer (SSL) Secure Electronic Transactions (SET) I-Pay Interpays Dutch SET payment platform The Three Domain Model (3D SET) Virtual Credit Cards Debit cards Rabo Direct Betalen On-line use of Maestro Card-based electronic money

I G A

O R T

7.4.1 7.4.2 7.5

Proton on Internet Chip-Secure Electronic Transaction (C-SET) Trends and developments

72 72 73 75 75 75 76 77 79 79 80 80 81 81 82 84 85 85 85 86 87 88 90 91 91 92 93 95 95 95 96 96

8 Exploitation of electronic products 8.1 8.2 8.3 8.3.1 8.3.2 8.3.3 8.4 8.4.1 8.4.2 8.4.3 8.5 8.6 Introduction Characteristics Potential payment scenarios Example: ISP Trivnets WiSP Example: Access network operator Example: ISP and Network operator KPNs SwitchPoint Total solutions for content-exploitation Magex Qpass NetBill Network-based electronic money schemes Evaluation of discussed payment systems

9 Micropayment systems 9.1 9.2 9.3 9.4 9.4.1 9.4.2 9.5 9.5.1 9.5.2 9.6 Introduction The problems to solve Potential players Commercially available micropayment systems NewGenPays Micropayment solution (former IBM) Millicent (Compaq) a token-based system Micropayment standards and standardisation efforts A Common Markup for micropayment per-fee-links (Draft) Micro Payment Transfer Protocol (MPTP) The future of micropayment systems

10 Conclusions 10.1 Coverage of on-line payment transactions 10.2 Cultural impact 10.3 Introduction of new payment services and instruments 10.4 Telco-finance integration

I G A

A B P / 2 0 0 1 / D 0 . 1

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

Consumer

B2C transaction
B2B

Merchant, Service Provider

Supplier

Transfer: Money

Beyond scope

Figure 1: The Business-to-Consumer setting

I G A

A B P / 2 0 0 1 / D 0 . 1

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

5 and

0.10 to

5.

Subscription, post-paid,
long(er) term relationship
0 0.10 5 15 Utilities Telecom

Invoice

B2C
500

B2B
Transaction value

Digital products
Content

Physical goods

Per item, direct,

Books Clothing CDs/DVDs

Electronic services

short term relationship

Figure 2: Payment contexts: What are we paying for on-line?

12

I G A

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, consumers money resides initially mainly in bank accounts. Therefore the relation between the financial sectors 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 Service Bureaus PSPs Transaction Processors

Financial networks

Financial sector
Banks ISPs Wallet SPs Mobile ISPs

Clearing Houses Fixed Network money issuers

e-Bill presenters

Consumer

Telecom and Internet

Mobile network operators Mobile

Merchant or Service Provider

Fulfillment companies

Parcel delivery firms

Transport & logistics

Non-electronic

Scope of this document 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

I G A

A B P / 2 0 0 1 / D 0 . 1

13

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
a cco unting data use r info

Information prov isioning

pro vide r info

charging data

bill

me ter input

Usage data acquisition

usage da ta

Data & process manage me nt

reconcilia tion data

Financial Se ttle me nt
paym ent indicatio n

payme nt i nititiatio n

Aspects covered

Approaches to metering, report mechanisms; implementations

describes

Demonstrator implementation

Backgrounds on the Dutch payment system

Payment in various contexts e.g. Internet, mobile e-billing This doc

[JST+01]

[ToWi00]

[Wibb01]

[HiSt01]

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

I G A

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 readers convenience we have included a list explaining acronyms at the end of the document, as well as an index of key words.

I G A

A B P / 2 0 0 1 / D 0 . 1

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 operators 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-AMROs e.dentifier, Rabobanks random calculator and Postbanks 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

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 P

I G A

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 [Bhl01], Section 2.1. 1. Internet payments can evolve independently from the banks 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 sectors 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.

I G A

A B P / 2 0 0 1 / D 0 . 1

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 (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
2

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

I G A

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 Nedaps 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 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 customers bank account by means of direct debit. The customer can get a statement of his transactions via the Internet.
4 3

3 According to De Volkskrant, Experiment met tanken betalen via mobieltje, October 20, 2001, Economy supplement. 4 See also http://www.bp.nl/

I G A

A B P / 2 0 0 1 / D 0 . 1

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 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 vendors 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
5

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 users 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 Observatorys Inventory database: http://epso.jrc.es/cfapp/invent/details.cfm?uid=80

22

I G A

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

I G A

A B P / 2 0 0 1 / D 0 . 1

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. 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 countrys payment culture and varies over countries (see Figure 5). According to the European 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.
8 7

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

I G A

A B P / 2 0 0 1 / D 0 . 1

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.

Financial Settlement

Payers financial handling

Billing
Bill preparation Bill presentment
bill
bill

charging data

billing data

billing info

Authorisation

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 Payers 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 P

I G A

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 payers 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 euroacceptgiro) 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 payers convenience, payment finality and who initiates and controls the payment process. In the first
9

The payment instruments are discussed in detail in [HiSt01].

I G A

A B P / 2 0 0 1 / D 0 . 1

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:
Credit transfer Acceptgiro Direct debit

Payment initiator:
Payer Payer Biller

Control: Payment finality:

Payer Payer Shared After processing After processing After 5-30 days

Payers convenience:
Low Medium 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

I G A

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 billers 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 (optional)

Digital accepgiro
Payment channel

Customer

hyper linking
Bill presentment channel

Biller

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 @cceptgiros 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

I G A

A B P / 2 0 0 1 / D 0 . 1

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)
10

Electronic Bill Presentment (EBP) allows consumers

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

I G A

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 write checks (28.7%) and saving time (14.9%) . Candidates for such primary sites (in the 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. Citigroups 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 bills using a web interface, are powered by Paytrusts 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 users 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.
14 12 13 11

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 bannersPowered by PayTrust on these sites.

I G A

A B P / 2 0 0 1 / D 0 . 1

31

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.

I G A

A B P / 2 0 0 1 / D 0 . 1

33

 The availability of convenient bill payment instruments;

In the Netherlands there are sufficiently many convenient payment instruments (from the payers 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 users 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): Manually sending bill with error (cost): Number of bills/month that consumer receives: Manually paying bill by consumer: Total time/month for consumer: Manually processing payment (cost): Savings of EBPP on bill of $100: Total cost of U.S. payment system: Cost of check transaction: $1.00 - $1.50 $2.00 - $3.00 17 10 minutes 3 hours $1.00 $1.90 3% of Gross Domestic Product 50-100% more than electronic payment U.S. number of C2B billing transactions 1998 U.S. number of B2B billing transactions 1998 15 billion 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

I G A

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

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

See http://www.ebilling.org/glossary/default.htm

I G A

A B P / 2 0 0 1 / D 0 . 1

35

Biller
In-house Outsourcing

EBP customer services (review, customer care)

Customer 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.
EBP customer services (enrolment, high level review)

Biller Bill Consolidator Biller

Customer

EBP customer services (details, customer care) EBP system outsourcing

Biller Service Provider (BSP)

Service provisioning Service payment (money flow)

Figure 9: Thin Service Provider Consolidation Model for EBP

36

I G A

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 Customers 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 billers 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 bills 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

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

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:
Alysis Avolent Edocs Solant 4.5 Iplanet Checkfree Portal TransPoint

Application Service Providers (ASPs):

BillServ.com Derivion TransPoint YourAccounts.com CheckFree Pinceton eCom

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
18

Anachron: Pulse Suite 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

I G A

O R T

4.5.2 Bluem
20

Bluem 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 Avolents 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, that initiative was unplugged however (april 2001) . Currently, Bluems payment service supports credit card payments and direct debits. Their system automatically sends payment reminders. 4.5.3 Privver
22 21

TNT Post Group: Privver 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 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 Postsparkasse ([Bhl01], footnote 9, p 22). 4.5.4 Intrum Justitia
24 23

stereichische

Intrum Justitia

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 21

See http://www.bluem.nl See Innonet New, April 9, 2001: Aus fr 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

I G A

A B P / 2 0 0 1 / D 0 . 1

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 NetGiros 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 Open Financial Exchange (OFX)
26

Open Financial Exchange (OFX)

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

I G A

O R T

Server Application Client application

Web-client
HTTP (appl/x-ofx)

Web -server

OFX request

OFX reply

Legacy format

Legacy system
(implementing service 2)

OFX request

OFX client

This section has been sourced from [Stef00]. 4.6.2 GOLD message standard
27

The GOLD message standard

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.

OFX reply

OSF-server
Service 1 Service 2 ... Service n

Figure 10: OFX Architecture

was created by the Integrion Financial Network , an industry-

28

27 28

http://www.integrion.net/gold/ http://www.integrion.net/

I G A

A B P / 2 0 0 1 / D 0 . 1

41

4.6.3

Interactive Financial Exchange (IFX)

29

The Interactive Financial Exchange (IFX) specification

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)
30

BillCast is a product of Avolent (formerly of Just in Time solutions)

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 systems 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 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.
31

29 30 31

http://www.ifxforum.org/ http://www.justintime.com/home.html http://www.justintime.com/productsTechnology/billCastArch.html

42

I G A

O R T

BillCast seems to be the back-end system for both Bluems service (see Section 4.5.2) as well as Intuit's billing site .
32

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 IBMs Solution Investment Initiative in order to bundle its WorkOut software with IBMs e-business solutions, in particular the above mentioned WebSphere and DB2 Universal Database. . Moreover, Alysis signed a joint marketing agreement with Bibit Internet Payment Services (see Section 5.5.1) in order to offer Bibits bill payment methods in combination with its WorkOut e-billing solution.
34 33

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 Bibts press release of December 18,2000: Alysis teams with Bibit to target European e-billing market.
33

32

I G A

A B P / 2 0 0 1 / D 0 . 1

43

4.7.3

Oracles 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 Trends and developments

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 P

I G A

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

I G A

A B P / 2 0 0 1 / D 0 . 1

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

I G A

A B P / 2 0 0 1 / D 0 . 1

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

I G A

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
36

Jalda-based Safetrader 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 providers application sends ticks to the server that charges the appropriate account and updates the service providers account. Ticks can be generated by any part of the service providers 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 customers 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

See http://www.jalda.com/.

I G A

A B P / 2 0 0 1 / D 0 . 1

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 customers 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 clients 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
37

GlobalCollect

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 payers choice, following the local customs. The invoice recipient can pay the bill with various local payment instruments. By means of GlobalCollects 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

I G A

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 consumers 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 Merchant oriented

Web shop application

(client side)

Web shop application

(server side)

Primary service Internet payment system Interface Device e-Purse, debit card Internet

e-Wallet

Internet Cash Register

payment instruments
Public communication network Banking application Financial network (client-side) (server-side)

Public communication network

issues

Payment Gateway

Financial sectors payment system

Issuers bank system

Acquirers 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

I G A

A B P / 2 0 0 1 / D 0 . 1

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 merchants 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 consumers 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 systems 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

I G A

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
(server-side)

Public communication network

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

I G A

A B P / 2 0 0 1 / D 0 . 1

53

5.5.1
38

Bibit Internet Payment Services

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 Bibits 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. Bibits 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 Bibits 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 merchants 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 Bibits
transaction database.

38

See http://www.bibit.com/

54

I G A

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 seller

redirect

BIBIT

acquirer

issuer

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 Bibits payment services to their European customers. Pay-it-now Pay-it-now
40 39

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
41

Netgiro International

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 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 issuers 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.
42

39

According to Bibits 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/

I G A

A B P / 2 0 0 1 / D 0 . 1

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

I G A

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 merchants 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 PCs hard drive, is protected by means of encryption. Server-based wallets enable usage of the wallets functions from any location on the Internet.

Browser

Application server

Consumer
Primary service

Internet

Webshop application

Mediation

Wallet application

Secundary services (supporting: payment) Card reader

IC Card

Bank system
(PSP: Payment Service Provider)

PSP platform

E-Money system

Figure 16: The role of electronic wallets

I G A

A B P / 2 0 0 1 / D 0 . 1

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

I G A

O R T

Table 3: A comparison of some commercially available wallets on their functionality and approach.

Identification, authentication
X X

Approach (thin/thick)

Product name
e-Wallet Passport Wireless Wallet Digitalme Nokia 6310 6.3.1

Provider
ABN-AMRO Bank Microsoft Xiring (was: Ericsson) Novell Nokia Thick Thin Thick Thin Thick X X X

ABN-AMROs e-Wallet

ABN-AMRO has developed a wallet, called e-Wallet, for use on the Internet. The software must be installed on the users 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 users 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 Interpays I-Pay payment gateway (to be discussed in Section 7.2.3). 6.3.2 Microsoft Passport
45

Microsoft Passport

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

http://www.passport.com/

I G A

A B P / 2 0 0 1 / D 0 . 1

Payment instrument organiser

X X

Shopping assistant

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 Novells 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 Microsofts 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 smart card reader , the Wireless Wallet enables smart card transactions over the mobile Internet.
47 46

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

A secure payment, e.g. for an airline travel ticket, is made following several steps:

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 47

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

60

I G A

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 Wallets 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 agencys 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.). 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)
50

The IETF and W3Cs Electronic Commerce Modelling Language [EaGo99] is the product of the ECML Alliance , which consists of a number of major industry leaders including American
51

50 51

See http://www-db.stanford.edu/~daswani/wallets/ See http://www.ecml.org/.

I G A

A B P / 2 0 0 1 / D 0 . 1

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 merchants revenues by reducing the high percentage of abandoned shopping carts . A full description of ECML is given in the IETFs RFC 2706 . The ECML standard is adopted the wallet vendors in the ECML alliance: Brodia, CyberCash , 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
55 56 57 54 53 52

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

I G A

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 Microsofts Passport (Section 6.3.2) or AOLs 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 consumers 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

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

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

I G A

A B P / 2 0 0 1 / D 0 . 1

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)
60

The Secure Socket Layer

(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

I G A

O R T

SSLs 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 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)
61

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

61 62 63

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

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 cardholders 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 Interpays 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 payers PC and an Internet Cash Register application (Internet Centrale Kassa ICK) for the merchants domain, which implements the merchants part of the SET protocol. The Internet Cash Register can be connected to the merchants Web shop or any other application through a special API.

64

See http://www.i-pay.com

68

I G A

O R T

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 about 215 Dutch merchants . ABN-AMRO has developed a special (branded) SET wallet, called e-Wallet, which makes use of the I-Pay infrastructure statistics are available however. 7.2.4 The Three Domain Model (3D SET)
67 66

65

(see Chapter 6). [BRR99,

p.49] assumes that it is seldom used. It mentions 20,000 reported users. No official usage

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 customers mobile phone as an authentication tool. Before use, a customer must register at GiSMos 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 66

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

I G A

A B P / 2 0 0 1 / D 0 . 1

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 terminals console. The terminal then transmits the data securely to the issuing banks 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 consumers 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 banks 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 payers 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 P

I G A

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 others 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 Rabobanks 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 [BRR99]. 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).

I G A

A B P / 2 0 0 1 / D 0 . 1

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 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)
68

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

I G A

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 Trends and developments

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

See http://www.totaltele.com/view.asp?ArticleID=25811&Pub=tt.

I G A

A B P / 2 0 0 1 / D 0 . 1

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 Chapter 6. 8.2 Characteristics 5. Payment issues concerning the selling of physical goods in an electronic shop have been discussed in

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
Payment request

Controls

Operation Support System

Usage Authorisation

Business Support System

Figure 17: Relations among payment and delivery systems

G A B P / 2 0 0 1 / D 0 . 1

I G A

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

I G A

O R T

Consumer
Network access Internet access & services

Content provider
Network access, transport

Access Network Operator

Network access, transport

ISP
High capacity interconnectivity

ISP
Network access, transport

Access Network Operator

Backbone Network Operator(s)

Legend:

Role player

Service provisioning

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 providers charges. 8.3.1 Example: ISP Trivnets WiSP
70

Trivnet Ltd.

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 subscribers 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. Trivnets 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

See http://www.trivnet.com

I G A

A B P / 2 0 0 1 / D 0 . 1

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 users 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 users and the merchants currency and purchase details in the users 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 ISPs 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 merchants site is established by the WiSP merchant API.
78
G P

I G A

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 operators bill or may be made to the cost of the consumers 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 operators 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 companys 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 employees 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 companys bill. Other events appear on the employees 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 KPNs SwitchPoint

KPN Telecom offers a service to Internet content and service providers, called SwitchPoint that enables charging consumers of content or services through the consumers phone bill at KPN Telecom. The service is able to support to types of charging policies: per-minute with an upper bound of visit.
71

0.70 per minute, and per-visit (session), with a maximum of

1.15 per

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

According to KPN Telecom, http://www.kpn.com/

I G A

A B P / 2 0 0 1 / D 0 . 1

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
72

Magex is a company

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

I G A

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 merchants server.

73

http://www.netbill.com/

I G A

A B P / 2 0 0 1 / D 0 . 1

81

A generic scenario looks as follows: 1. The merchants server sends goods (electronically and) encrypted to the consumers machine. 2. The Money Tool checks whether the goods arrived intact. It sends a verification message to the merchants server. 3. The merchants 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 consumers account. If so, it transfers funds, stores encryption key and sends a report back to the merchants server. 5. The merchant sends the decryption key to the Money Tool upon successful payment. If the merchants 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 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 [BRR99].
74

74

See http://public.deutsche-bank.de/global/ui/nav_ec.nsf/frameset/DMEL-47ULWU?OpenDocument

82

I G A

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

acquired DigiCashs blind signature technology and other assets .

76

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 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 customers bank account. The bank can not see the serial number of the coin it signs. (It is encrypted with the banks secret key and can be decrypted with the banks public key.) The bank uses a distinct signature for each coin value. The coins are stored in the wallet software on the customers 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 merchants 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
77

See http://www.ecashtechnologies.com/ According to ePSOs Inventory Database: http://www.jrc.es/cfapp/invent/details.cfm?uid=30 77 According to Bibits press release of January 3, 2000: Bibit joins Deutsche Bank in suporting payment solutions from eCash Technologies.
76

75

I G A

A B P / 2 0 0 1 / D 0 . 1

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 TrivNets 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 operators 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 KPNs 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 consumers 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

I G A

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.

I G A

A B P / 2 0 0 1 / D 0 . 1

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 500,000. Thus the operator needs a large number of users and be of an order of magnitude

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

I G A

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 operators 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 NewGenPays micropayment solution seems to be used. A 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:
79

78 79

See http://www.millicent.com/home.html See http://www.cartio.nl

I G A

A B P / 2 0 0 1 / D 0 . 1

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 NewGenPays Micropayment solution (former IBM)
80

NewGenPay

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 NewGenPays 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 merchants; 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

I G A

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.
buyers billing daily deposits sellers billing service daily deposits

service
daily credentials overspending prevention

buyer payment order

seller

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

I G A

A B P / 2 0 0 1 / D 0 . 1

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
81

Millicent

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

I G A

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 customers 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 vendors site reduces the need for a validation server at the brokers 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 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
83

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 Wide Web Consortium (W3C) . Currently W3C has closed its Ecommerce/Micropayment Activity. 9.5.1
85 84

A Common Markup for micropayment per-fee-links

86

The W3C defined a micropayment task

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 W3Cs 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 83

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

I G A

A B P / 2 0 0 1 / D 0 . 1

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 Wallet 3 Browser Browser-to-wallet API
W3Cs focus

Merchant side
Internet (WWW)

User agent Per-Fee-Link Handler

Web server

Common Markup for per-fee-links

Figure 20: W3Cs 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

I G A

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 consumers 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 providers 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 A B P / 2 0 0 1 / D 0 . 1

I G A

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

I G A

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

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

I G A

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

I G A

A B P / 2 0 0 1 / D 0 . 1

97

Acronyms
ADIF CDR CEPS DNB EBP EBPay ECML EIP EIPP EJB EPF GBA IETF IFX IPDR JEPI IRTF M3I NACHA OFX PFMS PIN VAT W3C Accounting Data Interchange Format Call Detail Record Common Electroni Purse Specification De Nederlandsche Bank N.V. Electronic Bill Presentment Electronic Bill Payment Electronic Commerce Modelling Language Electronic Invoice Presentment Electronic Invoice Presentment and Payment Enterprise Java Beans Electronic Payment Forum Global Billing Association Internet Engineering Task Force Interactive Financial Exchange Internet Protocol (IP) Detail Record Joint Electronic Payment Initiative Internet Research Task Force Market Managed Multiservice Internet National (U.S.A.) Automated Clearing House Association Open Financial eXchange Personal Financial Management System Personal Identification Number Value Added Tax World Wide Web Consortium

98

I G A

O R T

References
[AuKa01] Au, Y.A., and R.J. Kauffman, Should We Wait? Network Externalities and Electronic Billing Adoption, Proceedings of the 34 Hawaii International Conference on System Sciences, 2001. [BIS96] [BIS99] Bank of International Settlements, Security of Electronic Money, Basle, August 1996. 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/. [Bhl01] Bhle, 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 [BRR99] Bhle, 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] NACHAs 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] NACHAs 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, 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/.
rd th

I G A

A B P / 2 0 0 1 / D 0 . 1

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] [ECB01] European Central Bank. Report on Electronic Money, August 1998. http://www.dnb.nl/betalingsverkeer/index.htm. 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. [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, OReilly, 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, 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).
th rd

100

I G A

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] [JBHS01] Hovinga, M., Betaalmiddelen op Internet: Cruciale schakel voor e-commerce, Controllers Magazine, January/February 2001. 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] [Krue01] Jongeneel, Ch., Microbetalingen schuiven stilaan uit beeld, MNET, Number 14, September 2000, pp. 30-33. 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, Afrekenen met een verleden, Financile & 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] OMahony, 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
e

I G A

A B P / 2 0 0 1 / D 0 . 1

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] OMahony, 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. INET98 Proceedings, http://www.isoc.org/inet98_proc/3e/3e_2.htm. [Stef00] [Stei98] [Ston01] Stefanova, M., OFX - Description of Open Financial Exchange Standard, Giga Transaction Services, 2000. Stein, Web Security A Step by Step reference Guide, Addison Wesley Longman,1998. Stone, A., Paying for Stuff (Part Two): Why Micropayments Wont 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] [W3C99] Visser, H. and L. van Goor. Inleiding tot het geld- en bankwezen. 4 edition, Academic Service, Schoonhoven, 1997. (ISBN 90 5261 197 1). 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.
th

102

I G A

O R T

Index
A
Acceptgiro Digital 29 Definition IP gateway 25 52

J
Java Wallet 61, 62

B
Bill Definition 27 25

L
Late payment Local loop 25 76

C
Calculator Card reader Card Validation Code Cash on delivery Customer Relations Management CyberCash 70 94 67 47 30 66

M
Magex Micropayment system Millicent Mobile Pay Mobile payment Paybox WAP 80 85 90 21 96 22 22

D
Digipass Direct payment Dual-chip phones Dual-slot phones 71 18 21 21

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

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

F
FINREAD 94

G
Gateway issues GiSMo GlobalCollect 52 69 50

T
Telco-finance integration 96

I
Invoice 27

I G A

A B P / 2 0 0 1 / D 0 . 1

103

U
Unattended point-of-sale 71

WAP gateway 52 WASP see Wallet Application Service Provider WiSP 77

W
Wallet Application Service Provider 63

104

I G A

O R T