Re: IP: "CyberCash can't oust credit cards"

[Dave Birch <daveb-lists@mail.hyperion.co.uk>]

Ryan Lackey said

>I think resistance to new payment schemes on the part of a merchant is in 
>cost and effort to set up.  Having a free apache commerce plugin which 
>handles
>a variety of payment systems...

What's wrong with this model is that it imports historical physical 
models that are irrelevant on the Net. Why does the merchant take 
payments at all?

Imagine this scenario: you go into the Good Guys and buy a Walkman. The 
clerk gives you a ticket. You go round to your branch of Wells Fargo and 
get a cashiers cheque made out to the merchant, walk round to the 
merchant's branch of BankAmerica -- or BankBank, or whatever it's called 
now :) -- and deposit the cheque in the merchants account. BankBank gives 
you a receipt which you take back to the Good Guys and pick up your 
Walkman. Now, apart from all of the walking around, this is not a bad 
system. The Good Guys don't need cash registers, links to First Data etc 
etc. The Good Guys don't need to put up stickers saying "we take Visa", 
because the bank takes everything. The Good Guys don't care how you paid.

The bank is much better placed than the merchant to handle the risks 
associated with payments and therefore the information asymmetries 
associated with the payment are significantly reduced (there's a good 
article about this in the Federal Reserve Bank of Atlanta's Economic 
Review, 1Q98). On the Net, there's no walking around.

In the physical world, it clearly makes no sense for every bank to build 
a network out to every merchant: hence it makes sense to have physical 
payment instruments (e.g. notes, cheques) and credit/charge cards. On the 
Net, though, every participant is connected. When you buy a book from 
Amazon, what is the point of sending your credit card details to Amazon 
just so that they can send the details on to an acquiring network, 
third-party processor etc. Surely it makes more sense for merchants to 
have deals with payment agents (this is the model in OTP, Smart Access 
etc). When you press the button marked "Pay" on your browser, wouldn't it 
be more natural for a message to go to your bank than to the merchant?

Thus, I get a "ticket" from Amazon saying "you owe $20 for this book". I 
pass the ticket to a payment agent (which may be a bank) and pay them 
(the negotiation being between my wallet and the agent"). The agent sends 
me a receipt to keep: I send the receipt to Amazon and they send me a 
book. Alternatively, perhaps the receipt let's me play Doom for a month 
or get ten upgrade to an item of software or whatever.

All Amazon care is that the money has been paid: what do they care 
whether I used DigiCash or Mondex, Visa or MasterCard? You might argue 
that the merchant would discount for cleared funds (pay by Mondex and get 
2% off) but I think that its frankly too much bother for them to work out 
N different prices by M different payment methods. I would imagine that 
just a merchants run loyalty schemes ("double points if you buy 
cornflakes") then so would payment agents ("double points for DigiCash") 
but each could operate their business independently.

I would argue that the idea that merchants take payments is outdated. 
Since merchants don't care about cypherpunk favourites such as bearer 
instruments and anonymity, they'll be perfectly happy to have an 
acquiring account with BigBank and get a statement at the end of the 
month that details the payments taken and says "Money collected $1000, 
our fee $50, deposited to your account $950". Now, the merchant hasn't 
had to buy a commerce server, negiotiate 10 different acquiring 
agreements, implement SET or do anything else. Hey, so it's 5%: so what?

Regards,
Dave Birch.

=== mailto:daveb@hyperion.co.uk ===== http://www.hyperion.co.uk/ ===