- インテグレーションガイドライン
- <<directPayment>> のインテグレーションの実装
<<directPayment>> のインテグレーションの実装
前提条件
- 加盟店プロファイルが <<webServicesIntegration>>で有効であることを確認する。
- 必要に応じて、<<directPayment>>ソリューションをカスタマイズする方法を確認する。
- インテグレーションを開始する前に、「ベストプラクティスとヒント」を確認する。
インテグレーションの手順
手順 1: ゲートウェイへのアクセス
最初の手順として、QNB ALAHLIへの接続を確認します。
手順 2: 入力フィールドを確認する
インテグレーションを構築する前に、入力が必要なフィールドの値を準備しておく必要があります。
手順 3: 取引要求の作成
要求の本文の作成は、インテグレーションにとって重要な手順です。
手順 4: 取引要求の送信
取引要求をQNB ALAHLIに確実に安全に送信するための多数のコンポーネントがあります。
手順 5: 取引応答の処理
取引要求がゲートウェイに送信されると、通常は、非常に短い間隔で応答を受信します。取引を完了するにはこれを処理する必要があります。
手順 6: テストと実際の取引処理の開始
テストによって、インテグレーションが想定どおりに動作するかどうかを確認できます。
トラブルシューティングと FAQ
API リファレンスインデックスページの「プロトコル文書」セクションにある該当する(REST/NVP) [すべてのバージョン] リンクに移動します。
はい、すべての操作で API のフィールド名は大文字と小文字が区別されます。
HTTP POST を使用する場合、JSON エンコーディングを使用して HTTP 本文に要求パラメータを格納します。HTTP GET を使用する場合、要求パラメータがクエリパラメータとして URI に格納されるようにします。
加盟店が定義したフィールドはこのバージョンの QNB ALAHLI<<webServicesIntegration>> ではサポートされていません。
再送信された同一の取引は、最初の取引と同じ応答が返されます。このバージョンの QNB ALAHLI<<webServicesIntegration>> でのすべての操作はべき等です。つまり、繰り返された同一の要求の影響は、1 つの要求の影響と同じです。したがって、取引はお客様自身の銀行または支払人の銀行との間で繰り返し処理されません。
<<webServicesIntegration>> v15 以降、注文の初回取引が失敗した場合、新しい注文を作成しなくてもこの注文に対して(新しい取引 ID を使用して)新しい初回取引を送信できるようになりました。
<<webServicesIntegration>> v15 以降、正常に実行された初回取引に対して後続の Capture 取引または Refund 取引を実行する場合、要求でカードの詳細を提供できなくなりました。注文に正常に実行された初回取引が既に存在する場合にカードの詳細を提供した場合、QNB ALAHLI は要求を拒否します。
応答を受信しなかった場合、60 秒間待ってから、同一の要求を再送信することをお勧めします。銀行との取引は繰り返されないので、資金が重複して振り替えられることはありません。最初の要求に対して受信する予定であった応答と同じ応答を受信します。
すべての承認された取引は、QNB ALAHLIからの取引応答コード APPROVED
で表されます。他のすべてのコードは、取引の拒否または失敗を表します。
QNB ALAHLI のすべての操作はべき等なので(N > 0 件の同一の要求の副次的影響は、1 つの要求に対するものと同じ)、再送信された同一の取引では、最初の取引と同じ応答が返されます。したがって、取引はお客様自身の銀行または支払人の銀行との間で繰り返し処理されません。
ベストプラクティスとヒント
QNB ALAHLIに接続する場合には、必ずQNB ALAHLIの SSL 電子証明書を検証することを強くお勧めします。QNB ALAHLIの SSL 電子証明書は、Web 環境でルート電子証明書がすでに使用できる必要がある Verisign や Thawte などの業界標準の認証局によって発行されています。