PayPal REST API 订单工作流程:付款 ->销售 ->网络钩子? [英] PayPal REST API order workflow: Payment -> Sale -> Webhook?

问题描述

我正在尝试将 PayPal REST API 集成到我的 Symfony 2 Web 应用程序中，但我发现很难理解完整的工作流程究竟是怎样的:

PayPal 文档描述了以下步骤接受付款.可以使用 PayPal Playground 来模拟这些步骤:

1. 获取访问令牌
2. 通过查询 API 来创建Payment 对象
3. 将用户重定向到 Payment 响应中收到的 approval url
4. 在用户批准 PayPal 页面上的付款后，他将使用 Payment 对象中定义的成功链接重定向回我的页面.使用收到的信息执行付款.
5. 付款已完成，状态 approved

<块引用>

来自文档:>支付完成，它被称为销售.然后，您可以查询销售情况并退款.

到目前为止一切顺利.但是: 在此工作流程中，Webhook 在哪里使用/触发?我在 PayPal Developer Dashboard 中定义了一个通配符 Webhook(接受所有可能的事件).

我的观察是，我的系统在 1-2 分钟 (!) 之后 接收到 Webhook 事件，用户被重定向回成功链接并且 付款执行后(第 4 步).

除了执行付款和接收 Webhook 之间的长时间延迟之外，此工作流程意味着我只收到 Webhook AFTER 处理成功链接.这意味着，处理成功链接对于完成付款是绝对必要的.这是正确的吗?

我需要使用网络钩子吗?

几天前我已经问过这个问题，nifr 的回答非常合理:不能信任用户遵循任何重定向 URL，但应仅依赖于 Webhook 事件.

然而，这与我之前描述的观察相冲突，因为如果不处理重定向 URL，我将永远不会收到 Webhook...

因此，处理 PAYMENT.SALE.COMPLETED 网络钩子事件没有多大意义，因为在处理重定向 URL 时应该已经完成​​了.正确吗?

但是，只有通过侦听这些事件才能处理待处理付款的更新、处理退款或撤销付款等.

所以答案是:仅使用 Webhooks 获取之前付款的更新.正确吗?

所以，主要问题是:

1. 接受付款的 5 步流程并未说明如何使用 Webhooks.这似乎没有多大意义，因为如果没有 Webhooks，人们会错过更新事件等?那么，真的可以在没有 Webhooks 的情况下实现完整的支付工作流程吗?
2. 如果是，在这种情况下如何处理更新(退款、待处理等)?
3. 如果不是，完成订单需要很长时间才能完成订单的正确策略/时间是什么?

解决方案

我还是 PayPal 世界的新手，但几天前我在网上商店中集成了 PayPal Plus REST API，根据我的理解，我可以看出工作流程如下:

1. 创建付款
2. 重定向到 PayPal
3. 付款人可以使用 PayPal 帐户付款或(使用银行直接借记卡或没有 PayPal 帐户的信用卡付款)
4. 在 PayPal 端完成流程后，PayPal 会将用户重定向回您的成功 URL.
5. 直到现在用户仍然没有被收费(你没有钱).当您(在您的成功 URL 中)执行 $payment->execute($paymentExecution,$api); 时，您要求 Paypal 向用户收取费用.但在此之后，你也没有钱了.Paypal 必须首先处理收费，然后通过 WebhookEvents 通知您.

当用户按直接借记卡或信用卡等付款时，Webhook 通知(具有令人讨厌的延迟)尤其重要.处理此类付款需要几秒/分钟.

redirectUrl 是收费/执行付款绝对必要的.这里执行成功，只是告诉用户，他完成了他的工作，您可以在这里保存/捕获 PaymentID/Transaction id 以供以后使用/通过 WebhookEvent 侦听器更新.

所以我建议您仅在通过 WebhookEvent Listener 接收通知后更新您的数据库(付款完成)，而不是在成功 RedirectUrl 中.

I am trying to integrate the PayPal REST API into my Symfony 2 web app but I find hard to understand how exactly the complete workflow looks like:

The PayPal docs describe the following steps to accept a payment. One can use the PayPal Playground to simulate these steps:

1. Get an access token
2. Create a Payment object by querying the API
3. Redirect the user to the approval url received in the Payment response
4. After the user approved the payment on the PayPal page, he is redirected back to my page, using the success-link defined in the Payment object. Use the received information to execute the payment.
5. Payment is completed with status approved

From the docs: Once a payment is complete, it is referred to as a sale. You can then look up the sale and refund it.

So far so good. BUT: Where are Webhooks used/fired in this workflow? I have defined a wildcard Webhook (accepting all possible events) in the PayPal Developer Dashboard.

My observation is, that my system receives the Webhook event 1-2 Minutes (!) after the user was redirected back to the success-link and after the payment was executed (Step 4).

Beside this long delay between executing the payment and receiving the Webhook, this workflow means, that I only receive the Webhook AFTER handling the success-link. This means, handling the success-link is absolutly necessary for the payment to be completed. Is this correct?

Do I need to use Webhooks?

I already asked this question a few days before and the answer by nifr is quite reasonable: One cannot trust the user to follow any redirect URL but should only rely on the Webhook events.

However this collides with the observations I described before, since I will never receive the Webhook without handling the redirect URL...

So, handling the PAYMENT.SALE.COMPLETED webhook event does not make a lot of sense, since this should already be done in when handling the redirect URL. Correct?

However, to handle updates on pending payments, handle refunds or reversed payments, etc. are only possible by listening on those events.

So the answer is: Only use Webhooks to get updates on payments made before. Correct?

So, the main questions are:

1. The 5-step process to accept payments does not say anything about using Webhooks. This does not seem to make a lot of sense, because without Webhooks one would miss update events, etc.? So, is it really possible to implement the complete payment workflow without Webhooks?
2. If yes, how are updates (refunds, pending, etc) handled in this case?
3. If no, what is the right strategy/time to fulfill the order since it take quite a long time to completly receive and handle the webhook?

解决方案

i am still a newbie in PayPal world, but few days ago i integrated PayPal Plus REST API in an online Shop, and from my understanding i can tell that the workflow looks like:

1. create a Payment
2. redirect to PayPal
3. Payer could pay using PayPal account OR (using Bank Direct debit or Credit Card Payment without PayPal Account)
4. After completing the process on PayPal side, PayPal redirect the user back to your success URL.
5. till now the user is still not charged(you got no money). At the moment where you (in your success URL) do $payment->execute($paymentExecution,$api); , you ask Paypal to charge the amount from user. BUT also after this, you got no Money. Paypal have first to process the charging and notify you later via WebhookEvents.

the Webhook Notification (with that nasty delay) is especially important when the user pays per direct debit or Credit Card etc. Processing such Payments takes few seconds/minutes.

the redirectUrl ist absolutly necessary for charging/executing the Payment. here on execution succeed, just to tell the user, that he finished his Job, and you can here save/capture the PaymentID/Transaction id for later usage/update via WebhookEvent Listener.

so i would recommend you to update your Database(Payment completed) only after receiving notofications via WebhookEvent Listener and not in the success RedirectUrl.

这篇关于PayPal REST API 订单工作流程:付款 ->销售 ->网络钩子?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！