概要

• UPI決済 の5つの瞬間とその裏側の仕組みを解説
• ユーザーが体験するのはごく一部、実際は複数組織が連携
• アプリ、PSP、NPCI、銀行など各ステークホルダーの役割
• 障害や失敗時の処理、システムの堅牢性と進化
• 商用利用や技術的失敗の統計と今後の課題

UPI決済の5つの瞬間とその舞台裏

• UPI決済 は「スキャン」「名前と金額の確認」「PIN入力」「決済完了（緑のチェック）」「受取側の通知」の5ステップで構成
• ユーザーが目にするのはこの5瞬間のみで、その間の処理はすべて舞台裏で進行
• アプリでQRコードをスキャンし、表示された名前を確認、金額入力、PIN入力で決済指示
• 決済完了時、受取側に通知が届き、全体で2〜3秒程度の高速処理
• この間、複数の組織が連携し、各ステップで異なるチェックや処理を実施

アプリの役割と競争

• PhonePe、Google Pay、Paytmなどが主な サードパーティアプリプロバイダー（TPAP）
• アプリはユーザーの意図を集約し、PIN入力等を安全に収集するのみ
• アプリ自体は 銀行免許を持たず、資金を保持しない
• シェアの8割以上をPhonePeとGoogle Payが占める 寡占状態
  • 新規参入アプリ（例：super.money by Flipkart）が急成長する動きも
• どのアプリも 直接決済ネットワークに接続できず、必ず銀行（PSP）の後ろ盾が必要

スポンサー銀行（PSP）の役割

• アプリの スポンサー銀行（PSP）が決済ネットワークへの接続やUPIアドレス発行を担当
• UPI IDの「@」以降がスポンサー銀行を示す（例：@ybl=Yes Bank, @okaxis=Axis）
• 大手アプリは 複数の銀行と連携 し、障害時の冗長性や負荷分散を実現
• 同一銀行間での決済は ネットワーク手数料の節約や処理の高速化 が可能

決済リクエストの流れ

• ユーザーのアクションで作成されたリクエストは、 アプリ→スポンサー銀行→NPCIスイッチ の順で伝達
• 名前確認はネットワーク側で行われ、PINは 暗号化されてアプリからは見えない
• リクエスト送信後は、すべて銀行とNPCI間で処理される

NPCIスイッチの中心的役割

• 全てのUPI決済はNPCI（中央スイッチ）で集約・中継
• スイッチはリクエストを受け取り、 送金元銀行で残高・PINチェック→送金先銀行で着金処理 の順に進行
• 必ず「引き落とし→着金」の順で処理され、逆はない
• 結果は アプリに直接返されず、必ずスポンサー銀行経由で伝達

銀行の決済処理と特徴

• 送金側と受取側で 最も処理件数の多い銀行は一致しない
  • 送金側はState Bank of Indiaなど大手消費者銀行が中心
  • 受取側はYes Bankが圧倒的に多く、商用決済の増加が背景
• 商用決済（人→店舗）が2022年を境に個人間決済を上回る
• 店舗のUPIコード発行もスポンサー銀行が担当、特に大手商用アプリはYes Bank依存が顕著

失敗・障害時の対応

• 失敗は「ビジネス上の理由（PINミス、残高不足等）」と「技術的理由（システム障害等）」に分類
• 技術的失敗は年々減少、現在は 1/400未満　ビジネス上の失敗は増加傾向
• システム停止（全国規模の障害）は稀で、 通常はルール違反や利用者側の要因が主因
• まれに「決済処理中」状態で止まるケースもあり、この場合は一定時間後に再確認が行われる仕組み

まとめ

• UPI決済は表面的にはシンプル だが、実際は多層的な組織連携と高度なシステム運用が支える
• アプリ、PSP、NPCI、銀行それぞれが明確な役割を持ち、 障害時の安全網や進化する堅牢性 も特徴
• 商用利用の増加や新規参入アプリの動向、 失敗時の原因分析 など今後も注目すべき点が多い