Ask HN: Why doesn't this exist? Signing ecommerce transactions.
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.
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.
Verified by Visa and Secure Electronic Transaction (SET) seem to be similar solutions but with obvious drawbacks.
There are some obvious problems, but nothing seems insurmountable. So I'm surprised to find nobody is really working on something like this.
Here are some problems I see: 1. Adding an extra hurdle to the checkout process might be completely unpalatable to most merchants
2. How do you know you can trust someone the first time they sign a transaction?
3. Storing private keys in the cloud -- scary.
4. It's extra work for payment processors to implement this feature. Why would they?
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.
4 comments
[ 5.5 ms ] story [ 22.1 ms ] threadWhy 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.
Disclaimer: I do not work in this space.