5

そのため、セッションに依存してショッピングカートの内容を保存する複数ページのチェックアウトシステムがあります。また、サードパーティのシステムを使用してクレジット カードを処理しています。このシステムは、サーバー上で実際の支払いページをホストしています。最終的な合計をページに投稿するだけです。

私が予見する問題は、誰かがクリックしてホストされた有料ページに移動し、正当または悪意のある理由で別のタブでショッピング カートの内容を変更した場合です。ホストされた支払いページが領収書ページにリダイレクトされたら、注文をデータベースに挿入することを最初に計画していました。ただし、その時点でセッションが変更された場合、注文は請求される合計費用とは異なります。

この問題の解決策は何でしょうか。この種のことはすべてのカート システムで問題になっていることがわかります。

ユーザーがボタンをクリックしてホストされたペイページに移動したときに、データベースの temp_order テーブルに一時的な注文エントリを作成し、支払いが完了したときに、その一時レコードを永続的なレコード テーブルに転送できますか? そうすれば、変更されたセッション情報からレコードを挿入しません。しかし、ホストされた有料ページに POST する必要がある場合、ショッピング カートを一時テーブルに保存する機会はどこにありますか?

また、重複したくないため、一時オーダー ID は一時テーブルと永続テーブルの両方で一意である必要があります。

最後に、一時オーダー テーブルは単なる一時レコードであるため、頻繁にクリアする必要があります。ユーザーがホストされた有料ページで気が変わる可能性があるため、一部は通過しない場合があります.

どうしたらいいのか本当に困っています！

4

3 に答える 3

2

別のテーブルを作成する必要はないと思います。たとえば、既存のテーブルに 1 つの列を追加するだけ payment_in_progressで、クライアントがカートに変更を送信したときにそれを分析できます。

未処理の古い注文を一掃する要件は引き続き適用されます

于 2012-09-28T19:35:19.150 に答える
1

ペイパル エクスプレス チェックアウトなど、注文の最終処理の前に支払いシステムがお客様のウェブサイトに制御を戻さない限り、チェックアウト プロセスを制御し続ける方法はありません。一方通行のチェックアウト システムは、実際には一方通行であることを意図しています。フォローアップ管理は手動 (支払い領収書による) またはサーバー間の通知によって処理されます。

支払いサイトに直接投稿しても、別の Web サイトに送信すると制御できなくなります。おそらく最良のシナリオは、注文をウェブサイトに未払いの注文としてデータベースに送信し、「もうすぐ終了です。支払いを続行してください」というページを提供することです。-- この時点で、顧客のカートを空にして、処理中の注文 (すでに DB にある) を変更できないようにする必要があります。支払いシステムがウェブサイトにリダイレクトされたら、未払いの注文を探して支払い済みとしてマークするだけです。ユーザーが支払額を下げようとして POST データを変更した場合に備えて、支払額を確認することもお勧めします。

EDIT：
チェックアウトプロセスをより詳細に制御できる支払いゲートウェイソリューションが本当に必要な場合があります. あなたの懸念は現実のものですが、最初にトランザクション サーバー側を設定せずに、ユーザーをウェブサイトから直接遠ざける支払いフローを使用して適切に対処することは通常ありません。

于 2012-09-28T19:41:10.253 に答える
1

支払いゲートウェイが戻ってきたら、ショッピングカートに対して受け取った金額を保存し、受け取った金額が合計より少ない場合は、支払いページに戻して、未払いの未払い残高を表示します。

于 2012-09-28T19:43:51.250 に答える