IPN延迟和SAAS应用

Question

我有一个通过订阅费运作的 SAAS Web 应用程序。如果订阅有效，则一切正常，否则应用程序将进入只读模式，直到客户续订订阅。我已经使用 PayPal API 开发了支付流程。

问题在于 PayPal 文档是这样说的：

"Although PayPal usually processes IPN messages immediately, IPN is not synchronized with actions on your website. Internet connectivity is not always 100% reliable and IPN messages can be lost or delayed. The IPN service automatically resends messages until the listener acknowledges them. The service resends messages for up to 4 days.
Because IPN is not a real-time service, your checkout flow should not wait for the IPN message before it is allowed to complete. If the checkout flow is dependent on receiving an IPN message, processing can be delayed by system load or other reasons. You should configure your checkout flow to handle a possible delay."

不幸的是，这正是我的情况：当客户续订订阅时，我需要立即激活应用程序，因此我将所有逻辑都放在“通知回调”中，我必须在其中创建订单、发送确认电子邮件、更新一些会话变量...但是如果 PayPal IPN 有延迟，这就是个问题！ 这几天我在沙盒模式下做了一些测试，有几次我在成功付款后4小时就得到了IPN的答复！这对我的应用来说是不可接受的！

最后的问题是：我的情况的最佳解决方案是什么？将应用程序激活从“通知回调”移动到“成功回调”是否有意义？可能有问题？

谢谢

Answer 1

不要为此使用 IPN；它不适合并且不适合插入同步用户体验流程。它可以很好地作为一种启动离线履行的方式，但如果他们正在积极等待访问，则可能会延迟您的客户。

您没有具体说明您使用的是哪种 PayPal 产品，但每种产品都应提供一种方式，让您立即向您提供付款已完成的反馈。例如，使用 Express Checkout 或任何基于 API 的付款，您可以在收到成功的 API 响应（在 Express Checkout 的情况下为 DoEC API）时采取行动（激活/重新激活订阅）。

对于纯网络/非 API 产品，您可以在客户重定向到您的 return_url 时采取行动，如果需要，您可以使用 PDT 安全地获取有关交易的信息（它可以包括您回传的 IPN 样式的密钥到 PayPal 进行验证，就像使用 IPN 一样）。

如果您担心有人在浏览器重定向到您之前关闭浏览器的边缘情况，或者其他类型的连接断开或编程错误，您可以也检查并激活/完成收到 IPN 以捕捉任何后果。所以所有完成正常支付流程的客户都会立即被激活；如果他们做了一些奇怪的事情（或者你的代码中断，或者其他什么），那么激活仍然会发生，尽管可能会延迟几秒钟或几分钟。