views:

490

answers:

1

Should I use sessions for the first few steps (validation, review purchase) then input the information into the database in the final submit?

Could the cookies get jacked and transform into a lawsuit? Is it too risky?

Would I need to protect my db any special way if storing credit card numbers?

Any and all recommendation and personal experiences are welcome.

+8  A: 

Credit card issues have strict requirements (google "PCI Compliance") about storing credit card data.

There's at least one payment gateway that allows you to outsource the compliance stuff: http://www.braintreepaymentsolutions.com/

Last time I looked, you can run an initial transaction, and get back a token. That token can be used to make future charges against the card, but only by you. The payment gateway guys take care of storing the actual credit card data.

As far as I know (and I don't do a ton of card processing), this is probably the best solution if you need to make arbitrary charges against the same card.

If all you need is some recurring charge (a set amount at regular intervals), most payment gateways (authorize.net comes to mind) can be configured for this.

At the end of the day, if you're not dealing with a particularly large budget, you're better off outsourcing the card # storage. Doing it yourself is too much of a liability.

(Edit: As to storing things in session -- yeah, you can probably get away with that, but you should probably avoid it. Just make your initial auth/capture in-process when the CC info is submitted.)

timdev
Authorize.net does have a nice recurring charge API. Using it now. And yes, we leave the business of storing our credit card numbers to Authorize.net. WAY too much legal exposure otherwise.
Bob Kaufman
When choosing a gateway to store your credit card data keep in mind that most service providers won't give your data back to you if you want to leave. We (Braintree) started a credit card data portability standard to address the problem http://bit.ly/a2uEvm .
dan-manges