Introduction

Outline
+The Net Effect on Payment/E-Payment
+Impact on Developed Countries
+Starting point for Developing Nations
+New Opportunities

Conventional Payment
Mechanisms in United States
+ Approx 80% of payments in Cash











+ International Trade involves Wire Transfers,
Letters of Credit etc.
Non-Cash
Payment
Instrument
Trans.
Volume
Trans.
Value
Average
Value
Check 71% 10% $1,179
C/D Card 25% 0.1% $59
C/D Transfer
by ACH
2.5% 2% $2,000
Wire Transfer 0.1% 86% $4.3m
1999 Source BIS
Retail Payments Net Evolution
+ Cash evolving (very slowly) to Internet based
systems such as Paypal
+ Credit-Card based systems
Ideal for Internet already a global payment method
tradition of card-not-present
Combined with Secure Socket Layer, it is used for
almost all retail E-commerce high fraud rate
+ Retail Check being eroded by Electronic Bill
Payment, electronic home banking
Trade Payments Net Evolution
+ Check Payments migrating to Electronic Transfers
in the U.S. via the Automated Clearing House
(ACH) networks
FSTC E-check and BIPS Projects
+ ACH Transfers growing in importance
European Initiatives: STEP1 (<50K)
Global Initiatives : WATCH, CLS
Internet access to these is coming
+ Total trading Systems
Bolero, Tradecard
Other Aspects of Electronic
Trading
+Electronic Trust building becoming more
common
Legislative Changes in E-Commerce in Europe,
US and Asia enable this
PKI Infrastructure being (slowly) built
Verisign
Identrus
Wisekey
In combination with E-paymentswill enable
complete transactions on-line
Conventional Payments in
Developing Countries
+Generally less developed banking industry
+Credit Cards not widely available
+More reliance on paper
+Foreign Exchange transactions more
problematic
+Being left out of new payment initiatives
Currently 1
9
+ 10 32 +
New Opportunities
+ On the Internet
no-one knows you
are a dog
+ Internet banking
infrastructure is
cheap and easy to
build.. Opportunity to
leap-frog
+ Open standards level
the paying field
+ Must work with new
standards

Electronic Payment Systems
+ Transaction reconciliation
Cash or check
Electronic Payment Systems
Intermediated reconciliation (credit or debit card, 3rd party money
order)
Electronic Payment Systems
+ Online transaction systems
Lack of physical tokens
Standard clearing methods wont work
Transaction reconciliation must be intermediated
Informational tokens
Ecommerce enablers
First Virtual Holdings, Inc. model
Online payment systems (financial electronic data interchange)
Secure Electronic Transaction (SET) protocol supported by Visa and
MasterCard
Digital currency

Electronic Payment Systems
Digital currency
Non-intermediated transactions
Anonymity
Ecommerce benefits
Privacy preserving
Minimizes transactions costs
Micropayments
Security issues with digital currency
Authenticity (non-counterfeiting)
Double spending
Non-refutability

Electronic Payment Systems
Contemporary forms of digital currency
Ecash
Set up account with ecash issuing bank
Account backed by outside money (credit card or cash)
Move credit from account to ecash mint
Public key encryption used to validate coins: third parties can
bite the coin electronically by asking the issuing bank to verify
its encryption
Spend ecoin at merchant site that accepts ecash
Merchant then deposits ecoin in his account at his participating bank, or
keeps it on hand to make change, or spends the ecash at a supplier
merchants site.
Role of encryption
Encryption
+ The need for encryption in ecommerce
Degree of risk vs. scope of risk
Institutional versus individual impact
Obvious need for ecurrencies.
+ Public key cryptography: an overview
One-way functions
How it works
Parties to the transaction will be called Alice and Bob.
Each participant has a public key, denoted P
A
and P
B
for Alice and
Bob respectively, and a secret key, denoted S
A
and S
B
respectively

Encryption
Each person publishes his or her public key, keeping the secret key
secret.
Let D be the set of permissible messages
Example: All finite length bit strings or strings of integers
The public key is required to define a one-to-one mapping from the
set D to itself (without this requirements, decryption of the message is
ambiguous).
Given a message M from Alice to Bob, Alice would encrypt this using
Bobs public key to generate the so-called cyphertext C=P
B
(M). Note
that C is thus a permutation of the set D.
The public and secret keys are inverses of each other
M=S
B
(P
B
(M))
M=S
A
(P
A
(M))
The encryption is secure as long as the functions defined by the public
key are one-way functions
Encryption
+ The RSA public key cryptosystem
Finite groups
Finite set of elements (integers)
Operation that maps the set to itself (addition, multiplication)
Example: Modular (clock) arithmetic
Subgroups
Any subset of a given group closed under the group operation
Z
2
(i.e. even integers) is a subgroup (under addition) of Z
Subgroups can be generated by applying the operation to elements of
the group
Example with mod 12 arithmetic (operation is addition)
Encryption
12 1 mod x
12 2 mod x
Encryption
12 3 mod x
12 4 mod x
Encryption
12 5 mod x
12 6 mod x
Encryption
12 7 mod x
12 8 mod x
Encryption
12 9 mod x
12 10 mod x
Encryption
12 11 mod x
Encryption
+ A key result: Lagranges Theorem
If S is a subgroup of S, then the number of elements of S divides
the number of elements of S.
Examples:
12 12 ,
12 3 ,
12 4 ,
12 6 ,
12 5 12 5
12 4 12 4
12 3 12 3
12 2 12 2
= = c -
= = c -
= = c -
= = c -
Z Z Z Z
Z Z Z Z
Z Z Z Z
Z Z Z Z




Encryption
+ Solving modular equations
RSA uses modular groups to transform messages (or blocks of
numbers representing components of messages) to encrypted form.
Ability to compute the inverse of a modular transformation allows
decryption.
Suppose x is a message, and our cyphertext is y=ax mod n for
some numbers a and n. To recover x from y, then, we need to be
able to find a number b such that x=by mod n.
When such a number exists, it is called the mod n inverse of a.
A key result: For any n>1, if a and n are relatively prime, then the
equation ax=b mod n has a unique solution modulo n.
Encryption
+ In the RSA system, the actual encryption is done using
exponentiation.
+ A key result:
1 mod
, 0
1
=
= e

p a
a Z f or any a ime, then If p is pr
rem ittle Theo Fermats L
p
p


Encryption
+ RSA technicals
Select 2 prime numbers p and q
Let n=pq
Select a small odd integer e relatively prime to (p-1)(q-1)
Compute the modular inverse d of e, i.e. the solution to the
equation



Publish the pair P=(e,n) as the public key
Keep secret the pair S=(d,n) as the secret key
( )( ) 1 1 mod 1 = q p de
Encryption
For this specification of the RSA system, the message domain is Z
n
Encryption of a message M in Z
n
is done by defining



Decrypting the message is done by computing
n M M P C
e
mod ) ( = =
( ) n C C S
d
mod =
Encryption
Let us verify that the RSA scheme does in fact define an invertible
mapping of the message.
( ) ( ) ( ) ( )
( )( )
( )
theorem.) s Fermat' applying by follow steps last (the
mod
mod
mod mod
Hence, . integer some for
1 1 1
other each of inverses modular are and Since
n. mod
any For
) 1 (
) 1 ( ) 1 (
) 1 )( 1 (
M n M M
n M MM
n MM n M
k
q p k ed
e d
M M P S M S P
Z M
k
q
q k p
q p k ed
ed
n
= =
=
=
+ =
-
= =
e -

Encryption
Note that the security of the encryption system rests on the fact that
to compute the modular inverse of e, you need to know the number
(p-1)(q-1), which requires knowledge of the factors p and q.
Getting the factors p and q, in turn, requires being able to factor the
large number n=pq. This is a computationally difficult problem.
Some examples:

http://econ.gsia.cmu.edu/spear/rsa3.asp
Encryption
+ Applications
Direct message encryption
Digital Signatures
Use secret key to encrypt signature: S(Name)
Appended signature to message and send to recipient
Recipient decrypts signature using public key: P(S(Name)=Name
Encrypted message and signature
Create digital signature as above, appended to message, encrypt
message using recipients public key
Recipient uses own secret key to decrypt message, then uses senders
public key to decrypt signature, thus verifying sender
Policy Issues
+ Privacy and verification
+ Transaction costs and micro-payments
+ Monetary effects
Domestic money supply control and economic policy levers
International currency exchanges and exchange rate stability
+ Market organization effects
Development of new financial intermediaries
+ Effects on government
Seniorage
Legal issues
2/16/00 EMTM 553 33
E-payment systems
+To transfer money over the Internet
+Methods of traditional payment
Check, credit card, or cash
+Methods of electronic payment
Electronic cash, software wallets, smart cards,
and credit/debit cards
Scrip is digital cash minted by third-party
organizations


2/16/00 EMTM 553 34
Requirements for e-payments
+Atomicity
Money is not lost or created during a transfer
+Good atomicity
Money and good are exchanged atomically
+Non-repudiation
No party can deny its role in the transaction
Digital signatures
2/16/00 EMTM 553 35
Desirable Properties of Digital Money
+Universally accepted
+Transferable electronically
+Divisible
+Non-forgeable, non-stealable
+Private (no one except parties know the
amount)
+Anonymous (no one can identify the payer)
+Work off-line (no on-line verification
needed)

No known system satisfies all.



2/16/00 EMTM 553 36
Types of E-payments
+E-cash
+Electronic wallets
+Smart card
+Credit card

2/16/00 EMTM 553 37
Electronic Cash
+Primary advantage is with purchase of
items less than $10
Credit card transaction fees make small
purchases unprofitable
Micropayments
Payments for items costing less than $1




2/16/00 EMTM 553 38
E-cash Concept
Merchant
Consumer
Bank
1
2
3
4
5
1. Consumer buys e-cash from Bank
2. Bank sends e-cash bits to consumer (after
charging that amount plus fee)
3. Consumer sends e-cash to merchant
4. Merchant checks with Bank that e-cash
is valid (check for forgery or fraud)
5. Bank verifies that e-cash is valid
6. Parties complete transaction: e.g., merchant
present e-cash to issuing back for deposit
once goods or services are delivered

Consumer still has (invalid) e-cash

2/16/00 EMTM 553 39
Electronic Cash Issues
+E-cash must allow spending only once
+Must be anonymous, just like regular
currency
Safeguards must be in place to prevent
counterfeiting
Must be independent and freely transferable
regardless of nationality or storage mechanism
+Divisibility and Convenience
+Complex transaction (checking with Bank)
Atomicity problem

2/16/00 EMTM 553 40
Two storage methods
+On-line
Individual does not have possession personally
of electronic cash
Trusted third party, e.g. online bank, holds
customers cash accounts
+Off-line
Customer holds cash on smart card or software
wallet
Fraud and double spending require tamper-
proof encryption
2/16/00 EMTM 553 41
Advantages and Disadvantages of
Electronic Cash
+Advantages
More efficient, eventually meaning lower prices
Lower transaction costs
Anybody can use it, unlike credit cards, and
does not require special authorization
+Disadvantages
Tax trail non-existent, like regular cash
Money laundering
Susceptible to forgery
2/16/00 EMTM 553 42
Electronic Cash Security
+Complex cryptographic algorithms prevent
double spending
Anonymity is preserved unless double spending
is attempted
+Serial numbers can allow tracing to prevent
money laundering
Does not prevent double spending, since the
merchant or consumer could be at fault
2/16/00 EMTM 553 43
Blind Signatures
+Goal
to have the bank sign documents without
knowing what they are signing.

+Why?
Anonymity with Authentication
2/16/00 EMTM 553 44
How to sign with blind fold?
+How?
Basic: Sign anything

1. You encrypt the message
2. Send it to the bank
3. The bank signs the message
and returns it
4. You decrypt the signed
message
5. You spend it
2/16/00 EMTM 553 45
Cut and Choose
+Problems
The bank honors anything I write down
+Solution: the Cut-and-choose algorithm

1. Prepare n copies of the messages
and n different keys, and send them to
the bank
2. The bank requests the keys for and
opens n - 1 of them, and verifies them.
It then signs the remaining one.
3. The bank sends back the signed
message, which can then be
decrypted and spent
2/16/00 EMTM 553 46
Anonymous digital cash?
+Protocol #1
+Protocol #2
+Protocol #3
+Protocol #4
2/16/00 EMTM 553 47
Detecting Double Spending
2/16/00 EMTM 553 48
Past and Present E-cash Systems
+E-cash not popular in U.S., but successful
in Europe and Japan
Reasons for lack of U.S. success not clear
Manner of implementation too complicated
Lack of standards and interoperable software that
will run easily on a variety of hardware and
software systems
2/16/00 EMTM 553 49
Past and Present E-cash Systems
+Checkfree
Allows payment with online electronic checks
+Clickshare
Designed for magazine and newspaper
publishers
Miscast as a micropayment only system; only
one of its features
Purchases are billed to a users ISP, who in turn
bill the customer
2/16/00 EMTM 553 50
Past and Present E-cash Systems
+ CyberCash
Combines features from cash and checks
Offers credit card, micropayment, and check payment services
Connects merchants directly with credit card processors to provide
authorizations for transactions in real time
No delays in processing prevent insufficient e-cash to pay for the
transaction
+ CyberCoins
Stored in CyberCash wallet, a software storage mechanism located on
customers computer
Used to make purchases between .25c and $10
PayNow -- payments made directly from checking accounts

2/16/00 EMTM 553 51
Past and Present E-cash Systems
+ DigiCash
Trailblazer in e-cash
Allowed customers to purchase goods and services using anonymous
electronic cash
Recently entered Chapter 11 reorganization
+ Coin.Net
Electronic tokens stored on a customers computer is used to make
purchases
Works by installing special plug-in to a customers web browser
Merchants do not need special software to accept eCoins.
eCoin server prevents double-spending and traces transactions, but
consumer is anonymous to merchant

Aggregation
+Used when individual transactions are too
small for credit card (e.g. $2.00)
+Consumer and Merchant sign up with
Aggregator
+Consumer makes purchase. Merchant
notifies Aggregator.
+Aggregator keeps Consumers account.
When amount owed is large enough (or
every month), charges to Consumers credit
card
+Aggregator sends money (less fees) to
Merchant
+QPASS, CyberCash, GlobeID
2/16/00 EMTM 553 53
Past and Present E-cash Systems
+ MilliCent
Developed by Digital, now part of Compaq
Electronic scrip system
Participating merchant creates and sells own scrip to broker at a discount
Consumers register with broker and buy bulk generic scrip, usually
with credit card
Customers buy by converting broker scrip to vendor-specific scrip,
i.e. scrip that a particular merchant will accept
Customers can purchase items of very low value
Brokers required for two reasons:
Small payments require aggregation to insure profitability
System is easier to use -- customer need only deal with one broker for
all their scrip needs

2/16/00 EMTM 553 54
Electronic Wallets
+Stores credit card, electronic cash, owner
identification and address
Makes shopping easier and more efficient
Eliminates need to repeatedly enter identifying
information into forms to purchase
Works in many different stores to speed checkout
Amazon.com one of the first online merchants
to eliminate repeat form-filling for purchases
2/16/00 EMTM 553 55
An Electronic Checkout Counter Form
2/16/00 EMTM 553 56
Electronic Wallets
+ Agile Wallet
Developed by CyberCash
Allows customers to enter credit card and identifying information once,
stored on a central server
Information pops up in supported merchants payment pages, allowing
one-click payment
Does not support smart cards or CyberCash, but company expects to soon
+ eWallet
Developed by Launchpad Technologies
Free wallet software that stores credit card and personal information on
users computer, not on a central server; info is dragged into payment
form from eWallet
Information is encrypted and password protected
Works with Netscape and Internet Explorer


2/16/00 EMTM 553 57
Electronic Wallets
+Microsoft Wallet
Comes pre-installed in Internet Explorer 4.0,
but not in Netscape
All information is encrypted and password
protected
Microsoft Wallet Merchant directory shows
merchants setup to accept Microsoft Wallet
2/16/00 EMTM 553 58
Entering Information Into Microsoft Wallet
2/16/00 EMTM 553 59
W3C Proposed Standard for Electronic
Wallets
+ World Wide Web Consortium (W3C) is attempting to create an
extensible and interoperable method of embedding micropayment
information on a web page
Extensible systems allow improvement of the system without eliminating
previous work
+ Merchants must accept several payment options to insure the widest
possible Internet audience
Merchants must embed in their Web page payment information specific
to each payment system
This redundancy spurred W3C to develop common standards for Web
page markup for all payment systems
Must move quickly to prevent current methods from becoming
entrenched
2/16/00 EMTM 553 60
W3C Electronic Commerce Interest Group (ECIG) Draft
Standard Architecture
+Client (consumers web browser) initiates
micropayment activity
Client browser includes Per Fee Link Handler
module and one or more electronic wallets
New HTML tags will carry micropayment
information
2/16/00 EMTM 553 61
W3C Proposed Micropayment HTML Tags
2/16/00 EMTM 553 62
The ECML Standard
+Electronic Commerce Modeling Language
(ECML) proposed standards for electronic
wallets
Companies forming the consortium are
America Online, IBM, Microsoft, Visa, and
MasterCard
Ultimate goal is for all commerce sites to
accept ECML
Unclear how this standard will incorporate
privacy standards W3C set forth
Electronic Commerce Modeling Language
(ECML)
Wallet/Merchant Standards Initiative, July 1999
(Next four slides)
2/16/00 EMTM 553 63
Current state of the market - online data
exchanges
+ Providing payment and order information to merchants while shopping online
is typically a manual consumer process
+ 27% of online buyers abandon orders before check-out due to the hassle of
filling out forms
1
+ There is no standard way for identifying the specific data attributes that
consumers must provide to merchants during an online transaction
This significantly complicates/limits the ability for digital wallets to
automatically exchange information with a merchant web site
+ 76% of merchants surveyed indicated they are willing to participate in a
multi site wallet enterprise, indicating that multi site wallets offer reduced
acquisition costs that far outweigh the risk to merchants of losing an existing
customer
1

1 Jupiter Communications
2/16/00 EMTM 553 64
ECML - Wallet/Merchant Standard
+ Creating a standard approach for the exchange of information will enhance the
ability for digital wallets to be used at all merchant sites and therefore facilitate
the growth of e-commerce
+ ECML is a universal, open standard for digital wallets and online merchants
that facilitates the seamless exchange of payment and order information to
support online purchase transactions
Uniform field names only to start; will evolve over time
+ The ECML Alliance today:
America Online, American Express, Brodia (formerly Transactor Networks),
Compaq, CyberCash, Discover, Financial Services Technology Consortium
(FSTC), IBM, MasterCard, Microsoft, Novell, SETCo, Sun Microsystems,
Trintech, and Visa
+ ECML is designed to be security protocol independent, support global
implementations, and support any payment instrument
+ ECML does not change the look and feel of a merchants site
2/16/00 EMTM 553 65
Summary of current ECML specification
min min
field field
field names length field names length
Ecom_ShipTo_Postal_Name_Prefix 4 Ecom_ReceiptTo_Postal_Name_Prefix 4
Ecom_ShipTo_Postal_Name_First 15 Ecom_ReceiptTo_Postal_Name_First 15
Ecom_ShipTo_Postal_Name_Middle 15 Ecom_ReceiptTo_Postal_Name_Middle 15
Ecom_ShipTo_Postal_Name_Last 15 Ecom_ReceiptTo_Postal_Name_Last 15
Ecom_ShipTo_Postal_Name_Suffix 4 Ecom_ReceiptTo_Postal_Name_Suffix 4
Ecom_ShipTo_Postal_Street_Line1 20 Ecom_ReceiptTo_Postal_Street_Line1 20
Ecom_ShipTo_Postal_Street_Line2 20 Ecom_ReceiptTo_Postal_Street_Line2 20
Ecom_ShipTo_Postal_Street_Line3 20 Ecom_ReceiptTo_Postal_Street_Line3 20
Ecom_ShipTo_Postal_City 22 Ecom_ReceiptTo_Postal_City 22
Ecom_ShipTo_Postal_StateProv 2 Ecom_ReceiptTo_Postal_StateProv 2
Ecom_ShipTo_Postal_PostalCode 14 Ecom_ReceiptTo_Postal_PostalCode 14
Ecom_ShipTo_Postal_CountryCode 2 Ecom_ReceiptTo_Postal_CountryCode 2
Ecom_ShipTo_Telecom_Phone_Number 10 Ecom_ReceiptTo_Telecom_Phone_Number 10
Ecom_ShipTo_Online_Email 40 Ecom_ReceiptTo_Online_Email 40
Ecom_BillTo_Postal_Name_Prefix 4 Ecom_Payment_Card_Name 30
Ecom_BillTo_Postal_Name_First 15 Ecom_Payment_Card_Type 4
Ecom_BillTo_Postal_Name_Middle 15 Ecom_Payment_Card_Number 19
Ecom_BillTo_Postal_Name_Last 15 Ecom_Payment_Card_Verification 4
Ecom_BillTo_Postal_Name_Suffix 4 Ecom_Payment_Card_ExpDate_Day 2
Ecom_BillTo_Postal_Street_Line1 20 Ecom_Payment_Card_ExpDate_Month 2
Ecom_BillTo_Postal_Street_Line2 20 Ecom_Payment_Card_ExpDate_Year 4
Ecom_BillTo_Postal_Street_Line3 20 Ecom_Payment_Card_Protocol 20
Ecom_BillTo_Postal_City 22
Ecom_BillTo_Postal_StateProv 2 Ecom_ConsumerOrderID 20
Ecom_BillTo_Postal_PostalCode 14
Ecom_BillTo_Postal_CountryCode 2 Ecom_SchemaVersion 30
Ecom_BillTo_Telecom_Phone_Number 10
Ecom_BillTo_Online_Email 40 Ecom_TransactionComplete -
2/16/00 EMTM 553 66
ECML implementation and Alliance
participation
+ The ECML Alliance seeks widespread support for and adoption of the ECML standard
+ ECML is publicly available today and can be easily implemented by online merchants, e-
commerce technology vendors, and other interested parties
www.ecml.org - the official web site of ECML
+ ECML has been enthusiastically endorsed by several e-commerce industry segments,
including the following leading online merchants:
To support the current version of ECML, a merchant will need to make a one-
time change to incorporate the uniform field names into the check-out pages
of its web site, and make changes to CGI/ASP scripts
Organizations interested in participating in the ECML Alliance should contact
coordinator@ecml.org with their indication of interest
beyond.com
Dell Computer
fashionmall.com
healthshop.com
Nordstrom.com
Omaha Steaks
Reel.com
1-800-Batteries
2/16/00 EMTM 553 67
Smart Cards
+ Magnetic stripe
140 bytes, cost $0.20-0.75
+ Memory cards
1-4 KB memory, no processor, cost $1.00-2.50
+ Optical memory cards
4 megabytes read-only (CD-like), cost $7.00-12.00
+ Microprocessor cards
Embedded microprocessor
(OLD) 8-bit processor, 16 KB ROM, 512 bytes
RAM
Equivalent power to IBM XT PC, cost $7.00-15.00
32-bit processors now available
2/16/00 EMTM 553 68
Smart Cards
+Plastic card containing an embedded
microchip
+Available for over 10 years
+So far not successful in U.S., but popular in
Europe, Australia, and Japan
+Unsuccessful in U.S. partly because few
card readers available
+Smart cards gradually reappearing in U.S.;
success depends on:
Critical mass of smart cards that support
applications
Compatibility between smart cards, card-reader
devices, and applications
2/16/00 EMTM 553 69
Smart Card Applications
+ Ticketless travel
Seoul bus system: 4M cards, 1B transactions since 1996
Planned the SF Bay Area system
+ Authentication, ID
+ Medical records
+ Ecash
+ Store loyalty programs
+ Personal profiles
+ Government
Licenses
+ Mall parking
. . .
2/16/00 EMTM 553 70
Advantages and Disadvantages of
Smart Cards
+ Advantages:
1. Atomic, debt-free transactions
2. Feasible for very small transactions (information commerce)
3. (Potentially) anonymous
4. Security of physical storage
5. (Potentially) currency-neutral
+ Disadvantages:
1. Low maximum transaction limit (not suitable for B2B or most B2C)
2. High Infrastructure costs (not suitable for C2C)
3. Single physical point of failure (the card)
4. Not (yet) widely used

2/16/00 EMTM 553 71
Mondex Smart Card
+ Holds and dispenses electronic cash (Smart-card based, stored-value
card)
+ Developed by MasterCard International
+ Requires specific card reader, called Mondex terminal, for merchant or
customer to use card over Internet
+ Supports micropayments as small as 3c and works both online and off-
line at stores or over the telephone
+ Secret chip-to-chip transfer protocol
+ Value is not in strings alone; must be on Mondex card
+ Loaded through ATM
ATM does not know transfer protocol; connects
with secure device at bank
2/16/00 EMTM 553 72
Mondex Smart Card Processing
2/16/00 EMTM 553 73
Mondex transaction
+ Here's what happens "behind the scenes" during a Mondex transaction
between a consumer and merchant. Placing the card in a Mondex
terminal starts the transaction process:
1. Information from the customer's chip is validated by the merchant's chip.
Similarly, the merchant's card is validated by the customer's card.
2. The merchant's card requests payment and transmits a "digital signature"
with the request. Both cards check the authenticity of each other's
message. The customer's card checks the digital signature and, if satisfied,
sends acknowledgement, again with a digital signature.
3. Only after the purchase amount has been deducted from the customer's
card is the value added to the merchant's card. The digital signature from
this card is checked by the customer's card and if confirmed, the
transaction is complete.

2/16/00 EMTM 553 74
Mondex Smart Card
+ Disadvantages
Card carries real cash in electronic form, creating the possibility of theft
No deferred payment as with credit cards -cash is dispensed immediately
+ Security
Active and dormant security software
Security methods constantly changing
ITSEC E6 level (military)
VTP (Value Transfer Protocol)
Globally unique card numbers
Globally unique transaction numbers
Challenge-response user identification
Digital signatures
MULTOS operating system
firewalls on the chip


2/16/00 EMTM 553 75
Credit Cards
+ Credit card
Used for the majority of Internet purchases
Has a preset spending limit
Currently most convenient method
Most expensive e-payment mechanism
MasterCard: $0.29 + 2% of transaction value
Disadvantages
Does not work for small amount (too expensive)
Does not work for large amount (too expensive)
+ Charge card
No spending limit
Entire amount charged due at end of billing period

2/16/00 EMTM 553 76
Payment Acceptance and Processing
+Merchants must set up merchant accounts to
accept payment cards
+Law prohibits charging payment card until
merchandise is shipped
+Payment card transaction requires:
Merchant to authenticate payment card
Merchant must check with card issuer to ensure
funds are available and to put hold on funds
needed to make current charge
Settlement occurs in a few days when funds
travel through banking system into merchants
account
2/16/00 EMTM 553 77
Processing a Payment Card Order
2/16/00 EMTM 553 78
Open and Closed Loop Systems
+Closed loop systems
Banks and other financial institutions serve as
brokers between card users and merchants -- no
other institution is involved
American Express and Discover are examples
+Open loop systems
Transaction is processed by third party
Visa and MasterCard are examples

2/16/00 EMTM 553 79
Setting Up Merchant Account
+Merchant bank
Also called acquiring bank
Does business with merchants that want to
accept payment cards
Merchant receives account where they deposit
card sales totals
Value of sales slips is credited to merchants
account
2/16/00 EMTM 553 80
Processing Payment Cards Online
+Can be done automatically by software
packaged with electronic commerce
software
+Can contract with third party to handle
payment card processing
Can also pick, pack, and ship products to the
customer
Allows merchant to focus on web presence and
supply availability
2/16/00 EMTM 553 81
Credit Card Processing
SOURCE: PAYMENT
PROCESSING INC.
2/16/00 EMTM 553 82
Payment Processing Services
+Internetsecure
Provides secure credit card payment services
Supports payments with Visa and MasterCard
Provides risk management and fraud detection,
and ensures all proper security for credit card
transactions is maintained
Ensures all transactions are properly credited to
merchants account
2/16/00 EMTM 553 83
Payment Processing Services
+Tellan
Provides PCAuthorize for smaller commerce
sites and WebAuthorize for larger enterprise-
class merchant sites
Both systems capture credit card information
from the merchants form and connect directly
to the bank network using dial-up or private,
leased lines
Bank network receives credit information,
performs credit authorization, and deposits the
money in the merchants bank account
The merchants web site receives confirmation
or rejection of the transaction, which is
communicated to the customer
2/16/00 EMTM 553 84
Payment Processing Services
+IC Verify
Provides electronic transaction processing for
merchants for all major credit and debit cards
Also allows check guarantees and verification
transactions
A CyberCash company
+Authorize.Net
Online, real time service that links merchants
with issuing banks by simply inserting a small
block of HTML code into their transaction page
2/16/00 EMTM 553 85
Secure Electronic Transaction
(SET) Protocol
+ Jointly designed by MasterCard and Visa with backing of Microsoft,
Netscape, IBM, GTE, SAIC, and others
+ Designed to provide security for card payments as they travel on the
Internet
Contrasted with Secure Socket Layers (SSL) protocol, SET validates
consumers and merchants in addition to providing secure transmission
+ SET specification
Uses public key cryptography and digital certificates for validating both
consumers and merchants
Provides privacy, data integrity, user and merchant authentication, and
consumer nonrepudiation


2/16/00 EMTM 553 86
The SET protocol
The SET protocol coordinates the activities of the customer,
merchant, merchants bank, and card issuer. [Source: Stein]
2/16/00 EMTM 553 87
SET Payment Transactions
+SET-protected payments work like this:
Consumer makes purchase by sending
encrypted financial information along with
digital certificate
Merchants website transfers the information to
a payment card processing center while a
Certification Authority certifies digital
certificate belongs to sender
Payment card-processing center routes
transaction to credit card issuer for approval
Merchant receives approval and credit card is
charged
Merchant ships merchandise and adds
transaction amount for deposit into merchants
account
2/16/00 EMTM 553 88
SET uses a hierarchy of trust
All parties hold certificates signed directly or
indirectly by a certifying authority. [Source: Stein]
2/16/00 EMTM 553 89
SET Protocol
+ Extremely secure
Fraud reduced since all parties are authenticated
Requires all parties to have certificates
+ So far has received lukewarm reception
+ 80 percent of SET activities are in Europe and Asian countries
+ Problems with SET
Not easy to implement
Not as inexpensive as expected
Expensive to integrated with legacy applications
Not tried and tested, and often not needed
Scalability is still in question

Electronic payments: Issues
+Secure transfer across internet
+High reliability: no single failure point
+Atomic transactions
+Anonymity of buyer
+Economic and computational efficiency:
allow micropayments
+Flexiblility: across different methods
+Scalability in number of servers and users
E-Payments: Secure transfer
+SSL: Secure socket layer
below application layer
+S-HTTP: Secure HTTP:
On top of http
SSL: Secure Socket Layer
+ Application protocol independent
+ Provides connection security as:
Connection is private: Encryption is used after an initial handshake
to define secret (symmetric) key
Peer's identity can be authenticated using public (asymmetric) key
Connection is reliable: Message transport includes a message
integrity check (hash)
+ SSL Handshake protocol:
Allows server and client to authenticate each other and negotiate a
encryption key
SSL Handshake Protocol
+ 1. Client "Hello": challenge data, cipher specs
+ 2. Server "Hello": connection ID, public key certificate, cipher specs
+ 3. Client "session-key": encrypted with server's public key
+ 4. Client "finish": connection ID signed with client's private key
+ 5. Server "verify": client's challenge data signed with server's private key
+ 6. Server "finish": session ID signed with server's private key
+ Session IDs and encryption options cached to avoid
renegotiation for reconnection
S-HTTP: Secure HTTP
+Application level security (HTTP specific)
+"Content-Privacy-Domain" header:
Allows use of digital signatures &/ encryption
Various encryption options
+Server-Browser negotiate
Property: cryptographic scheme to be used
Value: specific algorithm to be used
Direction: One way/Two way security
Secure end to end protocols
E-Payments: Atomicity
+Money atomicity: no creation/destruction of
money when transferred
+Goods atomicity: no payment w/o goods and
viceversa.
Eg: pay on delivery of parcel
+Certified delivery: the goods delivered is
what was promised:
Open the parcel in front of a trusted 3rd party
Anonymity of purchaser
Payment system types
+Credit card-based methods
Credit card over SSL - First Virtual -SET
+Electronic Cheques
- NetCheque
+Anonymous payments
- Digicash - CAFE
+Micropayments
+SmartCards
Encrypted credit card payment
+Set secure communication channel between
buyer and seller
+Send credit card number to merchant
encrypted using merchants public key
+Problems: merchant fraud, no customer
signature
+Ensures money but no goods atomicity
+Not suitable for microtransactions
First virtual
+Customer assigned virtual PIN by phone
+Customer uses PIN to make purchases
+Merchant contacts First virtual
+First virtual send email to customer
+If customer confirms, payment made to
merchant
+Not goods atomic since customer can refuse to
pay
+Not suitable for small transactions
+Flood customers mailbox, delay merchant
Cybercash
+Customer opens account with cybercash,
gives credit card number and gets a PIN
+Special software on customer side sends
PIN, signature, transaction amount to
merchant
+Merchant forwards to cybercash server that
completes credit card transaction
+Pros: credit card # not shown to server, fast
+Cons: not for microtransactions
SET:Secure Electronic Transactions
+Merge of STT, SEPP, iKP
+Secure credit card based protocol
+Common structure:
Customer digitally signs a purchase along with
price and encrypts in banks public key
Merchant submits a sales request with price to
bank.
Bank compares purchase and sales request. If
price match, bank authorizes sales
+Avoids merchant fraud, ensures money but
no goods atomicity
Electronic Cheques
+Leverages the check payments system, a
core competency of the banking industry.
+Fits within current business practices
+Works like a paper check does but in pure
electronic form, with fewer manual steps.
+Can be used by all bank customers who have
checking accounts
+Different from Electronic fund transfers
How does echeck work?
+Exactly same way as paper
+Check writer "writes" the echeck using one
of many types of electronic devices
+Gives" the echeck to the payee
electronically.
+Payee "deposits" echeck, receives credit,
+Payee's bank "clears" the echeck to the
paying bank.
+Paying bank validates the echeck and
"charges" the check writer's account for the
check.
Anonymous payments
1. Withdraw money:
cyrpographically encoded
tokens
2. Transform so merchant can check
validity but identity hidden
3. Send token after adding
merchants identity
4. Check validity and send goods
5. Deposit token at bank.
If double spent reveal
identity and notify police
customer
merchant
Problems with the protocol
+Not money atomic: if crash after 3, money
lost
if money actually sent to merchant: returning to
bank will alert police
if money not sent: not sending will lead to loss
+High cost of cryptographic transformations:
not suitable for micropayments
+Examples: Digicash
Micropayments on hyperlinks
+HTML extended to have pricing details with
each link: displayed when user around the link
+On clicking, browser talks to E-Wallet that
initiates payment to webserver of the source
site
+Payment for content providers
+Attempt to reduce overhead per transaction
Micropayments: NetBill
+ Customer & merchant have account with NetBill server
+ Protocol:
Customer request quote from merchant, gets quote and accepts
Merchant sends goods encrypted by key K
Customer prepares & signs Electronic Purchase Order having
<price, crypto-checksum of goods>
Merchant countersigns EPO, signs K and sends both to NetBill
server
NetBill verifies signatures and transfers funds, stores K and crypto-
checksum and
NetBill sends receipt to merchant and K to customer
Recent micropayment systems
Company Payment
system
Unique
code
Compaq Millicent mcent
IBM IBM payment
system
mpay
France
Telecom
Micrommerce microm
Smartcards
+ 8-bit micro, < 5MHz, < 2k RAM, 20k ROM
+ Download electronic money on a card: wallet on a card
+ Efficient, secure, paperless, intuitive and speedy
+ Real and virtual stores accept them
+ Less susceptible to net attacks since disconnected
+ Has other uses spanning many industries, from banking to
health care
Mondex
+Smart card based sales and card to card
transfers
+Money is secured through a password and
transactions are logged on the card
+Other operation and features similar to
traditional debit cards
+Card signs transaction: so no anonymity
+Need card reader everywhere
+Available only in prototypes