As already mentioned by someone who posted as Anonymous Monk, merlyn wrote an article, along with an example script (like always), on the best (and only) way cookies should be used (if they need to be used at all). Here's the article, which contains good advice and suggestions. Obey what you read here :)

That being said, definitely don't trust anything you get from the client. The cookie should only indicate which browser (notice the word 'browser', not 'user', since the same user should be able to have multiple sessions open with your web applications) is accessing the script. All data should be contained within a database, including prices (do NOT put prices in hidden html fields), all contact info, and anything else you can possibly think of. Also, make sure you expire the session from the database after a reasonable amount of inactivity. What is 'reasonable' is up to you, but don't leave inactive sessions around for too long, unless you want these picked up by somebody other than the original session creater :)

More from a view of making things work the way you expect, rather than security (but security can always hold a place in these things), is making sure the data you are being forced to receive from the client is the data you are expecting. What if a user tells your script they want 0.5 pairs of shoes? Your script had better insure that the only data it is accepting for quantities is a whole integer: no alpha characters, no decimal, etc etc. If you don't, your web app will charge your shopper the price of one shoe rather than the pair of them. And are you willing to ship out one shoe? :) Even worse, what do you do when someone tells your app "I want to purchase -10 pairs of shoes."? Will your app reject this value or will you be offering a refund for the amount of 10 pairs of shoes?

Are there any non-obvious security-related tips (i.e. besides "use taint checks well" and "encrypt credit card numbers" ...

Um... encrypting credit card numbers? No. Just don't do it. Don't even save the shopper's credit card number in your database, I don't care how safe you think you've encrypted it. If you can decrypt it to the true credit card number, then so can someone else who might find their way into your database. Will this require shoppers to re-enter their credit card number every time they buy something? Yes. Will it make them feel more secure? Perhaps. Will it make you feel better and more responsible when you find out your database has been hacked into by someone else? Definitely!

-------------------------------------
eval reverse@{[lreP
=>q{ tsuJ\{qq},' rehtonA'
,q{\}rekcaH },' tnirp']}[1+1+
1,1-1,1+1,1*1,(1+1)*(1+1)];
-------------------------------------