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