61

I need to store credit card numbers for recurring billing through our 3rd party merchant.

Are there any standards I need to adhere to regarding the storage of the details? We've been accepting credit cards for years but we used to discard their details as soon as we were done with them. Our customers have requested that we store their details so they don't have to manually pay their subscription fee each month.

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!

We utlise MSSQL 2005 for our data, and everything is already SSL'd.

Improve this question

10 Answers 10

Reset to default
85

You will need to follow (to the letter) and preferably exceed the PCI DSS 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.

Improve this answer
7
  • Hmm, we're half-way there already because we deal with sensitive information on our clients behalf (locked servers and intrusion detection and IPSec on the DMZ is already in place). I'll have a good read, thanks.
    – Mark Henderson
    Commented Jul 16, 2010 at 6:12
  • @Farseeker - Beyond preventing illegal access, the most important part is detecting it and figuring out what may have been compromised and who needs to be notified very quickly. Note, this would include unauthorized copying of the files that back the database, as well.
    – Tim Post
    Commented Jul 16, 2010 at 6:27
  • 5
    The fact that you're handling credit card data now, even if you're not storing it permanently, means you need to comply with PCI DSS.
    – Stephen Jennings
    Commented Jul 18, 2010 at 0:39
  • @Stephen - Handling and storing are completely separate things when it comes to PCI. Handling just means POST'ing some data to a gateway and waiting for a response. Storing is its own unique can of worms.
    – Tim Post
    Commented Jul 18, 2010 at 7:19
  • PCI DSS Requirement 3.2 indicates that track and verification code cannot be stored after the authorization even if encrypted and this includes ALL logs including transaction logs for the database.
    – Leigh Riffel
    Commented Jul 19, 2010 at 15:14
22

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.

Improve this answer
2
  • 3
    +1 for the idea of never storing CCs in your database. Our payment gateway provider stores all that information now, which is a huge relief on our security exposure.
    – Milner
    Commented Jul 16, 2010 at 12:37
  • For an example, one such offering is Authorize.net Customer Information Manager (CIM) authorize.net/solutions/merchantsolutions/merchantservices/cim and since recurring billing was mentioned Automated Recurring Billing (ARB) authorize.net/solutions/merchantsolutions/merchantservices/… You can store them, but they'll never be safe. In the end you will pay about what the services would have cost you in lost reputation, lost sales, fines from your processor and any litigation that comes from data compromise.
    – Fiasco Labs
    Commented Jun 23, 2013 at 20:07
13

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

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

Improve this answer
1
  • I've seen this PCI thing thrown around for a few years now, never had any idea what it actually was. Thanks.
    – Mark Henderson
    Commented Jul 16, 2010 at 6:13
8

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.

Improve this answer
5

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.

Improve this answer
4

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).

Improve this answer
3

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.

Improve this answer
1
  • That's a very good point, I hadn't thought of that. We've been using SecurePay for about 5-6 years and haven't had any concerns with them, so I think we'd be sticking with them, but who knows what the future holds...
    – Mark Henderson
    Commented Jul 30, 2010 at 5:07
2

I don't have enough rep to upvote or comment yet, so this is going in a new answer. As zhaph pointed out, 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.

Improve this answer
2

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

Improve this answer
2

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.

Improve this answer
2
  • 5
    But don't store CCs in your database. Don't.
    – dimo414
    Commented Jul 17, 2010 at 9:53
  • Encryption is only the beginning. Go download your applicable SAQ (Self Assessment Questionnaire) pcisecuritystandards.org/merchants/self_assessment_form.php and start figuring out that database encryption is quite far down the requirements list. There are so many ways of leaking credit card credentials you haven't even touched that pertain to credit card storage.
    – Fiasco Labs
    Commented Jun 23, 2013 at 20:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.