Skip to content
Published on

決済システム入門：フロー・PSP・カードネットワーク・精算

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

はじめに — 決済ボタンの向こう側の世界

ユーザーが「支払う」ボタンを押す瞬間は、見た目には1秒もかかりません。しかしその1秒のなかで、カード番号は五つ六つの会社と少なくとも二つの決済ネットワークを通り、発行銀行まで往復します。そして実際にお金が口座から口座へ移るのは、その瞬間ではなく数日後です。

決済は、他のどんなシステムよりも「間違ってはいけない」領域です。検索結果が一件間違えばユーザーは不便なだけですが、決済が一件間違えば誰かがお金を失います。だからこそ決済システムでは、整合性(consistency)、冪等性(idempotency)、監査可能性(auditability)が何よりも先に来ます。

この記事は、決済システムを初めて設計あるいは理解しようとするエンジニアのための地図です。オーソリとキャプチャと精算がどう違うのか、その間にどんな登場人物がいるのか、3-D Secureとチャージバックとは何か、そして消込と冪等性とPCI-DSSがなぜ決済の定数なのかを押さえます。決済にはセキュリティが必須なので、認証とトークンの基礎が気になる方はこのサイトの認証・セキュリティ実習室を、以下で頻出するレスポンスコードの意味が分からなければHTTPステータスコード図鑑を併せて参照してください。

五人の登場人物

カード決済を理解する第一歩は「誰が何をするのか」を知ることです。一度のカード決済には少なくとも五つの登場人物がいます。

  • 加盟店(merchant): 商品やサービスを売る側です。私たちが作るサービスがこれに当たります。
  • PSP / ゲートウェイ(payment service provider / payment gateway): 加盟店と複雑な金融網の間をつなぐ仲介者です。Stripe、Adyen、Braintreeのような会社です。カード情報を安全に受け取り、以下の各主体との通信を代行します。
  • アクワイアラ(acquirer / 加盟店銀行): 加盟店に代わってカード代金を「買い取る(acquire)」銀行です。加盟店の精算口座にお金が入るようにする側です。
  • カードネットワーク(card network / スキーム): VisaやMastercardのように、アクワイアラとイシュアの間で取引をルーティングするネットワークです。ルールと手数料(インターチェンジ)を定める主体でもあります。
  • イシュア(issuer / 発行銀行): カードを発行した銀行です。「この取引を承認するか」を決める最終権限を持ちます。限度額、残高、不正を判断する場所です。

この五つがどうつながるかを図で見ると次のとおりです。

  [加盟店] --カード情報--> [PSP/ゲートウェイ] --> [アクワイアラ]
                                                    │
                                                    ▼
                                             [カードネットワーク]
                                                    │
                                                    ▼
                                               [イシュア] --承認/拒否--> (応答が逆順で戻る)

核心となる直感はこうです。カードネットワークは「ルーター」、イシュアは「意思決定者」、アクワイアラは「加盟店の銀行」、PSPは「この複雑さすべてを隠すアダプター」です。私たちがコードで向き合うのはたいていPSPのAPIひとつだけですが、その裏では取引のたびにこの連鎖全体が動いています。

オーソリ vs キャプチャ vs 精算 — 決済の三段階

決済を学ぶときにもっともよくある誤解が「決済 = お金が移動すること」という思い込みです。実際には三つの段階が時間を置いて分かれています。この三つを区別できないと、決済の状態管理は必ずこじれます。

1. オーソリ(authorization / 与信). 「このカードでこの金額を決済してよいか?」をイシュアに問い合わせて答えをもらう段階です。イシュアは限度額と残高、不正シグナルを確認し、承認または拒否を返します。承認されると、その金額だけカードの利用可能枠がホールドされます。ただしこの瞬間にお金が実際に引き落とされたわけではありません。「予約」に近いものです。

2. キャプチャ(capture / 売上確定). 承認された金額を実際に請求すると確定する段階です。オンラインコマースでは通常、商品が発送されるときにキャプチャします。オーソリとキャプチャを分けておくと、在庫がなく注文を取り消す必要が出たとき、キャプチャ前にオーソリだけを取り消す(void)ことができて綺麗です。承認金額より少なくキャプチャする(部分キャプチャ)ことも可能です。

3. 精算(settlement). 実際に資金がイシュアからアクワイアラへ、そして加盟店の口座へ移動する段階です。これは通常バッチで、一日単位で行われます。そのため、ユーザーが決済した日と、加盟店が実際にお金を受け取る日の間には数日のずれがあります。

この三つの関係をタイムラインで見ると明確です。

  T+0秒    オーソリ(authorization)  -> 枠をホールド、お金はまだ動かない
  T+数時間~日  キャプチャ(capture)       -> 「この金額を請求する」と確定
  T+1~3日  精算(settlement)         -> 実際の資金移動、加盟店口座へ入金

ワンタップ決済や即時決済の商品では、オーソリとキャプチャが事実上一度に起こるように見えることもあります(sale/purchase方式)。しかし内部的にはこれらの段階は依然として存在し、精算は常にあとからバッチで行われる点は変わりません。決済システムのステートマシン(状態機械)は、まさにこの三段階を反映して設計すべきです。

オーソリのフローを追う

オーソリ一件がどう流れるかを段階を追って見ていきましょう。ユーザーがカード情報を入力して決済を押した瞬間からです。

  1) ユーザーがカード情報を入力 -> 加盟店フロントエンド
  2) 加盟店(またはPSPのSDK)がカード情報をPSPへ送信(トークン化)
  3) PSP -> アクワイアラへオーソリ要求
  4) アクワイアラ -> カードネットワークへルーティング
  5) カードネットワーク -> 該当のイシュアへ転送
  6) イシュアが限度額/残高/不正を判断 -> 承認または拒否
  7) 応答が同じ経路を逆順で戻ってくる
  8) 加盟店が結果を受け取り注文状態を更新

ここでエンジニアがとくに気をつけるべき点がいくつかあります。

第一に、この往復は複数のネットワークホップを通るので遅く、失敗しうることです。タイムアウト、接続断、PSP障害がいつでも起こります。だから「応答を受け取れなかった」状況を常に想定しなければなりません。これがのちに扱う冪等性が必要な理由です。

第二に、拒否(decline)には種類があります。残高不足、限度超過、紛失届済みカード、不正の疑い、イシュアの一時障害などです。ある拒否は再試行すれば通るかもしれませんが(ソフトデクライン)、ある拒否は再試行しても無駄で、むしろカード会社の不正スコアを悪化させます(ハードデクライン)。この二つを区別して処理することが決済成功率(コンバージョン)に直結します。

第三に、応答はたいてい**オーソリコード(authorization code)**とともに届きます。このコードはあとでキャプチャ、取消、返金、消込でこの取引を識別する鍵になるので、必ず保存しなければなりません。

3-D Secure — 責任を移す認証

オンライン決済(カード非対面、card-not-present)はカード実物がないため不正に弱いです。これを補うためにカードネットワークが作った認証プロトコルが**3-D Secure(3DS)**です。Visaの「Verified by Visa」、Mastercardの「Identity Check」といったブランドで知られ、現在広く使われているのは2.x版です。

3DSの動きを要約するとこうです。決済の途中で、ユーザーをイシュアが制御する認証ステップへ送ります。イシュアはここで追加認証(アプリのプッシュ承認、ワンタイムパスワード、生体認証など)を求めることができます。認証が終わると決済フローに戻り、オーソリを進めます。

  決済要求
     │
     ▼
  3DS認証を開始 -> イシュアの認証画面(必要な場合)
     │  (アプリ承認 / OTP / 生体 など)
     ▼
  認証結果をオーソリ要求に載せてイシュアへ
     │
     ▼
  承認または拒否

3DSの核心は技術ではなく、**ライアビリティシフト(責任転嫁)**という商業的な概念です。3DSで認証された取引で不正が発生した場合、その損失責任は加盟店からイシュアへ移ります。つまり3DSは不正を100%止める道具ではなく、不正損失の責任の所在を変える仕組みに近いものです。

3DS 2.xは以前の版より賢くなりました。リスクが低そうな取引はユーザーに何も尋ねずに通し(フリクションレスフロー)、危険に見えるときだけ追加認証を求めます(チャレンジフロー)。欧州のPSD2/SCA(強力な顧客認証)規制は、事実上こうした認証を義務化しました。決済システムを設計するときは、3DSのステップでユーザーが離脱する、認証が失敗する、コールバックが遅延する、といったケースをすべて状態として扱う必要があります。

チャージバック — ユーザーが異議を申し立てるとき

決済が成功したら終わり、ではありません。ユーザーはあとからその決済に異議を申し立てられます。これが**チャージバック(chargeback)**です。

チャージバックは、ユーザーが自分のカードのイシュアに「この取引はおかしい」と異議を申し立てるところから始まります。理由はさまざまです。商品が届かない、説明と違う、自分がしていない決済だ(不正)、二重請求だ、などです。イシュアが異議を認めると、すでに加盟店へ渡ったお金を差し戻し(reverse)、ユーザーへ返金します。

  ユーザー -> イシュアへ異議を申し立て
     │
     ▼
  イシュアがアクワイアラ経由でチャージバックを開始 -> 加盟店から代金を回収
     │
     ▼
  加盟店が証憑の提出で反論(representment)可能
     │
     ▼
  カードネットワークの仲裁で最終判定

チャージバックは返金(refund)とは異なります。返金は加盟店が自発的にお金を返すこと、チャージバックはカードシステムを通じて強制的に回収されることです。チャージバックは加盟店にとって多くの面で不利です。代金を失うだけでなく別途チャージバック手数料がかかり、チャージバック率が高くなるとカードネットワークから制裁を受けたり、ひどい場合は加盟店資格を失ったりします。

そこで決済システムには、チャージバックを扱う流れが必要です。チャージバック通知を受信して注文状態を更新し、証憑を集めて反論(representment)を提出し、チャージバック率を監視することです。不正によるチャージバックを減らすために、先に見た3DSのライアビリティシフトや不正検知ルールを併用します。

冪等性 — 二重課金を防ぐ定数

決済フローはネットワークを何度も往復するので失敗が多く、失敗すると再試行することになります。ここで決済特有の恐ろしい問題が生じます。再試行が二重課金を生みうるということです。

シナリオはこうです。加盟店がPSPにオーソリ要求を送りました。PSPは正常にイシュアまで往復してオーソリに成功しました。ところがその成功応答が加盟店へ戻る途中でネットワークが切れました。加盟店の立場では「応答を受け取れなかった」だけなので、成功したのか失敗したのか分かりません。そこで安全のために再試行します。しかし最初の要求はすでに成功しているので、再試行が二つ目の決済を作ってしまいます。ユーザーは二度請求されます。

この問題の標準的な解法が**冪等キー(idempotency key)**です。クライアントが決済要求ごとに一意のキーを生成して一緒に送れば、サーバーは同じキーの要求を二度目に受け取ったとき、新たに処理する代わりに最初の結果をそのまま返します。すると何度再試行しても決済は一度だけ起こります。

  要求1: POST /charges  Idempotency-Key: abc-123  -> 決済を実行、結果を保存
  (応答が失われる)
  要求2: POST /charges  Idempotency-Key: abc-123  -> 保存された結果をそのまま返す
                                                       (決済は再び起こらない)

この記事では概念だけに触れますが、冪等性は決済システムの核心中の核心なので、別の記事でキーの寿命、重複排除ウィンドウ、ユニーク制約、決済のステートマシンまで深く扱います。今は「決済要求は常に冪等であるべき」という原則をしっかり刻めば十分です。

消込(reconciliation) — 帳簿を合わせる仕事

決済システムで表には目立って現れないものの決定的に重要な作業が**消込(reconciliation)**です。消込とは「自分のシステムが記録した取引」と「PSPやカード会社が記録した取引」、そして「実際に銀行口座に入ったお金」が互いに一致するかを突き合わせる仕事です。

なぜこれが必要なのでしょうか。決済は複数の主体と複数の段階を経るので、どの地点でも不一致が生じうるからです。

  • 自分のシステムはオーソリ成功として記録したのに、PSPの精算明細にはその取引が抜けていることがあります。
  • キャプチャは100件なのに精算入金は98件分しか入らないことがあります(手数料、チャージバック、返金の控除のため)。
  • 先に見た二重課金や部分キャプチャ、返金が絡むと金額が微妙にずれます。

消込の基本的な考え方はこうです。自分の内部台帳の取引一覧と、PSPが毎日提供する精算ファイルを突き合わせて、両方にあるもの、自分側にだけあるもの、PSP側にだけあるものに分類します。

  内部台帳の取引   vs   PSP精算ファイルの取引
        │                    │
        ▼                    ▼
     突き合わせ(取引ID / オーソリコード / 金額で照合)
        │
        ├─ 両方一致          -> OK
        ├─ 自分側のみ         -> 精算漏れ? 調査が必要
        └─ PSP側のみ          -> 取りこぼした取引? 調査が必要

不一致が出たら、それを例外(exception)として分類し、人が調査するか自動ルールで解消します。よく作られた決済システムは毎日自動で消込を回し、不一致の件数と金額を指標として観測します。消込が綺麗に合うことは「お金を失っていない」もっとも直接的な証拠です。そして消込を可能にするには、そもそもすべての取引が変更不可能な(immutable)記録として残っていなければなりません。この地点で決済は自然に会計台帳の設計と出会います。

PCI-DSS — カード情報を扱う規則

カード番号はきわめて機微な情報です。漏れれば直ちに金銭被害につながるからです。そこでカード業界は**PCI-DSS(Payment Card Industry Data Security Standard)**というセキュリティ標準を作り、カード情報を保存・処理・伝送するすべての場所にこれを守るよう求めています。

PCI-DSSの要求事項は膨大ですが、エンジニアがまず理解すべき大きな原則はこうです。

  • 保存しなくて済むなら保存するな。 カード番号全体(PAN)、有効期限、CVCを直接保存した瞬間、PCI準拠の範囲(スコープ)が爆発的に広がります。CVCはオーソリ以降は絶対に保存してはいけません。
  • トークン化(tokenization)を活用せよ。 実際のカード番号の代わりに、それを置き換える無意味なトークンだけを自分のシステムに置く方式です。本物のカード番号はPCI認証を受けたPSPや専用の金庫(vault)にのみ保管されます。ほとんどのサービスはこの方式でPCIスコープを最小化します。
  • スコープを最小化せよ。 カードデータが通るシステムが少ないほど、監査と管理が容易になります。PSPが提供するホスト型決済画面やクライアント側トークン化(たとえばカード情報をブラウザから直接PSPへ送り、トークンだけを受け取る方式)を使えば、カード番号がそもそも自分のサーバーを通らないようにできます。

まとめると、今日のほとんどのサービスにとって最良のPCI戦略は「カードの生データに直接触れないこと」です。トークン化とPSPの決済画面を積極的に活用し、機微なデータが自分のシステムに入らないように設計することです。認証とトークンの基礎概念がもっと気になる方は、認証・セキュリティ実習室で関連概念を実習できます。

全体像をもう一度見る

ここまでの断片を一枚の絵にまとめてみましょう。ユーザーが決済を押してから、加盟店が実際にお金を受け取り、必要なら返金やチャージバックを処理するまでの全体の旅です。

段階何が起こるかエンジニアの関心事
決済要求カード入力、トークン化PCIスコープの最小化
3DS認証必要ならイシュア認証離脱/失敗/コールバック遅延の処理
オーソリイシュアが枠を確認、ホールド冪等性、ソフト/ハードデクラインの区別
キャプチャ請求確定(発送時など)部分キャプチャ、取消(void)
精算バッチで実際の資金移動手数料/控除の反映
消込内部記録と精算の突き合わせ不一致検知、例外処理
返金/チャージバック事後の代金返還状態管理、証憑、率の監視

この表が決済システム設計の要約版です。各行がひとつの状態でありひとつの失敗地点であり、これらすべてをステートマシンで束ねて管理することが決済バックエンドの本質です。

おわりに

決済システムは「決済ボタンを押すとお金が移る」という単純な見た目の裏に、五つの登場人物と三つの段階と複数の失敗シナリオが幾重にも積み重なった世界です。オーソリは予約、キャプチャは確定、精算は実際の移動です。その間を3DSが認証で守り、チャージバックが事後の異議を処理し、冪等性が二重課金を防ぎ、消込が帳簿を合わせ、PCI-DSSが機微なデータを制御します。

決済エンジニアリングの最初の教訓は「お金が動くシステムは間違える余地を最小化しなければならない」ということです。だから冪等性と変更不可能な記録、そして毎日の消込が選択ではなく定数になります。この地図を手にすれば、次に掘り下げるべき二つのテーマが自然に見えてきます。二重課金を防ぐ冪等性の実装、そしてお金を絶対に失わない複式簿記の台帳の設計です。

参考資料

Discuss on Twitter • View on GitHub