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

EUR 20277 EN

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.

Report EUR 20277 EN

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 do not easily produce the data the merchants would like to feed into 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 appropriate 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 5 6 7 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

1 1.1

INTRODUCTION 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 19 November 2001 entitled "Integration of Internet payment systems into ecommerce", part of which was dedicated to the validation of the aforementioned study.1 The topic was also addressed in several articles of the ePSO-Newsletter 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).

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. Small and medium enterprises (SMEs) reportedly have major problems, because of their lack of both ICT expertise and bargaining power with intermediaries,. What measures should be taken to strengthen their position? 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 do not easily produce the data merchants would like to feed into their legacy back-office systems. Even if this were 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 do not 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. After that 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.

2 2.1

MODELLING THE ONLINE TRANSACTION PROCESS 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 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

Seller
goods/services

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.

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 well and is perceived as doing so, 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 well the goal of integration is attained. We can also add that integration includes situations when everything does not work well 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 hand and private networks (e.g. banking networks) and proprietary back-office systems of merchants on the other hand. 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 offline. 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, properties 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 both parties. The merchant

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.

must 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 both parties. 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 bank 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 for either the consumer or the merchant. 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 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 Offering: seller offers specific goods and services Advertising: seller communicates its products and services (catalogue) Buyer Information gathering: buyer retrieves information about goods, terms and conditions etc.

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

Paying: buyer pays the seller by giving a payment instruction or a form of cash

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 principally for the actual transaction process, 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 a 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, and 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, e.g. 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).

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 that considers 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 incentive 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, mcommerce, 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 Back-office Customer browser

Merchant server

ERP

ERP

Merchant server

Legacy system

Legacy system

e-commerce helpers

10

To sum up, it is important to look at back-office technology developments (towards Internet technology) and the changes necessary in 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 between 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 offline 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 centres 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 are

12

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 offline transactions. Merchants need to comply with requested data formats. The problem of continuous change is also worth a 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 decision 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 (ePSO 2001/Hendry), data from the UK were presented based on information by the
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

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 from 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 difficult position. If a retailer operates its own credit-card authorisation services and is confronted with a charge back, the first thing it would do would be to find out the specifics of the customer and the order. On the basis of this 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, which handles among other things 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 onlineshopping 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 passwords accumulate, as they are often required to sign in or log in. The result is that

14

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 payments. The operation of eWallets should also imply workable solutions to identification/authentication issues and form-filling. 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 Modelling 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, according to 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 midterm. The eWallet standardisation project, supported mainly by smaller technology companies seeking wider market acceptance through the development of common standards, experienced during the course of its work that major industry players stepped into the identity
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

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

4 4.1

THE ROLE OF STANDARDIZATION IN PAYMENT INTEGRATION 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 Trade EDIFACT X.12 Architectures and Frameworks EbXML ICT-vendors Biztalk, MS .net XrML SEMPER SET SPA/UCAF Financial Transaction Protocols and Message Formats and related components 3D Secure e-M commerce Visa XML Invoice [HBCI] [EMV] [CEPS] FINREAD, Enabling Technology Standards and Specifications Open Platform JavaCard Windows for Smartcards Multos SSL XML, XSLT HTML TCP/IP TLS ISO-IEC JTC1SC17 XML Pay OFX / IFX Passport Liberty Alliance {W3 micropayments standard} ECML CEN/ISSS eWallet project WWW/IETF AAA SAML Standardisation bodies MPEG-21 Multimedia Framework (ISO/IEC JTC1/ SC29/WG11)

eCO framework IOTP

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 centres 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 Modelling 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 ecommerce 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 and the product-service levels. 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 are trying 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 basic enabling Internet technologies. This facilitates the flexible sending, formatting and translation of data over open networks. It increases the possibility of defining 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 prin-

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

ciple, with further migration towards XML-based communication, interoperability 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 cut back. One of the main reasons for this is the lack of a framework for using XML, rather than any limitation of the technology itself. 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 with payment system integration in mind, we also have to take into account the several standardisation efforts centred around authentication. Financial sector proposals include the SET-protocol, followed by a number of more lightweight specifications (3D-secure, UCAF/SPA), and different ways to produce "pseudo card numbers". At the level of those standards closely related to B2C e-commerce and payments we also see, as already mentioned in chapter III/2, that ICT-vendors stepped in

21

and addressed authentication and identification with their e-wallet 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: 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 brandindependent environment. The initial design and implementation 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 P2P
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 home banking 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 "home banking 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

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 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 e-merchants ask a payment service provider to integrate e-payments into their webshops and back offices, they require their most urgent business needs to be solved within a given budget and given time constraints, without too many changes having to be made in their back-offices. The e-merchant will not 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, which 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 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. Harmonising the product catalogue within an industry already 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 is ever to 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 largely 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 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 credit cards (of about 20 cents), for example, and other Internet enabled traditional payment instruments. Herzberg also points out that credit cards and other traditional payment instruments are not suited to low value transactions of digital goods because of the 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 errorprone and difficult to prove. Escrow services could solve the problem, but are out of the question for small value payments. One can add that often young consumers, the target

26

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 will probably want payment upfront but the buyer will want 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 "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 for an efficient micropayment infrastructure and the type of co-operation that could bring it about. The answer also depends 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 also on direct debit mandates paving the way to integrate the presentation of the bill for an online purchase and bill payment. The difference between payment cultures and the national character of existing integrative solutions emphasises again the need in Europe 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) significantly increase transparency. However, banking industry standards are considered to be either outside the scope of these efforts, or they are not taken into account appropriately, even though one might expect that banking standards bodies like ECBS in the future will have to increasingly orient their activities 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 an example of co-operation between different types of standardisation bodies (Centeno 2001). With respect to policies, a cautious approach would be to focus on dissemination of available information on standards and specifications, rather than on 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 fundamental to 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 consumers have in making 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 being developed to a large extent outside the incumbent financial industries, strengthening 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 for 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://wwwi4.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 Observatory Project. S. Lelieveldt Consultancy. Amsterdam, December 2001; http://epso.jrc.es/project/M4Agenda.html.

32

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/esociety/preprints/ecommerce/Wessels.pdf Wichmann, Thorsten Billing Woes. ePSO-Newsletter Nr. 13 April 2002, http://epso.jrc.es/newsletter

33