ユーザーがクレジット カードの取引を重複して行わないようにする最善の方法は何ですか? 送信ボタンを何度もクリックしたり、領収書ページから戻って送信ボタンを再度クリックしたりしています。
6 に答える
一意の値を生成し、非表示のフォームに入れることができます。クレジット カードに請求する前に、この一意の値がまだ処理されていないことを確認してください。これは、ボタンを無効にするという CodeToGlory の提案と相まって、両方のユースケースを解決するはずです。
いくつかの方法:
クリック後すぐにボタンを無効にします。
その日の後半に決済から重複を削除するバッチ プロセスを用意して、請求されないようにします。
ある種のモーダル ウィンドウを使用して、クレジット カード トランザクションが処理されるまでユーザーがナビゲートできないようにします。Jqueryには、あなたのために働くことができるblock.UIプラグインがあります。
ほとんどの銀行では、一意の注文IDを提供する必要があるため、同じ注文に対して2回請求する方法はありません。
これで、重複送信の防止を求めている場合、標準的な方法はPost / Redirect/Getパターンです。また、JavaScriptで送信ボタンを非アクティブ化することと組み合わせることができます。
あなたが持っているだろう:
- order_form.aspx、一意の注文IDを生成し、 POSTで送信
- proces_order.aspxが実際の作業を行い、バスケットを空にしてから、
- thankyou.html
これで、ユーザーが[再読み込み]をクリックすると、staticのみが再読み込みされますthankyou.html
。彼がクリックして戻ることを選択した場合は、に戻りますorder_form.aspx
が、彼のバスケットはすでに空です。何らかの形でキャッシュされた場合、同じ注文IDでキャッシュされるため、そこで2回課金されるリスクはありません。
バックエンド システムにある種の同期メカニズムを追加して、任意の時点で 1 つのスレッドのみが基になるデータ ソースへの「課金対象」レコードを処理できるようにします。この同期された領域内で、処理しようとしている請求がデータソースにまだ存在しないことを確認するチェックを追加します。このようなエラーが発生した場合は、何らかの適切なメッセージを顧客に出力するようにしてください - 少なくともバックエンドで致命的になることはありません。
また、CodeToGlory で提案されているように、UI レベルで第 2 層の保護を追加するのにも役立ちます。これにより、これが発生する回数が最小限に抑えられます。
注文したらすぐにバスケットのアイテムを削除し、送信ボタンを無効にします。
この場合、ユーザーが戻ってきても、カゴに何も入っていないため、リフレッシュなどで 2 回購入することはできません。