3

Django プロジェクト内で django-paypal アプリを動作させようとしています。Django 1.4 でdcramer forkを使用しています。また、Paypal サンドボックス Web サイトを介してトランザクションを処理し、ビジネス アカウントと個人アカウントで Paypal 開発者アカウントを使用しています。

信号に受信機機能が接続されていない場合payment_was_successful、物事は期待どおりに機能するようです。トランザクションが発生した後、列paypal_ipnに「VERIFIED」の値を持つデータベースのテーブルに新しい行が作成されresponseます。Paypal IPN ログは、このトランザクションの再試行がなかったことを報告しています。

payment_was_successful信号に受信機能を接続すると、テーブルにはタイムスタンプが 10 ～ 15 秒離れたpaypal_ipn2 つの新しい行が含まれます。created_atどちらも応答列に「VERIFIED」の値がありますが、後者には次のflag_infoようなフラグが付けられます。

'txn_id が重複しています。(5M907276M1007902B)」

Paypal ビジネス アカウントは、IPN が 1 回再試行されたと報告しています。

dispatch_uidまだ試していない信号にレシーバー機能を接続するときの使用について言及している可能な解決策を見つけました。私の問題は、関連する django-paypal ソース コードを調べたところ、最初のポストバックが確認されたときに Paypal が IPN を再試行する理由を理解できないことです。

他の誰かがこれに立ち向かい、彼らが理解できる解決策を見つけましたか?

アップデート：

レシーバー関数コードにエラーがあり、例外が発生していたことがわかりました。これを修正したので、Paypal は IPN を再試行しなくなりました。問題が解決したことは喜ばしいことですが、なぜそれが起こったのかはまだわかりません。

以下は、データベース内の最新の重複レコードの抜粋です。最初の行は、後続の行より少なくとも 10 秒前に作成および更新されていることに注意してください。

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
4

1 に答える 1

7

私はこれを理解しました。簡単な答えは、受信機能が正しく機能していることを確認することです。

Paypal は、指定した URL に IPN を送信すると、HTTP ステータス コード 200 の応答を期待しています。応答コードがそれ以外の場合、再試行します。コールバックを処理して VERIFIED メッセージを受け取ったとしても、Paypal からの IPN には 200 OK の応答が必要です。

Apache のアクセス ログを調べたところ、payment_was_successfulシグナルの受信機能にエラーがあったときに、paypal からの最初の IPN が HTTP ステータス コード 500 を受信したことがわかりました。

django-paypal パッケージは、 「VERIFIED」を返す Paypal へのポストバック、データベースに保存されているオブジェクト、シグナルの送信など、HttpResponse("OKAY")他のすべてが処理された後にのみ応答します。PayPalIPNシグナル受信関数で問題が発生し、未処理の例外が発生したとき、Django は HTTP ステータス コード 500 で応答していました。

Paypal が IPN を再試行したとき、django-paypal パッケージは重複した txn_id を検出し、payment_was_flaggedシグナルを送信していました。このシグナルの受信機能にはエラーがなかったため、Paypal は予期していた HTTP ステータス コード 200 を受信し、再試行を停止しました。

うまくいけば、これは将来誰かを助けるでしょう。

于 2013-02-04T11:25:21.757 に答える