Tangled in the Threads
Jon Udell, March 22, 2000E-payment alternatives
In my Feb 21 column I talked about the woeful state of e-commerce infrastructure. 128-bit SSL is well and good, but:
- The site to which you send your credit card number doesn't know it came from you. There's no client authentication because, even though the technology has been available since 1996, nobody wants to slow down the e-commerce juggernaut by forcing people to use personal digital IDs.
- The site to which you send your credit card is, as all sites are, hackable. There have been notable thefts of credit-card numbers in recent months.
In response to that column, I received an essay from a reader, Andrew Todd, who said:
The central problem of credit card transactions over the telephone or internet is that they have the effect of treating the merchant as if he were the customer's bursar. There is an inherent conflict of interest between the roles of merchant and bursar. No amount of technical manipulation can overcome this conflict of interest. Only a different set of payment arrangements can address the problem.
Suppose the merchant gives or sends the customer an unvalidated payment order, which the customer signs and turns in to his own bank. The bank then pays the merchant. One advantage of this system is that it radically restricts the merchant's "need-to-know." When the stakes are big enough, we do something approximately similar with cashiers' checks.
Andrew went on to describe a scheme for a standard "shopping-cart URL" which would store purchase information client-side on the user's PC, and an associated "bursar client program" which would read the browser-generated information, contact the user's bank, and authorize payment to the vendor. He added:
From this standpoint, the merchant would no longer have "need-to-know" concerning the customer's identity. Rather, he would have an order on the Last National Bank, authorizing him to ship specified merchandise to a specified address in exchange for a specified price. What addresses the Last National Bank will authorize shipment to is purely a matter for the Last National Bank and its depositors. During the ordering process, the shopping cart would be maintained by the user rather than the merchant.
Franck Arnaud agreed in principle but thought the scheme could be simpler.
After you've made an order on a vendor site, you need:
- A reference number/identifier for your order (opaque to the bank).
- The bank account number of the vendor
- The amount
Then you go to your bank site, enter this information, and do a customer-originated electronic transfers to the vendor's bank account. This is good as it moves all the security issues to the relationship between the customer and their bank and less security is needed on the vendors' side.
Martijn Pieters reported that in the Netherlands, there is growing use of a system called I-Pay, based on the SET (Secure Electronic Transaction) protocol.
SET basically implements the principles of the essay, it includes the bank in the purchasing triangle, effectively removing the need for credit card information traveling to the merchant. The merchant gets his payment, the customer gets the goods, the bank gets the transactions.
It is an official SET implementation, and in the Netherlands you can use both your credit-card and the (in Europe, immensely popular) debit card. International payments only support the credit card right now, and of course only on sites that support SET payments, which are scarce outside the Netherlands.
More information on the scheme: http://www.i-pay.com/merchant/
Martijn wasn't kidding about the global maldistribution of SET support. MasterCard's page of SET merchants features long lists of SET-capable merchants in Finland, Norway, Switzerland, Denmark, and the Netherlands, a few in Germany, Canada, and the Czech Republic, and just one in the US.
Will the US market reverse its attitude toward SET? I don't know, but in the meantime, it'd be nice if the non-SET-aligned world could find a way to include the bank more directly in the online purchasing triangle -- without requiring radical infrastructure changes.
A few days later, Franck Arnaud reported on a fascinating new system:
http://www.orbiscom.com/ seems to have a pretty clever, if simple, solution to the secure e-payment problem. And I don't see that you need to use their technology to implement something similar.
The trick is just to issue one-time credit card numbers:
The buyer goes to the bank's site and asks the bank for a one-time number, with a limit on the amount it can be used for. The buyer uses that number instead of a real permanent credit-card number. It appears to the merchant as an ordinary card number, so it works everywhere already! After it has been used, it is useless. And before it's used, it has a limit on it so there's some protection against theft and unscrupulous merchants. Sould such a system become popular, is there a risk to run out of credit card numbers pretty quick? Hmm. 10^16 possible numbers, 10^15 valid ones, 10^9 people making 10^2 transactions/year, it may fit...
There's no reason it shouldn't work with telephone and mail order too, where security can be an issue if not as visible as the online one.
To recap:
- A card issuer maintains a batch of one-time credit card numbers.
- Uses it to make a purchase
- After which, the number expires.
Mark Wilcox had some questions:
Q: How do you get a number?
A: You fetch them, one at a time, on demand, from a cooperating card issuer.
Q: What do I do if I lose a number, or it's stolen?
A: Fetch a new one. The lost number was limited to the amount of your transaction. If the number was stolen, or the amount was nontrivial, cancel the number.
Q: How can I associate a set of numbers with a particular bank?
A: A cooperating, card-issuing bank handles this. It manages the one-time numbers that it dispenses to you as proxies for your real account with them.
Q: Can I associate a set of numbers across a wide spectrum of personal payment options (e.g. checking account, savings, credit-card, etc)?
A: To the bank, all of the one-time numbers resolve to a single real account number. You'll have whatever options are available for that account.
Q: How does the company verify that the number is valid and actually belongs to me before the order is complete?
A: Validity is easily determined by checksumming. Client authentication is another matter. I think ecommerce should move toward stronger authentication, and SET does that, but most of the world has failed to adopt SET, and almost nobody uses existing client-certificate technology. This scheme is no better, and no worse, than the current standard SSL-based e-payment scheme, with regard to authentication. But it appears to be vastly superior in that it relieves the merchant of the need to securely receive, process, and store real credit-card numbers.
I think this is a nifty idea. You'd still want to encrypt the one-time number over the wire. But customers wouldn't need to worry about their card numbers being left around on sites that can get hacked -- once used, the numbers are worthless. Likewise merchants don't need to lie awake at nights worrying that if their sites are hacked, valuable credit card numbers will be stolen.
This scheme has the interesting side-effect of serializing every transaction -- very useful for tracking purposes. And as Franck points out, it's completely general-purpose. It could work as well with phone or snail-mail orders as with Internet orders. Finally, since the arrangement is only between the shopper and the card issuer, there is no change required of the merchant, as the numbers received in this scheme work like any others w/respect to authorization and payment.
As Frank points out:
This scheme requires virtually zero new technology, and uses existing infrastructure. It's just a clever use of the existing payment card system, playing with the timing of existing operations.
The whole idea is breathtakingly simple. That makes me think it just might work.
Jon Udell (http://udell.roninhouse.com/) was BYTE Magazine's executive editor for new media, the architect of the original www.byte.com, and author of BYTE's Web Project column. He's now an independent Web/Internet consultant, and is the author of Practical Internet Groupware, from O'Reilly and Associates. His recent BYTE.com columns are archived at http://www.byte.com/index/threads
This work is licensed under a
Creative Commons License.