php - 如何使用 PayPal REST API 和 IPN 验证销售

Question

我目前通过 PayPal _xcart 方法有一个完整的购物车和结帐流程，但我想将其迁移到 REST API，主要是因为我想降低价格劫持的可能性。目前，我的 IPN 确实会检查价格插孔并设置相应的标志，因此不会下载产品(仅销售数字产品)。更重要的是，我发现 PayPal 文档非常困惑，我正在努力完全掌握它。

这是我到目前为止所理解和解决的。

1. 使用我的 PHP 脚本(我们称之为页面 A)我创建了购物车内容，然后我创建了一个新的 PayPal 销售并将客户重定向到 PayPal 以进行身份​​验证

2. 在 PayPal 上进行客户端身份验证，然后将其重定向回我的站点到页面 B(页面 B 在页面 A 中定义)

3. 页面 B 需要获取 PaymentID(来自页面 A)并使用它来有效地完成交易。一旦完成结帐。

现在这是我的问题:

a) 我已经阅读了很多论坛和教程，他们都提到我应该使用 session 来存储页面 A 的 PaymentId，然后在页面 B 中使用它来完成交易。 SO 上的一些线程建议 PayPal 实际上应该在对页面 B 的调用中包含 PaymentID，以及 token 和 PayerID。这些都是将近 3 年前的帖子，在我的测试过程中，我发现 PayPal 现在也确实返回了 PaymentID。

• 这是新事物吗，PayPal 真的开始将 PaymentID 作为 GET 变量发送了吗？ 好的，我在 PayPal SDK 文档(当然不是 PHP，当然是其他语言)上发现了这个，他们返回PaymentID 以及 GET。
• 与存储从页面 A 到 B 的 session 相比，使用 PayPal 提供的 GET 有什么缺点吗？我真的不想要 session ，所以 GET 对我来说是理想的选择。 我想如果它在 PayPal 文档中，那么使用它是安全的。
• 这是否也适用于实时页面或仅适用于 Sandbox？

b) 在页面 B 上，当我执行付款时，我得到一个很好的 JSON 作为响应，但同时我的 IPN 监听器也被调用，这让我很困惑。我可以/应该只信任 JSON 响应中的所有数据并或多或少地忽略 IPN 监听器吗？这对于即时下载很有意义，例如，更容易处理，或者我是否仍应依赖 IPN 进行数据验证？

• 如果我只使用返回到页面 B 的 JSON，哪些是要查找的正确字段以及哪些值？例如，有一个已批准的状态字段和另一个已完成的(交易 -> 相关项目 -> 状态)。我需要检查哪一个？
• 如果我依赖 JSON，我是否仍需要检查支付金额是否与原始金额相符，或者我是否可以相信支付金额等于我在通话中请求的金额？
• 如果我使用 IPN，我如何将它与交易分开？ PaymentID 不会出现在发布到 IPN 的变量中。我能想到的唯一方法是从 JSON 响应中获取 txn_id，但不知何故感觉很奇怪，而且我怎么知道 JSON 响应是否在 IPN 之前到达服务器？

Answer 1

Can/Should I just trust all the data which is in the JSON response and more or less ignore the IPN listener?

是的，也不是。按照这个顺序。

简而言之，您不能信任调用“页面 B”时的支付 ID(它可能是伪造的、伪造的、重复的等)，但您可以信任 YourServer->PayPalServer 的响应，因为它不能被最终用户拦截和伪造。

所以你的过程是(正如你上面描述的)

1. 页面 A:创建 session ID(cookie)、金额、购物车详细信息等并存储在本地数据库/存储中。您还可以创建一个“自定义”字段来存储您自己的 saleID
2. 将金额等发送到 Paypal，然后您将返回到....
3. 页面 B:获取 PayPal TransactionID 并将(服务器->服务器)发送回 PayPal。 Paypal 返回金额、状态等。然后检查您的数据库，金额是否相同并且属于 sessionID。如果您还使用自定义字段，请也检查一下。如果一切都结婚了，你就很好。如果不是，则由您决定如何处理。

此时对于简单的销售，状态应该是“完成”；但是(与下面的 IPN 一样)您应该验证这一点。

请检查金额，以防万一。它们应该匹配，但如果不匹配，PayPal 将是您收到的，您可以接受、标记它(并打电话)或通过 API 退款并拒绝订单等。

那么为什么要有 IPN？

用户有可能在 Paypal 上完成交易，然后在调用“页面 B”之前关闭浏览器。在这种情况下，您了解订单的唯一方式是通过 IPN。

如果您的 IPN 处理程序收到 IPN 通知，IPN 仍然可以伪造，但验证方式略有不同。

您实际上将 IPN 信息发送回 Paypal(服务器到服务器)，Paypal 确认它是正确的还是错误的 (https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNIntro/)。然后您的 IPN 处理程序将检查交易 ID(是的，这就是您使用的)并验证数据库中的所有匹配项(就像您在“页面 B”中所做的那样)。如果是，则在状态为已完成的情况下将订单标记为已完成(如果尚未在“页面 B”中标记为已完成)。

显然，此时您不能向用户显示任何内容，因为他们不是调用该页面的用户。

上面的文档警告您可以为同一笔交易获得多个 IPN，因此您还需要检查状态。

(注意:您可以像在“页面 B”中那样使用 API 来验证 transactionID)。

那为什么不在 IPN 上回复呢？

Paypal 警告 IPN 可能无法到达。 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.

回到最初的问题

是的:依靠您进行的 JSON(服务器-> 服务器)调用来验证“页面 B”的参数(如果您选择的话，还有 IPN 处理程序)

否:不要忽略 IPN，以防永远不会调用页面 B。但仍然在这里运行验证检查。

是:“页面 B”和“IPN 处理程序”的检查状态 = 完成

是的:使用 Paypal TransactionID，但使用自定义字段或 sessionID 混合到您自己的数据库中。

是的，您可以/将同时收到页面 B 和 IPN 通知，如果付款已标记为已完成，我建议忽略 IPN，否则请适当处理。他们应该使用相同的数据库。