为什么PayPal在使用django-paypal时重试IPN [英] Why does Paypal retry IPN when using django-paypal

问题描述

我一直试图让django-paypal应用程序在我的Django项目中工作。我正在使用Django 1.4中的 dcramer fork 。我还使用PayPal开发者帐户与业务和个人账户，通过Paypal沙箱网站处理交易。

如果我没有接收器功能连接到 payment_was_successful 信号，事情似乎按预期工作。在事务发生后，在 paypal_ipn 表中，在响应中具有值VERIFIED的数据库中创建一个新行。 code>列。 Paypal IPN日志报告说，这次交易没有重试。

当我有一个接收功能连接到 payment_was_successful 信号， paypal_ipn 表格包含两个新行，其中 created_at 时间戳间隔10-15秒。它们在响应列中都具有VERIFIED值，但两者中的后者被标记为 flag_info ，表示如下：

'重复的txn_id。 （5M907276M1007902B）'

Paypal业务帐户报告IPN已重试1次。

我发现在将接收机功能连接到我尚未尝试的信号时，提及使用 dispatch_uid 的可能解决方案。我的问题是，我已经查看了相关的django-paypal源代码，我不明白为什么当第一个回发验证时，PayPal将重试IPN。

有没有人反对，找到一个他们明白的解决方案？

---

更新：

我发现我的接收器功能代码有一个错误，例外。现在我已经解决了这个问题，贝宝不再重试IPN了。我很高兴这个问题已经消失，但我仍然无法弄清楚为什么会发生这种情况。

以下是最新的重复记录摘录数据库。请注意，第一行在随后的至少10秒之前创建和更新。

  created_at updated_at响应标志
 2013-02-03 07：53：56.628013 + 00 2013-02-03 07：53：56.628057 + 00 VERIFIED FALSE 
 2013-02-03 07：54：07.393795 + 00 2013-02-03 07:54 ：07.403008 + 00 VERIFIED TRUE 
  

解决方案

出。简单的答案是确保您的接收器功能正常工作。

当PayPal向您指定的URL发送IPN时，他们期待使用HTTP状态代码如果响应代码是其他的，他们将重试。即使您处理回调并获得VERIFIED消息，来自Paypal的IPN需要200 OK。

我查看了我的Apache访问日志，并发现当我的收件人功能中有 payment_was_successful 信号发生错误时，来自paypal的初始IPN收到HTTP状态代码500.

django-paypal包只有在处理了所有其他内容后才包含 HttpResponse（OKAY），包括返回已验证的Paypal的回发， PayPalIPN 对象保存到数据库，并发送信号。当我的信号接收器功能发生错误，并且提出了一个未处理的异常时，Django正在响应HTTP状态代码500。

当Paypal重试IPN时， paypal包检测到一个重复的txn_id并发送 payment_was_flagged 信号。我的这个信号的接收器功能是无误的，所以Paypal收到HTTP状态代码200，它期望并停止重试。

希望这将有助于其他人在未来。

I have been attempting to get the django-paypal app working within my Django project. I'm using the dcramer fork, with Django 1.4. I am also using a Paypal developer account with business and personal accounts, processing transactions through the Paypal sandbox website.

If I have no receiver function connected to the payment_was_successful signal, things seem to work as expected. After a transaction has occured, a new row is created in the paypal_ipn table of the database which has a value of 'VERIFIED' in the response column. The Paypal IPN log reports that there were no retries for this transaction.

When I do have a receiver function connected to the payment_was_successful signal, the paypal_ipn table includes two new rows with created_at timestamps 10-15 seconds apart. They both have a value of 'VERIFIED' in the response column, but the latter of the two is flagged with flag_info indicating something like:

'Duplicate txn_id. (5M907276M1007902B)'

The Paypal business account reports that the IPN was retried 1 time.

I have found possible solutions that mention the use of dispatch_uid when connecting a receiver function to the signal which I am yet to try. My issue is that I have looked through the relevant django-paypal source code and I can't understand why Paypal would retry the IPN when the postback on the first one was verified.

Has anybody else come up against this and found a solution that they understand?

---

Update:

I have discovered that there was an error in my receiver function code, which would have been raising an exception. Now that I have fixed this, Paypal is no longer retrying the IPN. I'm glad that the problem has gone away, but I still can't figure out why it was happening.

Below is an excerpt of the most recent duplicate records in the database. Note that the first row was created and updated at least 10 seconds before the subsequent one.

created_at                       updated_at                       response    flag
2013-02-03 07:53:56.628013+00    2013-02-03 07:53:56.628057+00    VERIFIED    FALSE
2013-02-03 07:54:07.393795+00    2013-02-03 07:54:07.403008+00    VERIFIED    TRUE

解决方案

I have figured this one out. The short answer is to make sure your receiver functions are working correctly.

When Paypal sends an IPN to the URL you have specified, they are expecting a response with HTTP status code 200. If the response code is anything else, they will retry. Even if you process a callback and get a VERIFIED message, the IPN from Paypal needs a response of 200 OK.

I had a look through my Apache access logs and discovered that when I had errors in my receiver function for the payment_was_successful signal, the initial IPN from paypal received a HTTP status code 500.

The django-paypal package responds with HttpResponse("OKAY") only after everything else has been processed, including the postback to Paypal which was returning "VERIFIED", the PayPalIPN object being saved to the database, and the sending of signals. When things went wrong in my signal receiver function and an unhandled exception was raised, Django was responding with a HTTP status code 500.

When Paypal retried the IPN, the django-paypal package was detecting a duplicate txn_id and sending the payment_was_flagged signal. My receiver function for this signal was error free, so Paypal received the HTTP status code 200 it was expecting and stopped retrying.

Hopefully this helps someone else out there in the future.

这篇关于为什么PayPal在使用django-paypal时重试IPN的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！