所以我有一个多页面的结账系统，它依赖于会话来存储购物车的内容。我也在使用第三方系统来处理信用卡，它在他们的服务器上托管实际的支付页面。我只需要把最后的总数发到页面上。
我预见到的问题是，如果有人点击进入托管付费页面，然后出于某种合法或邪恶的原因更改了另一个选项卡中的购物车内容，会发生什么。我最初计划，当托管付费页面重定向回我的收据页面时，我会将订单插入我的数据库。但是，如果会话在此时更改，则订单将与收取的总成本不同。
这个问题的解决方案是什么。我可以看到这类事情是所有推车系统的问题，所以我想知道他们是如何做到的
也许当用户点击按钮转到托管的付款页面时，我可以在数据库中的临时订单表中创建临时订单条目，然后当付款完成时，我就可以将该临时记录转移到永久记录表中？这样，我就不会插入已更改的会话信息中的记录。但是，如果我必须POST到托管的付费页面，我在哪里有机会将购物车保存到临时表？
此外，临时订单id在临时表和永久表中都必须是唯一的，因为我不希望有任何重叠。
最后，我应该经常清除临时订单表，因为它们只是临时记录。有些可能不会通过，因为用户可能会在托管的付费页面上改变主意。
我真的很困惑我该怎么办！
我认为没有必要创建一个单独的表。只需在现有表中添加一列，例如payment_in_progress，并在客户端向购物车提交任何更改时对其进行分析。
清除未处理的过期订单的要求仍然是
当支付网关返回时，只需将收到的金额存储在购物车中，如果收到的金额小于总额，则将其放回支付页面，显示剩余的未付余额。
除非支付系统在订单最终处理之前将控制权返回到您的网站，例如PayPal Express Checkout，否则无法控制结账过程。单向结账系统实际上是单向的。后续管理是手动的(通过付款收据)或通过服务器到服务器的通知来处理。
一旦你提交到其他网站，直接在支付网站上发帖不会给你任何控制权。可能最好的情况是，你将订单作为UNPAID订单提交到你的网站，然后提供一个页面，上面写着"你快完成了。继续付款。"——此时，你也应该清空客户的购物车，这样他们就无法更改正在处理的订单(已经在你的数据库中)。当支付系统重定向回您的网站时，您只需查找未付款订单并将其标记为已付款。验证支付金额也是一个好主意，以防用户为了减少支付而修改POST数据。
编辑：
您可能真的需要一个支付网关解决方案，让您能够更好地控制结账过程。您的担忧是真实存在的，但通常情况下，在没有首先设置交易服务器端的情况下，使用直接将用户从您的网站上赶走的支付流并不能充分解决这些问题。