我有一个网站，用户为其他用户提供的服务付费，并且在本周末，我们向用户支付他们的服务销售价值减去我们的佣金。
目前，当我们想要向用户付款时，我们会进行人工付款，登录到paypal并在付款后手动更新我们的数据库。我们遇到的问题是我们的交易每周超过一千，因此手动操作非常麻烦。
我们提出了一个小系统，通过使用PayPal的Adaptive Payments API，我们只需点击一下即可执行付款并更新我们的数据库。
我的问题如下 - 我们担心会发生一些情况：
我们向用户付款，我们的SQL数据库已关闭，因此我们不会更新我们的销售记录。因此，当cron执行时，系统会再次向用户付款。
我们可以反过来，并首先更新我们的SQL数据库，如果这样，我们执行paypal付款。问题是，如果在PayPal方面出现问题，我们最终根本不会向用户付款，因为我们的数据库已更新，就好像我们付了钱一样。
我们的解决方案：
我们更新数据库并跟踪所有已更改的记录 - ＆gt;继续致电PayPal API - ＆gt;如果PayPal调用失败，我们将更改还原为更新的记录;如果通话成功，我们保持原样。
我们执行PayPal付款，并更新数据库。我们将来自API的ACK消息存储在数据库中，当我们检查记录以向用户付款时，我们验证ACK字段是否成功。
我们的解决方案让我们非常疲惫，也许我们陷入了某种心态。我们担心的是，无论是SQL还是失败，或者PayPal api调用都不会通过。 有没有人对我们的支付系统有任何建议或完全不同的实施？
答案 0 :(得分：2)
嗯，基本上这是交易系统的事情。
看看这里：http://dev.mysql.com/doc/refman/5.0/en/commit.html
这将是最令人讨厌的方法，如果提交失败，只需在某个地方记录该错误而不是DB相关，然后手动处理（用户友好）
只是一个附注，当然在财务上更安全，更新用户数据，首先发送付款，然后运行顺利将付款发送到PayPal。
如果您在付款错误后无法回滚用户数据，则不会损害您的损失，但用户肯定会告诉您他没有收到付款....
答案 1 :(得分：2)
您需要的是two-phase commit
的变体创建付款流程的状态转换图，其中每个州表示持久存储的稳定状态（在本例中为您的MySQL数据库），并确保所有路径都可以导致正在处理一个付款。
首先，您记录您正在尝试付款。
如果付款成功，则录制该内容。
如果您从系统故障中恢复过来，并且您已经记录了您尝试支付但未支付的费用，则必须与paypal核实是否已付款。