Storing Credit Card Info & Billing Clients

[fulleffect]

Hi Folks,

My current project requires the monthly billing of client credit / debit cards.

I plan to use Protx / Streamline for the payment gateway.

However, what do you recommend for storing the customers credit card details?

The reason i want to store them, is so that i can process recurring billing on a monthly basis.

I use PHP / mySQL.

Im assuming a need some sort of encryption algorithm to safely store the credit cards in encrypted format, but then i would need to unencrypt upon processing of them. Any suggestions for php encryption classes?

I plan to install SSH on to the domain in question and transmit the data to the payment gateway using SSL.
And all passwords for the hosting account and admin will be highly secure (e.g: 8*k1l[0]p!).

But, are there any other security procedures i need to put into place to safely (and legally) store their credit card data. Last thing i need is a law suit on my hands.


Just thought i'd try you guys first in case some of you have great experience in this area.


Thanks
Daz

[danlefree]

You simply cannot store CVV2 codes (which are usually required for purchases where the card is not present - i.e. any online payment).

Look for a merchant account gateway which has an API for creating recurring transactions.

[fulleffect]

Thanks danlefree, i was able to track this down, and my payment processor supports this.



Daz

[Shift4SMS]

I would find a solution that offers tokenization so your application does not have to store the credit card details, only a token. Preferrably, I would recommend a solution that also removes your entire application and web server out of PCI scope qualifying you for the SAQ A -- by far the simpliest of the SAQ's (see www.pcisecuritystandards.org if you are not sure what an SAQ is). To qualify for SAQ A, credit card information cannot go directly to your site -- instead, the payment entry would take place directly on pages hosted by your gateway provider.

If your stuck with Protx, then you are limited to their feature set and I'm not aware of them offering either option.

[deepsand]

So as to avoid having to be compliant with PCI DSS, as well as limiting your liability, seek to have all data stored by your card processor, with none on your site.

[martindow]

We use Protx too and can use recurring payments so there is no need to store any card details. CVV2 codes are not supposed to be written down at all.

I'm sure you are registered under the Data Protection Act so you would need to conform to their regulations as well as the card processor's on storing data.
Information Commissioner's Office - ICO

[deepsand]

CVV2 codes are not supposed to be written down at all.

Though few outside the card processing industry do, it is important to make the distinction between the CVC/CVV data present on the card's magnetic stripe and that physically printed on the card; the two data values are different. From the PCI DSS "Glossary, Abbreviations and Acronyms," avaialable at https://www.pcisecuritystandards.org...glossary.shtml , we read:

"Card Validation Value or Code: Data element on a card's magnetic stripe that uses secure cryptographic process to protect data integrity on the stripe, and reveals any alteration or counterfeiting. Referred to as CAV, CVC, CVV, or CSC depending on payment card brand. The following list provides the terms for each card brand:

• CAV Card Authentication Value (JCB International payment cards)
• CVC Card Validation Code (MasterCard payment cards)
• CVV Card Verification Value (Visa Inc. Inc. and Discover payment cards)
• CSC Card Security Code (American Express)

[Shift4SMS]

We use Protx too and can use recurring payments so there is no need to store any card details. CVV2 codes are not supposed to be written down at all.

When the customer enteres their card number, where does the information get posted? Directly to a Protx web server and your server never handles card data at all, or to your server which in turn sends the request to Protx? This makes a big difference as far a security and the PCI SAQ's are concerned. If your site never sees or touches card information, you can sumit SAQ A and your site and hosting provider are out-of-scope as far a PCI is concerned. If your server ever sees or touches card information, you must submit SAQ C or D and your site and hosting provider must be PCI compliant.

[pixma85]

I believe authorize.net has a program that stores credit cards without any worries

[jjrs79]

That's correct, Authorize.net also uses a TOKEN system that is assigned to the original transaction, then you can place additional charges, refunds and recurring billing using only this token, there is no need to store the credit card information.

I believe this is the CIM solution, this is from their website, "The Authorize.Net Customer Information Manager (CIM) allows you to store your customers’ sensitive payment information on our secure servers, simplifying payments for returning customers and recurring transactions.".