現在問題が発生しています
サードパーティの支払いに接続するための電子商取引プラットフォームを開発します。支払いが完了すると、支払い成功ページに移動します。 。すると、データベース内の値が増加します。問題は、支払い成功ページを更新し続けるかどうかです。 。私のデータベース内の値は常に増加しています。実装できる簡単なアイデアはありますか? 支払いが行われた後、テーブルは更新され、その後のデータベースは更新されないというテーブルを設計できるという人もいます。実行されました。これは絶対にうまくいきません。 。仕事量が多すぎる。
$_SERVER['HTTP_REFERER'] を通じてソースを特定する方法を考えました。この Web サイトの場合、データベース ステートメントは実行されません。そうでない場合は、実行されます。
しかし、効果はあまり良くありません。
COOKIE を使用して実現できるという人もいます。これはどのように実現されますか?サードパーティのWebサイトから飛んできたパラメータ値なので、決済が成功したページにしか保存できません。そしてそれを判断材料に使うのか?前後の値が同じではないですか?データベースは引き続き実行されますか?
送信時に ?????? を追加し、送信後に ??? をリセットしてください。その後、再提出することはできません。
送信時に ?????? を追加し、送信後に ??? をリセットするだけです。その後、再提出することはできません。
記録を表に書き込んで繰り返し提出して判定するか、セッション記録でマークが変わったら提出が完了したことを意味します。
支払い成功ページに論理演算を埋め込むのはなぜですか?論理操作を支払いインターフェイス データに書き込み、同期されたファイルを返して操作を実行できます。
各注文には注文番号がありませんか?
支払いステータス (ステータスなど) が格納されるフィールドは、支払いが行われていない場合は 0、支払いが成功すると 1 に設定されます。再度更新され、注文ステータスが 1 になった場合は、支払いが成功したことを通知するだけで、その後のデータは挿入しないでください
あなたのフレームワークが何であるかわかりません。
ビジネスロジック層がある場合は、決済ビジネスロジックを先に実行します。実行後、結果画面を直接表示するのではなく、表示ビジネスロジックを実行します。そのロジックで結果画面を表示します。これにより、更新時に表示に使用するビジネスロジックのみが更新されます。重複して提出することはありません。
より安全な方法もあります。送信されたページでは、固有のコードが生成され、セッションに配置され、さらに画面の非表示のコントロールにも配置されます。送信時に、セッション内の固有のコードと非表示のコントロールが一致しているかどうかが判断され、一致している場合は一致します。 、送信操作が実行されます。操作が完了したら、セッション内の固有のコードを削除します。このようにすると、セッションが削除され比較に一貫性がないため、更新時にページを再度更新しないように求めるメッセージが表示されます。