UPI決済1件が処理されるまで

 (timeseriesofindia.com)
1 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • QRスキャンから完了通知まではわずか2〜3秒だが、その裏側ではアプリ、スポンサー銀行、NPCIの中央スイッチ、送金銀行・受取銀行という互いに分離された主体がリクエストとレスポンスをリレーしている
  • PhonePeやGoogle Payのようなアプリは決済の意思だけを収集し、資金やPINを直接扱わない。PSPスポンサー銀行がUPIアドレスの発行とNPCIへの接続を担う
  • NPCIスイッチは、送金銀行によるPIN・残高確認と引き落としが完了した後にのみ、受取銀行へ入金を依頼する。処理結果も両側のスポンサー銀行を経由してアプリへ戻る
  • 2026年6月、UPIは2,272 crore件以上を処理した。最近では決済約11件に1件が拒否されるが、システム自体の技術的失敗は400件に1件未満で、その大半は誤ったPIN、残高不足、限度額超過によって発生している
  • 引き落とし後に入金確認が遅れた**deemed取引**は、ステータス照会とNPCIの自動調整を経て、入金確定または引き落とし取消で完了する。返金が遅れた場合は期限規定と1日₹100の銀行への罰金が適用される

ユーザーが目にする5つの瞬間

  • UPI決済の体験は、QRスキャン、受取人名と金額の確認、PIN入力、決済完了表示、相手側の受取通知という5つの瞬間で構成される
  • 全体の流れは通常2〜3秒以内に終わるが、PIN入力と結果表示の間では、複数の組織がそれぞれ必要な検査を行い、次の主体へ結果を渡している
  • スマートフォンアプリは決済網につながる最初の接点にすぎず、ユーザーの資金を直接扱わない
  • 2026年6月、UPIは2,272 crore件以上の決済を処理し、世界のどのリアルタイム決済システムよりも多くの取引を運んだ
  • 1回の決済には、ユーザーアプリ、ユーザーPSP、送金銀行、NPCI、受取銀行、受取人PSP、受取人アプリが参加し、受取側は送金側を対称的に反映する

アプリは決済の意思だけを収集する

  • PhonePe、Google Pay、Paytmのようなアプリは**第三者アプリケーション提供者（TPAP）**として、決済先と金額を収集し、受取人を表示し、セキュアな入力パッドでPINを入力させる
    • アプリはPINを見ることができない
    • ユーザー資金を保有しない
    • 銀行免許も保有しない
  • UPIにおけるユーザー獲得競争はアプリ層に集中しているが、市場は大きく偏っている
    • PhonePeとGoogle PayがUPI決済全体の約5分の4を処理している
    • この2アプリの首位構図は何年も維持されている一方、その下のアプリの順位は変わり続けている
  • Flipkartが2024年に開始したsuper.moneyは、保証型キャッシュバックでユーザーを引き寄せ、約1年で50位圏外から上位5位に上がった
  • アプリには銀行免許も決済網への直接接続もないため、必ずスポンサー銀行の支援を受けなければならない

PSPスポンサー銀行とUPIアドレス

  • アプリの決済網接続と免許上の役割は、**決済サービス提供者（PSP）**であるスポンサー銀行が担う
    • 中央システムに接続する
    • ユーザーを表すUPIアドレスを発行する
    • UPIの初期設定時に携帯電話と銀行口座を結びつける
  • UPI IDで@の後ろにあるサフィックスは、利用しているアプリではなくスポンサー銀行を表す
    • @yblはYes Bankに属する
    • @okaxisはAxisに属する
    • PhonePeのハンドルはYes Bank、Axis、ICICIが運用している
    • Google PayのハンドルはAxis、HDFC、ICICI、State Bankが運用している
  • 大型アプリの多くは、1行ではなく複数のスポンサー銀行を利用する
    • ある銀行の障害でアプリ全体が停止しないようレジリエンスを高める
    • 1つのスポンサーがアプリの全取引量を背負い込む状況を避けられる
  • 送金人と受取人が同じスポンサーに属している場合、その銀行は自社の台帳で両方のアドレスを確認し、中央ディレクトリをスキップできる
    • 処理速度が上がる
    • 約1 paisaのアドレス確認手数料を節約できる
  • スマートフォンから出ていくのは資金ではなく、アプリが構成しスポンサー銀行が署名したリクエストである
    • 決済前にスキャンしたアドレスの実際の所有者名を確認し、誤った受取人に気づく機会を提供する
    • PINはスマートフォン上の認証済み共通コンポーネントが取得して暗号化し、アプリは転送中も内容を知ることができない
    • NPCI UPI APIの共通ライブラリでは、PINはCreds type="MPIN"として渡される

NPCI中央スイッチの処理順序

  • すべてのUPI決済は、非営利の運営機関NPCIが管理する単一の中央スイッチに集まる
  • スイッチはまず、受取人のUPIアドレスを担当するスポンサー銀行にリクエストを送り、その銀行がハンドルを実際の口座に変換する
  • 資金移動の順序は固定されている
    1. NPCIが送金銀行に引き落としを依頼する
    2. 送金銀行だけがスマートフォンから来た暗号化済みPINを開けるため、この段階でPINを検証する
    3. 送金銀行が残高を確認して資金を引き落とし、結果を返信する
    4. 引き落とし確認後にのみ、NPCIが受取銀行に入金を依頼する
    5. 受取銀行の入金確認を待つ
  • 資金は常に先に出てから入るのであり、逆の順序では処理されない
  • 結果はNPCIからアプリへ直接渡されるのではなく、両側のPSPを経由する
    • 送金人PSPがアプリに成功結果を渡すと、緑色の完了表示が現れる
    • 受取人PSPが相手側アプリに結果を渡すと、受取通知が表示される
  • 中央スイッチは1つしかないため、その自体の処理に関する比較資料はほとんど公開されておらず、規模は全体の処理量に表れている
    • UPIは2016年の開始当時の月間数百万件から、2026年6月には2,272 crore件へ増えた

送金銀行と受取銀行の順位が異なる理由

  • 送金側と受取側で最も忙しい銀行の順位は互いに異なる
  • 送金側の順位は顧客数と似た傾向を示す
    • State Bank of Indiaが大差で首位である
    • ほかの大手消費者向け銀行がそれに続く
  • 受取側ではYes Bankが他行を大きく上回る
    • Yes Bankの受取シェアは2年間で約2倍に増加した
    • 送金発生量は少ないが、受取量は最も多い
  • この差は、UPIが個人間決済よりも個人の店舗向け決済に多く使われるようになった構造と結びついている
    • 店舗決済と個人間決済の比率は2022年に逆転した
    • 取引件数ベースで店舗決済が個人間決済を上回った時点は2022年8月である
  • 店舗のUPI QRも個人ハンドルと同様にスポンサー銀行が発行し、大型加盟店アプリのスポンサーはほとんどがYes Bankである
  • 店舗でPhonePe QRをスキャンすると、入金はQRの背後にいるスポンサーであるYes Bankへまず入り、その後、加盟店アプリの共同口座から店舗オーナーへ支払われる
  • ここでいうbeneficiary bankは、店舗オーナーが個人的に利用している銀行ではなく、QRを支援した銀行を意味する

決済が拒否される2つの理由

  • UPIは失敗した決済を業務上の拒否と技術的拒否に分けて記録する
  • 業務上の拒否は、ユーザーまたは決済ルールに起因する
    • 誤ったPIN
    • 残高不足
    • 1日あたりの限度額超過
    • アプリがただちに具体的な理由を表示するため、ユーザーは原因を確認できる
  • 技術的拒否は、銀行システムや中央スイッチの処理段階が完了できなかった場合である
    • Bank server down
    • your bank’s server didn’t respond, please try again
    • ユーザー画面では、サーバー応答失敗以外の具体的な原因を把握しにくい
  • 最近では決済約11件に1件が拒否されるが、決済網自体の技術的失敗は400件に1件未満である
  • 技術的拒否率は、銀行とスイッチが安定するにつれて、100件に1件以上から400件に1件未満へと毎年低下している
  • 業務上の拒否率は下がらず、むしろ上昇しており、一般的な失敗はシステム障害というより、PIN・残高・限度額ルールが執行された結果に近い
  • UPIが全国的に数時間停止した事例もあるが稀であり、平時の決済失敗の主な原因は、限度額超過、残高不足、誤って入力した数字である

成功も失敗も確定できないdeemed取引

  • 送金口座から資金が引き落とされた後、受取銀行の確認が期限内に返ってこないと、ネットワークは入金の有無を即座に判断できない
    • 実際には入金済みだが、受取銀行が結果を報告できなかった可能性がある
    • 入金自体が行われていない可能性もある
  • このように入金の有無が確認されていない取引を**deemed状態**と呼び、アプリは緑色の完了表示ではなく、決済処理中であると表示する
  • アプリは結果を推測せず、約90秒後にネットワークへ実際の状態を照会できる
    • 照会回数は少数に制限される
    • アプリがステータス照会リクエストを過剰に送り、UPI障害を引き起こした事例がある
    • ユーザーが直接操作しなくても、アプリが照会を実行する
  • NPCIも両側の銀行を継続的に照会し、取引を自動調整する
    • 入金が行われていれば決済を確定する
    • 入金されていなければ引き落としを取り消し、資金を返す
  • 返金時点は銀行の裁量に委ねられない
    • 通常の送金は1日以内に返金されなければならない
    • 加盟店決済は数日以内に返金されなければならない
    • 期限を超えると銀行に1日**₹100の罰金**が科される
  • UPIはすべての決済を即座に確定できない場合でも、事後調整ルールを通じて入金を確定するか、ユーザーに資金を返すよう設計されている
  • こうした保留取引はもともと一般的ではなく、それを処理する調整体系は継続的に強化されている

隠れた決済リレー

  • ユーザーが目にするスキャン、名前と金額、PIN、完了表示、受取通知の間には、アプリ → スポンサー → NPCIハブ → 銀行へと続くリレーが存在する
  • 1回の決済の背後では、7つの企業と銀行がメッセージを送り返し、各段階で必要な検査を行っている
  • 失敗が発生しても、ステータス照会、自動調整、返金期限と遅延罰金が適用され、ユーザー資金は入金確定または返金で完了する

関連記事

1件のコメント

 
GN⁺ 3 시간 전
Hacker Newsの意見

  • インドの外にいる人や UPI をあまり使わない人には、取引規模を実感しにくい。家族間の送金から、菓子やチャイのような少額購入、自動車整備・配管など各種サービス、オンラインショッピング、バス・航空機・トラム・タクシー・鉄道まで、ほぼあらゆる決済に使われている
    Web アプリの UPI QR コードを携帯電話でスキャンしたり、モバイルアプリから UPI 決済画面を直接開いたりできる。Kolkata のような都市では、私と配偶者で1日に 20〜30件、ヒマラヤの小さな村でも1日に 6〜8件ほど決済している

    • 恒久的な認証情報の代わりに 使い捨てコードを使う仕組みは、英語圏では過小評価されすぎている。子ども・友人・配偶者・部下にクレジットカードを預けるより、アプリで承認が必要な単一取引用 OTP を渡すほうがはるかに安全だ
      ポーランドの Blik は6桁コードを使うので、信頼している知人が ATM にいるとき、電話でコードを読み上げるといった使い方もできる
    • 小さなマイクロ SaaS に UPI 決済を追加してから、ようやくインドで売上が出始めた。それ以前は、インドのユーザーに登録してもらうのがほぼ不可能なほどだった
    • 政府が少額決済をテロ活動と解釈して銀行口座を差し押さえる事態に備えた計画はあるのか？ 国ごとに速度の違いはあっても、こうした過程を経た末に結局は 現金回帰が起きると思う

  • UPI を運営している人たちには深い敬意を抱く。インドの高齢者層まで完全に デジタル決済へ移行させたのは、世界的にも前例のない成果だ

    • ブラジルの PIX やスウェーデンの Swish も似ており、そのほかにも先例は多いだろう
    • インドには大規模な クレジットカード決済網がなかったため可能だった。現金からデジタル決済へ一気に飛び越えた形だ

  • UPI が機能しているのは確かだが、プライバシーと自律性の観点ではひどい仕組みだ。仲介者が多すぎ、電話番号が必要で、個人の身元と結びつくため、どんな意味でも個人間決済の仕組みとは呼びにくい
    Visa や Mastercard の代わりに政府が統制しているというだけだ

    • Visa や Mastercard も取引情報を米国政府などに提供している。Hot Watch を通じて米国政府は特定対象をリアルタイム監視し、Bank Secrecy Act は民間の決済網とカード発行銀行に、無償の国家代理人のように振る舞うことを法的に強制している
      その点、UPI は情報を共有する政府の数が少ないとも言える
    • 結局のところ、通貨そのものが政府の統制を受けている

  • ブラジルの PIX は UPI と非常によく似ている。各国政府が独自インスタンスを運営する、オープンソース方式の 世界的な UPI 体系を作れない理由はあるのだろうか？

  • UPI がインドの成長にどのような影響を与えているのか、数値で分析できるだろうか？ 非公式経済の一部を制度圏に取り込む効果もありそうだ

  • 年間 220億件なら、NPCI スイッチの平均処理量はおよそ 毎秒700件だ。トラフィックが均一ではないのでピークは何倍も高いだろうが、取引開始時に毎秒10万件を超える Nasdaq TotalView ITCH フィードと比べると、それほど激しくは見えない

    • Nasdaq の注文・メッセージ処理量と比較するなら、インドの National Stock Exchange(NSE) が適切だ。NSE は1日の約定注文数が Nasdaq より多い
      数年前に UPI のスケーリング作業をしたことがあるが、リアルタイム決済ははるかに分散していて非常に複雑だ。各取引には資金を保有する2つの銀行、両側のユーザーアプリとその銀行、NPCI ネットワークが関与し、両側のユーザーが待つ間に複数回のメッセージ交換が必要になる。したがって、メッセージ数ベースの処理量は実際の取引数より 10〜25倍高い
      どの国内銀行からでも他行へ例外なく無料送金でき、年中無休で動くリアルタイム決済網はゲームチェンジャーだ。遅くて高価な米国の決済網とは対照的だ
      インドには UPI のほかにも、ACH のように一括精算する NEFT、UPI と似た即時処理だがユーザー体験が異なる IMPS、中央銀行 RBI が仲介する高額リアルタイム決済網 RTGS がある。いずれも年中無休で無料だ。カード網には Visa や Mastercard に加え、決済手数料がはるかに低い RuPay もある
    • 220億件は 2026年6月の1か月の数字なので、年換算では 2,640億件になる
    • システム設計面接から得られる教訓でもある。人口15億人の国で人気の決済システムですらこの程度なら、小さな会社が Google 風の面接をまねて設計する架空システムに、平均毎秒数百万件どころか数万件を要求する可能性も低い

  • 中央集権型・KYCベースの非公開な資金取引網は本当に良いものなのか？

    • 少なくとも実用的ではある。モバイルウォレットが成長していた頃、多くの人が金融技術の土台は分散化であるべきだとしてブロックチェーンを掲げ、議論は分散化・個人間取引・暗号資産を介した取引・ステーブルコインといった技術哲学に埋没していた
      コンサルティング会社は大金を稼いだが、政府機関や銀行は製品開発の進展もないまま数百万ドルをどう使い切ってしまったのか首をかしげることになり、結局、金融技術のイノベーションを政府が主導すべきではないという結論に傾いた
      大規模な情報技術インフラは、米国や西欧の政府の統制・影響下にある企業が各国政府向けに開発・販売することが多く、国家主権にもある程度影響する。政府は統制リスクのある既製ソフトウェアを待つか、リスクと限界を受け入れて今動くソフトウェアを自ら構築するかを選べる
      インドは検証済みで予測可能な基盤の上に仕組みを構築するという正しい選択をしたのだと思う
    • ユーザー体験と実用性だけを見れば非常に優れている。普及率が高く、小さな茶店でも決済が簡単になってより多くの客を受け入れられる
      ただし、銀行が認証した政府発行の身分証明書とひも付けされるため、外国人には非常に使いにくい
    • 民間銀行が同じことをしながら利用者から利益を吸い上げるよりはるかに良く、ユーザー体験が劣悪で全財産を失いやすい現在の暗号資産よりもましだ。現金より実用的だが、現金を選ぶ権利も維持すべきだ
      便利でありながら分散化され、匿名性まで備えた仕組みには及ばないが、まだそのようなものは存在しない。Ethereumがネイティブなアカウント抽象化、シームレスなスケーラビリティ、Monero並みのプライバシー保護を解決できれば、5年後くらいには可能かもしれない
    • 中央集権型でKYCベースなのはその通りだが、非公開と言うのは難しい。https://www.bankbazaar.com/tax/tax-on-upi-transactions.htmlを参考にできる
    • 良い仕組みであることは確かだ。新しい通貨を作ろうとしているのではなく、すでに機能している自分のお金を使う方法だからだ

  • タイのPromptPayのような東南アジアのQRベース決済も似た原理で動いているのか？
    ウェブサイトと構成図は読者に配慮していて、すっきりしており邪魔な要素がまったくない

    • PromptPayの仕組みはよく知らないが、少し調べた限りではQRスキャン用のユーザーアプリを銀行が直接運営している。一方、UPIにおけるGoogle Payは**サードパーティアプリ提供者（TPAP）**であり、1つのTPAPに同じ銀行または異なる銀行の複数口座を接続できる
      銀行間プロトコルの実装も異なる可能性がある。UPIの取引メッセージは非同期で、NPCIが送金銀行に出金要求であるReqPayを送ると、銀行は同じHTTPリクエスト内で確認メッセージのAckだけを返す。処理が終わると銀行スイッチがNPCIのコールバックエンドポイントへRespPayを送り、NPCIが再びAckを返す。NPCIが受取銀行へ入金要求を送るときも同様に進む

  • 内容も良いが、crore/billion変換機能が特に素晴らしい。インド関連のウェブサイトに広く普及してほしいが、CR/BNだけでは用途がすぐに分かりにくいので、ツールチップの説明があるとよい

    • その機能だとは気づかなかった。最初はHI/ENのような言語切り替えボタンに見えたが、どの言語の略なのか分からず、実際に言語も変わらなかった。分かってみると良いアイデアだ