

Ask HN: Why doesn't this exist? Signing ecommerce transactions. - SMrF

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.
======
wmf
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.

~~~
SMrF
But what if additional authentication reduced fraud? Wouldn't that be
beneficial? Are you saying it's impossible to reduce fraud rates any lower
than where they are now?

~~~
wmf
The cost of the additional authentication is higher than the savings due to
reduced fraud.

------
ggchappell
> 3\. Storing private keys in the cloud -- scary.

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.

Disclaimer: I do _not_ work in this space.

