Индия: UPI и IMPS дают разные реквизиты и разные очереди проблем

«Клиент отправил через UPI, значит деньги уже наши» — плохое начало разбирательства. На экране покупателя может быть подтверждение, в кассе — незакрытый заказ, у провайдера — более позднее событие, а в банковской выписке — движение без понятного номера заказа. Это не четыре платежа. Это четыре представления одной операции, которые процессинг должен связать, прежде чем увеличивать доступный баланс.

UPI и IMPS стоит сравнивать как платёжные механизмы, а не как приложения. Название приложения отвечает на вопрос, где пользователь нажал кнопку. Оно не определяет договор получателя, набор доказательств, разрешённую деятельность и порядок возврата. Ниже рассматриваются законные торговые операции; наличие индийского платёжного метода само по себе не открывает рынок азартных игр.

IMPS — это что и чем он отличается от UPI

IMPS (Immediate Payment Service) — это система мгновенных межбанковских переводов, которую NPCI запустила в 2010 году. Перевод проходит круглосуточно, включая выходные, и обычно адресуется по номеру счёта и IFSC банка получателя. UPI работает поверх той же инфраструктуры, но адресует платёж по виртуальному адресу (UPI ID вида «имя@банк») или QR-коду и добавляет торговые сценарии. Для мерчанта отсюда главное: у двух рельсов разные реквизиты, разные идентификаторы в выписке и разные правила разбора сбоев.

Сначала определите, что именно интегрировано

NPCI описывает UPI как систему мгновенных платежей, построенную поверх инфраструктуры IMPS. Для приёма торговых платежей нужен эквайер; он определяет категорию мерчанта и предоставляет интеграцию. UPI-адрес, QR и переход в приложение не превращают обычный личный счёт в согласованный торговый продукт. Описание NPCI полезно для ролей участников, но старые примеры пользовательских сценариев нельзя автоматически считать актуальной спецификацией запуска.

В IMPS привычная маршрутизация использует номер счёта и IFSC; документация также описывает комбинацию мобильного номера с MMID. IFSC относится к банковскому маршруту, MMID — к соответствующей схеме идентификации. Это не замена merchant order ID. NPCI указывает предел IMPS в 500 000 INR на операцию, кроме SMS и IVR; конкретный банк может ограничивать доступный клиенту канал строже.

Какие поля не стоит склеивать

Рекомендуемая карточка платежа должна содержать внутренний номер заказа, номер попытки, тип рельса, идентификатор платежа провайдера, банковский reference в исходном виде, сумму, валюту, время создания и время подтверждения. Реквизиты назначения сохраняют отдельным снимком: для UPI это соответствующий платёжный адрес и торговый контекст, для банковского перевода — счёт и банковский код. Сам реестр не должен содержать PIN, OTP или банковские пароли.

Почему нужен именно снимок? Реквизит могли заменить после создания заказа, а клиент мог заплатить по старой инструкции. Если система показывает только нынешнего получателя, расследование превращается в спор о памяти. Нужны условия, выданные конкретной попытке, и фактическое зачисление на тот момент. При этом совпадение суммы и времени — только поисковая подсказка, не доказательство принадлежности денег определённому заказу.

Не заставляйте оператора угадывать, что означает поле «UTR» в отчёте посредника. Попросите словарь: кто сформировал значение, уникально ли оно в пределах банка или всей интеграции, сохраняется ли после возврата, доступно ли для запроса статуса. Один интерфейс может показывать клиентский reference, другой — идентификатор шлюза. Отсутствие документированного соответствия создаёт реальные расходы поддержки.

Успешная страница и денежный статус живут отдельно

У Razorpay, например, есть события payment.authorized и payment.captured; документация предупреждает, что webhook передаёт состояние на момент события, даже если объект уже изменился. Это конкретная модель шлюза, не универсальные статусы UPI. Для собственной кассы полезен тот же принцип: проверять подлинность события, сверять сумму и заказ, сохранять исходный статус и проводить финансовую запись один раз.

Представим учебный случай: заказ истёк в 12:05, а подтверждение пришло в 12:06. Нельзя одновременно объявить попытку окончательно неоплаченной, выдать новый платёж и автоматически засчитать старый повторно. Введите очередь поздних подтверждений. Она должна решить, восстанавливать ли заказ или оформлять возврат по утверждённой процедуре. В обоих вариантах пользователь получает понятный итог, а бухгалтерия сохраняет связь с первоначальной попыткой.

Возврат после сбоя и возврат покупки — разные процессы

Правила RBI о неуспешных операциях различают списание без зачисления получателю и UPI-платёж, при котором торговая точка не получила подтверждение. В опубликованной таблице для соответствующих случаев указаны T+1 и T+5 соответственно, с компенсацией за превышение срока. Это сроки исправления определённых технических сбоев, а не обещание вернуть любую покупку за такое же время. T означает календарную дату операции. Таблица RBI.

Поэтому тикет должен сначала получить категорию. Было ли списание? Есть ли подтверждённое зачисление? Заказ отменён по коммерческой причине или операция не состоялась? Выполнен ли отдельный refund? Если клиенту просто перечислить такую же сумму новым переводом, исходная операция останется незакрытой, а поздний автоматический reversal может создать двойное возмещение.

Мгновенная оплата не описывает ваш расчётный договор

Вопрос «когда деньги у мерчанта» требует назвать счёт. Это может быть согласованный торговый или промежуточный счёт по договору эквайринга. Внутренний баланс PSP, доступный остаток и зачисление на расчётный счёт предприятия нельзя считать синонимами. Попросите образец settlement report: gross, комиссия, налоговые удержания, возвраты, резерв и net. Затем проверьте, что net действительно находится в банковской выписке.

Отдельно уточните лимиты: одна операция, сутки, тип плательщика, категория мерчанта и канал. Число из старого FAQ нельзя превратить в универсальный предел всех UPI-платежей. В пилоте тестируют разрешённые пограничные суммы и штатные отказы; дробить платежи ради обхода контроля недопустимо.

Граница для игровых проектов

Индийский Promotion and Regulation of Online Gaming Act, 2025 содержит запрет содействия платежам для online money gaming service в разделе 7; определение денежных игр не ограничивается играми случая. MeitY публикует также правила и уведомления 2026 года. Иностранная игровая лицензия не является разрешением принимать такие платежи в Индии. Перед обсуждением подключения требуется актуальное юридическое заключение о конкретном продукте, применимых нормах и судебных решениях.

Практический критерий готовности прост: команда должна восстановить один платёж от показанных реквизитов до зачисления, затем до расчёта с мерчантом и возможного возврата. Если это удаётся только по скриншотам и сообщениям в чате, подключение ещё не готово к росту, даже когда первые десять переводов прошли мгновенно.