[Ixiaus]

The best way to handle it is to have your gateway handle the storage of CC data - gateways (Authorize.net - CIM, Braintree - Vault, etc...) have the resources and incentive to be PCI compliant.

With it stored on your gateway's servers, they will usually provide an API that you can use to issue transactions against the stored user data (it shouldn't return the CC data, just run transactions against it).

I'm heavily against storing CC data on my own servers - I store the last 4 digits (for display purposes to users) but that is it.

[deets]

But that just delegates the problem to the gateway. My personal experience with these guys let's me assume the worst. E.g. not being able and willing to only send me confidential information with signed mail and similar things.

But somebody stores the CC-data, and I wonder why that can't be an encrypted storage only the CC-card-companies can decrypt. Of course this would need some protocol, but can it be so hard (especially when that much is at stake?)

[kposehn]

Agreed, I never want to store any actual data that someone could use in order to commit fraud. The legal exposure there is too great - let someone else take the blame and I'll switch providers if I have to.

[CoachRufus87]

is it a PCI violation to store the expiration month/year of a customers CC (for the purpose of knowing when a CC expires and reminding the card holder to update their info)

[Ixiaus]

I believe it is a violation to store the expiration date without encrypting it. I could be wrong, here is a link to PCI DSS standards documents.

[CoachRufus87]

hey could you send me that link again?

Edit: I looked up the document, TL;DR - you don't need to encrypt the cardholder name, service code, or expiration date unless you are also storing an associated primary account number.