PayPal API 处理退货答案

【问题标题】：PayPal API handling the returnPayPal API 处理退货
【发布时间】：2014-06-29 16:21:39
【问题描述】：

流程本身非常简单：

现在我发现有点棘手的是步骤 1-2 和 4-5。

让我们从第 4 部分开始。从 PayPal 返回时，URL 具有 PayerID 和 token 作为 GET 参数。 PayerID 是进行交易的用户的良好标识符，但不是订单的标识符（如果他们有很多订单）。因此，token 似乎是用于识别订单的合乎逻辑的东西。

不过……

在步骤 1 中创建付款的响应仅包含 token 末尾的 approval_url，它嵌套了几个节点。我已设法将其取出并保存以供将来参考。这样它就可以用来确定在第 5 步中要执行的付款。如果PaymentID 在返回中会容易得多。

我想知道我的方法是否准确或是否有更好的方法。当用户转到 PayPal 以防过期时，我不能完全确定自己是否将信息存储在会话中。

请你的想法。

【问题讨论】：

【解决方案1】：

您实际上不需要存储令牌，因为它只能使用一次并在 3 小时后过期。相反，我所做的是存储生成的 paymentId：

$_SESSION['paymentId'] = $return['id'];

当他们被重定向到您的着陆页时，您只需检查以确保已设置，如果没有重定向他们并生成一个新页面。您甚至需要 paymentId 才能执行付款，或查找有关付款的信息：

POST /v1/payments/payment/{paymentId}/execute

和

GET /v1/payments/payment/{paymentId}

哪个会返回选择的收货地址等

【讨论】：

我一直在做的是将PaymentID 和token 存储在数据库中，然后在返回时使用token 从数据库中获取PaymentID。您提到令牌会在 3 小时后过期，但默认情况下会话可能会在 24 分钟后过期。
如果您希望用户的会话超时，那么存储令牌将是交叉引用原始付款的唯一方法。请记住，该令牌对于将来的任何使用都是无效的。
是的，我收集到了。无论您使用的是会话还是令牌，这似乎都有些松散。