eコマースアプリケーションでのバウチャーシステムの設計
現在、当社の電子商取引アプリケーションに実装されるバウチャーシステムを設計しています。
私は現在、データベースに次の情報を含むバウチャーテーブルを持っています：
- 固有のバウチャーコード
- バウチャーの残り数->このバウチャーを購入トランザクションで使用できる回数
- その他の列
現在、お客様は、支払い（クレジットカードとインターネットバンキングを使用）が発生する前に、チェックアウトページでバウチャーコードを入力します。
ホスト型ペイメントゲートウェイを使用しています。つまり、顧客をペイメントゲートウェイのWebサイトにリダイレクトしています。そこで顧客が入力して支払いを完了し、当社のWebサイトにリダイレクトされます
私の質問は、いつバウチャーの残りの数情報をデクリメントする必要があるかについてです。
私は次のように2つの選択肢を検討しました：
- 顧客はバウチャーコードを入力し、バウチャーコードの検証ボタンを押します。バウチャーコードを検証し、割引されたトランザクション金額を取得してから、バウチャーの残りの数を減らすためのajax呼び出しがあります。このソリューションの弱点は、支払いが失敗したり、在庫が突然なくなったりしたときに、バウチャーがすでに使用されているため、顧客が怒るということです。
- お客様がバウチャーコードを入力し、バウチャーコードをプッシュ検証します。バウチャーの使用により、コードと割引された取引金額を検証するためだけにajax呼び出しが行われます。支払いが正常に行われた後、バウチャーの残りの数を減らします。このソリューションの弱点は、支払い後、別の顧客からの別の使用のためにバウチャーの残りの数がすでにゼロになっている場合、間違った取引金額を請求し、損失を被ったことを意味します。
上記の2つよりも優れた代替策はありますか、それとも上記の解決策の1つを選択する必要がありますか？
ムハンマドが提案したように、バウチャーを注文に関連付け、ajaxを使用して空き状況を確認できます。オープンオーダーとペイドオーダーのすべてのバウチャーを数えます。キャンセルされた注文のバウチャーはカウントしないでください。この方法では、誰かがバウチャーを使用できない可能性がありますが、後で他の誰かが使用できる可能性があります。その最初の誰かがそれについて不満を言うならば、あなたが割引率のために手放すことができる1つの余分な在庫アイテムを持っていることを確認してください、そして誰もが幸せです;）
バウチャーの残りの列を追加する必要はありません。代わりに、許可された最大のバウチャーフィールドのみを使用し、作成されたすべてのバウチャーを別のテーブルに保存します。
利用可能な在庫（バウチャーの最大許容値-バウチャー作成テーブルの合計数）がゼロより大きい場合、お客様は新しいバウチャーの作成を開始できます。