问题
So I have a multi paged checkout system that relies on sessions to store the contents of the shopping cart. I'm also using a third party system to process credit cards, which hosts the actual payment page on their servers. I just have to POST to the page the final total.
The problem I foresee is what if someone clicks to go to the hosted pay page, and then for some legitimate or nefarious reason changes the shopping cart contents in another tab. I had initially planned that when the hosted pay page redirects back to my receipt page I would then INSERT the order into my database. But, if the session is changed at that point, the order will be different from the total cost charged.
What would be a solution to this problem. I can see this sort of thing being an issue for all cart systems, so I'm wondering how they do it.
Maybe when the user clicks the button to go to the hosted paypage I can make a temporary order entry in a temp_order table in the database, and then when the payment goes through I can transfer that temp record into the permanent record table? That way I don't insert the record from the session information that has changed. But if I have to POST to the hosted pay page, where do I have the opportunity to save the shopping cart to the temp table?
Also, the temp order id must be unique across both temp and permanent tables since I don't want any overlap.
Lastly, I should want to clear the temp order table frequently as they are just temp records. Some might not go through as the user could change their mind on the hosted pay page.
I'm really confused as to what I should do!
回答1:
I see no need to create a separate table. Just add one column into existing table, say, payment_in_progress and analyse it when client submits any changes to the cart.
The requirement to clear out unprocessed outdated orders remains
回答2:
When the payment gateway returns just store the amount received against the shopping cart and if the amount received is less then the total, put them back onto the payment page, showing the outstanding balance left to pay.
回答3:
Unless the payment system returns control to your website before final processing of the order, e.g. like PayPal Express Checkout, there is no way to stay in control of the checkout process. One-way checkout systems are really meant to be one-way. Follow-up management is manual (by a payment receipt) or handled by server to server notifications.
Posting directly to the payment site is not going to give you any control once you submit away to the other website. Probably the best case scenario is you submit the order to your website as an UNPAID order into your database, then provide a page that says "You're almost finished. Continue to payment." -- At this point, you should have also emptied the customer's cart so they cannot change anything about the order in process (which is already in your DB). When the payment system redirects back to your website, you will simply look for the unpaid order and mark it paid. It would also be a good idea to verify the payment amount, just in case the user modified the POST data in an effort to pay less.
EDIT:
You might really be in need of a payment gateway solution that gives you more control over the checkout process. Your concerns are real, but they are not typically addressed adequately using payment flows that send the user directly away from your website without first setting up the transaction server-side.
来源：https://stackoverflow.com/questions/12646200/creating-a-ordering-and-checkout-system-protecting-against-changing-the-cart-du