I had this idea the other day and in doing research, surprisingly, I've yet to find someone taking this approach for b2c ecommerce. Digitally signing invoices for b2b ecommerce seems to be a slightly more common practice, at least in Europe.<p>Here's the idea: An identity service that sits between merchants and credit card processors that signs transactions. This would seem to be an effective way to reduce credit card fraud.<p>Every customer would have an identity/username/email with the service and a corresponding private/public key stored on our servers. The merchant asks us to sign a transaction, (which would be some nonce plus a username or something, it wouldn't hold credit card numbers), using the users private key. The payment processor makes an api call to our service to verify the customer is who they say they are and then verifies it has seen the customer use this credit card before. If not, it looks like potential fraud.<p>Verified by Visa and Secure Electronic Transaction (SET) seem to be similar solutions but with obvious drawbacks.<p>There are some obvious problems, but nothing seems insurmountable. So I'm surprised to find nobody is really working on something like this.<p>Here are some problems I see:
1. Adding an extra hurdle to the checkout process might be completely unpalatable to most merchants<p>2. How do you know you can trust someone the first time they sign a transaction?<p>3. Storing private keys in the cloud -- scary.<p>4. It's extra work for payment processors to implement this feature. Why would they?<p>I'm very interested in any feedback from someone who works in this space. I suspect my inexperience with payments is why I'm thinking this would be a good idea.
The whole credit card pipeline has been optimized to the point that no additional authentication is beneficial. If you want to talk about replacing cards, that's a different story.
> 3. Storing private keys in the cloud -- scary.<p>Why do you need to do that? Isn't it enough to sign a transaction that includes the customer's (public) id, using your own private key (which does not need to be different for different customers)? Either way, your service is "giving its word" that this transaction was authorized by the person with the given id; but this way there is one less security risk.<p>Disclaimer: I do <i>not</i> work in this space.