Don't store the credit card info in the session, don't store it to a database, don't store it to a file. Instead, write the cc info back to the review page in a hidden html inputs.
So the program flow would work like this:
- User posts payment and billing information to the server via an html form.
- Server verifies that this information is in the correct format (i.e. credit card has the appropriate number of digits, a billing address was entered, etc.)
- After verification the server writes back all the information submitted as hidden form input fields. This includes billing address, shipping address and credit card info.
- The form on the review page (with the hidden input fields) has a button labeled "Finish Order" / "Complete Order". This review form posts to the finalize order script.
- The finalize script stores billing/shipping info in your database and submits the credit card info to your payment gateway.
The advantages of
this method are two-fold:
- You save the overhead and cost of additional PCI compliance that is required when storing credit info.
- This method stays within the security bounds of the SSL protocol. Meaning, encrypted credit card info will have to be submitted to your server in any instance - this method continues to rely solely on the efficacy of SSL, without introducing the complexities of persisting credit card data.
This last point raises another concern - by having a review page you're doubling the number of times the encrypted credit card data is being transmitted across the network. With this method there are 4 transmissions minimum: client to server, server to client, client to server (again) then server to gateway. Without review there are 2 transmissions minimum: client to server and server to gateway. Is the convenience of a review page worth the risk of extra transmissions? That's a decision you as a web developer (and your client) get to make.