カード決済
カード決済：端末からアクワイアラーへ、そして台帳へ戻る
EMV端末と決済ゲートウェイをISO 8583またはAPIでアクワイアラーに接続し、精算ファイルをERPで照合します。
ブループリント
横にスクロールすると図全体を確認できます。
カード決済：レジでオーソリ、後日精算、ERPで照合
端末またはオンラインレジがゲートウェイに問い合わせ、ゲートウェイがアクワイアラに、アクワイアラがカードスキームと発行会社に振り分けます。精算ファイルは後から届き、ERPで売上と手数料に照合されます。タイムアウト時は自動で取り消し、顧客が二重に請求されないようにします。
- 主要フロー
- 非同期
- 例外経路
8ステップのフロー
フローを順に示す
- EMV端末またはオンラインレジから決済ゲートウェイへ：オーソリゼーション要求、EMV · REST/JSON経由（主要フロー）。
- 決済ゲートウェイからアクワイアラへ：オーソリゼーション、ISO 8583経由（主要フロー）。
- アクワイアラからカードスキームと発行会社へ：発行会社へルーティング、ISO 8583経由（主要フロー）。
- アクワイアラから決済ゲートウェイへ：承認または否認、ISO 8583経由（非同期）。
- アクワイアラから連携レイヤーへ：精算・手数料ファイル、SFTP経由（非同期）。
- 連携レイヤーからERPへ：精算済みの売上、手数料、入金、REST/JSON経由（主要フロー）。
- 決済ゲートウェイからEMV端末またはオンラインレジへ：時間内に応答なし：自動取り消し、ISO 8583 0400経由（例外経路）。
- 連携レイヤーから決済運用チームへ：精算の不一致またはチャージバック（例外経路）。
概要
これはカード決済の経路です。端末やオンラインのチェックアウトから、アクワイアラー、カードブランド、イシュアーへと進み、戻ってきます。顧客はレジで結果を待ちます。手数料を差し引いた資金は後日、精算ファイルとして届き、ERPの売上と突合する必要があります。
参照設計では、オーソリゼーションを決済ゲートウェイ経由で送ります。ゲートウェイはカードをトークン化し、ISO 8583またはアクワイアラーのAPIで要求をアクワイアラーへ転送します。精算・手数料ファイルは統合レイヤーが収集し、元の売上と突合して、売上、手数料、支払としてERPへ転記します。
設計はうまくいかない場合も扱います。時間内に応答がない要求は取り消し、顧客が二重に請求されないようにします。一致しない精算やチャージバックは、元の売上を添えて決済運用チームへ送ります。
フローの仕組み
端末またはチェックアウトから開始
EMV端末がチップまたは非接触カードを読み取るか、オンラインのチェックアウトがホスト型ページでカード情報を収集し、オーソリゼーション要求をゲートウェイへ送ります。
ゲートウェイでのオーソリ
ゲートウェイはカード番号をトークンに置き換え、ISO 8583またはアクワイアラーのAPIでオーソリゼーションをアクワイアラーへ送ります。
イシュアーへの転送
アクワイアラーはカードブランドを通じて要求をイシュアーへ転送し、イシュアーが承認または拒否します。
結果の返却
承認または拒否は、応答コードとともに同じ経路で端末やチェックアウトへ戻ります。
精算の受信
後日、アクワイアラーが精算・手数料ファイルを送り、統合レイヤーが収集して検証します。
突合と転記
レイヤーは精算済み取引を元の売上と突合し、売上、手数料、支払をERPへ転記します。
障害が起きたとき
時間内に応答なし
アクワイアラーの制限時間内に応答がない場合、ゲートウェイは取り消し要求（ISO 8583の0400メッセージまたはAPIの相当機能）を送り、完了しなかった売上で顧客が請求されることはありません。
支払いが拒否された場合
応答コードが明確なメッセージとともにレジやチェックアウトへ届きます。拒否率を監視し、技術的な障害を示す急増があればアラートを発します。
精算が一致しない場合
売上と異なる精算額、または精算のない売上は、両方の記録を並べて決済運用チームの確認リストへ送ります。
カード会員が支払いに異議を申し立てた場合
アクワイアラーの異議申立レポートを取り込み、元の売上と精算に結び付けるため、お客様のチームは証拠を一か所で揃えて回答できます。
標準とシステム
- 銀行の標準とチャネル
- SFTP (H2H)
- 決済
- ISO 8583
- EMV
- EMV 3-D Secure
- PCI DSS
- 連携
- REST
- Webhooks
よくある質問
ゲートウェイとアクワイアラーはどう違いますか。
アクワイアラーは、お客様のためにカード決済を処理し資金を支払う銀行または認可機関です。ゲートウェイはその手前にある技術サービスで、端末やチェックアウトからの要求を受け、カードをトークン化して転送します。両方を兼ねる事業者もあります。設計はどちらでも機能し、2つの役割を明確に保ちます。
これでカードデータを当社のシステムから排除できますか。
それが設計の狙いです。カード番号は認定端末またはホスト型決済ページで取得し、ゲートウェイでトークンに置き換えるため、POS、ERP、データストアにはトークンしか残りません。これによりPCI DSSが適用される範囲を縮小できます。最終的な範囲はお客様の評価機関が確認します。
ISO 8583はどのアクワイアラーでも同じですか。
いいえ。ISO 8583は構造を定めるもので、フィールド、メッセージ種別、コードの仕様は各アクワイアラーやネットワークが独自に公開します。そのため当社はアクワイアラーの仕様に基づいて構築し、その認定試験を実行します。アクワイアラーの手前に置くゲートウェイAPIがこうした違いを吸収し、小売業者にとっては多くの場合より簡素です。
精算が売上より遅れて届くのはなぜですか。
オーソリゼーションは資金を確保するだけです。アクワイアラーは手数料とブランド料を差し引いたうえでバッチ単位で精算し、独自のスケジュールで支払います。そのため設計ではオーソリゼーションと精算を別のイベントとして扱い、突合することで、何が売れ、何が精算され、何が未着かを財務が把握できます。
オンライン決済のEMV 3-D Secureに対応していますか。
はい。オンラインのカード決済では、規制やリスク上必要な場合にイシュアーがカード会員を認証できるよう、EMV 3-D Secureをゲートウェイ経由で組み込みます。チェックアウトでチャレンジ方式とフリクションレス方式の両方を実装し、事業者のテストカードで双方を試験します。
複数の決済事業者を使えますか。
はい。統合レイヤーが決済の内部モデルを1つ保ち、各事業者へマッピングするため、チャネル、国、カード種別で振り分けたり、事業者間で取扱量を移したりできます。各事業者には個別の連携と認定が必要で、事業者ごとに計画します。
契約ではなく、対話から始めましょう
構築、接続、保護のどれが必要かを教えてください。アーキテクトが内容を一緒に整理し、どこから始めるべきかを提案します。
今後の流れ
日程の調整
セッションの日程を調整するため、当社チームからメールをお送りします。
事前コンサルティングセッション
無料の30分オンライン事前相談です。目標、システム、制約を伺います。
準備状況レビュー
無料の48時間準備状況レビューで、プリンシパルアーキテクトがプロジェクトを6項目のDefinition of Readyに照らして確認し、適切なトラックを提案します。
トラックの選択
スコープが確定したプロジェクトには、拘束力のある提案書を3–5営業日以内にお渡しします。構想段階のプロジェクトはBlueprint Studioから始まります。稼働中のシステムに障害がある場合、文書化されていない場合、連携が必要な場合は、1–2週間の診断から始まります。Blueprint Studioと診断はそれぞれ固定料金で、提案書に記載します。