I have a checkout process for a shopping cart that is currently storing credit card data in the session for retrieval once the user finalizes the purchase. The purchase process
The best way to handle this scenario is to use a payment service that supports two things:
Authorization allows you to reserve the designated charge amount at the time the payment information is received, and then Completion allows you to commit the charge to the payment batch once the payment/order is confirmed. If the order is canceled, you don't have to issue a Completion and you can also attempt to delete the authorization as well.
Regarding tokenization, most gateways that support the aforementioned method of handling payments will return a token, typically a numeric id, for the pending transaction. The token may then be handled however you wish, as it has no value to anyone without access to your authentication credentials at the gateway. This transfers the burden of safety to the gateway as well.
Storing the actual credit card information in any way other than relaying a charge to a gateway/processor is a bad idea. Beyond the problems of securing the data, this will also put your application into card information storage scope for PCI/PABP, which entails a lot of rules and regulations that you won't want to deal with in your application. I believe there is also a regulatory fee that will be imposed in the coming year for compliant applications, reputedly $10k USD. All of this is likely not worth the trouble to you or your client.
Last, during intermediate processing (in-page/event/route handlers), you can use a SecureString to hold the contents of the data until you no longer need them.
SecureString class (System.Security) @ MSDN