3
支払いプロバイダーとの統合。適切で堅牢なOOPアプローチ
歴史 現在、私たちはオンライン支払いにいわゆるリダイレクトモデルを使用しています(支払人を支払いゲートウェイに送信し、そこで彼は支払いの詳細を入力します-ゲートウェイは成功/失敗のコールバックページに戻ります)。これは簡単でわかりやすい方法ですが、残念ながら非常に不便であり、お客様を混乱させることがあります(サイトを離れる、別のサイトに追加ログインしてクレジットカードの詳細を変更するなど)。 意図と問題の説明 現在、XML要求と応答の交換を使用する統合アプローチに切り替える予定です。私の問題は、処理中に発生する可能性のあるすべて(またはほとんど)の要求にどのように対応するかです。通常、単純さは堅牢であり、複雑さは壊れやすいことを念頭に置いてください。 例 ユーザーによる中止:ユーザーはクレジットカードの詳細を入力し、送信を押します。プロバイダーのゲートウェイへのXMLメッセージが送信され、応答を待ちます。ユーザーがブラウザで「停止」を押すか、ウィンドウを閉じます。 PHPのignore_user_abort()はオプションかもしれませんが、それは信頼できますか? ユーザーを「お待ちください」ページにリダイレクトすると、接続に依存しない実際のプロセッサへのAJAXまたはその他の要求が開かれます。 データベースがなくなる 非常に複雑に聞こえますが、たとえば、米国のWebサーバーと英国のDBの場合、これは発生し、また発生します。ユーザーが注文を一緒にクリックすると、支払い要求がプロバイダーに送信されましたが、応答をデータベース。個々のステップに応じて、PHPを使用して「トランザクション」のようなSQLを開始し、最後にのみコミットまたはロールバックするアプローチを使用できますか?その後、コミットもロールバックも発生しなかった場合、ユーザーを「ロック」して、ユーザーが再度支払うことを防いだり、不適切に支払いを説明したりしないようにすることができます。 また、技術的に他に何を検討する必要がありますか?たとえば、Worldpay、Realex、SagePayの統合例では、洞察が得られません。また、私の検索エンジンまたは私の検索用語は、これについて他の誰かの考えを見つけるのに十分ではありませんでした。 これにどのように取り組むかについての洞察をありがとうございました!