デビットカード決済の仕組み
デビットカードは口座から即時払いに見えますが、利用承認、残高確保、売上確定、清算、返金は別のmessageです。この差が難しさの中心です。
銀行ビジネスと主要商品を、利用者・銀行・会計の視点から理解する。
先に学ぶ内容 — Prerequisite: 基礎学ぶこと — LEARNING GOALS
このページで学ぶこと
- 利用者・店舗・銀行・card networkの役割
- authorizationと売上確定の違い
- 取消・返金・不正利用を含む状態管理
体験24 · DEBIT CARD（未実装機能を正直に示す）
「カードを一時停止」を押したら、本当にカードが止まるか確かめよう
まずは予想をひと言。本文を読んだ後、実際の画面でボタンを押して確かめます。
- 01まず予想する — PREDICT
まずここだけ：思ったことをひと言書く
デビットカード画面で「カードを一時停止」ボタンを押したら、実際にカードの利用が止まる設定になると思いますか？
正解でなくて大丈夫です。「〜だと思う」から始めてみましょう。
ヒント1を見る
カード情報やこれまでの利用履歴が表示されているからといって、操作ボタンも同じように機能するとは限りません。
ヒント2を見る
画面上部に何か注記が表示されていないか、よく見てみましょう。
もっと詳しく：この問いで使う専門用語
- Authorizationは、その時点でcard利用を進めてよいかissuerが判断することです。
- Preview UIは、まだ実装されていない機能を「準備中」と正直に示す画面です。
- PreviewActionBarは、どのボタンを押しても同じ案内文を表示するだけで、実際のデータ変更をしないUI部品です。
日常語で理解する — PLAIN LANGUAGE
まず、ここだけつかむ
デビットカードは利用時に口座残高から支払うcardですが、利用承認と最終売上は別処理です。
店舗、加盟店契約会社、card network、発行銀行がmessageをつなぎ、後から売上dataと参加者間の資金を清算します。
取消は未確定のholdを解放し、返金は確定後に新しい資金移動を行います。似ていても状態と会計が違います。
順番に理解する — DIFFICULT PARTS, STEP BY STEP
難しいポイントを、順番にほどく
専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。
Authorization
その時点でcard利用を進めてよいかissuerが判断することです。
残高・card状態・上限・不正riskを商品提供前に確認します。
card authorizationは未実装です。
Hold
承認額を利用可能残高から一時的に確保することです。
売上確定まで同じお金を別取引へ使わせないためです。
available balanceとholdは未実装です。
Clearing / Settlement
売上明細を整理し、参加機関間で最終的に資金を移す段階です。
顧客口座の即時表示と店舗への入金は同じ時刻ではないからです。
外部card networkとの清算はありません。
Reversal / Refund
reversalは未確定承認の取消、refundは確定取引後の返金です。
元取引の状態に応じて正しい残高・Ledger・network messageが違います。
Ledger reversalはありますが、card protocolのreversal/refundではありません。
Issuer / Acquirer
issuerはcard発行側、acquirerは店舗側をnetworkへ接続する会社です。
誰が顧客、店舗、承認、精算へ責任を持つか分けるためです。
単一bank内modelなので両者の役割はありません。
Feature preview UI
まだ実装されていない機能を、正直に「準備中」と示す画面の作り方です。
画面が存在することと、機能が実際に動くことを利用者に混同させないためです。
`FeaturePreviewNotice`と`PreviewActionBar`が、デビットカードを実装済み機能と区別して表示します。
発展 — ADVANCEDもっと詳しく確認する最初の学習では読まなくても問題ありません。仕組みをもっと深く理解したい場合に開いてください。
5つの登場人物
国際brand debitとJ-Debitではnetwork・card・利用可能場所などが異なります。どちらも『口座から支払う』点は共通しますが、同一の仕組みとして扱わないことが重要です。
| 登場人物 | 仕事 |
|---|---|
| Cardholder | cardを使い、口座残高から代金を支払う顧客 |
| Merchant | 商品・serviceを提供し、決済を受け付ける店舗 |
| Acquirer / processor | 店舗の決済messageを受け、networkへ接続する |
| Card network | 共通ruleとmessage networkでacquirerとissuerをつなぐ |
| Issuer | cardを発行し、本人・利用可否・残高・不正riskを判断する銀行等 |
店頭で使ってから店舗へ入金されるまで
- 01店舗端末やonline画面がcard情報・金額を受け取る
- 02acquirerとcard networkを通じてissuerへauthorizationを送る
- 03issuerがcard状態、本人確認、残高、上限、不正riskを確認する
- 04承認なら利用可能残高を減らす、または資金をholdする
- 05店舗が商品を渡し、後で売上確定dataを送る
- 06networkが参加者間の金額をclearingする
- 07銀行間でsettlementし、店舗へ手数料控除後の代金を入金する
- 08取消・金額変更・返品ならreversalまたはrefundを別処理する
2種類の残高と主な状態
| 言葉 | 意味 | 例 |
|---|---|---|
| Ledger balance | 確定記帳された残高 | 売上確定済み取引を反映 |
| Available balance | 今すぐ使える残高 | 未確定authorization holdも差し引く |
| Authorized | 現時点で利用を承認 | まだ最終売上ではない |
| Cleared / posted | 売上dataを照合し確定記帳 | 承認額と確定額が違う場合もある |
| Reversed | 未確定の承認を取消 | holdを解放する |
| Refunded | 確定後に返金 | 元取引と結び付く新しい資金移動 |
| Declined | 利用不可 | 残高、card状態、上限、不正riskなど理由は複数 |
card特有の難しい問題
- 通信断で店舗にはtimeout、issuerには承認済みという食い違い
- hotel・gas stationなど承認額と最終売上額が異なる利用
- 同じ売上dataの再送と二重計上
- 取消messageが遅れ、holdだけが残る状態
- 紛失・盗難、card番号漏洩、偽装店舗、account takeover
- online、contactless、暗証番号など取引ごとの本人確認強度
- token化したcard番号と実番号の安全な対応管理
- 不正申告、調査、補償、chargeback・disputeの証跡
実際のMinibankでは
Minibankにcard、加盟店、acquirer、card network、authorization hold、clearing、settlement、refund、disputeは実装されていません。現在の振込画面やwithdrawalをcard決済と呼ぶことはできません。
顧客画面には`/app/debit-card`という将来機能を想定したpreview画面があります。「Preview / 実装準備中」の表示とともに固定のcard情報・利用履歴を見せますが、一時停止・限度額変更などのbuttonを押しても実際の設定は変わりません。
既存Ledgerとidempotencyは基礎になりますが、available balance、authorization lifecycle、外部messageの重複・順序逆転、card fraud、network reconciliationを新たに設計する必要があります。
体験学習の続き · LEARNING LOOP
ここまで読めましたか？続けて確認してみましょう
デビットカードの仕組みを読んだところで、実際の画面でボタンを押し、自分の言葉で説明してみます。
- 02実際に操作する — OPERATE
同じ仕組みを、動く画面から観察する
実際の顧客画面を開いて操作し、この教材へ戻ります。リンクは新しいタブで開きます。ログインが必要です。
アカウントがない場合は新規登録が必要です。本人確認・口座開設には管理者承認が必要です。承認前や操作できない場合も、この教材内の図・説明・Source Trail（教材の参照元）で代替学習し、次へ進めます。
ログイン・新規登録の入口を開く ↗操作できない場合：教材の参照元で確認する ↓もっと詳しく：管理者の画面で観察する
管理者ログインが必要です。権限がない場合は、次の「証拠を確認する」の教材による確認で進められます。
- 03証拠を確認する — EVIDENCE
何を見たか、1つずつ確かめる
Evidence（判断の根拠となる記録）を確認したらチェックします。各項目の「何を見るか」を手がかりにしてください。
画面を開けない項目は、Source Trail（教材の参照元）と教材の説明で確認できます。失敗を実際に起こす必要はありません。
- 04コードの処理経路を追う — CODE TRAIL
コードを書く必要はありません
ここでは「説明されている仕組みが、実際のMini Bankのどこに実装されているか」を確認します。まずは日本語の役割説明を読み、入力した依頼がどこへ渡るかをつかみましょう。コードの全文を読む必要はありません。
まずpreview画面自体を見て、次にボタンを押した時の実装を見ます。画面の反応と実際のデータ変更が一致しているかを確かめましょう。
教材の参照元を確認する — Source Trail ↓デビットカードのpreview画面本体。固定card情報と操作ボタンを探します。
src/app/app/debit-card/page.tsxボタンのonClickが実際に何をしているかを探します。
src/components/common/PreviewActionBar.tsx - 05自分の言葉で説明する — EXPLAIN
LEVEL 1 — やさしい説明（まずここだけ）
なぜMinibankは、まだ実装されていないデビットカード機能を非表示にせず、あえて「Preview / 実装準備中」という画面として見せているのでしょうか？ 短い2文を目安に説明してください。
日常語だけで完了できます。専門用語の数や正誤を自動採点するものではありません。
ヒント1を見る
「画面が動く」と「機能が実装されている」という2つの言葉を使って書いてみましょう。
ヒント2を見る
なぜ非表示にせず、あえてpreview画面として見せているのか考えてみましょう。
もっと詳しく：LEVEL 2 — 専門用語を使った説明（任意）
Authorization、Hold、Feature preview UIの3つを使って、デビットカードの実装範囲とpreview画面の役割を説明してみましょう。
挑戦する場合は、上の説明欄に追記できます。追加しなくても完了できます。
説明の確認ポイント — Checkpoint- ボタンを押しても実際のカード設定は変わらないと確認できる
- 画面が存在することと機能が実装されていることは別だと説明できる
理解を確かめる — CHECK YOUR UNDERSTANDING
4問で理解チェック
答えを頭の中で考えてから、各項目を開いて確認してください。
Q1authorization承認は売上の最終確定ですか？
違います。後続の売上確定dataとclearingが必要です。
Q2帳簿残高と利用可能残高が違うのはなぜですか？
未確定のholdを利用可能残高だけに反映する場合があるためです。
Q3取消と返金は同じですか？
違います。未確定承認を解放するreversalと、確定後に資金を戻すrefundを区別します。
Q4Minibankの振込はデビットカード決済ですか？
違います。加盟店、card network、authorization、clearingなどがありません。
完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。
業界・外部の参照元 — INDUSTRY / EXTERNAL SOURCE
業界資料・参考文献
一般論と業界知識の根拠です。外部サイトを新しいタブで開きます。
- 全国銀行協会 — デビットカード
J-Debit・Visa debit・JCB debitと即時払いの利用者向け入門
- JCB — JCBデビットカード（加盟店向け）
即時引落しと、売上確定までの資金保留・取消に関する説明
- JCB — J-Debit決済
cash card、暗証番号、加盟店、金融機関を結ぶJ-Debitの概要
- 日本銀行 — 最近のデビットカードの動向
J-Debitと国際brand debitの構造を扱う決済system資料
教材の参照元 — SOURCE TRAIL
根拠と関連教材
CURRENT IMPLEMENTATIONは確認したrepository内の実装です。HISTORICAL IMPLEMENTATIONは導入・修正の履歴で、後続migrationによる再定義があり得ます。RELATED LESSONは教材への案内で、実装の一次Sourceではありません。ASSUMPTIONは仮定、UNKNOWNは未確認を表します。
確認基点: d02eae8914f39cbf06bfe422dc39c71886f82b3e / 2026-09-11。稼働環境への適用確認: UNKNOWN。パス実在の自動検査と、記述した技術的事実の確認は別です。
- 現在の実装 — CURRENT IMPLEMENTATION
src/app/app/debit-card/page.tsxpreview画面本体。固定sample dataとinert buttonのみ - 現在の実装 — CURRENT IMPLEMENTATION
src/components/common/PreviewActionBar.tsx全buttonが同じnoticeを表示するだけで、実mutationを呼ばない実装 - 現在の実装 — CURRENT IMPLEMENTATION
src/services/TransactionService.ts現在の入出金。card authorizationやclearingではない - 現在の実装 — CURRENT IMPLEMENTATION
src/services/TransferService.ts内部振込のlocking・idempotency例。card機能ではない - 過去の実装 — HISTORICAL IMPLEMENTATION
supabase/migrations/既存Ledger基盤。card関連table・RPCは未実装