Institute for

Prospective Technological Studies

Directorate General Joint Research Centre
European Commission

Integration of Electronic Payment Systems

into B2C Internet-Commerce
Problems and Perspectives
Background Paper No. 8
Electronic Payment Systems Observatory (ePSO)
April 2002
Knud Bhle

IPTS, World Trade Center, Isla de la Cartuja, s/n, E-41092, Seville, Spain
Tel: +34 954488281, Fax: +34 954488208
URL : http://epso.jrc.es/

European Commission
Joint Research Centre (DG JRC)
Institute for Prospective Technological Studies
http://www.jrc.es

Legal notice
Neither the European Commission nor any
person acting on behalf of the Commission is
responsible for the use which might be made of
the following information.

European Communities, 2002

Reproduction is authorised provided the source

is acknowledged

Abstract
The focus of this paper is on the integration of payment systems into B2C Internetcommerce. Our understanding of the payment integration problem starts from the
observation that not all payment instruments are online yet. If they are online they are
often not integrated into the online-shopping process from the consumer's point of view
and they don't easily produce the data the merchants would like to feed in their legacy
back-office systems. If this is the case, it is only true for some payment instruments, it is
only true for simple cases, and it is only true in the national framework. There are hardly
any payment systems that are truly integrated in online-shopping of digital goods and
services in the market. Solving or tackling these problems would help to increase the
efficiency of electronic payment systems.
The paper starts by modelling the whole transaction process; and then addresses the
merchant's point of view, followed by the customers' point of view. In Chapter 4, a
structured picture of payment relevant B2C standards is drawn before standardization
problems are discussed. In Chapters 5 and 6 the B2B integration problem and the
challenges for payment integration in the digital goods and services market are addressed.
Finally major findings are summarised in the light of potential policy relevance. The
following questions emerged:
Is it adequate that payment service providers leverage their "payment systems" to take
care of all steps of the completion phase of B2C transactions thus shaping the whole
security infrastructure for electronic transaction processes?
Is smooth integration of online payment methods into B2C e-commerce transactions a
point on the agenda of major ICT vendors and the banking industry?
How can a common view and common actions of e-banking, e-payments and ecommerce standardisation in the field be achieved?
What measures should be taken to strengthen the position of SMEs, which lack ICT
knowledge and have less bargaining power with intermediaries?
How will the competition between identification/authentication approaches within the
financial sector and the ICT sector, and between these two sectors, affect the adoption
of e-commerce by consumers?
Is convergence of "identity technology" and "payment technology" a privacy threat?
Is the integration of digital rights management technology in B2C e-commerce
required for the further development of the European eContent market?
Is the establishment of a micropayment infrastructure required for the further
development of the European eContent market?

CONTENTS
1
1.1
1.2
2
2.1
2.2
2.3
2.4
3
3.1
3.2
4
4.1
4.2

INTRODUCTION ....................................................................................... 1
Role of the background paper ............................................................. 1
Scope of the background paper .......................................................... 2
MODELLING THE ONLINE TRANSACTION PROCESS......................... 4
Defining e-commerce and commercial transactions ............................ 4
Defining the integration problem.......................................................... 5
Modelling the transaction process ....................................................... 6
integration into the local data processing environment...................... 10
VIEWS OF THE INTEGRATION PROBLEM .......................................... 12
The merchant's view.......................................................................... 12
The consumer's view......................................................................... 14
THE ROLE OF STANDARDIZATION IN PAYMENT INTEGRATION .... 17
Overview of payment and e-commerce related standardisation
efforts ................................................................................................ 17
Standardisation problems.................................................................. 19

THE B2B INTEGRATION PROBLEM..................................................... 24

INTEGRATION CHALLENGES FOR THE DIGITAL GOODS MARKET 26

MAIN POINTS FOR FURTHER DISCUSSION ....................................... 28

BIBLIOGRAPHY........................................................................................... 31

INTRODUCTION

1.1

ROLE OF THE BACKGROUND PAPER

This eighth background paper is about the integration of electronic payment systems into
B2C Internet-commerce on the Internet. This topic was suggested and agreed on at the
first Steering Group Meeting of 21 November 2000 (Bhle et al. 2000). Previous to the
present paper a study on the subject, based on desk research and interviews in The
Netherlands, had been prepared for ePSO (Lelieveldt 2001). ePSO also organised an
expert workshop on the 19 November 2001 entitled "Integration of Internet payment
systems into e-commerce", part of which was dedicated to the validation of the
aforementioned study.1 The topic was also addressed in several articles of the ePSONewsletter between December 2001 and March 2002. Acknowledging this input we
present a tentative outline of the payment integration problem with a view to pointing out
real world problems of merchants and consumers and to identifying policy issues.
The following questions, worth further analysis and discussion, emerged:
Is the complete integration of all steps of an online transaction process an objective
worth pursuing? Why not also consider the benefits of disintegration, i.e. transaction
processes in which purchases on the Internet and the payment are dissociated?
Examples are paying for an online purchase with an offline payment instrument, or
adding the GSM network as a security channel.
There are signs that payment service providers, like credit card organisations, can
leverage their "payment systems" and extend the scope of their business to take care of
all steps of the completion phase of B2C transactions. Is such a development probable
and would it be an appropriate way to build a security infrastructure for electronic
transaction processes?
Payment system integration into online e-commerce has started with the preparation of
traditional payment instruments for the Internet environment and the provision of some
special Internet payment schemes. The mere presence of these payment systems does
not imply their integration into B2C Internet-commerce. Will the next step also be
taken, i.e. the smooth integration of these online payment methods into B2C ecommerce transactions? This could include for example the production of those data
1

The workshop is documented at the ePSO website http://epso.jrc.es/project/M4Agenda.html

providing the study of S. Lelieveldt Consultancy, and a long abstract of each presentation plus the
workshop minutes, quoted as (ePSO 2001).
1

that allow merchants to match order information and payment information, electronic
receipts of payments for customers, or tracing and tracking capabilities for merchants
and consumers.
The large number of relevant standards at different levels by a multitude of actors has
led to a lack of transparency. How can a common view and common actions of ebanking, e-payments and e-commerce standardisation in the field be achieved?
With respect to merchants, a variety of solutions is currently being used to integrate epayments into the online transaction process. Because of a lack of ICT expertise and
less bargaining power with intermediaries, small and medium enterprises (SMEs)
reportedly have major problems. What measures should be taken to strengthen the
position of SMEs?
With respect to consumers the development of "browser-software" is crucial. At
present the smooth integration of identification/authentication mechanisms is at stake.
How will the competition between approaches within the financial sector and the ICT
sector, and between these two sectors, affect the adoption of e-commerce by
consumers?
An implicit question with importance for consumer privacy is whether "identity
technology" and "payment technology" will and should converge.
Is the integration of digital rights management technology in B2C e-commerce
required for the further development of the European eContent market?
Is the establishment of a micropayment infrastructure required to further the
development of the European market for digital goods and services?

1.2

SCOPE OF THE BACKGROUND PAPER

The Internet is still far from being a frictionless B2C marketplace and at present research
points at considerable information asymmetries and lack of market transparency (Latzer
and Schmidt 2001). Integration is already a problem before the order takes place as the
high rate of online-shoppers abandoning their shopping cart shows. Market researchers
report that up to 78% of online-shoppers abandon their shopping carts (Perman 2000,
Vividence 2001). Integration is obviously also a problem after the order with, for
example, an average fulfilment rate of barely 88% in Germany and the Nordic countries
(The Boston Consulting Group 2000, p. 30). As ePSO background paper 7 (Centeno
2002a) suggests, the biggest integration problem of all is probably to build-in trust and

security. However, all these problems are not, in first place, payment integration
problems.
Our understanding of the payment integration problem starts from the observation that not
all payment instruments are online yet. If they are online they are often not integrated into
the online-shopping process from the consumer's point of view and they don't easily
produce the data merchants would like to feed in their legacy back-office systems. Even if
this should be the case, it is only true for some payment instruments, it is only true for
simple cases (excluding e.g. easy revocation of payments), and it is only true in the
national framework. There are hardly any payment systems integrated in online-shopping
of digital goods and services (the micropayment and the digital rights management issue)
in the market. In short, we have not identified the payment integration problem, but a
series of different practical problems. Solving or tackling them would help to increase the
efficiency of electronic payment systems.
In this paper we don't focus on the whole transaction process but on the issues related to
payment system integration. As background, we first model the whole transaction
process. Next we address the merchant's point of view of the integration problem
followed by the customers' point of view. Turning to the role of standards, we first draw a
structured picture of payment relevant B2C standards before we discuss problems of
standardization. In the next two chapters we address first B2B payment integration,
showing that the problems faced in this segment are quite different from those in the B2C
segment. Then we address the challenges for payment integration in the digital goods and
services market, which is expected to grow considerably in the future. Finally we
summarise major findings in the light of potential policy relevance.

MODELLING THE ONLINE TRANSACTION PROCESS

2.1

DEFINING E-COMMERCE AND COMMERCIAL TRANSACTIONS

Electronic commerce can be defined as the application of information and communication

technology to any of the activities involved in making commercial transactions.2 The
Internet offers the potential to trade electronically in an open network environment that in
principle is accessible and adaptable to the needs of any trader or type of transaction. In
electronic commerce, however, not only is the entire mediation structure open to
restructuring, but also new types of goods and services emerge. While current interest and
debate in electronic commerce is focused on the Internet, further platforms or channels
mobile commerce and iTV have started to raise interest.
The most fundamental aspect of all commercial transaction processes is the exchange of
value. All commercial processes involve transactions between buyers and sellers in which
value is exchanged. In all but the simplest case of a face to face purchase of physical
goods and payment with cash, virtually all value exchanges are subject to various forms
of intermediation. E-commerce is no exception and the number of potential intermediaries
is quite high as Diagram 1 suggests.

Diagram 1: Potential e-commerce intermediaries

Intermediaries

Seller
goods/services

Software providers
Internet access providers
Webhosting services
Payment service providers
Payment processors
Banks
Credit card organisations
Third party biller
Trustees
Escrow services
Certification authority
Trust mark services
Rating and scoring services
Logistics service provider

Buyer
monetary value

Transactions occur in structures, the form and function of which is determined largely by
the type of good or service (e.g. homogeneous or differentiated products, digital or
physical good, value) and the relationship of buyers and sellers (e.g. frequent customers,
2

The definitions given in this section are taken from a paper (OECD 2000) produced in the context
of the OECD's Electronic Commerce Business Impacts Project (EBIP), to which IPTS contributed.
The EBIP synthesis report will be made publicly available at the OECD website this year.
4

known brand, spontaneous purchase). A transaction is defined here as any exchange

between participants in a market that is directly or indirectly related to the acquisition of
goods and services, irrespective of whether these goods or services are finally acquired.
Some transactions involve product and service delivery and the direct exchange of
money, but many others are exploratory and involve the acquisition of market information
advertising, personal inquiries, and so forth. This broad definition has the advantage of
also being suitable for the analysis of incomplete transaction processes when for
example analysing break offs at checkout or transaction processes where part of the
transaction is performed on the Internet and the rest outside or vice versa. The definition
is also broad enough to be applicable to B2B and B2C e-commerce alike. Our focus will
be on B2C Internet e-commerce.

2.2

DEFINING THE INTEGRATION PROBLEM

What the "real integration problem" is depends on the concept of "integration". A broad
notion would state that when everything works fine and is perceived as such, the goal of
integration has been achieved. In social affairs like e-commerce we can be even more
precise and say that when everything is perceived as working fine the goal of integration
is attained. We can also add that integration includes situations when everything doesnt
work fine and integration is perceived as a problem, but capabilities and mechanisms to
cope with these difficulties are in place. Therefore the ability to repudiate orders, to
revoke payments, to chargeback, to turn to legal actions or to alternative dispute
resolution, are elements of integration. A broad view would paradoxically also have to
take into account disintegration as a means of best integration. A case in point would be
an online-order on the Internet paid for with a payment instruction via the mobile phone.
A somewhat narrower view would focus on integration as the task of making unequal
ends meet by linking, bridging, embedding, interfacing, encapsulating etc. The integration
of online transaction steps with offline transaction steps addresses one type of problem at
this level. The integration of different types or generations of information technology (e.g.
generation of programming languages, communication protocols) is the next type of
problem at this level, i.e. to couple Internet-technology and protocols on the one side and
private networks (e.g. banking networks) and proprietary back-office systems of
merchants on the other side.
The strictest concept of integration would claim that the more steps of an online
transaction process are done on the Internet the higher the level of integration. Full

integration in this sense would require that all functions take place on the web. In practice
this will be restricted by definition to digital goods and services. If the products/services
are physical, the transaction process will be partly off-line. Often, but not always, these
transactions involve an online payment mechanism. In a sense a payment method initiated
online would be regarded as more integrated than a purely offline payment (e.g. cash on
delivery, fund transfer after receipt of a bill), and "e-mail money" and real time accessible
virtual accounts could hence be considered as more integrated than payment methods.
These three concepts of integration are not exclusive and may help to distinguish different
levels of the problem.

2.3

MODELLING THE TRANSACTION PROCESS

2.3.1 A simple model

There are different ways to model a complete transaction process and to split it into steps
for analytical purposes.3 One way is to distinguish a preparation phase, the deed of sale,
and the fulfilment or completion phase. In our opinion it makes sense to add a fourth
category to address problem solving issues ("exception handling") which may become
relevant even after the completion of the transaction process.
From the point of view of the customer, the preparation phase may include information
collection about markets, companies, prices, proprieties of merchandise, or about the
quality attributes of the so called complementary goods like consumer and privacy
protection, delivery service, after sales services (Latzer and Schmitz 2001). Once an
apparently appropriate company is identified, more information about the offered good
(references of other customers, test reports, data sheets etc.) and maybe a test of the good
or service is wanted. Negotiation about terms and conditions, although not very common
in B2C e-commerce, could be the next step. From the merchant's point of view, offering,
advertising, marketing, and negotiation may be the corresponding activities related to the
preparation phase.
The deed of sale, as we call it here, goes together with the often implicit conclusion of a
contract defining terms and conditions, and the order by the customer. This act requires
the acknowledgment of the order terms and conditions by either party. The merchant must

Thanks to a comment by Hansrudolf Thomann in ePSO-F, 9 Apr 2002 09:28:32 our simple model
has been augmented; cf. ePSO-F archive at http://epso.jrc.es/forum/enter.

agree to deliver the goods and services under the payment terms defined and the
consumer must agree to provide payment under the delivery terms defined.
The completion or fulfilment phase contains the transfer of products and services from
sellers to buyers (logistics) and the transfer of money from the buyer to the seller. The
fulfilment phase is initiated by the closing of the sales contract and is about the fulfilment
of the obligations accepted in the sales contract by either party. The merchant must
deliver the goods and render the services, the consumer must provide payment. Thus the
fulfilment consists of the delivery and the payment process. Choice of payment methods
as well as clearing and settlement of the payment belong to the payment part of this
phase.
For the customer, fulfilment often starts by pressing the payment button at checkout. The
consumer accepts the sales contract terms, and he may initiate the payment by presenting
card data or details of his banking account thus accepting his or her payment obligation.
In cases of pre-payment the pressing of the payment button is indeed a payment act.
Payment and delivery methods are intertwined in various ways, such as:
1. Pre-payment: the merchant delivers after receipt of full payment.
2. Post-payment: the consumer transfers the funds after the goods have been delivered or
the services have been rendered.
3. Payment on delivery: a trusted third party (e.g. the postman) receives payment and
hands out the goods.
4. Partial payment: Consumer pays a part before and another after delivery.
5. Sliced payment: Delivery and payment occur in slices, according to the pre- or postpayment model, e.g. payment of phone calls on a pay per time slice basis.
We add here a final phase that aims at resolving delivery or payment problems related to
the purchase. Another term in use for the same matter is "exception handling". The
problem to be resolved or handled can emerge on either the consumer side or the
merchant side. In most cases consumers will be the originators of requests and
complaints. Customer service after sales, help-desk information, and in general all types
of dispute resolution and consumer redress are ways of tackling these problems. Payment
failures (partial or complete) may be caused by technical problems or by non-fulfilment
of the payment obligation by the consumer. Any business must implement controls to
detect such failures and to take appropriate action, up to execution of a claim. For an easy
treatment of delivery failures (non or incomplete delivery, not-as-defined delivery) the
7

payment system may support payment reversals, credit transactions and chargebacks.
Reversal mechanisms are state-of-the-art in most POS systems and vending machines.
Credit transactions are commonplace in physical stores (return the goods, get the money
back) and also supported by most credit card acquirers, but not generally implemented by
the merchants. The chargeback is a unique feature of the credit card system relying on the
specific contractual relations between merchant and acquirer, cardholder and issuer and
acquiring/issuing members with the card associations.

Table 1: Typical elements of a B2C transaction process

Seller

Buyer

Offering: seller offers specific goods and

services

Information gathering: buyer retrieves

information about goods, terms and
conditions etc.

Advertising: seller communicates its

products and services (catalogue)

Selling: seller agrees in a contract with the buyer on the content of a specific order
Billing: seller produces and presents
invoice

Paying: buyer pays the seller by giving a

payment instruction or a form of cash

Delivering: the seller delivers to the buyer

Resolving: seller and buyer try to resolve delivery or payment issues related to the
purchase
Note: These steps can involve third parties and be supported by software tools. The steps may consist
of many elements and there is no strict chronological order when they are due.

2.3.2 A somewhat enhanced model

Regarding the online-transaction process, this simple model is worth enhancing. During
the transaction process huge amounts of transaction-related data are generated, recorded
and processed. The capability to acquire transaction-related information, and the
capability to organise, process and apply it, is crucial for the integration of the online
transaction process. Tracing and tracking facilities should be allowed for as these would
reduce insecurities during the fulfilment phase. The throughput of payment data to
support the efficient organisation of the payment value chain should also be facilitated
from data capture to reconciliation and other business processes such as, delivery and
customer services. The data exchange should also allow matching; i.e. the seller should be
able to match payment information (the authorisation results and the actual crediting of
account) and order information and to feed the result into the back-office. While these
requirements of data exchange are relevant in first place for the actual transaction process,
8

it has to be stressed that the data captured can also be used for the support of other
business processes such as market analysis, customer relation management (CRM),
advertising, and the development of new products and services.
The next necessary extension of the model for online transaction processes is to add the
dimension of security, especially of authentication. For each transaction step,
authentication of trading partners and integrity of data exchanged has ideally to be
guaranteed. This is provided by a whole new range of transaction related data types and
messages often cryptographic objects (digital signatures, certificates etc.) as part of a
security infrastructure. It is essential that the legal framework as component of the
transaction model be added. Implicit or explicit reference to the legal system is present in
each commercial transaction and fulfils an indispensable integration function.

Diagram 2: Model of online transaction process

Security infrastructure enabling e.g. authentication of traders

Preparation

Deed of sale

Completion

Resolving

Data collection, storage, throughput, tracking, tracing, analysis

Legal framework

There are, of course, more sophisticated models and architectures available.4 What seems
to be lacking in the public research domain, however, is a meticulous modelling of data
formats, data flow, data storage, data processing for all types of electronic payment
instruments (traditional giro payments, card payments, prepaid payment methods, other
new innovative schemes) that takes into account all types of intermediaries in the chain
like payment service providers, payment processors, escrow services, etc. Systems
analysis of this type could considerably help us to be more precise about efficiency
aspects of payment system integration. A study of this type could start from the payment
value chain as depicted in Diagram 3.

See for example the paper of the Telematica Instituut on accounting, billing and payment produced
as part of its GigaPort project (Telematica Instituut 2000b).
9

Diagram 3: Payment value chain

Originate
payment

Validate
payment

Capture
payment

Capture
customer
info

Transmit

Process

Settle

Legend: Boston Consulting Group quoted in Nieuwenhof 2001, p. 14

2.4

INTEGRATION INTO THE LOCAL DATA PROCESSING

ENVIRONMENT

At this stage we add another view on the integration problem of online transactions
considering the technical environment of the merchants and consumers as trading
partners. For the customer, "browser software" is the crucial enabling software for
electronic transactions on the World Wide Web, for the merchant it is the merchant
server. The customer has an interest to integrate his trade activities with other applications
such as financial management software, home banking software and sometimes he is
required to integrate special software for the consumption of traded goods (e.g. a music
player to play downloaded files).
The merchant has to integrate shopping software in his data processing environment and
to add payment functions into his online-shop. As an alternative he may outsource
functions. The crucial point for the merchant is probably the effort to integrate
information flows created by the online-shop with the legacy system (billing, ERP
Enterprise Resource Planning, CRM Customer Relation Management). In other words,
the merchant needs integrated data processing for all delivery channels (bricks and
mortar, Internet, m-commerce, iTV commerce), and he needs back-office integration as
basis for the relation with other businesses.
Diagram 4: Merchant and customer environment
Merchant

B2B

Merchant

B2C

Customer

financial applications
Back-office

Merchant
server

Back-office
ERP

Legacy system

ERP

Merchant
server

Legacy system

10

Customer
browser

e-commerce helpers

To sum up, it is important to look at back-office technology developments (towards

Internet technology) and the changes necessary at the back-office to integrate e-commerce
processes today, to understand the integration problem from the merchant's point of view.
It is important to look at browser developments and the browser as an integration tool to
understand the experiences and expectations of consumers.

11

3
3.1

VIEWS OF THE INTEGRATION PROBLEM

THE MERCHANT'S VIEW

In the B2C segment the e-shop is central for the merchant. Usually the seller presents a
catalogue of products and services and chooses a sales mechanism. The standard
mechanism is the shopping cart. Often, but not always, the transaction process involves
an online payment mechanism.
A considerable number of products and solutions are available to realise the payment part
of an online transaction. The functionality of these products and solutions ranges from
facilitating the payment process only, to supporting the complete web presence (including
e-payments). We distinguish virtual cash registers, i.e. virtual Point of Sale software, and
complete E-commerce solutions.
The virtual cash register can be viewed as a software application that performs a specified
transaction protocol to realise the online payment function emulating a POS terminal.
The application requires the basic order information and includes interaction with the
customer to obtain payment details. The application can be bought or built on the basis of
the specification of the company that offers the payment service. This can be a bank or a
payment service provider.
The payment service provider (PSP) is an organisation that operates a payment collection
system, which includes a virtual cash register. It processes payments on behalf of the
merchant/business and has set up all necessary links to the financial system for
authorisation, clearing and settlement of payments. Its operations may be limited to
specific payment functions or it may also provide billing and matching services. The
range of payment methods accepted depends on the nature of the provider. Internet cash
registers that are operated by PSPs generally support a wide (national and international)
range of payment methods, including off-line payment methods. Cash registers that are
provided by banks facilitate a more limited range of payment methods.
In principle the integration issue for PSPs and merchants centers around the format of the
payment information required to match orders and payments. In practice PSPs develop
customer specific interfaces to facilitate the matching function or offer matching services.
It is important to note that the payment information format can be chosen to be
compatible with regularly used administrative software, i.e. feeding e-commerce data into
the existing back-office system should be no problem, when standard software packages
12

are used in-house. The output report that the PSP delivers to the company (for matching
purposes) can be delivered in a wide range of formats such as HTML, XML, commaseparated files etc. If a customer expresses a need for a specific output format, translation
techniques are available to deliver the output in this format. In addition PSPs support the
resolving function by offering online enquiry facilities so that companies may review the
status of a specific payment. There is less flexibility with respect to the data formats the
merchant has to provide, i.e. the order/payment information needed to be able to process
online and/or off-line transactions. Merchants need to comply with requested data
formats.
The problem of continuous change is also worth mention. Merchants hesitate to update
their e-shop's payment page to implement new payment authentication mechanisms. The
required integration effort by merchants has been identified as one major barrier to the
deployment of SET (Thomann 2001), and also the current authentication approaches of
Mastercard and Visa require adjustments of the webshop (discussed in Thomann 2001
and Gpayments 2002).
Complete E-commerce solutions are software suites that allow the design and operation of
a web store in all its business aspects. Large software vendors offer these integrated ecommerce solutions or suites.5 The solutions cover shop-settings as well as auctions. In
the commercial domain, the success of campaigns or e-mail actions can be monitored and
personalisation is supported. Generally, the software will use parameters to allow multiple
languages, currencies and tax regimes. The software suites can include a number of
payment protocols and allows for the use of payment cassettes, i.e. off the shelf modules
to be added easily to the shopping software in use. These modularised interfaces can be
used for specific payment protocols or for the interaction with PSPs.
The issue and importance of payments integration is often dealt with in the context of the
outsourcing discussion. It appears that both merchants and the payment industry have
climbed up the learning curve to discover that both shop-hosting (synonym: web-hosting)
and payment services require specific expertise. A considerable market now exists of
webhosters and PSPs. Important factors that influence the choice to outsource are the size
of the company and the availability of expertise. Research also indicates that there are
country differences with respect to outsourcing. During the November ePSO Workshop
5

Examples of suppliers/products are: IBM's WebSphere Commerce Suite Pro, Intershop's Enfinity,
Microsoft's Commerce Server 2000, BroadVision's Business Commerce 6.0, ATG's Dynamo 5
Commerce Suite, Blue Martini's 4.
13

(ePSO 2001/Hendry), data from the UK were presented based on information by the two
largest acquirers, Barclays Merchant Services and Streamline (RBS/NatWest), showing
that of 10,000 retailers 9,950 have outsourced part or all of the payment function. The 50
companies which do everything themselves, however, are those making 90% of the
turnover. The Tarifica Survey, which compares Sweden and Ireland, shows that there is a
relation between web-experience and outsourcing rate. In Sweden, where over half of the
respondents have had an operational website for 5 years or more, only 30% of companies
outsourced their web hosting, whereas in Ireland with just 17% of organisations having
had a website for five years or more, 60% outsourced (Tarifica 2001).
The decision to outsource and the subsequent price and interface negotiations with PSPs
requires considerable attention for retailers. Apart from the price-negotiations, one of the
requirements of merchants is that the statement on the customer bank account should not
show the name of the PSP but the name of the merchant.
One of the major issues when having a PSP in the middle is that the PSP may choose to
accept a credit card chargeback and charge this to the retailer. This delegation may put the
merchant in a troublesome position. If a retailer operates its own credit-card authorisation
services and is confronted with a charge back, the first thing to do would be to find out
the specifics of the customer and the order. On the basis of that information the charge
back could be granted or proof could be supplied in the dispute. Thus, if the PSP does not
hesitate to accept chargebacks on behalf of the merchant, this can increase opportunities
for "friendly fraud" (Centeno 2002b).

3.2

THE CONSUMER'S VIEW

WWW-browser-software (Netscape, Internet Explorer) provides the main interface for

users to the online world and therefore it is crucial for new web-related applications to
integrate with the browser software via browser extensions or plug-ins. Today browser
software, handling among others digital certificates and user profiles, is obviously more
than just a tool to present HTML-tagged pages in a graphical interface. It is the key
technology determining the user experience and thus in a way the gatekeeper of accepted
Internet applications (Kahin 1997). In this sense it is also the key to the online-shopping
consumer experience.
This experience is today still scattered. As the consumer is supposed to shop at many
merchants, website design and interfaces vary a lot, forms to be filled in are different, and

14

passwords accumulate as they are often required to sign-in or log-in. The result is that
users need to manage a wide range of personal information, user-IDs, nicknames,
passwords, and also financial data for repeated use. To alleviate this inconvenience,
techniques for automatic form filling and easy authentication have been developed. They
can be implemented at the user's device or at one or more central servers to which the
consumer has access. Bigger merchants, with Amazon pioneering, implemented a "1 click
method", but the more general approach is dealt with under the label of eWallet. eWallets
are defined by a CEN/ISSS working group on the subject as follows: "An eWallet is a
collection of confidential data of a personal nature or relating to a role carried out by an
individual, managed so as to facilitate completion of electronic transactions" (Hinchley
2002). eWallets address much more than only payments. The operation of eWallets
should also imply workable solutions to identification / authentication issues and formfilling. Further functions mentioned in a Mastercard study (2000, p. 7) are generating
"pseudo account numbers", providing shopping offers, access to online-banking
functions, and a repository for the online purchasing history. It has to be stressed that the
days of the first generation of "thick wallets" have gone and that wallets today have to be
imagined as server-based wallets or thin wallets, which in some cases are just plug-ins to
the browser software in place.6
In this domain standardisation takes place at two levels. At the level of eWallets the
CEN/ISSS eWallet project already mentioned is active. Referring just to the form-filling
aspect, ECML, the E-Commerce Modeling Language, standardised by IETF under the
umbrella of its TRADE working group has to be taken into account. The eWallet project
has shown that most of the eWallets in the market are also capable of filling forms
according to ECML. ECML is therefore taken into account by eWallet providers, but
following a paper of Gpayments (2001) "at this point in time the number of sites
supporting ECML is negligible" (p.4). More "intelligent" techniques such as "intelligent
form population" or "intelligent agents" may also threaten the success of ECML in the
mid-term.
The eWallet standardisation project, supported mainly by smaller technology companies
seeking wider market acceptance by developing common standards, experienced during
6

The importance of server-based solutions is discussed in Bhle 2001b and Bhle 2001c.
Information about types of eWallets and eWallet development can be found on the CEN/ISSS web
site ftp://ftp.cenorm.be/PUBLIC/ws-ec/Projects/ewallet/ewallet_Documents.doc. The eWallet
Project is expected to publish its final deliverables as a CEN Workshop Agreement (CWA) in July
2002.

15

the course of its work that major industry players stepped into the identity technology
arena. This in a way will influence the standardization effort of CEN/ISSS. One is
tempted to think that in the near future the heavyweights - Mastercard (SPA/UCAF) and
Visa (3D-Secure) on the side of the financial industries, Microsoft (Passport) on the side
of ICT companies and Liberty Alliance (yet no product name) with a mixed profile of
companies - will be the main competitors in the race for the coming industry standard(s).
The fragmentation of approaches in both sectors is bad news for consumers, who can be
expected to be reluctant to cope with multiple identity approaches as their objective is
precisely to reduce fragmentation and create a common shopping experience. While
fragmentation is detrimental to a common user experience, privacy concerns of users are
at least as vital and worth discussing with respect to each of the promoted approaches. At
a more general level the probability and desirability of a convergence of
identification/authentication technologies and payment technologies is at stake.

16

THE ROLE OF STANDARDIZATION IN PAYMENT INTEGRATION

4.1

OVERVIEW OF PAYMENT AND E-COMMERCE RELATED

STANDARDISATION EFFORTS

Standards, architectures and models that are relevant for the e-payments and the online
transaction process are numerous.7 A way to structure them, shown in Table 2, is to apply
two criteria: the function or abstraction level aimed at by each initiative and the type of
actor driving it. Textbox 1 gives short explanations of the most relevant standardisation
efforts mentioned in this paper.

Table 2: E-payment and e-commerce related standardisation efforts

Actor
Function

Finance

Architectures and
Frameworks

Trade

ICT-vendors

WWW/IETF

EDIFACT

Biztalk,

AAA

X.12

MS .net

SAML

EbXML

eCO framework IOTP

XrML

Standardisation
bodies
MPEG-21
Multimedia
Framework
(ISO/IEC JTC1/
SC29/WG11)

SEMPER

Financial
Transaction
Protocols and
Message Formats
and related
components

SET

XML Pay

SPA/UCAF

OFX / IFX

3D Secure

Passport

e-M commerce

Liberty
Alliance

Visa XML Invoice

{W3 micropayments
standard}

CEN/ISSS
eWallet project

ECML

[HBCI]
[EMV]
[CEPS]

Enabling
Technology
Standards and
Specifications

FINREAD,

JavaCard

XML,

Open Plaform

Windows for
Smartcards

XSLT

Multos

TCP/IP

SSL

TLS

ISO-IEC JTC1SC17

HTML

Legend: Schemes in bold are of special relevance for B2C e-commerce; [ ] not yet relevant for Internet
e-commerce, { } closed down. Mobile payment initiatives and banking standards with no immediate ecommerce relevance are not covered.

See for compilations of payment relevant standards especially the website of the EC funded Diffuse
project at http://www.diffuse.org/payment.html#help and CEN/ISSS 2001a; see also Li 2002. The
European Committee for Banking Standards (ECBS) website at http://www.ecbs.org/ informs
about ongoing banking standardisation at the European level.
17

Textbox 1: E-commerce standardisation efforts with B2C payment relevance

SET
This financial transaction protocol performs the complete payment function. The protocol has been
extended to allow the use of chipcards for authentication.
SPA/UCAF
Authentication protocol by Mastercard and Maestro
e-M commerce protocol
Authentication protocol by Maestro
3D Secure (Verified by Visa)
Authentication protocol by Visa
Visa XML Invoice
The Visa Extensible Markup Language (XML) Invoice Specification provides a cross-industry,
interoperable message format to enable processing of enhanced data across regions and industry
sectors. It can be used in combination with an agreement for "enhanced data services"; under such an
agreement, companies get more detailed information on the purchases made. This information serves to
improve the matching and internal bookkeeping processes. The focus of the specification is on B2B
procurement processes (http://www.visa.com/ut/dnld/spec.ghtml).
HBCI
HBCI is a specification for the communication between intelligent customer systems and the
corresponding computing centers for the exchange of home banking transactions. The transmission of
data is done by a net data interface, which is based on a flexible delimiter syntax (similar to
UN/EDIFACT). It is planned to bring in HBCI into international committees for standardization.
EMV
Specifications by Europay, MasterCard and Visa that define a set of requirements to ensure
interoperability between chip cards and terminals on a global basis, regardless of the manufacturer, the
financial institution, or where the card is used. The latest version of the specifications, EMV 2000
version 4.0, was published in December 2000 (http://www.emvco.com/).
CEPS
The Common Electronic Purse Specifications (CEPS) define requirements for all components needed
by an organization to implement a globally interoperable electronic purse program, while maintaining full
accountability and auditability. CEPS, which were made available in March of 1999, outline overall
system security, certification and migration. CEPS have paved the way for the creation of an open, de
facto, global electronic purse standard http://www.cepsco.com/).
XMLPay
XMLPay is a standard proposed/developed by Ariba and Verisign. It defines an XML syntax for payment
transaction requests, responses and receipts in a payment processing network. The intended users are
Internet merchants and merchant aggregators who need to deal with multiple electronic payment
mechanisms (credit/debit card, purchase card, electronic cheque and automated clearing house
payment). The supported operations include funds authorization and capture, sales and repeat sales,
and voiding of transactions.
(http://www.verisign.com/resources/wp/payment/overview/paymentServices.pdf)
OFX/ IFX
OFX, which stands for Open Financial Exchange has been developed by ICT-vendors (CheckFree,
Intuit and Microsoft) and is essentially a common data format to be used for communication between
banks and home banking applications for customers. It has its roots in the USA and Canada.
IFX, Interactive Financial Exchange, is a message specification for exchanging financial data and
instructions that can be viewed as OFX for the Internet-environment. The IFX specification does not
describe any specific product implementation, this is left to the individual institutions. The IFX initiative is
the product of a joint effort between teams that include representatives of Integrion Financial Networks
GOLD, developed by IBM and Integrion, and representatives of OFX. IFX is now being further
developed by the IFX Forum, which is a consortium of industry leading financial institutions, service
providers and software vendors. (http://www.ifxforum.org/ifxforum.org/prdoc.cfm?Name=666)

18

ECML
The Electronic Commerce Modeling Language ECML is a specification that describes the format for
data fields that need to be filled at checkout in an online transaction. The fields defined include shipping
information, billing information, recipient information, payment card information and reference fields.
Version 2.0 describes these fields in an XML syntax.
W3C standard on micropayments
The W3C standard on micropayments has originated from IBMs standardisation efforts. It covers the
payment function for payment of digital goods. It is implemented in the products of Netactuals (Cartio)
and Newgenpay. The Micropayment initiative specifies how to provide in a Web page all the information
necessary to initialize a micropayment and transfer this information to the wallet for processing. The
W3C Ecommerce/Micropayment Activity is now closed (http://www.w3.org/ECommerce/Activity).
Passport
Microsoft Passport is an online user-authentication service. Passports primary service is user
authentication, referred to as the Passport single sign-in (SSI) service. Passport also offers two other
optional services: Passport express purchase (EP), which lets users store credit card and
billing/shipping address information in their optional Passport wallet profiles to expedite checkout at
participating e-commerce sites, and Kids Passport (source: Microsoft Passport Technical White Paper).
Liberty Alliance
The Liberty Alliance Project is a business alliance formed to deliver and support an identity solution for
the Internet that enables single sign-on for consumers as well as business users in an open, federated
way. The primary goals of the Liberty Alliance Project are: to allow individual consumers and businesses
to maintain personal information securely, to provide a universal open standard for single sign-on with
decentralized authentication and open authorization from multiple providers, to provide an open
standard for network identity spanning all network devices (source: http://www.projectliberty.org/).
eWallet project of CEN/ISSS
CEN/ISSS Electronic Commerce Workshop initiated the eWallet project in mid-2001 assuming a need
for standardization in the field. CEN/ISSS has chosen a flexible working definition considering an
eWallet as "a collection of confidential data of a personal nature or relating to a role carried our by an
individual, managed so as to facilitate completion of electronic transactions". In July 2002 a CEN
Workshop Agreement (CWA) will be delivered containing recommendations.
SEMPER
Secure Electronic Market Place for Europe (SEMPER) was produced by an EU supported project under
the ACTS programme, undertaken by a 20 partner consortium led by IBM. It is a definition of an open
and system independent architecture for Electronic Commerce. The project was concluded in 1999.
Based on access via a browser, the architecture specifies common functions to be supported by
applications which include Exchange of certificates, Exchange of signed offer/order, Fair contract
signing, Fair payment for receipt, and Provision of delivery information. The SEMPER architecture also
includes standard buyer/seller scenarios. As a part of the SEMPER work a design has been made for an
object based payment architecture. Some of the concepts of this work have been used by IBM as part of
its development of the Websphere manager.
IOTP
The Internet Open Trading Protocol (IOTP) is defined as an interoperable framework for Internet
commerce. It is optimised for the case where the buyer and the merchant do not have a prior
acquaintance. IOTP is payment system independent. It can encapsulate and support payment systems
such as SET, Mondex, secure channel card payment, Geldkarte etc. The current version of IOTP
(Version 1) is published as an Internet "standard", RFC 2801 (RFC = Request for Comments).

4.2

STANDARDISATION PROBLEMS

The overview shows many active players in the standardization field besides the formal
standard developing organisations. The convergence of previously separately standardised
technologies (telecommunications, computers, web, finance) has led to many crossindustry consortia and contributed to the rapid increase of actors. The large volume of
specifications emerging from hundreds of actors without clear delineation of the scope

19

and without interoperability is one general concern of observers (e.g. Diffuse 2002). This
general statement also holds if we look just at the payment-relevant initiatives. Many of
the existing architectures and models, however, are not relevant to the B2C segment.
CEN/ISSS (2001a) also admits that few companies are on the market with products that
actually implement any of these frameworks, architectures, and models apart from those
vendors generating them. In addition vendor implementation of a particular model in a
product or service does not necessarily entail implementation in the sense of actual
adoption by (potential) users. There are also different degrees of and approaches to
implementation of the same model, which do not necessarily guarantee interoperability at
the system level and the product-service level. Moreover, the purpose of the models is
often to differ from one another. Further, ad hoc development and ad hoc adoption of
electronic commerce architectures remains an important concern for interoperability.
The formal standardisation bodies are aware of the new situation and try to adapt
standardization and specification procedures. The ISO-fast track, the IETF-procedures,
and the CEN-ISSS Workshop model reflect this change.8
A specific CEN/ISSS standardisation effort is now focused on the development of
ECIMF, an E- Commerce Integration Meta-Framework (CEN/ISSS 2001b). The main
purpose of this meta-framework is to facilitate interoperability by mapping the concepts
and contexts between different existing e-commerce frameworks, across multiple
architectural layers. This effort is however more relevant to the B2B segment than to the
B2C segment.
The good news is that we observe, despite fragmentation and competition at many levels,
widely accepted and deployed standards, such as SSL, HTML, XML, at the level of the
enabling basic Internet technologies. This facilitates the flexible sending, formatting and
translation of data over open networks. It increases the possibility to define bridging
services and protocols between different systems. More specifically the availability of
XML and XML translation specifications are important in enabling a flexible integration
of the payment process into the whole transaction process. One could expect that in
principle, with further migration towards XML-based communication, interoperability
8

For the general discussion of ICT standardisation and its current challenges see for example Boyd
1999, Cargill 1999, Jakobs 2001 and Clements et al. 2001.

20

problems at the messaging level will be limited to the development of translation

software.
At present, however, the diversity of formats is still a problem, although XML could
solve it "in principle" as explained by Hendry (2002): For each form of payment, there are
competing suppliers. In order to carry out the transaction, each supplier collects different
data, and collects it in different ways. For merchants or portals, the different interfaces
required by each payment service supplier pose a problem: it is impossible to design a
generic payment page to capture all the relevant information. However, as there is only a
limited set of fields that can have a direct bearing on the payment function, they all could
be encoded using XML. XML was designed to handle just such structured data, but
although there have been several initiatives proposing XML-based solutions (e.g. IOTP,
ECML, Visa XMLInvoice, XMLPay, or W3C Micropayment Initiative), none has yet
achieved significant market acceptance. Some have been closed down or severely
curtailed.
One of the main reasons for this is not any limitation of the technology itself, but the lack
of a framework for using XML. XML requires a structured approach, whereas the Internet
has grown up in an organic, deliberately unstructured way. In particular, the definition of
roles is not agreed each merchant and purchaser has its own business model. Some
providers have sought to impose their solutions, but users have not found the common
solutions they were seeking. In the B2B world (particularly the former EDI networks) one
is closer to such defined roles and business cases, and this is where XML is more widely
used.
If we approach the problem from the side of payment system integration, we have also to
take into account the several standardisation efforts centred around authentication.
Proposals of the financial sector include the SET-protocol, followed by a number of more
light-weight specifications (3D-secure, UCAF/SPA), and different ways to produce
"pseudo card numbers". At the level of those standards closely related to B2C ecommerce and payments we also see, as already mentioned in chapter III/2, that ICTvendors stepped in and addressed authentication and identification with their e-wallet

21

strategies. The range of different approaches and their limited adoption in the market is a
problem.9
Considering that neither particular XML messaging standards nor payment authentication
standards are very successful today, we have to add a further fundamental problem,
namely the integration of authentication/payment mechanisms into messaging standards.
In principle it is possible to model and define the exchanges of online transaction steps,
including authentication exchanges, on the grounds of XML. IOTP, a truly open standard
consisting of several Internet RFCs is exactly addressing this problem.10
If IOTP is the right approach, why is it not widely used? No major website or ecommerce business is yet built on this technology. There are three parts to the answer:
One part of the problem is that the interface between IOTP, the "payment bridge", and the
payment system has turned out to be inefficient and inconvenient. Therefore, a possible
work item for IOTP version 2 is to find a way to exchange payment messages without
having to tunnel through the IOTP protocol. With respect to the integration of
authentication mechanisms the IOTP version 2 requirements make clear that IOTP v2
(different from v1) is to adopt standard message and authentication systems that others
are developing like the IETF/W3C XML Digital Signature working group or ETSI
(European Telecommunications Standards Institute). In other words, IOTP v2 is expected
to reduce further required adjustments of payment products and authentication schemes.11
Part of the problem also lies in the genesis of the specification. IOPT goes into great
detail, for example, on the way to ensure brands are presented correctly in a generic
brand-independent environment. The initial design and implementations of IOTP have put
perhaps too much effort into being completely generic and brand-independent, rather than
attacking directly the areas where this capability yields immediate user benefits. In a
sense the price of the purist and generic character of a standard may be a lack of
flexibility towards existing and emerging products, and new e-commerce phenomena like
9

10

11

Current debate is often limited to card payments. It would however be interesting to also discuss the
integration of credit transfers via homebanking into Internet E-commerce. Efforts to integrate credit
transfers this way into B2C electronic commerce are apparent in some countries like Finland,
Austria, and Germany. The role and the potential of "homebanking standards" like HBCI to
facilitate international credit transfers integrated into B2C e-commerce is however not clear.
The following argumentation is derived from articles of ePSO-N, particularly Hendry 2002,
Eastlake 2002, Bhle 2002, Bhle 2001a, Bhle and Lelieveldt 2002. Worthwhile introductions to
IOTP can be found in CEN/ISSS 2001a and Telematica Instituut 2000a.
There has been no source found discussing explicitly the relation of IOTP and the authentication
mechanisms provided by the financial sector and ICT vendors.
22

P2P payments. The usual strength of standards of being generic and brand independent
might turn out to be a disadvantage.12
Maybe the most important part of the answer is about the lack of incentives to adopt this
type of standard. What incentives are there to take the step from proposed standards to
standard compliant products and their adoption, when there are products and solutions in
the market to integrate payments? When the e-merchant asks a payment service provider
to integrate e-payments in her webshop and her back office, what she requires is that her
most urgent business needs are solved within a given budget and given time constraints,
and that not too many changes have to be made in the back-office. She won't ask for
IOTP. Payment Service Providers, in the words of Mike Hendry (2002) "tend to offer the
payment methods that yield the best margin, and are less concerned about creating
generic interfaces". Developers of payment systems usually start with a very specific
solution. It only targets a specific environment and a specific customer group. They
probably don't care about standards at this early stage.

12

One might ask if there are alternative "shopping protocols" or frameworks that would have to be
discussed. To our knowledge there has been within the IETF domain a draft standard "for Shopping
over the Internet" (Reddy 1997). This protocol essentially describes a search/comparison
mechanism followed by a transaction, but seems to be of no relevance today. What could be
worthwhile however would be a comparison and further analysis of both "limited-success-stories",
the IOTP and the SEMPER (Lacoste et al. 2000) one.
23

THE B2B INTEGRATION PROBLEM

There is a significant difference between the characteristics and problems in the B2B and
B2C domain. In the B2B domain the main issue is how to optimise procurement practices
and especially catalogue management. In the B2B segment trading partners generally
have a previous relationship and pay through invoices and the payment procedures that
are common in that specific business context. In the so-called giro-countries these
payment procedures will be based on credit-transfers, whereas in cheque-countries, the
cheque or the procurement card plays a bigger role.
The primary issue in this segment is to optimise administrative procedures. Generally the
development of e-payment facilities for the B2B sector has been slow to take off and has
not been the first priority for the players in the market. In the B2B segment, the payment
function relates to the procurement responsibility, the financial responsibility and the
responsibility to operate and maintain the ICT-infrastructure. Organisational policies will
exist in all these domains, as a result of which the changes in the current operating
procedures will often be evolutionary. Improvements in the procurement process may
therefore be limited to certain types of procurement, without affecting the payment
methods. If the procedures are to be changed beyond the existing organisational
responsibilities, clear benefits need to exist for the organisational functions involved. The
introduction of a procurement card that simplifies procedures and reduces payment
periods as well, is an example of a cross-organisational change with a clear benefit.13
Now that a wide range of e-procurement solutions have been developed, attention is
shifting towards further using the applications to streamline the payments process. An
increasing number of marketplaces, suppliers and solution providers are starting to
include facilities to get payment authorisation and to transmit payment orders. As in the
B2C segment, PSPs are active in the provision of e-payments for the B2B segment as a
part of their regular services.
The main integration problem of B2B e-commerce has to do with the best way to develop
or use procurement catalogues. Already trying to harmonise the product catalogue within
an industry appears to be a quite cumbersome and difficult task. The use of sector specific
standards to streamline procurement procedures is typical for the B2B segment. In this
13

A good overview about steps of the procurement process is provided by Telematica Instituut
(2000c)

24

line the application of XML-based standards is often industry specific and dependent on
power relations within the industry sector. In the B2B procurement segment some
successful usage of specifications in specific industries is reported (e.g. Rosettanet and
CIDX in the chemical industry). ebXML, which would allow integration and automation
of inter-organisational procedures, is more generic. This framework competes with the
.NET approach taken by Microsoft, which covers the technical, protocol, business and
architecture domain.
In general, the solutions in the B2B segment appear to be primarily focused on the larger
companies. Interestingly, solutions that have their origins in the B2C domain such as
card-payments, payment service providers, or payment cassettes for software suites are
increasingly being used by larger companies.

25

INTEGRATION CHALLENGES FOR THE DIGITAL GOODS MARKET

Jupiter Research projects annual revenues for all pre-paid content categories of $1.7
billion for 2002 and $5.7 billion for 2005 and estimates that the items most likely to be
purchased will be, in order of importance, general content, music, online games, e-books
and e-learning (quoted in Centeno 2002b). It is expected that content providers will
develop strategies for the future with a mix of free and paid content. Content industries
favour a pay-per-feature model and hope to sell digital goods and services in slices. Some
eContent service markets such as online games and e-learning seem particularly
appropriate for content fragmentation as, for example, users play at increasing game
levels or learn through a step-by-step approach. A significant task ahead for industries is
to change the habits of Internet users who have grown up with free content. If this change
will ever happen payment systems have to be simple and user-friendly (Wessels 2001).
The most important characteristic of digital goods and services are zero copy costs, i.e.
costs for duplication of digital goods are low for content-sellers and consumers. To avoid
duplication by consumers typical solutions are encryption, personalisation or serialising.
Although this is in the first place a delivery problem, payment integration plays a role
when the usage or consumption of a digital good or service is controlled by an integrated
combination of digital rights management (DRM) and payment system. The marriage of
DRM and ePayment facilities is seen by some as a unique opportunity to control the
delivery of digital goods and to establish new paths for monetizing the consumption
(Belpaire 2002).
It is expected that an important part of the digital content market will be low value, and
that this segment will be attractive for "unbanked" youngsters. Thus the development of
the digital goods market is closely related to the so called micropayment problem.
Micropayment systems as pointed out by Herzberg (2002) can be best defined as those
payment systems that allow charging of amounts smaller than or close to the minimal
transaction fees for e.g. credit cards (of about 20 cents) and other Internet enabled
traditional payment instruments. Herzberg also points out that credit cards and other
traditional payment instruments are not suited for low value transactions of digital goods
because of their substantial delay in processing payments, the level of required user
involvement, and the disproportionate costs for disputes resulting in chargebacks and
substantial handling costs. This last point is especially relevant as online-delivery of
digital goods is error-prone and difficult to prove. Escrow services could solve the

26

problem, but are out of the question for small value payments. One can add that often
young consumers, the target market, don't have a bank account and are therefore in need
of alternative payment methods.
Given the particular character of digital goods and services the seller probably wants
payment upfront but the buyer wants to pay after delivery. Pre-payment and bill payment
(micro-billing) are the two basic models, when subscriptions or other more complex
revenue models are not viable (Riehm and Bhle 1999). It is common sense that cost
effective micropayment services require aggregation of transactions. Money flows can be
aggregated either in-house or by using a payment-service-provider (PSP). PSPs often
operate as Application Service Providers (ASPs) and integration is often simple and can
be done quickly. The aggregation of money flows from third parties is the real bottleneck
(ePSO 2001/Wichmann). Most obvious candidates like telcos or mobile operators are
surprisingly bad at solving this problem.
The technical challenge and the complexity of the matter lies in the fact that not only
telephone minutes have to be billed, but also totally different entities like data packets,
digital goods or subscriptions of digital services, post-payments and prepayments have to
managed. Here rebates might apply and the proceeds might have to be shared between
telephone operator and content provider. The CDR-based (Call Detail Record) legacy
billing system employed by most incumbent telcos have to be replaced by so called
"convergent billing systems" (for more details see Wichmann 2002). Herzberg points out
that for micropayment systems to be profitable it is critical to have a large number of
transactions, customers and merchants. Many micropayment providers so far have the
implicit strategy to become the dominant micropayment player. This is probably not a
realistic strategy. If on the contrary we have to assume many small players, user
experience would remain fragmented and micropayment systems unsuccessful.
The question is therefore clearly about the need of an efficient micropayment
infrastructure and the type of co-operation that could bring it about. The answer depends
also on the incumbent players and their ability to bring costs down for their traditional
products or applying chip technology for ("prepaid" or "postpaid") aggregation purposes.

27

MAIN POINTS FOR FURTHER DISCUSSION

In this chapter we summarise findings with policy relevance for further discussion:

1. Payment systems as key integration tool

In our view payment system integration has two aspects: On the one hand, as expected,
the link between the payment process and other transaction steps such as ordering and
customer service can be improved and streamlined. On the other hand electronic payment
systems are more than the payment function. Payment systems are never only about
payments embracing technical security measures, authentication mechanisms, legal
regulations and potential law enforcement, contractual regulations of liabilities and
insurance against risks. The credit card schemes provide the best example with zero
liability for consumers (in case of online payment fraud in many countries), and consumer
redress in case of over-charge, unauthorised charge, no delivery of goods, goods not
delivered as ordered or fraud. The question is whether this extension of the functions and
the responsibilities of payment service providers is the best way to bring about a security
infrastructure for B2C online transaction processes?

2. Integration into e-commerce is more than enabling online payments

The first step of payment system integration could consist in bringing all traditional
electronic and non-electronic payment systems to the Internet. In many European
countries offline payments for online purchases still dominate with 73% of consumers in
Sweden, 68% in Germany and 50% in Italy paying exclusively offline for their Internet
purchases. In other payment cultures like France or the UK the situation is already quite
different with 20% or 10 % respectively (Datamonitor 2001). The next step would be to
integrate the online payment methods into B2C e-commerce transactions. Credit card
organisations have been working on the first step for years, and non-bank payment
service providers (like PayPal) have worked especially on the integration of their
proprietary online payment system into the e-commerce segment of online-auctions. In
ePSO background paper No.4 (Bhle and Krueger 2001), we have pointed at some
integrated solutions based on credit transfers via home banking and based on direct debit
mandates paving the way to also integrate the presentment of the bill for an online
purchase and bill payment. The difference between payment culture and the national
character of existing integrative solutions stress again from a European perspective the
need for cross-border co-operation and standardization to further payment systems
integration into B2C e-commerce.
28

3. Standards require co-operation across industries and standardisation bodies

The multitude of standard initiatives at different levels and their low level of mutual
recognition have led to a lack of transparency as admitted by experts (CEN/ISSS 2001a,
Li 2002). A particular challenge is, in our view, the marriage of XML-based e-commerce
messaging standards with payment and authentication protocols developed by the
financial industries and ICT vendors. Efforts by the CEN/ISSS E-Commerce Workshop,
the EC funded Diffuse project, and the European Information Technology Observatory
(EITO) are very important to increase transparency, but a shortcoming still seems to be
that standards from the banking industries are not taken into account appropriately or are
considered as outside the focus of these efforts. At the same time one might expect in the
future that banking standards bodies like ECBS will have to orient their activities more
and more towards e-commerce integration. Opportunities for co-operation in the
standards field should be created. The example of co-operation of ETSI and ECBS in the
field of mobile payments may be taken as example of co-operation between different
types of standardisation bodies (Centeno 2001).
With respect to policies, a cautious approach would be to focus policies towards
dissemination of available information on standards and specifications, rather than
proactive formulation of proposals for standards. The Diffuse project appears to be an
example of such an approach. The evaluation of standards by independent analysts and
researchers with respect to state of implementation, international deployment, usage
figures etc. is out of the scope of the Diffuse project. Analysis of this type however could
lead to a demystification of some initiatives and to realistic relevance profiles of standards
and could on these grounds support decision making.

4. Integration as problem for SMEs

With respect to merchants, a variety of solutions is currently being used to integrate epayments into the online transaction process. In terms of pricing and complexity, the
solutions in the B2C segment cover the low-end and the high-end of the market. The
problem of a wide variety of payment mechanisms and formats can be solved with these
solutions or by outsourcing the payment function to Payment Service providers. Because
of a lack of ICT knowledge and less bargaining power with intermediaries, small and
medium enterprises (SMEs) reportedly have major problems.

29

5. Integration of privacy related technologies into the consumer environment

With respect to customers, in our view, the crucial criteria of convenience for consumer
acceptance and adoption of e-commerce components is also basic for the payment
integration issue. The criteria of convenience is closely related to the development of
browsers, the prime interface of consumers for Internet e-commerce. The smooth
integration of identification/authentication and payment technologies is at stake. Credit
card organisations as well as technology providers are following different approaches and
the impact of this competition on the development of browser software and the difficulties
for consumers to make a (right ) choice are worth further observation and discussion. An
implicit question with importance for consumer privacy is whether "identity technology"
and "payment technology" (should) converge.

6. Debatable need for DRM integration and micropayment infrastructure

The political relevance of DRM integration and the establishment of a micropayment
infrastructure are important for the development of the digital goods and services market,
especially for the European eContent market. As both technologies, DRM and
micropayment, are apparently developed to a large extent outside the incumbent financial
industries, to strengthen this innovation potential might become a political concern. The
debate about the future of free and paid content is also related to media policy
(commercialisation of the Internet vs. free content) and consumer protection and privacy
policy (DRM as control and data mining technology). The debate about the need for
DRM systems in e-commerce and about the need of micropayment systems is
controversial.

30

BIBLIOGRAPHY
Belpaire, Anthony
Digital Rights Management and ePayment Infrastructures: The Future of Digital Content on the
Internet. ePSO Final Conference, 19. February 2002, Brussels (slides available at:
http://epso.jrc.es/conference/presentations/belpaire.ppt
Bhle et al. 2000
Bhle, Knud; Krueger, Malte; Herrmann, Christoph, G. Carat, Gerard; Maghiros, Ioannis: Electronic
Payment Systems Strategic and Technical Issues. Background Paper No. 1. Electronic Payment
Systems Observatory (ePSO), Seville December 2000 (EUR 19933 EN);
http://epso.jrc.es/Docs/Backgrnd-1.pdf
Bhle, Knud (a)
Integration of Internet Payment Systems What's the Problem? ePSO-Newsletter Nr. 11 December
2001 http://epso.jrc.es/newsletter/vol11/5.html
Bhle, Knud (b)
Access is King: About the Bright Future of Server-based E-payment Systems
ePSO-Newsletter Nr. 6 March 2001
http://epso.jrc.es/newsletter/vol06/2.html
Bhle, Knud (c)
The Potential of Server-based Internet Payment Systems. An attempt to assess the future of Internet
payments. Background Paper No. 3. Electronic Payment Systems Observatory (ePSO), Seville
July 2001 (EUR 19935 EN); http://epso.jrc.es/Docs/Backgrnd-3.pdf
Bhle, Knud and Krueger, Malte
Payment Culture Matters. A comparative EU US perspective on Internet Payments, ePSO project
Background Paper No.4, May 2001; EUR 19936 EN; http://epso.jrc.es/Docs/Backgrnd-4.pdf
Bhle, Knud and Lelieveldt, Simon L.
Elegant Standards and Everyday B2C E-Commerce. ePSO-Newsletter Nr. 12 February 2002
http://epso.jrc.es/newsletter/vol12/1.html
Boyd, James
Taming the West - CEN/ISSS is a pioneer in opening up participation in the Information Society In:
Proceedings of IEEE Conference on Standardization and Innovation in Information Technology.
Aachen 1999. Online at http://www-i4.informatik.rwth-aachen.de/~jakobs/siit99/proceedings/Boyd.doc
Cargill, Carl
Consortia and the Evolution of Information Technology Standardization Proceedings of IEEE
Conference on Standardization and Innovation in Information Technology. Aachen 1999. Online:
http://www-i4.informatik.rwth-aachen.de/~jakobs/siit99/proceedings/Cargill_consortia.doc
CEN/ISSS (a)
Electronic Commerce Workshop. Frameworks, Architectures and Models for Electronic Commerce
Group. CEN Workshop Agreement 14228: 2001. Summaries of some Frameworks, Architectures and
Models for Electronic Commerce. Draft Revision 1.a (for version 2). October 2001
ftp://ftp.cenorm.be/PUBLIC/ws-ec/Projects/Architectures/2001/arch_01017.zip
CEN/ISSS (b)
CEN/ISSS Electronic Commerce Workshop: E-Commerce Integration Meta-Framework Project
(ECIMF); http://www.ecimf.org/
Centeno, Clara
Mobile Payment Industry Fora Consolidation of Initiatives Expected. ePSO-Newsletter Nr. 8 July
2001; http://epso.jrc.es/newsletter/vol08/3.html
Centeno, Clara (a)
Building Consumer Trust and Security in Internet Payments The potential of soft measures.
Background Paper No. 7. Electronic Payment Systems Observatory (ePSO), Seville 2002;
http://epso.jrc.es/Docs/Backgrnd-7.pdf

31

Centeno, Clara (b)

Paybest, an emerging micropayment solution for digital goods and services. ePSO-Newsletter Nr. 12
February 2002, http://epso.jrc.es/newsletter
Clements, Bernard et al.
Future Bottlenecks in the Information Society. Seville 2001 (EUR 19917 EN)
Datamonitor
European ePayments 2002: opportunities and threats for FSIs. Statistic retrieved from the ePaynews
website at http://www.epaynews.com/statistics/purchases.html#29
Diffuse
Conference Conclusions of 2nd Diffuse Conference 6th February 2002,
http://www.diffuse.org/conference2-conclusions.html
Eastlake, Donald
Interview: Whether or not the Internet Open Trading Protocol (IOTP) is successful depends on the
definition of success. Knud Bhle (IPTS, Seville, talks to Donald Eastlake, chairman of the IETF
TRADE working group that is developing IOTP. ePSO-Newsletter Nr. 12 February 2002,
http://epso.jrc.es/newsletter
ePSO 2001
Documentation of ePSO Workshop "Integration of Internet payment systems into e-commerce", Friday
9th of November, IPTS Seville; http://epso.jrc.es/project/M4Agenda.html
Gpayments
Smart Payment Technology. Form filling techniques designed to expedite online payment transactions.
Warriewood (Australia) 2001
http://www.gpayments.com/pdfs/GPayments_Smart_Payment_Technology_Whitepaper.pdf
Gpayments
VISA 3D-Secure vs. MasterCard SPA. A comparison of online authentication standards, Warriewood
(Australia) 2002
Hendry, Mike
The Internet Open Trading Protocol: What is it and why is it needed? ePSO-Newsletter Nr. 12
February 2002, http://epso.jrc.es/newsletter
Herzberg, Amir
Secure Communication and Commerce Using Cryptography. Prentice Hall 2002 (forthcoming); the
chapter on Micropayments is available at http://www.cs.tau.ac.il/~ah/Notes/micropayments.pdf
Hinchley, Andrew
The CEN/ISSS eWallet project presents its work. ePSO-Newsletter Nr. 12 February 2002
http://epso.jrc.es/newsletter
Jakobs, Kai (Ed.)
Information Technology Standards and Standardization: A global perspective. Hershey, London 2000
Kahin, Brian
The Internet Business and Policy Landscape. In: The Internet as Paradigm. Annual Review of the
Institute for Information Studies. Queenstown MD: Aspen Institute 1997
Lacoste et al.
Lacoste, Grard; Pfitzmann, Birgit, Steiner, Michael, Waidner, Michael (eds.): SEMPER Secure
Electronic Marketplace for Europe. Berlin, Heidelberg, New York, 2000
Latzer Michael and Schmitz, Stefan W.
B2C eCommerce: A Frictionless Market is Not in Sight. Arguments and Policy Implications. In:
Innovations for an e-Society. Challenges for Technology Assessment, Berlin 17-19.10.2001;
http://www.itas.fzk.de/e-society/preprints/ecommerce/LatzerSchmitz.pdf
Lelieveldt, Simon L.
Research Study on the Integration of E-Payments into the Online Transaction Process. Study
commissioned by the Institute for Prospective technological Studies as a part of the ePayments Systems

32

Observatory Project. S. Lelieveldt Consultancy. Amsterdam, December 2001;

http://epso.jrc.es/project/M4Agenda.html.
Li, Man-Sze
E-payment in Seamless e-Commerce. Too many Standards, too few Solutions? ePSO Final Conference,
19. February 2002, Brussels (slides available at:
http://epso.jrc.es/conference/presentations/ps2/msli.ppt)
MasterCard International
Understanding the E-Wallet User. A Market research Report. MasterCard International 2001
OECD (Working Party on the Information Economy)
WPIE ad hoc technical expert group. Electronic Commerce Business Impacts Project: Methodology for
assessing the dynamics and impacts of electronic commerce. Paris 2000
Perman, Stacy
E-tailing Survival Guide: OK, Forget the Whole Damn Thing. Business 2.0.
http://www.business2.com/articles/mag/0,1640,8786,00.html
Reddy, R
Protocol for shopping over the Internet. IETF draft, December 01, 1997,
http://globecom.net/ietf/draft/draft-reddy-ishop-00.html
Riehm, Ulrich and Bhle, Knud
Geschftsmodelle fr den Handel mit niedrigpreisigen Gtern im Internet. In: Thieen, F. (Hrsg.):
Bezahlsysteme im Internet. Frankfurt am Main 1999, p. 194-206
Tarifica
Tarifica survey finds untapped market for webhosting among early adopters of corporate websites.
Press Release, London, 21May 2001; http://www.tarifica.com/press/view_release.asp?pressid=46
Telematica Instituut (a)
Modelling Transaction Services, Telematica Instituut, Enschede, May 2000,
https://extranet.telin.nl/docuserver/dscgi/ds.py/Get/File-9153
Telematica Instituut (b)
A functional architecture for the financial exploitation of network-based services, Enschede, Jan 2000,
http://extranet.telin.nl/dscgi/ds.py/Get/File-13196/GigaABP_Functional_Architecture_v1.pdf
Telematica Instituut (c)
Electronic Procurement, a functional reference model, Enschede, November 2000,
https://extranet.telin.nl/docuserver/dscgi/ds.py/Get/File-15270/
The Boston Consulting Group
The race for online riches. E-retailing in Europe. February 2000
http://www.bcg.com/new_ideas/new_ideas_subpage3.asp
Thomann, Hans-Rudolf
The death of SET. European Card Review. November/December 2001, p. 28-35
van den Nieuwenhof, Jozef
Interbank systems for retail payments in euro. The agenda for 2010. Keynote speech at the ECB
conference on retail payments "Towards a domestic payment infrastructure for the euro area".
Conference held at the premises of the ECB, on Wednesday, 7 February 2001",
http://www.ecb.int/events/conf/other/retailps/03Nieuwenhof2.pdf
Vividence
Vividence discovers why consumers abandon shopping carts online.
http://www.vividence.com/public/news+and+events/press+releases/2001-1105+shopping+cart+abandonment.htm
Wessels, Jan
The future of digital content Free or paid? In: Innovations for an e-Society. Challenges for
Technology Assessment, Berlin 17-19.10.2001;
http://www.itas.fzk.de/e-society/preprints/ecommerce/Wessels.pdf
Wichmann, Thorsten
Billing Woes. ePSO-Newsletter Nr. 13 April 2002, http://epso.jrc.es/newsletter

33