The Internet Encyclopedia (Volume 3)

P1: JDV

Merkow WL040/Bidgolio-Vol I WL040-Sample.cls June 20, 2003 12:46 Char Count= 0

254 SECUREELECTRONICTRANSACTIONS(SET)

Payment Gateway Systems

A few pioneering banks began to develop their own pay-

ment gateway interfaces for SET, and SET pilot testing

with willing merchants or simulated e-commerce systems

using employees of the banks began to reveal problems

in implementation and compatibility of implementations

across software developers.

In the United States, NationsBank of Charlotte, North

Carolina conducted the bank’s first SET transaction in

early 1998, demonstratingsomeinteroperability between

SET software providers. NationsBank worked closely

with IBM, MasterCard, GlobeSet, and GTE to create a

system for purchase of items from the MasterCard Empo-

rium, an initial Web site built by the association to help

consumers make small initial purchases and overcome

their fears of shopping electronically.

Interoperability actually turned out to be more elusive

than anyone had originally thought. For example, if an

IBM CommercePOINT e-wallet failed to send properly

formatted and decipherable messages to a GlobeSet POS

system or vice versa, the IBM product would lock out cus-

tomers or payment processors except for those who used

the same software—creating an intolerable situation. Al-

though any given SET suite may have worked flawlessly

across all its own components, it was of no use if did not

also work with components from other SET software de-

velopers. The situation was similar to the problem of a

Web site owner insisting that visitors use one brand of

browser to the exclusion of all other browsers. Merchants

will never be certain which e-wallets shoppers use, nor

can they know which payment gateway software their Ac-

quirer bank uses.

By the middle of 1999, it looked like implementing

SET—without adequate incentives from the issuers—was

leading to a train wreck, and by 2000, several of the soft-

ware providers for SET systems had sold off their assets

and closed their doors forever.

With the ongoing pilot testing of SET Version 1.0,

banks were finding that their consumers were experienc-

ing agony and resentment when asked to deal with bank-

branded electronic wallets. Banks were erroneously hop-

ing their customers could perform these tasks:

Select SET-compliant e-wallets

Download them

Install them correctly on their PCs

Acquire the digital certificates for each credit card they

wanted to use on-line

Always use SET for shopping and refuse to shop with mer-

chants who were not SET-compliant.

Between the excessive downloading times for the

huge e-wallet files (6MB+), encrypted transmissions that

caused bandwidth-sapping operations, and unacceptable

waiting times while transactions completed their process-

ing, the testing banks and SET developers were forced

to consider alternative software distribution approaches.

Complicating the problems further, testing banks and

SET developers assumed that merchants (and their

webmasters) would become experts in banking systems

for payment card processing. Initial implementations of

POS components required near-ideal secure hosting envi-

ronments, robust cryptographic processing facilities, and

full understanding of banking and bank internetworks. As

it turned out, only merchants with colossal patience could

begin to meet these requirements.

Industry Attempts to Assuage SET

User Concerns

GlobeSet, out of Austin, Texas, was the first to introduce

the GlobeSet ServerPOS as an alternative to the Globe-

Set POS System for merchant commerce servers. With

ServerPOS, the merchant’s acquiring bank or card service

provider operates the POS component on its premises

with a merchant storefront adapter that resides on the

merchant’s commerce server.

ServerPOS used a multiprotocol approach, supporting

both SET and SSL, to encompass all online merchants

with whom the acquiring bank had forged relation-

ships. On the consumer front, GlobeSet also offered

ServerWallet, using a similar scheme. With the Globe-

Set ServerWallet, card issuer banks bear the responsibility

for managing the SET consumer digital certificates (and

public keys), transaction data related to purchases made

with their cards, and the other SET-related security data.

Consumers needed only to download a thin-client com-

ponent (45 Kbytes in size) to start the communications

with ServerWallet at the bank when a SET transaction

was initiated.

Trials of ServerWallet began in July 1998 and contin-

ued throughout the summer. The service model for SET

appeared as a bright moment for the future of SET, but

unfortunately, little interest in the service model was gar-

nered, either, and the assets of GlobeSet were sold off in

2000.

Further interest in testing or hopes of ever rolling out

SET in the U.S. had completely waned by 2000. Inter-

est internationally, where credit card fraud very much

remained a threat to the banking industry, continued to

expand and several applications of SET made it into the

news.

International Field Trials of SET

EasySET was one implementation of SET from the Span-

ish bank Banesto. EasySET was designed to answer

many of the criticisms of “classical SET” by lighten-

ing the weight of consumer wallets and centralizing the

complex processing of the point of sale (POS) system

and the acquirer payment gateway system into a ser-

vice model implementation, hosted at Banesto. This ser-

vice model approach to SET takes the processing load

off the merchant r-commerce systems and offers the

advantages of improved transaction security and faster

processing.

EasySET

Banesto’s involvement with SET began in 1996 with a pi-

lot project using the Banesto Virtual@Cash card. By mid-

1997, the first Spanish SET transaction was run, and in

1999 the SET Facil, or EasySET project was launched.