【问题标题】:Paypal IPN Status - QueuedPaypal IPN 状态 - 已排队
【发布时间】:2013-09-19 18:47:36
【问题描述】:

我正在使用 paypal 沙盒进行一些测试付款,直到今天它们都很好。我没有收到来自 paypal 的 IPN,当我查看 IPN 通知历史记录时,所有消息都显示为 Queued

如果我重新发送状态为已发送的 IPN,我会收到罚款但没有新的通过。

我检查了服务器上的错误日志,没有收到任何编码错误。

我做错了什么还是这只是 PayPals 端的积压?

【问题讨论】:

  • 同样的事情发生在我身上,我也想在这里问。我认为他们的服务器很忙或因 ipns 或其他原因而超载,这就是它排队的原因。不知道,希望有人能给出更好的答案。
  • 我想是的。我已经等了大约 6 个小时了。
  • 我花了两个小时调试这个,状态网站上没有更新。否则,我很高兴看到我不是唯一面临这个问题的人。
  • 我也遇到了同样的问题。
  • 对于我在 PayPal 上遇到的每个错误,我都遇到了一个 SO 线程,每个人都认为“这是他们最后的问题”。 :)

标签: paypal paypal-ipn


【解决方案1】:

PayPal 沙盒应该让我们在舒适的伪造/测试环境中测试 PayPal 功能。

但是,在实践中:沙盒环境比生产环境慢得多——而且通常异常缓慢。

不幸的是,这是一个相当典型的例子:

2017-12-19 10:27     Test payment OK.
2017-12-19 12:43     Test payment finally visible in the test business account, but IPN still not sent (queued, 0 retry, nothing on ngrok.)
2017-12-19 20:23     IPN finally received.

即:从测试购买到收到第一个 IPN 花了将近 10 个小时。

以下是一些提示。


正常的购买流程(无论是生产还是沙盒)是这样的:

  1. 您在自己的网站上进行购买。
  2. 款项会汇入您的商家帐户。
  3. IPN 被发送到您的站点。

在生产中:步骤 2 和 3 通常在步骤 1 的几分钟内发生。

但是,在沙盒环境中:第 2 步(余额)通常仅在第 1 步之后几个小时发生。即使第 2 步确实发生了,第 3 步(IPN)仍然不会立即发生,并且需要等待几个小时是很常见的。

当然,这一切都很烦人,并且违背了测试环境的目的。

要测试你的工作是否正常,只是“老旧”的 PayPal 非常缓慢:

  • 密切关注您的错误日志。您的测试订单期间没有错误?
  • 密切关注 Sandbox 商家帐户,了解资金何时到账。
  • 密切关注您的活动日志,看看您是否收到有关预期 URL 的任何通知。 (使用 ngrok 进行本地开发使这变得更加容易。)
  • 密切关注IPN history page of the Sandbox 以了解IPN 的状态。特别是:
    • 检查最近的交付尝试日期/时间字段。只要是空的,就不能怪自己的 IPN 脚本。

来源:这是基于我多年来在生产环境中使用 PayPal 并每年使用 PayPal Sandbox 进行几次测试。测试时,总是很难判断我是否搞砸了(没有通知),或者只是沙盒速度慢。我最终把事情超时了……结果发现通知延迟 5 小时以上是很常见的,甚至更多。


底线

  • 转移到一个新的更好的支付网关,例如:Stripe,测试环境可以实时运行。
  • 如果您无法使用 PayPal,模拟 IPN(通过提交您自己的假 IPN 或旧数据)可能会比使用沙盒更方便,至少在时间紧迫的情况下是如此。

【讨论】:

    【解决方案2】:

    我将发布我的解决方法,因为 2.5 年后我和其他人仍然无法使用 PayPal 的沙盒:

    1. 进入您的 IPN 设置并将其设置为“不接收 IPN 消息(已禁用)”,
    2. 开始测试付款。该交易将在交易历史记录中显示为“已禁用”而不是“排队”。
    3. 然后,将 IPN 通知设置为“接收 IPN 消息(启用)”。 当您查看历史记录时,您会看到交易旁边的复选框。
    4. 然后您可以选中复选框并重新发送。

    我知道这不是一个理想的解决方案,因为它需要一些额外的步骤,但至少它允许我们使用沙盒进行测试。

    【讨论】:

    • 可能会很慢,但慢慢调试总比不调试好:) 谢谢。
    【解决方案3】:

    我有同样的问题 - 原帖后 2 年。

    我想知道这是否与使用沙盒有关 - 是否也发生在普通帐户中。

    我可以通过要求损坏的沙盒服务商帐户重新发送消息来使用模拟器和事件获取 IPN 消息 - 所有工作都可以找到。只是来自损坏的沙盒服务商帐户的新消息无休止地排队。

    鉴于有证据表明这与 PayPal 积压无关,我非常确定。
    我的第一个消息是 25 小时前排队的(自从它开始后,我收到了大量消息,如重新发送的 IPN 消息 + 模拟器消息)。

    添加:3 天后,早上醒来发现我的 IPN 中所有排队的消息突然都被送达了。似乎他们有一些非常缓慢的过程(也许是人性化的?)可以解决问题(识别卡住的队列并让它们再次运行)。一旦队列被卡住,所有后续的新消息都会获得 QUEUE 状态,直到好的 PaylPal 进程让它们运行。

    如上所述,似乎所有投诉都与沙盒帐户有关 - 这可能意味着非沙盒帐户的处理速度要快得多,或者问题只是不会发生在真实帐户中。

    【讨论】:

    • 同样的问题。看起来这是 Paypal 沙箱服务器 IPN 处理的问题。该文档有关于何时期待回复的免责声明。 25 小时似乎指向 Paypal 沙盒服务器问题。避免的唯一方法似乎是使用 API 来实际创建整个支付流(与使用 Paypal 按钮相比,它不会给您返回任何信息,因为按钮会将它们带到 Paypal 站点,然后如果有指示将它们传回到您的网站)。
    • 我记得那些年前几乎相同的问题,这是由于我记得的贝宝服务器积压造成的。很高兴听到它再次开始为您工作。 Paypals 开发环境充其量一直是粗略的。
    【解决方案4】:

    对于遇到此错误的任何人,我今天早上再次开始收到我的 IPN 消息。所以一定是贝宝的问题。

    【讨论】:

      【解决方案5】:

      我整天都遇到同样的问题,马克。我知道 IPN 可以访问我的网站,因为我能够让 Paypal 重新发送一个较早的 IPN OK,同时手动发送一个测试 IPN 也可以正常工作。

      也许今天早些时候他们的问题之后有大量的积压工作要发送出去。

      约翰

      【讨论】:

      • 谢谢约翰,我也遇到了同样的问题。希望贝宝明天能修复它。
      猜你喜欢
      • 2016-08-07
      • 1970-01-01
      • 2016-07-30
      • 2016-06-16
      • 2014-09-09
      • 2016-02-08
      • 1970-01-01
      • 2014-01-18
      • 2014-01-03
      相关资源
      最近更新 更多