On 13-01-21 01:19, Matt Palmer wrote:
Things that require me to worry (more) about scalability are out, as are things that annoy a larger percentage of my userbase than cookies (at least with cookies, I can say "you're not accepting cookies, please turn them on", whereas with randomly resubmitting forms, I can't say "please stop changing your IP address" because that might not even be the problem).
There comes a poimt when the user confirms the order where you have to store the data on your server. And store the credit card, send the transaction, store authorisation etc. If a person needs to login before proceeding, you will need to store some info in a server side database to indicate a valid session and timestamp of last transaction (so you can time out sessions at the server level) You need to update this record everytime the user does a transaction to reset the timeout and keep the session alive. Might as well store cart information in it too as more and more items are added. One advantage of server side storage is that you have a record of users abandonning their transactions, can look at possible trends that pont to something that causes customers to go away before completing transaction. This would be important informatioon to help improve the shopping experience. Either way, you still need to have either a cookie or a hidden form field for some session ID token. Advantage of cookie is that you can switch to a static page (when you display standard shipping iformation for instancem or a help page, and you don't have to convert all those pages to a form that sends the session ID as a hidden field.