E-payments: Credit Cards on the Internet Richard Jewson docx

Part 1: Overview of Payments The Issues To exchange value in a secure and trusted manner using credit cards, you must consider a number of factors: • Card Validation: Is the presented

E-payments: Credit Cards on the Internet

Aconite

richard.jewson@aconite.net

Contents

! Introduction

! Part 1: Overview of Payments

! Part 2: Payments Technologies Past & Present

! Part 3: Current Developments

! Conclusion

! References

Introduction

Commerce involves the exchange of value By the end of 20th century, the exchange of financial value had evolved from coins, notes and other instruments to sophisticated e-payment systems In e-e-payments, the exchange of value is represented by the exchange of data It is easy, fast and cheap to transfer data, but these benefits come at

a cost The physical authenticity of payment instruments such as notes and coins can

be checked In e-payments, the parties involved will probably never even see or talk to each other Proving the authenticity of the payment, payer and payee are fundamental

to the widespread adoption of e-payments

This paper is the first in a series which

looks at e-payments technology and

solutions This article introduces the

basic components of any B2C

e-payment system: the protocols by which

the payer and payee establish trust in

each other and exchange value

electronically across open, insecure

channels such as the Internet In this

paper we concentrate on credit card

payments, the most popular method of

payment for goods, information or services on the Internet

Despite numerous technical advances, credit card payments have remained fundamentally unchanged since the early 80’s So have the risks Any business that accepts credit cards has to accept a certain level of fraud In the real world, you can manage and mitigate this risk with physical, policy and infrastructure controls This is

true for face-to-face or card-present transactions, despite recent marked increases in real world fraud such as card cloning It is less true for card-not-present transactions

Credit card payments have remained fundamentally unchanged since the early 80’s So have the risks

used for mail and telephone orders (known as MO/TO) The use of the Web for commerce means that there are now new ways to commit fraud

Part 1: Overview of Payments

The Issues

To exchange value in a secure and trusted manner using credit cards, you must consider a number of factors:

• Card Validation: Is the presented card valid?

• Cardholder Authentication: Is the cardholder genuine?

• Merchant Authentication: Is the merchant a bona fide member of a payment scheme (eg Visa, Mastercard)?

• Privacy: Are the details provided during the transaction handled securely and not available to unauthorized parties?

• Interoperability: Is the system compatible with a variety of vendor solutions and does

it use open standards?

• Ease of use: How visible is the system to the cardholder?

• Easy to implement: Is the system cost effective to the merchants and financial

institutions (FIs)?

• Future proof: Is the system able to use emerging technologies?

Solutions must address many of these factors, with ease of use the most important for customers The principle of ‘Risk vs Reward’ is central to the payments world Attempts to produce a very low risk system have largely failed and produced no reward The SET protocol is an example and we discuss it later On the other hand, higher risk solutions such as simpler SSL-based systems are widely used and have enabled the growth of e-commerce

Managing the risks associated with making payments is not covered in this paper, but is important in defining a usable solution Risk management looks at the whole picture, not just the technical aspects

Real World Card Payments

Let us review ‘real world’ credit card payments A credit card is a certificate: a statement made to a merchant about the holder of the card by athird party, the issuer of the card

In a card-present transaction the merchant can rely on the measures built into the card

to prove the authenticity of both card and cardholder (see Figure 1)

Authenticity of the card:

• Complex images printed on the card

• Hard to forge holograms

• Magnetic stripe (although this is relatively easy to duplicate)

Authenticity of the cardholder:

• Signature stripe, which provides a sample of the cardholder’s signature This must

be duplicated in front of the merchant In some cases this is printed on the card to stop their replacement

• Photograph of the cardholder

• Face-to-face contact between the cardholder and merchant

With card-not-present transactions, although the merchant cannot physically see the card or the cardholder he can still use certain methods of authentication:

• Address verification: Allows the merchant to match the cardholder’s address to an online database

• Cardholder verification values: A 3-digit number printed on the signature stripe that is not included on the magnetic stripe

• Human interaction A well-trained salesperson can identify a fraudulent transaction

A N Other A N Other A N Other

A N Other

AbcBank

666 A N Other

AbcBank

666

Acme Bank

1234 5678 9101 1234

MR A N OTHER

Acme Bank

1234 5678 9101 1234

MR A N OTHER

Acme Bank

MR A N OTHER

1234 5678 9101 1234

Acme Bank

MR A N OTHER

Acme Bank

MR A N OTHERExp 07/03

1234 5678 9101 1234

1234 5678 9101 1234

! Chip

! Hologram

! Magnetic stripe

! Card

! Embossing

! Signature

! Card Verification

Code (CVC)

Figure 1: Evolution of Credit Card Security Features

Virtual Payments

A virtual payment at an Internet retailer is similar to a card-not-present transaction The retailer has to trust that the payer is the authorised holder of the card If not, the retailer relies on the acquirer’s authorization and fraud systems to reject the transaction There

is one fundamental difference however: the complete automation of the processing on

the merchant’s side The lack of human involvement in the transaction

is one of the greatest benefits of e-commerce Automation allows the retailer to handle more transactions, more quickly and more cheaply But this benefit is also a security flaw Whilst the automation of the sales process has opened up new commerce opportunities, it has also opened up new scope for payment fraud:

• More opportunities for would-be fraudsters

• Technology which protects anonymity

• Many attempts in a very short time

The automation of the sales

process has opened up new

commerce opportunities - it

has also opened up new scope

for payment fraud

• Very little prosecution

• Successful fraudulent payment methods can be used at other sites simultaneously The Internet, like MO/TO transactions, also presents another problem: the authenticity of the merchant With a card-present transaction the customer can take up problems with the merchant face-to-face On the Internet there are fewer avenues available to help the customer resolve problems Other threats exist, such as ‘spoofing’ a legitimate retailer

to deceive users and gain cardholder details Who can you trust?

Part 2: Payments Technologies Past & Present

An Introduction to Secure Sockets Layer (SSL)

SSL establishes a secure communication channel between two computers Communicating parties use that channel to exchange data in a confidential manner SSL also enables both parties to check the integrity of that data and optionally, to authenticate each other SSL was designed to be a generic secure communication protocol - not a payment protocol

Why is SSL so widely used? Why is it not good enough for e-payments?

SSL is the foundation of most secure e-commerce transactions today From encrypting sensitive payment details to verifying the authenticity of a web site, SSL provides sufficient security for e-commerce In the context of electronic payments, SSL allows the cardholder to transmit their payment details to the merchant’s server in a secure manner SSL-based e-payments suffer from the same problems as MO/TO transactions, as well

as others more relevant to electronic channels:

• No mechanism to provide strong authentication of the cardholder or merchant

• No controls over what that merchant does with the cardholder’s payment details This problem was highlighted recently by the much-publicised theft of credit card details from several online retailers [5]

• Lack of policy and legal frameworks to allow a customer to trust a merchant

Despite these issues, SSL is now a de facto standard in the payments industry

An Introduction to Secure Electronic Transaction (SET)

In 1996 Visa and MasterCard developed the SET protocol It was designed to provide trusted electronic transactions This would provide security to all parties involved in the transaction and address many of the limitations associated with an SSL-only transaction SET is an open standard, now managed by SETCo LLC [1] SET defines four components – a Certificate Authority, Cardholder Wallet, Merchant SET Modules and Payment Gateways - any of which a technology vendor may implement

SET requires cardholder, merchant and acquirer software, and some components of a Public Key Infrastructure (PKI) to support the trust architecture SET allows the cardholder and merchant to authenticate each other with digital certificates before a transaction The cardholder is sure they are dealing with a legitimate merchant, and the merchant has proof that the cardholder is authorized to use the selected card Once this trust is established, both parties can exchange transaction information SET uses a ‘fat wallet’: a large application installed on the cardholder’s PC to hold payment details and

perform the SET transaction for the cardholder See Figure 2 for an overview

What Happened to SET?

There are many reasons why SET failed Here we highlight the more important technical reasons:

• Distribution and portability of cardholder certificates

A full implementation of SET requires that each cardholder has a digital certificate Issuing and installing these on cardholder PC’s was difficult A certificate installed at the customer’s home PC could not be used on any other PC – a major issue for cardholders

• Software distribution and maintenance

1 Purchase Request

6 Receipt

2 Authorisation Request

5 Authorisation Response

3 Authorisation Request

Acquirer Issuer

Payment Gateway

Cardholder Wallet

Merchant Server

4 Authorisation Response

Mutual Authentication

Figure 2: The SET Protocol

The installation and maintenance of wallet software on customer PCs requires support from the issuer Infrastructure at merchants and financial institutions is also required

• Interoperability

Incompatibility of different components from different vendors hindered uptake despite interoperability assurance provided by SETCo though their ‘SET Mark program’

• Co-operation from all parties

SET requires buy-in from FIs, merchants and consumers Without a clear business benefit for merchants such as reduced chargebacks, and similar benefits for consumers, uptake was limited Implementation costs were not justified

• Constraints on gathering market intelligence

Design limitations imposed by SET, such as the hiding of cardholder details, prevented merchants from tracking customers

Technically, SET is a sound protocol which answers most of the issues that the industry faces Its failure was due to the complexities of deployment

3D SET

SET never reached critical mass In the US, interest was almost non-existent while in Europe and the Far East, there was only limited success with pilot projects These have since been shut down one by one To address this lack of success and to promote SET further, Visa introduced ‘3D SET’ in 2000 3D SET was introduced to drive the use of credit card payments online, lower the complexities of the original SET protocol and simplify the chargeback mechanisms

Two of the core aims for 3D SET were to:

• reduce the effort of performing a SET payment on behalf of the cardholder

certificate from any device with Internet access

With 3D SET, the cardholder’s wallet is moved to a central server and maintained

by the card issuer or bank This vastly simplifies the cardholder subscription process and requires only a small application on the cardholders PC – a ‘thin wallet’ architecture

3D SET incorporates the SET protocol into the Three Domain Model:

1 Acquirer Domain The parties who acquire transactions, such as merchants and transaction services

2 Issuer Domain The parties who issue payment instruments that are used in the Acquirer Domain, such as FIs and other scheme operators

3D SET provides a flexible

framework that allows

banks and acquirers to use

their own methods to

authenticate cardholders

and merchants in a

transaction

3 Interoperability Domain The area between the Issuer and Acquirer domains that governs how a payment is made and how they operate with each other

The original SET protocol fits into the Interoperability Domain It is unchanged from the original SET protocol The 3D SET model provides a flexible framework that allows banks and payment acquirers to use their own methods to authenticate cardholders and merchants in a transaction Each party uses the secure and complex interoperability protocol to communicate with the others

As an example, let’s consider 3D SET within an issuing bank A SET Wallet resides on

a central bank server and provides the SET transactional capability The bank’s cardholders who have SET certificates also have accounts within that central wallet The issuing bank can decide how to authenticate its own cardholders because it owns the wallet This removes the need for specialised software on the cardholders PC and allows the cardholder to use many different payment channels from PC to mobile phones

3D SET has gained ground in Europe and South America but not yet in the US As supporting products mature, deployment of the solution will become easier and cheaper The jury is still out on its future

Part 3: Current Developments

Given the size of the US e-commerce

market, the lack of real payment security

presents huge risks to payment scheme

operators It comes as no surprise that

efforts are being made to address these

risks Both Visa and MasterCard have

developed competing payer authentication

standards Both use SSL and provide

additional mechanisms to authenticate the

cardholder and merchant

Visa: Payer Authentication Service

3D Secure [3] is a payer authentication service First, a cardholder enrols for the scheme at their issuing bank’s site This enables payments to be made with their card During enrolment, the cardholder registers a password Next, a cardholder visits the site

of a merchant which participates in the scheme He clicks the ‘Buy’ button on this site and is prompted to enter his password Finally, the issuing bank verifies the cardholder’s password and if successful, passes the payment details to the merchant

MasterCard: Secure Payment Application

Like the Visa initiative, MasterCard’s Secure Payment Application (SPA) [2] standard is a payer authentication service First, the cardholder registers for the service with their issuing bank They then set a password and downloads a Java applet Next, during a

The lack of payment security presents huge risks

to scheme operators - it comes as no surprise that efforts are being made to

address the risks

purchase, they enter the password for the service The issuer authenticates the cardholder and generates an authentication value which is returned to the applet The applet incorporates this value into a hidden part of the payment details form which is sent to the merchant Finally, this value is then used during when the merchant processes the purchase transaction, and is verified by the issuing bank

From the second half of 2001, online retailers will need to to support both authentication methods [4] This is meeting with a less than warm reception and some sources warn that the competing services may see no more acceptance than SET did

Table 1 gives a summary of the benefits provided by the different payment schemes:

Authentication

Key to matrix

- Not applicable * Basic or Poor ** Moderate *** Good **** High or Strong

Table 1: Payment Schemes Benefits Matrix

Other Technologies

Numerous other payment technologies are being promoted both as partial and full solutions to the problems faced Smart card technology is becoming more prevalent and will have many implications for e-payments These portable cards can store information such as signing keys, provide digital signing capabilities and authenticate the cardholder using a PIN or password Issuers are slowly replacing magnetic stripe cards by smart cards with payment applications loaded EMV, a joint initiative between Europay, Mastercard and Visa, is one scheme using smart cards Although EMV provides some security against fraud in the real and virtual worlds, it still leaves some questions unanswered These technologies undoubtedly provide many benefits but only when used in conjunction with a secure, widely accepted protocol Until then, consumers and merchants will not fully trust e-payments

Other technologies deal with other areas of e-payments These include:

• Micro payments, for very low value transactions;

• Surrogate card numbers - a new credit card number for each transaction the cardholder performs

• Mobile payments, to pay for services from a mobile handset or PDA;

Operators of payment schemes need to reinforce the position of credit cards as the preferred way to pay online,

by raising consumer and merchant confidence

• Person-to-person and B2B payments;

• Advances in cryptography such as elliptic curve methods (ECC) which improve the performance and efficiency of cryptographic processing also help to shape new and innovative e-payments capabilities ECC is better suited to constrained devices such as smart cards and mobile phones

Articles later in the series cover many of these themes and emerging technologies

Conclusion

It’s been 5 years since the payment industry made the first concerted efforts to make paying by credit card on the Internet straightforward and secure Ultimately, the real purpose of developing an e-payments protocol is to promote the use of the card Operators of payment schemes need

to reinforce the position of credit cards

as the preferred way to pay online, by

raising consumer and merchant

confidence There is no serious

competition to the credit card for

e-payments, and the industry is

dragging its feet over co-operation

and promotion of a globally accepted

solution Today we are no closer to

this goal and there remains serious

fragmentation of the industry This is a particular problem when you consider more complex issues, such as cross border payments For example, what happens when a

US cardholder wants to purchase goods in the EU and his issuer’s authentication method is not recognized? Who accepts the risk for that transaction?

Five years on, issues regarding technical interoperability and mutually accepted levels of authentication are being addressed, but a universally accepted solution is yet to arrive Recent initiatives such as EMV are gaining widespread support amongst merchants and consultancies such as Aconite are seeing growing demand from clients determined to make them work After a number of false starts, payments processing on the Internet is about to enter a new era

About the author

Richard is a consultant specializing in secure e-commerce payments, digital trust and

cryptography technologies He provides technical consultancy on secure payment protocols and products, e-commerce and security to major financial services and telecommunication clients, both in the UK and worldwide

About Aconite

Aconite provides consultancy and solutions to clients worldwide Aconite’s consultants each have ten years experience drawn from the financial services and retail sectors and specialise in smart cards, e-trust and security, and e-business systems integration For further information, contact Andy Davies, andy.davies@aconite.net or visit www.aconite.net

Use & Distribution

Use of this article is free of charge provided that the following citation is included wherever it is

referenced: “Aconite Whitepaper, E-payments: Credit Cards on the Internet, October 2001,

www.aconite.net” For questions regarding the use of this article, contact Andy Davies,

andy.davies@aconite.net

References

Web site references valid as of 6th October 2001

[1] SETCo LLC

www.setco.org

[2] Mastercard Secure Payment Application (SPA)

http://www.mastercardintl.com/about/press/pressreleases.cgi?id=423

[3] 3D Secure from Visa

http://www-s2.visa.com/av/news/press_release.ghtml?pr_form_edit=671

[4] Competing payment standards

http://news.zdnet.co.uk/story/0,,s2094952,00.html

[5] SecurityFocus news item on credit card fraud

http://www.securityfocus.com/news/111