ビジネスに最適な支払ソリューションを選択するか、支払ソリューションを組み合わせます。
<<checkout>>
<<checkout>> モデルでは、QNB ALAHLI によってホストされ、表示されるインタラクションを経由して支払者から支払詳細を収集できます。このインテグレーションのモデルでは、支払詳細がホスト型支払インターフェイスで収集され、支払者のブラウザから QNB ALAHLI に直接送信されるので、支払詳細を直接確認したり処理することはありません。
<<checkout>> は次のいずれかの方法で実装できます。
- 組み込まれたページ - 既存の加盟店サイト内に埋め込むコンポーネント。
- <<hostedPaymentPage>> - QNB ALAHLI によってホストされ、表示される Web ページ。
- <<checkout>> は、簡単にすばやく統合できます。
- 支払詳細を処理または保存する必要がないため、PCI コンプライアンス費用を削減できます。
- your payment service provider によって提供されるテーマを使用して、<<checkout>> インターフェイスを表示できます。これにより、your payment service provider のブランドを活用できるようになります。有力なブランドにより、支払者は支払詳細を提供することに抵抗が少なくなります。
- <<checkout>> インターフェイスの内容をカスタマイズして、ビジネスの情報を表示できます。
- 通知を契約している場合、支払いが正常に行われた場合に通知を受信することを選択できます。
- <<checkout>> は WCAG (Web Content Accessibility Guidelines) 2.0 Level AA に準拠しています。
<<checkout>> モデルの支払フローは次のようになります。
- 支払者は、ショッピングサイトで商品とサービスの支払プロセスを開始します。それに対して、アプリケーションは、JavaScript リクエストと必要なデータをQNB ALAHLIに送信し、選択された支払インターフェイスとして以下を表示します。組み込まれたページまたは <<hostedPaymentPage>>。
- 支払者に支払インターフェイスが表示されます。支払インターフェイスに表示される内容 (ビジネス情報、注文の詳細など) とその他の項目は、リクエストのデータによって制御されます。
支払者は、必要な情報を入力し、[支払い] をクリックします。
QNB ALAHLI は支払詳細を収集して検証し、支払いを処理します。
- PayPal、BancaNet、またはデジタルウォレットサービスなど、ブラウザ経由の支払サービスに合わせて設定されている場合、これらのサービスが他のカードオプションとともに支払方法として表示されます。支払者がこれらのサービスのいずれかを使用して支払うことを選択した場合、支払者は、支払詳細を選択するために決済代行会社の Web サイトにリダイレクトされます。
- 3D セキュアサービスに合わせて設定されている場合、デフォルトでは、支払者は支払いを処理する前に認証を行うようにリクエストされます。認証をバイパスすることを選択できます。「セキュリティ機能のバイパス」を参照してください。
- 支払いが正常に行われた場合、支払者は、次のいずれかのソースから支払詳細を取得できます。
- QNB ALAHLIによるホスト型受領 (組み込まれたページまたはホスト型ページ内)。これがデフォルトの動作です。
- ショッピングサイト。
- 電子メール通知。これを実装するには支払者通知を契約する必要があります。
支払いが正常に行われなかった場合、<<checkout>>は結果を表示し、支払者が別の支払詳細を使用して取引をやり直すことができるようにします。
Hosted Session
支払画面のレイアウトとスタイルを管理し、PCI コンプライアンスの費用を削減する場合は、Hosted Session モデルを選択します。Hosted Session JavaScript クライアントライブラリを利用すると、QNB ALAHLI から送信および制御される支払フォームフィールドを使用して、支払者から機密認証データを含む支払詳細が収集できます。ゲートウェイは支払セッション中に支払詳細を収集し、後で使用するためにその詳細を一時的に保存します。支払詳細の代わりに支払セッションを取引リクエストに格納して、支払いを処理できます。
- Hosted Session は、簡単にすばやく統合できます。
- 機密認証データを含む支払詳細を収集、保存、または処理する必要がないため、PCI コンプライアンス費用を削減できます。
- 支払画面のスタイルとレイアウトを管理できます。
- 支払者の操作をビジネスに適した操作にカスタマイズできます。
Hosted Session モデルの支払フローは次のようになります。
- 支払者は、ショッピングサイトで商品とサービスの支払プロセスを開始します。
- 支払者は、クレジット/デビットカード、デジタルウォレット、ギフトカード、または <<ach>> 支払いから選択して、支払詳細を提供できます。
- 支払画面: QNB ALAHLIによりホストされる iFrame が組み込まれたフォームフィールドで支払詳細が収集されます。
- デジタルウォレット: カードの詳細情報はウォレットインタラクションで安全に収集され、QNB ALAHLIに送信されます。
- QNB ALAHLI は支払セッションで支払詳細を収集します。この支払セッションはセッションを参照するすべての操作で使用できます。
<<directPayment>>
取引の完全な制御、独自の支払画面の管理、または支払詳細の収集が必要な場合、<<directPayment>> モデルを使用する必要があります。支払詳細は、取引を処理するために QNB ALAHLI に直接送信されます。この加盟店管理型モデルでは、アプリケーションで支払者の支払詳細を収集するときにセキュリティを管理する必要があるため、PCI コンプライアンス費用が増加します。
- 支払操作全体を完全に制御できます。支払ソリューションをカスタマイズする柔軟性があります。
- 任意のアプリケーション、Web サイト、コールセンター、Interactive Voice Response (IVR) と統合できます。
- QNB ALAHLI と直接通信して、API コールに対するリアルタイムのレスポンスを受信できます。これは、同期接続で、支払者はアプリケーションを離れません。つまり、支払者とのセッションは切断されません。
- 支払者が直接関与しない決済請求、返金、取消、クエリなどの高度な QNB ALAHLI 操作をサポートしています。
<<directPayment>> の情報フローは次のようになります。
- 支払者が購入を決定し、カードの詳細をアプリケーションまたは Web サイトに直接提供します。収集したカードの詳細と以前に保存されたトークンに保存されている詳細を組み合わせることを選択できます。「カードの詳細情報の複数のソース」を参照してください。
- アプリケーションまたは Web サイトが取引リクエストを作成し、インターネットで HTTPS POST または PUT を使用して <<webServicesIntegration>> を経由して QNB ALAHLI にそのリクエストを送信します。
ビジネス上の必要性に応じて、取引リクエストで追加のフィールドを渡すことができます。「追加機能」を参照してください。
支払取引を実行する前に、ダイナミックカレンシーコンバージョン (DCC)の換算レートリクエストを送信して、支払者の通貨とその通貨での注文金額を取得できます。
この段階で、EMV 3D セキュア認証を使用して支払者を認証することもできます。.支払者が DCC オファーを承諾した場合、認証リクエストで DCC 情報を提供する必要があります。 - QNB ALAHLI が取引を処理のためにアクワイアラー銀行に渡します。
- アクワイアラーはレスポンスを返し、QNB ALAHLI は取引レスポンスを生成し、API コールに対するレスポンスでその取引レスポンスをアプリケーションまたは Web サイトに渡します。取引レスポンスでは、取引が正常に実行されたかどうかが示され、その他のレスポンスデータも格納されます。
- アプリケーションまたは Web サイトは、取引の結果に基づいて受領またはその他の確認、またはエラーページを表示します。
<<batchIntegration>>
<<batchIntegration>>では、支払者による直接のインタラクションなしで操作のバッチ(Capture、Refundなど)を処理のためにQNB ALAHLIに安全かつ確実に送信できます。たとえば、オンライン買い物かごを使用して承認をトリガーしてから、<<batchIntegration>>を使用して決済請求を実行できます。
送信されると、バッチステータスを定期的にリクエストし、アップロード済み/処理済み/エラーの操作の総数および処理アクションの日時スタンプを含むバッチ処理の現在のステータスを確認できます。同じバッチステータスは、Merchant Manager の [<<batchIntegration>>ステータスの検索] 画面経由で your payment service provider でも表示できます。
バッチの処理が完了すると、アップロードした各操作の結果が含まれているレスポンスファイルをリクエストできます。
- 複数の操作を安全かつ効率的に処理。各操作を個別に処理するのではなく、バッチを送信することで複数の操作を安全に処理できます。
- ローカルアプリケーションのインストールが不要。システムにアプリケーションをインストールする必要がありません。これにより、アプリケーションの導入、更新、および管理に必要な費用がなくなります。
- PA-DSS 準拠義務なし。サードパーティへの支払アプリケーションのプロバイダは、Payment Application Data Security Standard (PA-DSS) の要件に準拠する必要があります。システムにアプリケーションをインストールする必要がなくなることで、PA-DSS 準拠義務を満たすために必要な費用がなくなります。
- 小規模および大規模両方の加盟店をサポート。機能では、(主に、使いやすく、インテグレーションが必要ないソリューションを求めている) 小規模加盟店と (大量の取引を効率的に処理することを望んでいる) 大規模加盟店の両方のニーズに対応しています。
- <<tokenization>> と併用すると PCI コンプライアンス費用を削減。<<tokenization>> と併用すると、<<tokenization>> と <<batchIntegration>> の処理の利点を組み合わせることができます。
<<batchIntegration>> の情報フローは次のようになります。
- インテグレーションは、支払者の操作を 1 つのバッチにまとめ、インターネットで HTTPS PUT を使用して QNB ALAHLI<<batchIntegration>> サービスを経由してQNB ALAHLI に操作のバッチをアップロードします。「バッチリクエストの作成」を参照してください。
収集したカードの詳細と以前に保存されたトークンに保存されている詳細を組み合わせることを選択できます。「カードの詳細情報の複数のソース」を参照してください。ビジネス上の必要性に応じて、バッチリクエストで追加のフィールドを渡すこともできます。「サポートされている機能」を参照してください。
- バッチが処理される前に、バッチの内容の SHA-1 ダイジェストで構成されるメッセージ完全性コード (MIC) を送信して、欠けているまたは破損している記録が検出されるようにすることで、バッチの内容を検証する必要があります。「バッチリクエストの送信」を参照してください。
- 検証されたら、バッチの各操作が処理されます。
- 処理中、バッチのステータスをポーリングして、処理された記録の数と全体のステータスを確認できます。「バッチステータスの取得」を参照してください。
- ステータスでバッチ処理が完了したことが示されたら、バッチレスポンスをリクエストできます。バッチレスポンスには、元のアップロードされたバッチヘッダーで指定されたとおりのレスポンス値が含まれています。「バッチレスポンスのダウンロード」を参照してください。