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

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

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

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

Answer 1

我可以/应该只信任 JSON 响应中的所有数据而或多或少地忽略 IPN 侦听器吗？

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

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

所以你的过程是（如上所述）

1. 页面 A：创建 sessionID (cookie)、金额、购物车详细信息等并存储在本地数据库/存储中。您还可以创建一个“自定义”字段来存储您自己的 saleID
2. 将金额等发送到 Paypal，Paypal 会将您退回到 ....
3. 页面 B：获取 PayPal TransactionID 并将 (server->server) 发送回 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 解释得最好：

虽然 PayPal 通常会立即处理 IPN 消息，但 IPN 不会与您网站上的操作同步。 Internet 连接并不总是 100% 可靠，IPN 消息可能会丢失或延迟。 IPN 服务会自动重新发送消息，直到侦听器确认它们为止。该服务最多会重新发送消息 4 天。

由于 IPN 不是实时服务，因此您的结帐流程不应等待 IPN 消息才允许完成。如果结帐流程依赖于接收 IPN 消息，则处理可能会因系统负载或其他原因而延迟。您应该配置结帐流程以处理可能的延迟。

回到原来的问题

是的：依靠您进行的 JSON (server->server) 调用来验证“Page B”的参数（如果您选择，还可以在 IPN 处理程序中）

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

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

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

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