You will need to follow (to the letter) and preferably exceed the PCI DSS ^[1] standard. This is, in no way, an easy task to accomplish nor should it be taken trivially.

I strongly recommend that you find a third party processor that can handle this for you and integrate it into your billing system. It goes WAY beyond just having SSL and encrypting the information in the database. You also have to monitor access, detect intrusions, have systems in place that can notify only affected people in the event of a breach (and determine what data may have been compromised), etc.

Then, there is physical access to the servers, the network, etc. This means a locked cabinet that is not shared on servers that you own where the physical LAN is also protected. Compliance is not going to be cheap, or easy.

Really, spend every effort possible to offload this to a third party. The liability alone is simply not worth the risk unless you're talking transactions that amount to hundreds of thousands of (insert your currency here) monthly. In that case, the fees you save might justify bringing on the talent needed to implement and monitor systems that store the information. You'll need:

• Systems programmers (you will need kernel and file system level auditing hooks)
• IDS/IPS gurus (unless you love vendor lock-in)
• 24/7/365 staff to monitor the alerts generated from the systems that the experts designed. These people aren't cheap, they make the decision to pull the billing plug or report a bug in the algorithms that you use.

And then again, you could offload all of that to a third party, quite cheaply.

It's never a good idea to store credit card details ever. You're just setting yourself up for a fall, any decent payment gateway will allow you to do recurring transactions with a token where you don't have to store the credit card details.

Many answers you seek can be found at the Payment Card Industry Compliance Guide ^[1] website. Their Links ^[2] page is particularly useful.

The best suggestion would be to let a third party handle this storage.

Does your 3rd Party Merchant not include the option for Continuous Credit Card Payments - most of the major ones here in the UK certainly do (DataCash, RBS World Pay, etc.).

Basically, you submit the Card Details once to them, with a request for a CCC authority (which, if I recall correctly needs to include the expected schedule and regular amount), and then you receive a token back from them. Then every month/whatever you poll the merchant with the token, and they process the subsequent transactions for you - there are also usually facilities to set these up for variable, ad-hoc requests. The key requirement on your end is to notify the customer (usually at least 10 days) prior to taking the payment.

This way, you aren't storing the CC details anywhere, that's all being handled by people that have met the requirements.

This is similar to doing Pre-authorisations on a card, so you should never have to store the credit card, just a token from the Merchant that you can call as needed.

We have to store them, and I need to make sure the storage is safe!

One question: Why?

I only ask that because I have to deal with PCI myself, and keeping up with it is a pain. Even though my daily work qualifies us as the lowest rung for PCI compliance, there is still a lot that goes into it. Encryption, least privilege considerations, server OS security, internal network security, border security, third party audits... it is all a lot to keep up with. And that's even with us not storing credit card info!

(Sidenote: If you're doing e-commerce, you have to be PCI compliant even if you aren't storing the CC data. If you aren't complaint now, consider yourself lucky it hasn't bitten you yet.)

Look into having your processor handle it. We use Authorize.net and they have a wonderful API so that we can build our own custom front-end, but they take care of storing and dealing with the actual payments. If we wanted to set up reoccurring billing, they have a system to store the information. Honestly, I trust them more than I trust myself.

As other people mentioned, you are looking for PCI-DSS. Also as other people mentioned, compliance is likely to be prohibitively expensive for small sites.

Moving to PayPal to utilise their subscriptions is not an option. We have to store them, and I need to make sure the storage is safe!

You could locally store an ID that identifies the customer's credit card information on your payment gateway. I am not sure PayPal offers this option but there are other payment gateways that do.

Also bear in mind that even if you're not storing credit card data to disk you are still in scope for some PCI-DSS requirements. By far the easiest way to be compliant is by not taking any CC data (ie.: by POSTing the payment form directly to the payment gateway).

Services like http://chargify.com/ offer an extra layer on-top of existing payment gateways. They'll likely offer all sorts of ways to store credit cards for you, implement recurring payments, and even create reports for you.

This will let you circumvent the whole liability and PCI compliance issue. One concern I have, is if one day you want to change vendors, merchant accounts, or gateways. How do you take your 10,000 customers with you? Do they hand over a database of credit cards? Will the work with a competitor to move the credit card information over?

I doubt it. Chances are you'd have to ask all of your customers to re-submit their billing info if you change providers. This is one small argument in favor of storing the credit card information yourself. Probably only worth it if you are going to have a lot of customers and a lot of revenue. I'd be very curious to hear other peoples thoughts on this particular conundrum.

If you are going to store credit cards in your database, encryption is key. You'll also want (or maybe need) to have a third-party do routine compliance testing to ensure your systems are up to snuff.

I don't have enough rep to upvote or comment yet, so this is going in a new answer. As zhaph pointed out ^[1], many merchant companies offer a recurring payment system where they handle the storage for you.

We've been using Authorize.net for any customers unwilling to use PayPal and it's been working fairly well (our only big complaint is that the API key's reset every 6 months and they don't bother to notify you when it happens, so the page just stops working). Their API is XML based and you can find wrappers for it in just about every language.

Note that if you do end up deciding to store the credit card information in your own db, you should not, under any circumstances store the 3 digit card security code ^[1]. Doing so is strictly forbidden by the card associations.

BTW, you do not need the card security code in order to make a transaction. It improves the fraud detection rate, but you shouldn't need it if you have an on-going relationship with the customer. (And even if you think you need it, you can't store it. No matter what.)

I also second the other recommendations to not store the info. Authorize.Net's Customer Information Manager ^[2] is easy and cheap to use. It will be MUCH MUCH cheaper for you to use it rather than incur the PCI costs inherent in storing the info on your own servers.