1

私は Web アプリケーションを構築しており、cardave の直接支払い API をアプリケーションに統合したいと考えています。これを行うための最良の方法について誰かがアドバイスを持っているかどうか疑問に思っていました。

Cardsave は統合用の標準コードを提供します: Gateway Integration Pack の ZIP ファイルをダウンロードします。

支払いが行われると、CrossPaymentsReference と支払い額をデータベースに保存する必要があり、残りは cardave の API に任せます。

1) すべてのコードと支払いの成功に対してビューを使用し、Ajax を使用して crossPaymentReference と成功した支払い金額でデータベースを更新します。これは、コードの編集が最小限で済むためですが、クライアント側で参照します。

2) 支払いシステム クラスを使用してライブラリを作成し、前処理の支払いとプロセスの支払いコードをコントローラーに配置し、フォームをビューにコピーします。成功した支払いでデータベースを更新するための小さなモデルがあります。(私はこれが最善の方法だと思います。)

3) すべてを編集し、MVC バージョンのコードをビルドする

4

1 に答える 1

4

私の最新のプロジェクトは CI 2.0 で実行されます。Card Save などの支払いシステムをうまく統合しました (私の場合、ベルギーの会社である Ogone を使用しています)。

以下に、注文と支払いのシステムをどのように実装したかを少し詳しく説明します。

私があなたにできるアドバイスは次のとおりです。

  • 商品、注文、支払いを別々のテーブルに保管してください。参照テーブルを介して製品を注文にリンクします (たとえば、注文のフィールドに製品 ID のリストを保存しないでください)。
  • 支払いには 1 つの注文のみを含めることができますが、注文には複数の支払いを含めることができます (ただし、支払われたのは 1 つだけです)。このようにして、支払いが失敗した場合 (たとえば、ユーザーが Card Saves 支払いページでキャンセルを押した場合)、新しい支払いを作成し、ユーザーに再試行させることができます (Card Save が同じ支払い ID で 2 つの支払い要求を受け入れる場合を除きます)。 ）。
  • 正常に支払われた注文を処理する別のライブラリ (コントローラーではない) を作成します。このライブラリは、たとえば、ユーザーが購入したサブスクリプションを有効にしたり、誰かに製品を出荷するための作業注文を作成したりします。それを別のライブラリに保持することで、支払いロジックに触れることなく機能を拡張できます (たとえば、特定の製品のために何か新しいことを行う必要がある場合) (したがって、重い再テストを防ぐことができます)。
  • データを投稿するとき、またはユーザーをチェックアウト ページ、支払いを準備するページにリダイレクトするときにハッシュを生成し、投稿したデータまたは URL にあるデータが改ざんされるのを防ぐために毎回ハッシュを再計算します。
  • すべてが AJAX なしで機能することを確認し、後で AJAX を追加します。

基本的に私が思いついた注文プロセスは次のように分けられます。

  1. ユーザーがサービス (私は物理的な製品を販売していません) をバスケットに追加します (CI のショッピング カートの修正版を使用)
  2. 完了したら、ユーザーが [製品の注文] をクリックすると、コントローラ Place_order に POST が実行されます。コントローラー Place_order は次のことを行います。
    • ユーザーがまだログインしているかどうかを確認します（私の場合、全員が事前に登録する必要があります）
    • ショッピング カートにある製品を取得し、それらが実際にデータベースに存在するかどうかを確認します (決してわかりません)。
    • データベースに新しい注文を作成し、製品を DB の注文に追加します
  3. Place_order は何も出力しませんが、成功するとユーザーをコントローラーのチェックアウトにリダイレクトします。ここでは POST を使用しません。このようにして、URL を再利用できます (たとえば、ユーザーが停止することを決定した場合、後で支払いを続行できます)。URL には注文 ID とハッシュが含まれています。
  4. チェックアウト コントローラーは次のことを行います。
    • ハッシュを再計算して、誰も URL を改ざんしていないかどうかを確認します
    • 注文が存在し、まだ支払われていないかどうかを確認する
    • 注文がログインしているユーザーのものかどうかを確認します
    • 支払いがまだ存在しない場合は作成します
    • 「注文のキャンセル」と「注文の支払い」ボタンのあるビューを表示します。これは実際には非表示フィールドに支払い ID と支払い ID のハッシュを含むフォームです。
  5. 「Pay order」をクリックすると、コントローラ Pay_order に対して POST が実行されます。Checkout コントローラーによって設定されたデータを投稿することによってのみユーザーがこのページにアクセスできるようにするため、GET は使用しません。GET を使用してページにアクセスすると、エラーがスローされます。このコントローラーは次のことを行います。
    • ハッシュを再計算して、投稿されたデータが改ざんされていないことを確認します
    • 支払いが存在し、まだ支払われていないかどうかを確認します
    • 問題がなければ、支払いサービスに投稿するために必要な情報を含むビューを作成します
    • ビューを表示します。
    • ユーザーが「Go to payment service」を押すと、すべてのデータがユーザーが支払いを実行する Ogone に投稿されます
  6. 支払いが完了すると (正しいかどうかに関係なく)、Ogone はユーザーをコントローラー Payment_successfull または Payment_other (エラーなどの場合) にリダイレクトします。Payment_succesfull では、支払い ID を入力として受け取るライブラリ Purchase_activator を呼び出します。これは注文を検索し、ユーザーが支払ったばかりのサービスを有効にします。それ以外の場合 (エラー時) には、正しいエラー メッセージと再試行またはキャンセルのオプションを含むビューがユーザーに表示されます。
于 2012-10-05T13:49:51.237 に答える