想象 3 个系统组件： 1. 处理信用卡交易的外部电子商务网络服务 2.本地数据库存储处理结果 3. 本地 UI（或 win 服务）执行客户订单文档的支付处理
外部web服务显然不是事务性的，那么如何保证： 1. 从 Web 服务接收到的结果最终会保存到数据库中，即使当时无法访问数据库（网络问题，数据库超时） 2. 防止客户端在其他客户端发起付款但结果尚未成功保存到数据库时处理客户订单（并在某种恢复队列中等待）
目的是做具有非事务性系统组件的处理，并保证事务在失败的情况下不会被其他进程重复。
（请在售后付款处理的上下文中查看它，其中多个运营商可能会尝试手动付款处理；而不是网络结帐应用程序）
【问题讨论】：
标签： web-services architecture payment-gateway
询问付款处理方是否可以根据您提供的订单 ID 检测重复交易。然后，如果由于数据库故障而无法存储响应，则可以安全地重新提交请求，而不必担心重复收费（在这种情况下，我使用的至少一个 PSP 返回了相同的响应/身份验证代码，以及表示这是重复的）。
或者，只需在尝试付款之前立即在您的订单上设置一个标志，如果该标志已经设置，则不要尝试付款。如果在付款过程中出现错误，您可以在闲暇时调查和修复数据。
我不愿意尝试自动取消订单并重新提交，因为这会让人感到困惑（例如，如果取消失败怎么办 - 您是否应该重试？）。最好保持逻辑简单，这样当出现问题时，您可以准确地知道自己的立场。
【讨论】：
在这样的任何系统中，您都需要强大的错误处理和错误报告。在处理付款时更是如此，您绝对不希望意外拿走某人的钱而没有交付货物。
由于您将付款处理外包给第三方，因此您最终非常依赖具有强大错误处理和报告系统的网关。
一般情况下，您将控制权交给支付网关并启动一个等待网关响应的任务，即“已接受付款”或“已拒绝付款”。当您得到响应时，您将进入流程的下一步，一切都很好。
当您根本没有收到响应（超时）或响应无效时，您如何进行很大程度上取决于支付网关：
如果网关支持，则发送“取消支付”样式请求。如果付款成功取消，那么您可能希望将用户发送到“抱歉，请重试”样式页面。
如果网关不支持取消，或者您没有与网关通信，那么您将需要手动（亲自，例如电话）联系第三者以发现问题所在以及如何继续.为此，您需要将尽可能多的详细信息转储到错误日志中，例如日期/时间、客户 ID、交易价值、产品 ID 等。
一旦您回到您的网站（并接受付款），您就可以更好地控制错误，但简而言之，如果您无法完成订单，那么您应该将详细信息转储到磁盘（例如csv文件手动处理）或联系网关取消支付。
还值得建立一个系统来跟踪发生的错误，如果出现过多的错误，请考虑应该发生什么。例如，如果它是一个高流量网站，您可能希望在调查问题期间暂时阻止更多客户下订单。
【讨论】：
分布式消息传递。
当您的支付网关返回时，将消息提交到持久队列，以保证处理程序最终会获取并处理它。处理程序将更新数据库。如果此时发生故障，处理程序可以将消息留在队列中或将其重新发布到队列中，或发布替代消息。
如果稍后发生使交易无效的事情，可以将另一条消息排队以“撤消”更改。
最近有很多关于最终一致性和分发消息的讨论。 NServiceBus 是新的组件热点。我建议调查一下，我知道我们是。
【讨论】：