1

Authorize.net支払いゲートウェイとして使用している e コマース サイトがあります。

最近、支払い確認を送信し、後でもう一度送信をクリックするという問題に遭遇しました。これにより、商品が二重になったり、支払いが二重になったりします。

考慮すべき事項:

  • 支払い確認ページは、ユーザーが支払いを送信する前に読み込まれる PRG (Post-Redirect-Get) の結果です。
  • リクエストの各部分に実際に作用する機能が用意されています (これについては以下の説明を参照してください)。
  • この状況は、Authorize.net トランザクションに通常よりも時間がかかる場合にのみ適用されます。
  • これはまだ本番環境ではありません。この動作を防ぐために、この新しい機能をテストする方法を探しているだけです。

防止ピース

次のプロセスに従う複数ステップのチェックアウト フォームがあります。

  • 製品の選択
  • 支払入力
  • 注文の確認/支払いの送信
  • レシート

プロセスの各ステップでは、サービスへの呼び出しが実行され、ユーザーが現在の「注文」を持っているかどうかがチェックされstartedます。processingcomplete

注文が の場合started、チェックアウト フローの最初のページにリダイレクトされます。注文が の場合、processing2 秒ごとに ajax リクエストを実行して注文のステータスを確認するプレースホルダー ページにリダイレクトします。注文が完了すると、receiptページにリダイレクトされます。注文が の場合、すぐにページにcompleteリダイレクトされます。receipt

問題

この機能は実際には処理トランザクションに時間がかかる場合にのみ有効であるため、いくつかの理由でテストに問題が発生します。

  1. Authorize.net私たちの開発サーバーは遅く、ページがアプリケーションによってレンダリングされる前に、リクエストに応答する可能性が高くなります。
  2. PHP 関数を使用して応答をダミーで作成するsleep()と、スレッドがブロックされて何も実行されなくなり、[1] と同じ状況になります。

私たちが望むこと

Authorize.netいくつかのパラメーターを介してリクエストへの応答を遅くする方法があるかどうか、またはこれを達成する別の方法があるかどうかはわかりません。あらゆるアイデアを歓迎します！

4

1 に答える 1

1

このため、Authnet に対して直接テストするべきではありません。独自の Authnet "サーバー" を作成し、応答を遅らせます。Authnet ライブラリ用に書いた単体テストのために、テストに必要な適切な応答を返す独自の偽のサーバーを作成しました。同じことを行い、「サーバー」を必要なだけ待機させてから、応答を返すことができます。遅延をテストするために、応答が本物である必要はありません。

于 2013-04-25T17:53:32.613 に答える