Question for those that store Credit Card information

[Brad Callen]

Ideally I'd like to create our own shopping cart system for our company, but storing credit card information on our servers scares me, so we've never stored CC info ourselves.

Are there third party services whose sole purpose is to store the CC info and they provide an API for developers to create their own shopping carts around it?

Does that make sense?

Brad

[Norma Holt]

it makes a lot of sense. Why not google it and see what comes up. I recently started working with e-junkie. That might help you.

[SteveJohnson]

You should not have a need to store CC #s at all. Most payment gateways, Authorize.net for instance, recommend that you do NOT store CC numbers. The transaction is kind of a use it and lose it type thing.

[trafficwave]

Authorize.net can store the information for automated recurring billing (ARB).

Be very careful. Storing customer CC info has some pretty stringent requirements from the card companies themselves. Be sure you check and follow the requirements.

[Gary_The_Ace]

Hey Brad,

Just Google Authorize.net CIM ... you'll get it.

Gary Ambrose

[David Neale]

However some very big clients of mine insist on storing credit card numbers for rebilling purposes. We advise them not to, even though we provide very high level security, but some still want to for a variety of reasons.

Brad if you need details please let me know and I will either email you directly or explain by phone.

Credit cards should never be stored on a server that is also a webserver regardless of encryption strength being used.

[AverageGuy]

Brad,


You should NOT store clients credit card information DIRECTLY on server/database. What you can do is:
1) get clients credit card information (or private information);
2) encrypt it (use some keys);
3) store the encrpted code in database;

when you need them, just unencrypt it.



david

[David Neale]

David this can have problems depending on how you plan on using it. Where is the key stored? What do you mean by "when you need them"? Do you mean when a program needs them to rebill for example?

Depending on your answers this could be very dangerous.

If the key is stored on the same box as the encrypted card numbers you have a big security problem.

Originally Posted by AverageGuy

Brad,


You should NOT store clients credit card information DIRECTLY on server/database. What you can do is:
1) get clients credit card information (or private information);
2) encrypt it (use some keys);
3) store the encrpted code in database;

when you need them, just unencrypt it.



david

[entrepenerd]

Originally Posted by AverageGuy

Brad,


You should NOT store clients credit card information DIRECTLY on server/database. What you can do is:
1) get clients credit card information (or private information);
2) encrypt it (use some keys);
3) store the encrpted code in database;

when you need them, just unencrypt it.



david

I've had a couple of clients that also required us to store CC numbers and we've taken this approach. But, as David Neale mentioned, there are still security issues. If someone gets access to both your database and your encryption key, then you're hosed.



Brad,

I'd recommend, like the others, that you look at some of the top third party processors like Authorize.net or PayPal. I've worked on several occasions with PayPal Web Payments Pro (also formerly known as Verisign Payflow Pro).

It's a pretty slick system where you don't have to store the CC numbers directly. You just pass them along in a backend call to PayPal and they return you a response that says whether the card was accepted or not.

I believe, at least with PayPal, that you can even setup recurring billing directly through their API and still not have to store CC numbers.

One of the nice things about the PayPal system is that they have some pretty robust fraud filtering that you can control (to some degree and with potentially higher cost depending on features). That helps to stop some of the bad transactions that might normally slip through a home grown system.

I've not used any other 3rd party processors, but I'd certainly check into the others if I were doing this for myself. But, so far I've had good luck with PayPal. The integration is pretty simple and they even provide SDKs for several different languages to get you started.

Hope that helps.

[seasoned]

https://www.pcisecuritystandards.org.../pci_dss.shtml

And the date is misleading. It has ACTUALLY been around LONGER. Look at this:

All About the PCI Data Security Standard - CSO Online - Security and Risk
Cardholder Information Security Program | Merchants | Visa USA

Don't worry though. According to novells site, the only direct sanctions are:

Fines of $500,000 per data security incident
Fines of $50,000 per day for non-compliance with published standards
Liability for all fraud losses incurred from compromised account numbers
Liability for the cost of re-issuing cards associated with the compromise
Suspension of merchant accounts

Norma,

How could e-junkie "help"?

Steve

[Brad Callen]

Thanks guys, yeah, I know authorize.net will allow me to integrate my custom shopping cart with their system. We do this with blinkweb.com. The problem is about 20% of cards have problems on the rebill each month due to cards expiring, addresses changing, or people just not having enough cash in their account at the time of rebill. I can't automatically retry the rebill x times because authorize doesn't store CC info either. That's the problem. Plus, I can't do a one click upsell 100% automated without storing CC info.

What do places like 1shoppingcart.com use?

Brad

[Simplweb]

DO NOT STORE CC INFORMATION, ENCRYPTED OR OTHERWISE!!!!!!

Seriously, really don't.

Did I mention don't store CC info?

There are 3 issues:

1. You need to be PCI compliant. Its a huge and expensive headache.
2. You are liable for losses. Companies routinely get fined millions of dollars for data loss. Just one incident and you company goes phut
3. "Suspension of merchant accounts" (as steve mentioned). This sounds not too bad until you realize it means going on a Visa and Mastercard blacklist. You and any business you start will have a really really hard time to CC processing.

We just started a subscription service, we are using Authorize.net's ARB system. It passes the CC info to auth.net and THEy have to look after it, and they do all the rebilling. A clever enough gateway can deal with the expiration etc issues.

Doesn't the customer need a paypal account to use paypal recurring billing?

[matrixman]

I'm in the credit card merchant account business, and I couldn't agree more with the previous poster about not storing cc numbers. I also would highly recommend using the Authorize.net CIM - Customer Information Manager. We have some of our customers using it and it works great. This allows Authorize.net to store the cc card and you can access it, charge the card, update it, etc. That way you get all the same benefits of storing the card yourself, however Authorize.net is storing the card and taking the liability and pci responsibility. Note that CIM is an add on to an existing Authorize.net account. If you find that CIM doesn't work for your situation, then you can store the cc number, but you MUST follow pci guidelines in doing so. To see those guidelines, you would have to pass the PCI Self Assessment Questionnaire (SAQ) part D. However, if Authorize.net is storing the cards and you are only using Authorize.net and not keeping paper copies or receipts, then you only need to pass part A. The SAQ parts A and D are available on the pcisecuritystandards.org website.

[johntanyishin]

Never store credit card information! I worked in a bank, boy, saw lots of scary cases.

JTYS

[KentM]

Originally Posted by Brad Callen

What do places like 1shoppingcart.com use?

Brad

We are both PCI and CISP compliant, but for obvious reasons I will not go into what we use for securing credit card information.

[entrepenerd]

Originally Posted by Brad Callen

Thanks guys, yeah, I know authorize.net will allow me to integrate my custom shopping cart with their system. We do this with blinkweb.com. The problem is about 20% of cards have problems on the rebill each month due to cards expiring, addresses changing, or people just not having enough cash in their account at the time of rebill. I can't automatically retry the rebill x times because authorize doesn't store CC info either. That's the problem. Plus, I can't do a one click upsell 100% automated without storing CC info.

What do places like 1shoppingcart.com use?

Brad

I've not integrated with Authorize.net before so forgive me for any stupidity here, but I don't understand how they can be doing rebill at all if they aren't storing CC info. They have to be storing the info to be able to resubmit the card for re-authorization each month. Now, I believe what you're running into is that Authorize is not allowing you access to the CC info, or to try the rebill x number of times. But, I don't believe it's because they don't store the CC info. If they are compliant with all the mandates, my guess is that they are not storing the CC info in plain text which their tech support may "understand" as "we don't store CC info". They are most likely using a combination of custom encryption features and high-tech networking security to store and retrieve the data for these cases of rebills.

As for the automated one-click upsells, you can definitely accomplish what you want without storing the CC info permanently. You could use a combination of encryption/decryption and temporarily storing the CC info in session variables. Now, this won't fix any issues with your rebill problems, but it will get you to where you can do one-click upsells.

PM me if you'd like to talk through the last part a bit more. I'd be happy to share some more details.

[Andy Fletcher]

Unless you know exactly what you're doing, I'd advise against storing credit card info. I looked into it for the company I work for. The requirements are super strict and your chances of violating several laws (and paying heavy fines) are high.

Your chances of doing it more cost effectively for yourself than for the fees that 3rd party providers charge are pretty slim and you don't run the risk of violating a load of laws.

I try not to be a doom sayer on too many topics but credit card info is one of them.

[Simplweb]

Originally Posted by entrepenerd

I've not integrated with Authorize.net before so forgive me for any stupidity here, but I don't understand how they can be doing rebill at all if they aren't storing CC info. They have to be storing the info to be able to resubmit the card for re-authorization each month.

If you use auth.net ARB ($10 extra a month, you can do recurring billing because THEY store the CC. THEY have to be PCI compliant and THEY assume the risk.

[KentM]

Originally Posted by entrepenerd

I've not integrated with Authorize.net before so forgive me for any stupidity here, but I don't understand how they can be doing rebill at all if they aren't storing CC info. They have to be storing the info to be able to resubmit the card for re-authorization each month. Now, I believe what you're running into is that Authorize is not allowing you access to the CC info, or to try the rebill x number of times. But, I don't believe it's because they don't store the CC info. If they are compliant with all the mandates, my guess is that they are not storing the CC info in plain text which their tech support may "understand" as "we don't store CC info". They are most likely using a combination of custom encryption features and high-tech networking security to store and retrieve the data for these cases of rebills.

We encrypt the credit card information for doing the recurring billing. The only information that in not kept is the CVV2 number which is against the law to store outside of the card owner and the credit card company. When it is time to bill for the recurring billing the credit card number is decrypted and sent to the payment gateway and then encrypted once again. The credit card information is never kept in plain text.

I would highly recommend not storing and dealing with credit card numbers on your own, use a company that is certified to take care of that, whether it is us or another company.

This is the reason why authorize.net, ibill.com, 2checkout.com and such exist.. Let them deal with all the legal crap that comes along with CC's..

Edit to Add: I do suggest that you still have SSL when dealing with these customers if they are entering personal information on your server and then transfered to someplace like authorize.net. Keeping them under SSL makes them feel more safe vs going from http -to- https and then back to http after purchase.

Keep it clean 256 bit encryption all the way from your site, through purchase and back to your site.

James

[seasoned]

Originally Posted by Brad Callen

Thanks guys, yeah, I know authorize.net will allow me to integrate my custom shopping cart with their system. We do this with blinkweb.com. The problem is about 20% of cards have problems on the rebill each month due to cards expiring, addresses changing, or people just not having enough cash in their account at the time of rebill. I can't automatically retry the rebill x times because authorize doesn't store CC info either. That's the problem. Plus, I can't do a one click upsell 100% automated without storing CC info.

What do places like 1shoppingcart.com use?

Brad

BTW the people at the USPTO are MORONS, and one thing they did to PROVE their stupidity was allow Amazon to PATENT "one click ordering". Amazon is ALSO stupid, but they have the tenacity and money, and HAVE fought it in court. This emans they might sue YOU like they sued barnes and noble! B&N decided to GIVE UP!

ALSO, you BETTER do "one click ordering" RIGHT! Amazon originally made so many mistakes that it was PITIFUL! Apparently, they have learned a bit since. Authorize.net is NOT to help you do this, contrary to what "therichjerksnet" says. When they started, they did what they went in business for, provided internet CC processing. They merely NOW realize it is needed and CAN provide it. They charge extra for that. As for 1shoppingcart, if they even do it, it DOES NOT MATTER what they use! Whatever they would directly use would be CUSTOM! HECK, they rebrand their SERVICE! That means that it isn't a common package, and they won't let you even SEE the code.

BTW Failure to use SSL when collecting personal data and CC info IS a PCI violation, technically ILLEGAL, STUPID, SCARY, opens you up to liability, and is a public relations NIGHTMARE! I hope you realize that. People that use Paypal and/or clickbank may not know/care about this, but that is ok because both clickbank AND paypal DO!!!!!!!

STEVE

[entrepenerd]

Originally Posted by KentM

We encrypt the credit card information for doing the recurring billing. The only information that in not kept is the CVV2 number which is against the law to store outside of the card owner and the credit card company. When it is time to bill for the recurring billing the credit card number is decrypted and sent to the payment gateway and then encrypted once again. The credit card information is never kept in plain text.

I would highly recommend not storing and dealing with credit card numbers on your own, use a company that is certified to take care of that, whether it is us or another company.

Thanks for the extra clarification Kent.

[Gary_The_Ace]

Originally Posted by Brad Callen

Thanks guys, yeah, I know authorize.net will allow me to integrate my custom shopping cart with their system. We do this with blinkweb.com. The problem is about 20% of cards have problems on the rebill each month due to cards expiring, addresses changing, or people just not having enough cash in their account at the time of rebill. I can't automatically retry the rebill x times because authorize doesn't store CC info either. That's the problem. Plus, I can't do a one click upsell 100% automated without storing CC info.

What do places like 1shoppingcart.com use?

Brad

Dude, didn't you read what I said? Check out Authorize.net CIM ... it's what you want. Trust me.

Gary

[Dmitry]

OK So in the end if I want to use one-click upsells and I want to have rebills - is there a 3rd party solution that will allow me to do this?