Hacker News Reader

Comment by xhrpost | Hacker News Reader

Off topic but still relevant, but doesn't it seem a bit primitive that companies have to store you CC# for recurring payments? The one number that uniquely identifies your account and everyone you want to re-use it has to keep a copy. Couldn't the credit card company issue some unique ID to each vendor for recurrent payments? Ex. the vendor issues your CC# to the CC Company for charge and recurring process. The CC Co. responds by replying back with authorization and an ID unique to that vendor that says "Use this number for charging this customer again, but it will only work coming from you, so if you lose it, it can't be used elsewhere". The vendor then discards your real CC number.

View on HN

> Off topic but still relevant, but doesn't it seem a bit primitive that companies have to store you CC# for recurring payments?

You really really don't have to. Any payment processor that isn't horribly incompetent does the unique token authorization scheme.

Storing CC #s for recurring payments is solely the domain of incompetents who have no business accepting payments from anyone.

What if you want to change processors? If you weren't storing the CC details, wouldn't you have to have customers enter all their details again? I imagine this could cause a drop in revenues due to people either forgetting, procrastinating, or just not bothering.

It's never cool to be actually- or quasi-locked into a vendor.

Most decent processors have processes in place for the transfer of CC numbers. I was involved with this process at a decent-sized magazine, it involved armed security, an encrypted hard drive in a locked container and millions of dollars of insurance. It's not an easy process, but is possible.

Sounds ... expensive.

Some will let you export the data, but it's a hassle. They burn it to a DVD and ship it to you and you have to sign tons of stuff freeing them of any liability.

Otherwise you just ask customers to re-authenticate. Often you have a few months headway for a switch like that.

Said processors allow you to export credit card data to another processor without having to store it yourself.

It seems there are a LOT of incompetents then. Are the payment processors you're talking about something the vendor interfaces with in the background and not a third party that is directly utilized by the customer (eg. Stripe, Paypal)?

This is basically what Stripe does. The "CC Company" basically doesn't offer more than a simple yes/no API -- "approved w/ #" or "declined". It'd be great if they could do more, but that's where the opportunity for folks like Stripe lies.

I guess it just surprises me that the CC companies don't do it themselves. Is the additional overhead of such a feature so high such as to warrant the choice between no payment processor (x% fee per transaction) vs. third party middle guy (x% + a bit more)? Not to mention the money the CC companies would save by not having so many fraudulent transactions (assuming they come out of their pocket, I honestly don't know).

Well, you can get AVS checks back too. But in general the entire system is so far behind the times. It really needs to be overhauled with security as the focal point.

It's amazing that it doesn't work that way. You could argue that it's because of the amount of infrastructure already in place, but why couldn't a new system be gradually and optionally rolled out?

Stripe (and probably others) has functionality like this where the seller's server never sees the CC number, and developers can store a unique token to re-charge the customer at a later date.

Depends on what part of the chain you are. Most gateways/processors offer some sort of token that the end user uses.

You then put your trust in the gateway/processor to store the credit card. Which I assume is most likely behind the best possible security stuff money can afford. Since that's their entire business. One screw up and their gone.

The majority of CC names have "Virtual CC numbers" which is precisely this - You generate a new number, which links to your account, but can only be used for the merchant you specify.

That's what Stripe do.

But isn't that just between Stripe and the company requesting payment?

e.g: Acme, Inc. sends Stripe your CC#, Stripe sends them some unique token, and they store that; correct?

So Stripe still has your CC#, and is at risk.

So this is really just risk mitigation; what I think TP is suggesting we need is unique authorizations at the banking level.

Something on the order of virtual credit cards, or temporary tokens, which are ultimately verified by your bank [or in other words: the lender(s) making anti-fraud guarantees, etc.]

(e.g: this token is authorized for 24 hours up to this limit; this token is authorized indefinitely up to $xx/mo.; this token is authorized for 1 year; etc.)

No. Customer sends Stripe their CC number, via AJAX in the browser. Acme, Inc. never has it even transiently. Stripe return a token to the browser, which is sent in a POST to Acme, Inc., then they verify it server side with a private API key.

Edit: yes Stripe has your number, but since their sole business is about securing that information, they probably do a better job of it than your typical online merchant.

Reply on news.ycombinator.com