UPI: анатомия одной платёжной транзакции

На стороне пользователя платёж через индийскую систему мгновенных платежей UPI (Unified Payments Interface, единый платёжный интерфейс) выглядит одинаково по нескольку раз в день: человек сканирует QR-код на кассе, проверяет имя получателя, вводит сумму и PIN-код, видит зелёную галочку, и через 2, 3 секунды у получателя на телефоне звучит сигнал о зачислении. Эти пять моментов, сканирование, имя с суммой, PIN, галочка и сигнал у получателя, единственное, что видит пользователь. За ними скрыта цепочка из семи отдельных компаний и банков, которые передают запрос друг другу и проверяют его на каждом шаге, укладываясь в те же несколько секунд. Масштаб системы таков: только в июне 2026 года UPI обработал более 2272 крор (индийская счётная единица; это более 22,7 млрд) платежей, больше, чем любая другая система мгновенных платежей в мире.

Первое звено, приложение на телефоне: PhonePe, Google Pay, Paytm и десяток других. В терминологии системы это «провайдер стороннего приложения» (Third-Party Application Provider, TPAP): оно собирает намерение пользователя (кому и сколько платить), показывает имя получателя и принимает PIN-код через защищённый ввод, содержимое которого само приложение прочитать не может. Приложение никогда не видит PIN, не хранит деньги пользователя и не имеет банковской лицензии, оно лишь передаёт готовый запрос дальше. Именно на уровне приложений разворачивается почти вся конкуренция рынка: PhonePe и Google Pay вдвоём держат около четырёх пятых (80%) всех платежей UPI, и эта дуополия сохраняется годами, но состав игроков ниже верхушки постоянно меняется. Пример, сервис super.money, запущенный компанией Flipkart в 2024 году: он поднялся с позиции за пределами топ-50 в топ-5 примерно за год благодаря гарантированному кешбэку.

Но ни одно приложение не может напрямую обратиться к платёжной сети, для этого ему нужен банк-партнёр, «спонсор» (Payment Service Provider, PSP). Спонсор подключается к центральной системе, выпускает UPI-адрес пользователя и является тем банком, который изначально привязал телефон к банковскому счёту при настройке UPI. Суффикс после «@» в UPI-адресе называет именно банк-спонсор, а не приложение: адрес, оканчивающийся на «@ybl», привязан к Yes Bank, а «@okaxis», к Axis Bank. Адреса PhonePe работают через Yes Bank, Axis и ICICI; адреса Google Pay, через Axis, HDFC, ICICI и Государственный банк Индии (State Bank of India). Большинство крупных приложений теперь опираются сразу на несколько банков-спонсоров, а не на один, в основном ради отказоустойчивости: если платежи распределены между банками, сбой одного банка не кладёт всё приложение целиком, и ни один спонсор не несёт весь объём нагрузки в одиночку. У самих банков-спонсоров есть свой тихий бонус: если плательщик и получатель обслуживаются одним и тем же спонсором, этот банк разрешает оба адреса в собственной базе и пропускает обращение к центральному справочнику сети, это быстрее и экономит комиссию за разрешение адреса (около одной пайсы). В итоге с телефона пользователя уходят не деньги, а запрос, собранный приложением и подписанный банком-спонсором; именно здесь происходят три из пяти видимых пользователю моментов, сканирование, имя с суммой и PIN. Проверка имени получателя, единственный шанс пользователя заметить неверного получателя до того, как деньги списаны; PIN шифруется сертифицированным компонентом на телефоне, и даже приложение, которое его передаёт, не может его узнать.

Дальше запрос полностью уходит из рук пользователя и попадает в единственную точку, через которую проходит абсолютно любой платёж UPI, центральный коммутатор, которым управляет некоммерческая организация NPCI (National Payments Corporation of India, Национальная платёжная корпорация Индии); другого такого коммутатора не существует. Сначала он определяет банк-спонсор получателя и направляет запрос туда, чтобы тот банк перевёл UPI-адрес в реальный номер счёта. Порядок движения денег строго зафиксирован: коммутатор сначала просит банк-спонсор плательщика списать сумму. Только этот банк способен вскрыть зашифрованный на телефоне PIN, поэтому именно и только здесь PIN проверяется: банк сверяет PIN, проверяет остаток на счёте, списывает деньги и отвечает коммутатору. Только после подтверждения списания коммутатор просит банк-спонсор получателя зачислить сумму и ждёт его подтверждения. Деньги всегда сначала уходят и только потом приходят, никогда наоборот. Итог коммутатор не сообщает сторонам напрямую: NPCI возвращает результат обоим банкам-спонсорам, а те передают его своим приложениям, приложение плательщика показывает зелёную галочку, а приложение получателя, сигнал о зачислении. Сам коммутатор почти не публикует данных о собственной работе (сравнивать его не с чем, он единственный); его масштаб виден только по общему количеству обработанных платежей.

Казалось бы, самые загруженные банки на стороне списания и на стороне зачисления должны совпадать, но это не так. На стороне списания с большим отрывом лидирует Государственный банк Индии, а за ним идут другие крупные розничные банки, примерно как можно ожидать по числу их клиентов. На стороне зачисления порядок совсем другой: далеко впереди частный Yes Bank, чья доля во входящих платежах не сравнима ни с одним банком на стороне списания и примерно удвоилась за два года, при этом сам Yes Bank почти не инициирует платежи. Причина в том, что большинство платежей UPI, это уже не переводы между людьми, а оплата в магазинах: эти две линии пересеклись в 2022 году и с тех пор продолжают расходиться. QR-код магазина, как и личный адрес пользователя, выпускает банк-спонсор, а для приложений, которые обслуживают самых крупных продавцов, этим спонсором почти всегда оказывается именно Yes Bank. Поэтому когда покупатель сканирует код PhonePe на кассе, деньги сначала зачисляются на Yes Bank, банк, стоящий за этим кодом, и только потом выплачиваются продавцу с общего счёта приложения. «Банк-получатель» в такой статистике, это не банк, где у продавца открыт собственный счёт, а банк, который спонсирует QR-код.

Каждый отклонённый платёж UPI фиксируется по одной из двух причин. «Бизнес-отказ», неверный PIN, нехватка средств, достигнут дневной лимит: причина видна пользователю сразу, приложение её объясняет, и она находится на его стороне. «Технический отказ», где-то в цепочке (в системах одного из банков или в самом коммутаторе) не удался один из шагов; пользователь видит только общее сообщение вроде «сервер банка недоступен, попробуйте позже» без объяснений. За последние годы разрыв между этими двумя причинами вырос: сейчас отклоняется примерно каждый одиннадцатый платёж, но менее одного из четырёхсот проваливается именно из-за самой системы. Доля технических отказов год за годом снижалась, с более чем одного из ста до менее одного из четырёхсот, по мере того как банки и коммутатор становились надёжнее, а доля бизнес-отказов при этом не снизилась, а выросла. Иными словами, система в целом становится надёжнее, даже когда сами платежи всё чаще срываются не из-за поломки, а из-за собственных правил (лимитов, проверки баланса). Случаи, когда UPI переставал работать по всей стране на несколько часов, действительно случались и запомнились, но они редки; в обычный день платёж почти никогда не срывается из-за поломки системы, а срывается из-за достигнутого лимита, нехватки средств или неверно набранной цифры.

Правило «деньги сначала уходят, потом приходят» почти всегда подтверждается мгновенно, и пользователь никогда не замечает разрыва между этими двумя моментами. Но иногда подтверждение о зачислении не успевает вернуться вовремя: банк получателя мог зачислить деньги и не сообщить об этом, а мог и не зачислить вовсе, и на короткое время сеть не может понять, какой из вариантов произошёл. У такого платежа есть собственное название, deemed (буквально «предполагаемый»): зачисление ещё не подтверждено. Именно в этот момент вместо зелёной галочки приложение показывает, что платёж «обрабатывается»: деньги уже списаны, но никто пока не может сказать, дошли ли они. Система рассчитана именно на такой случай: примерно через 90 секунд приложение может само тихо запросить у сети реальный статус платежа, но число таких запросов ограничено, потому что приложения, слишком часто задававшие именно этот вопрос, сами становились причиной сбоев UPI. От пользователя при этом ничего не требуется, запрос статуса происходит автоматически. Параллельно NPCI ведёт собственную сверку: запрашивает оба банка до получения точного ответа и выносит один из двух вердиктов, зачисление состоялось, и платёж считается проведённым, либо не состоялось, и списание отменяется. Если деньги нужно вернуть, сроки возврата не оставлены на усмотрение банков: для перевода между людьми деньги обязаны вернуться в течение суток, для платежа в магазине, в течение нескольких дней, а при просрочке банк платит штраф в 100 рупий за каждый день задержки. Такие «подвисшие» платежи никогда не были массовым явлением, а механизм сверки вокруг них с тех пор стал ещё строже.

Ключевые факты

В июне 2026 года UPI обработал более 2272 крор (свыше 22,7 млрд) платежей, больше, чем любая другая система мгновенных платежей в мире; видимая пользователю часть платежа (скан QR-кода, имя, сумма, PIN, зелёная галочка) занимает 2, 3 секунды и скрывает цепочку из семи отдельных компаний и банков.
Приложения (PhonePe, Google Pay, Paytm) формально называются «провайдерами стороннего приложения» (TPAP): они не видят PIN, не хранят деньги пользователей и не имеют банковской лицензии. PhonePe и Google Pay вдвоём держат около 80% рынка, но состав игроков ниже верхушки постоянно меняется, например, сервис super.money (запущен Flipkart в 2024 году) поднялся с позиции за пределами топ-50 в топ-5 примерно за год за счёт гарантированного кешбэка.
Суффикс UPI-адреса (например, «@ybl» или «@okaxis») называет реальный банк-спонсор (Payment Service Provider), а не приложение; центральный коммутатор NPCI жёстко фиксирует порядок операций, сначала подтверждённое списание у плательщика, и только потом зачисление получателю, деньги никогда не приходят раньше, чем уходят.
На стороне списания лидирует Государственный банк Индии, а на стороне зачисления, частный Yes Bank (доля примерно удвоилась за два года), потому что он спонсирует QR-коды большинства приложений для крупных продавцов; с 2022 года платежей в пользу магазинов стало больше, чем переводов между людьми.
Отказы делятся на «бизнес-отказ» (неверный PIN, нехватка средств, сейчас каждый одиннадцатый платёж) и «технический отказ» (сбой самой системы, сейчас менее одного из четырёхсот и доля снижается); при неподтверждённом зачислении («deemed») NPCI проводит сверку и либо подтверждает платёж, либо отменяет списание, с обязательным возвратом денег (сутки для перевода, несколько дней для покупки) и штрафом банку в 100 рупий за каждый день просрочки.

Почему это важно

Статья показывает, что кажущаяся простой операция, сканирование QR-кода и ввод PIN, на деле держится на строгой архитектуре с чётким разделением ответственности между семью участниками и на жёстких правилах: списание подтверждается раньше зачисления, а сроки возврата денег и штрафы банкам при сбое закреплены заранее. Это объясняет, почему система, обрабатывающая более 22,7 млрд платежей в месяц и остающаяся самой нагруженной системой мгновенных платежей в мире, при этом год от года становится надёжнее: доля технических отказов падает, а сбои всей сети, редкое, а не типовое явление. Для платёжной отрасли в целом это готовый пример того, как архитектура с разделением ролей (приложение, банк-спонсор, единый коммутатор, сверка после сбоя) способна выдерживать нагрузку национального масштаба.

Кому это важно

Пользователям UPI в Индии, чтобы понимать, что стоит за привычной галочкой на экране, и почему суффикс их платёжного адреса указывает на конкретный банк-спонсор, а не на приложение. Инженерам и архитекторам платёжных и финтех-систем, как разобранный по шагам пример проектирования отказоустойчивой распределённой системы расчётов с чётким протоколом подтверждений и сверки. Банкам-спонсорам (PSP) и владельцам приложений (TPAP), потому что от выбора спонсора и его надёжности напрямую зависит доступность их сервиса. Регуляторам и экономистам, которые следят за системно значимой платёжной инфраструктурой Индии и за её концентрацией вокруг пары приложений и отдельных банков.

Как это применить

Проверить суффикс собственного UPI-адреса, он указывает на реальный банк-спонсор, а не на приложение, которым пользуется человек. Инженерам, проектирующим похожие системы расчётов, разобранная в статье модель даёт готовый шаблон: жёсткий порядок «сначала подтверждённое списание, потом зачисление», раздельная классификация отказов на «по вине пользователя» и «по вине системы», ограничение числа запросов статуса от приложения (чтобы клиентские приложения не заваливали сеть повторными проверками при заминке, именно так уже случались сбои UPI) и обязательные сроки со штрафом за просроченный возврат при сбое. Продуктовым и финтех-командам, выбирающим банк-партнёра для запуска платёжного сервиса, стоит учитывать пример из статьи: несколько банков-спонсоров одновременно повышают отказоустойчивость сильнее, чем один даже самый надёжный банк.

Можно ли доверять

Материал ссылается на конкретные источники: процедурные руководства NPCI по UPI, документацию Razorpay и Google Pay, а также собственные многолетние ряды данных, обновлённые по июнь 2026 года, то есть выводы о трендах отказов и распределении долей банков опираются на публикуемую статистику, а не на предположения автора. При этом сам материал опубликован не самим NPCI, а сторонним изданием, специализирующимся на анализе данных (timeseriesofindia.com), поэтому конкретные цифры стоит сверять с первоисточниками перед тем, как опираться на них в решениях, а не полагаться только на пересказ. Прямых цитат от представителей NPCI, банков или приложений в статье нет, это разбор архитектуры и статистики, а не журналистское расследование с комментариями участников.

Риски и подводные камни

Статья явно предупреждает не путать «банк-получатель» в статистике с банком, где у продавца открыт собственный счёт: банк-получатель, это лишь спонсор QR-кода. Отдельный риск, который отмечает сам материал: слишком частые запросы статуса платежа со стороны приложений уже становились причиной сбоев самой сети UPI, то есть наивная реализация проверки статуса на стороне клиента способна навредить общей системе. Есть и структурный риск концентрации: около 80% рынка приложений держат всего два игрока (PhonePe и Google Pay), а подавляющая часть зачислений от продавцов идёт через один банк-спонсор (Yes Bank), поэтому сбой любого из них способен задеть непропорционально большую долю всех платежей страны. Наконец, при всей растущей надёжности системы общенациональные отключения UPI на несколько часов уже случались и, по словам автора, «реальны и памятны», полностью исключить крупный сбой архитектура не может.