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/ ===