Integration of Electronic Payment Systems into B2C Internet Commerce Problems and Perspectives

(1)

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 Böhle

EUR 20277 EN

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

(2)

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

Reproduction is authorised provided the source is acknowledged

(3)

Abstract

The focus of this paper is on the integration of payment systems into B2C Internet-commerce. Our understanding of the payment integration problem starts from the obser-vation 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 elec-tronic payment systems.

The paper starts by modelling the whole transaction process; and then addresses the mer-chant'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 pay-ment 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 banking, payments and e-commerce 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?

(4)

Is the integration of digital rights management technology in B2C e-commerce re-quired for the further development of the European eContent market?

Is the establishment of a micropayment infrastructure required for the further devel-opment of the European eContent market?

(5)

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 (Böhle et al. 2000). Previous to the present paper a study on the subject, based on desk research and interviews in The Neth-erlands, had been prepared for ePSO (Lelieveldt 2001). ePSO also organised an expert workshop on 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 ePSO-Newsletter between Decem-ber 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 mer-chants 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? Exam-ples 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 lev-erage 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 transac-tion 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 e-commerce 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}

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

(8)

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 e-banking, 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 e-payments into the online transaction process. Small and medium enterprises (SMEs) reportedly have major problems, because of their lack of both ICT expertise and bar-gaining power with intermediaries,. What measures should be taken to strengthen their position?

With respect to consumers, the development of "browser-software" is crucial. At pres-ent the smooth integration of idpres-entification/authpres-entication mechanisms is at stake. How will the competition between approaches within the financial sector and the ICT sec-tor, and between these two sectors, affect the adoption of e-commerce by consumers? An implicit question with importance for consumer privacy is whether "identity tech-nology" and "payment techtech-nology" will and should converge.

Is the integration of digital rights management technology in B2C e-commerce re-quired for the further development of the European eContent market?

Is the establishment of a micropayment infrastructure required to further the develop-ment 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 exam-ple, 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.

(9)

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 sim-ple 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 effi-ciency 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 proc-ess. 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 standardiza-tion. 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.

(10)

2 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 restruc-turing, but also new types of goods and services emerge. While current interest and de-bate 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

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 physi-cal 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.

goods/services monetary value

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

(11)

known brand, spontaneous purchase). A transaction is defined here as any exchange be-tween 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 exam-ple analysing break offs at checkout – or transaction processes where part of the transac-tion is performed on the Internet and the rest outside or vice versa. The definitransac-tion 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 re-voke 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 ac-count 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 mer-chants on the other hand.

The strictest concept of integration would claim that the more steps of an online transac-tion process are done on the Internet, the higher the level of integratransac-tion. Full integratransac-tion in

(12)

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 in-volve 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 ac-counts 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 pro-tection, delivery service, after sales services (Latzer and Schmitz 2001). Once an appar-ently appropriate company is identified, more information about the offered good (refer-ences 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

3_{Thanks to a comment by Hansrudolf Thomann in ePSO-F, 9 Apr 2002 09:28:32 our simple model}

(13)

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 de-liver 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 post-payment model, e.g. post-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 prob-lem 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 serv-ice 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 com-plete) may be caused by technical problems or by non-fulfilment of the payment obliga-tion 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

(14)

support payment reversals, credit transactions and chargebacks. Reversal mechanisms are state-of-the-art in most POS systems and vending machines. Credit transactions are com-monplace 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 charge-back is a unique feature of the credit card system relying on the specific contractual rela-tions between merchant and acquirer, cardholder and issuer and acquiring/issuing mem-bers with the card associations.

Table 1: Typical elements of a B2C transaction process

Seller Buyer

Offering: seller offers specific goods and

services

Advertising: seller communicates its

prod-ucts and services (catalogue)

Information gathering: buyer retrieves

in-formation about goods, terms and conditions etc.

Selling: selleragrees in a contract with the buyer on the content of a specific order

Billing: seller produces and presents

in-voice

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

pur-chase

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 capabil-ity 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 inse-curities during the fulfilment phase. The throughput of payment data to support the effi-cient organisation of the payment value chain should also be facilitated – from data cap-ture to reconciliation – and other business processes such as delivery and customer serv-ices. 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 require-ments of data exchange are relevant principally for the actual transaction process, it has to

(15)

be stressed that the data captured can also be used for the support of other business proc-esses 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, authentica-tion 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 infrastruc-ture. 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

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 analy-sis 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.

4_{See for example the paper of the Telematica Instituut on accounting, billing and payment produced}

as part of its GigaPort project (Telematica Instituut 2000b).

Preparation Deed of sale Completion Resolving

Data collection, storage, throughput, tracking, tracing, analysis Security infrastructure enabling e.g. authentication of traders

(16)

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 trans-actions 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 down-loaded 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 func-tions. 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 Re-source 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

Back-office Merchant server Customer browser Legacy system financial applications ERP e-commerce helpers Back-office Legacy system ERP

Merchant B2B Merchant B2C Customer

Merchant server

(17)

To sum up, it is important to look at back-office technology developments (towards Inter-net 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.

(18)

3 VIEWS OF THE INTEGRATION PROBLEM

3.1 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 mecha-nism is the shopping cart. Often, but not always, the transaction process involves an on-line 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 authorisa-tion, clearing and settlement of payments. Its operations may be limited to specific ment functions or it may also provide billing and matching services. The range of pay-ment 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 pay-ment methods, including offline paypay-ment 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 compati-ble with regularly used administrative software, i.e. feeding e-commerce data into the ex-isting back-office system should be no problem, when standard software packages are

(19)

used in-house. The output report that the PSP delivers to the company (for matching pur-poses) can be delivered in a wide range of formats such as HTML, XML, comma-separated 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 e-commerce 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 pay-ment protocols and allows for the use of paypay-ment 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 Work-shop (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.

(20)

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 func-tion. 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 organisa-tions 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 obvi-ously 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 passwords accumulate, as they are often required to sign in or log in. The result is that

(21)

users need to manage a wide range of personal information, user-IDs, nicknames, pass-words, and also financial data for repeated use. To alleviate this inconvenience, tech-niques 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 con-sumer 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 cording to ECML. ECML is therefore taken into account by eWallet providers, but, ac-cording to a paper of Gpayments (2001), "at this point in time the number of sites sup-porting 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 through the development of common standards, experi-enced during the course of its work that major industry players stepped into the identity

6

The importance of server-based solutions is discussed in Böhle 2001b and Böhle 2001c. Informa-tion 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.

(22)

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 com-ing 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 identifica-tion/authentication technologies and payment technologies is at stake.

(23)

4 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 Trade ICT-vendors WWW/IETF

Standardisation bodies Architectures and Frameworks EDIFACT X.12 EbXML Biztalk, MS .net eCO framework XrML SEMPER AAA SAML IOTP MPEG-21 Multi-media Frame-work (ISO/IEC JTC1/ SC29/WG11) Financial Transac-tion Protocols and Message Formats and related com-ponents SET SPA/UCAF 3D Secure e-M commerce Visa XML Invoice [HBCI] [EMV] [CEPS] XML Pay OFX / IFX Passport Liberty Alli-ance {W3 micro-payments standard} ECML CEN/ISSS eWallet project Enabling Technol-ogy Standards and Specifications FINREAD, Open Platform JavaCard Windows for Smartcards Multos SSL XML, XSLT HTML TCP/IP TLS ISO-IEC JTC1-SC17

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

7_{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.

(24)

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

SET

This financial transaction protocol performs the complete payment function. The protocol has been ex-tended 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, interoper-able message format to eninteroper-able 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 corre-sponding 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 ver-sion 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 sys-tem 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 pay-ment). 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, In-tuit 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 in-structions that can be viewed as OFX for the Internet-environment. The IFX specification does not de-scribe 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 Network’s GOLD, developed by IBM and Integrion, and representatives of OFX. IFX is now being further devel-oped 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)

(25)

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 IBM’s 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. Passport’s primary service is user authenti-cation, 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 ad-dress 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 stan-dard 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 eWal-let as "a collection of confidential data of a personal nature or relating to a role carried our by an individ-ual, 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 appli-cations 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 com-merce. 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 pub-lished 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 cross-industry 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

(26)

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 adop-tion by (potential) users. There are also different degrees of and approaches to imple-mentation 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 archi-tectural 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

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.

(27)

ciple, with further migration towards XML-based communication, interoperability prob-lems 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 al-though 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 defi-nition 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 com-mon solutions they were seeking. In the B2B world (particularly the former EDI net-works) 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. Finan-cial sector proposals 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 e-commerce and payments we also see, as already mentioned in chapter III/2, that ICT-vendors stepped in

(28)

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 e-commerce 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 authentica-tion 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 devel-oping 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 de-tail, for example, on the way to ensure brands are presented correctly in a generic brand-independent environment. The initial design and implementation of IOTP have put per-haps 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 flexibil-ity towards existing and emerging products, and new e-commerce phenomena like P2P

9_{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, Aus-tria, 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.

10

The following argumentation is derived from articles of ePSO-N, particularly Hendry 2002, Eastlake 2002, Böhle 2002, Böhle 2001a, Böhle and Lelieveldt 2002. Worthwhile introductions to IOTP can be found in CEN/ISSS 2001a and Telematica Instituut 2000a.

11_{There has been no source found discussing explicitly the relation of IOTP and the authentication}

(29)

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 mar-ket 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 pay-ment 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 mecha-nism 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.

(30)

5 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 re-sponsibility 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 proce-dures 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 pro-curement card that simplifies procedures and reduces payment periods as well, is an ex-ample 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 in-clude 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 al-ready 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}

(31)

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 suc-cessful 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 in-ter-organisational procedures, is more generic. This framework competes with the .NET approach taken by Microsoft, which covers the technical, protocol, business and archi-tecture 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.

(32)

6 INTEGRATION CHALLENGES FOR THE DIGITAL GOODS MARKET

Jupiter Research projects annual revenues for all pre-paid content categories of $1.7 bil-lion for 2002 and $5.7 bilbil-lion for 2005 and estimates that the items most likely to be pur-chased 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 eCon-tent 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 combina-tion 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 sys-tems 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 pay-ment instrupay-ments 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 error-prone 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

(33)

market, don't have a bank account and are therefore in need of alternative payment meth-ods.

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 pay-ment (micro-billing) are the two basic models, when subscriptions or other more complex revenue models are not viable (Riehm and Böhle 1999). It is common sense that cost ef-fective micropayment services require aggregation of transactions. Money flows can be aggregated either in-house or by using a payment-service-provider (PSP). PSPs often op-erate 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 mi-cropayment 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 infra-structure 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 prod-ucts, or applying chip technology for ("prepaid" or "postpaid") aggregation purposes.

(34)

7 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 pay-ments embracing technical security measures, authentication mechanisms, legal regula-tions and potential law enforcement, contractual regularegula-tions 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 responsi-bilities of payment service providers is the best way to bring about a security infrastruc-ture 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 elec-tronic and non-elecelec-tronic 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 pay-ment system into the e-commerce segpay-ment of online-auctions. In ePSO Background Paper No.4 (Böhle 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 differ-ence 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.

(35)

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

The multitude of standard initiatives at different levels and their low level of mutual rec-ognition 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 finan-cial 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 ac-count 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 avail-able 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 ap-proach. 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 e-payments into the online transaction process. In terms of pricing and complexity, the so-lutions in the B2C segment cover the low-end and the high-end of the market. The prob-lem of a wide variety of payment mechanisms and formats can be solved with these solu-tions 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.