UPI Индия: QR, VPA и лимиты

1) Что такое UPI

Unified Payments Interface (UPI) — национальная платежная шина Индии, управляема NPCI. Она обеспечивает мгновенные переводы 24/7 между банковскими счетами и финтех-приложениями (PSP). Для пользователя и мерчанта UPI — это единый слой адресации (VPA), подтверждения (2FA) и клиринга, поверх которого строятся P2P и P2M-сценарии.

• Интероперабельность: любые UPI-приложения ↔ любые банки/счета.
• Адресация без реквизитов: VPA вида `имя@handle` вместо IFSC/счета.
• Мгновенность и финальность: перевод подтверждается сразу; возвраты — отдельной операцией.
• Низкие издержки для мерчанта: регулирование по MDR/схемам снижает стоимость инкассации.

2) Участники экосистемы

NPCI (схема/свитч): роутинг, правила, сертификация.
PSP-банки и non-bank PSP (Front-End Apps): клиентские приложения (PhonePe, Google Pay, Paytm и др.), SDK/APIs для мерчантов.
Acquirer/Issuer: банк-эквайер мерчанта и банк-эмитент плательщика.
Merchant PSP: провайдер приема UPI для бизнеса (SDK, QR, Intent, reconciliation).

3) Идентификаторы: VPA и реквизиты

VPA (Virtual Payment Address) — основной идентификатор UPI: `user@psphandle` или `merchantname@acquirer`.

• Привязывается к банковскому счету/ноде в UPI.
• Может быть персональным (P2P) или мерчантским (P2M) с включенными реквизитами бизнеса.
• Поддерживает запрос платежа (collect request), инвойсы и метаданные (orderId, purpose, MCC).

4) QR-платежи: статический vs динамический

Статический QR

Содержит VPA/handle мерчанта, иногда — фиксированные поля (MCC, название).
Сумма вводится плательщиком вручную (подходит для кафе/малого ритейла).
Плюсы: простота, печать один раз. Минусы: риски неверной суммы, слабее аналитика.

Динамический QR (per-order)

Генерируется на каждый чек: включает сумму, orderId, поле purpose, необязательные скидки, prop-метки.
Скан → приложение плательщика открывает инвойс с фиксированной суммой.
Плюсы: меньше ошибок, проще сверка, лояльность и антивозвратные доказательства.

Intent & Deep-Link Flow

Вместо сканирования приложение мерчанта запускает UPI-клиент по deeplink/Intent URI, передавая сумму и метаданные.
Удобно в e-commerce/приложениях, позволяет строить ровный UX без камеры.

5) Типовые платежные потоки

P2P (pull/push): перевод между пользователями по VPA/телефону/QR.
P2M (push): покупатель инициирует оплату (scan/pay).
Collect Request (pull для мерчанта): мерчант выставляет запрос, покупатель подтверждает в своем UPI-приложении.
AutoPay (e-mandate): подписка с предавторизацией лимита и периодичности, дебет инициируется по мандату без ручного подтверждения каждую операцию (до лимита).

6) Лимиты UPI: как они работают

Лимиты определяются правилами схемы, политиками RBI/NPCI, банками-эмитентами и иногда — категорией мерчанта. Они могут различаться по участникам, рисковому профилю и каналу.

1. Per-transaction cap (на операцию): «типичное» значение для большинства retail-сценариев — до ~₹1,00,000 (1 лакх) на платеж; для отдельных категорий выше/ниже.

2. Per-day cap (на сутки): ограничение на суммарный объем/кол-во операций по платежному приложению/банку.

3. Категорийные лимиты: для определенных MCC (например, инвестиции, образование/медицина, билеты, коммунальные) могут действовать повышенные/отдельные пороги.

4. Новые получатели / риск-таймауты: при первом переводе на новый VPA возможны пониженные разовые лимиты и выдержка.

5. UPI Lite (офлайн-микроплатежи): кошелек на устройстве/банке для мелких оффлайн-платежей; лимиты ниже обычных UPI и задаются отдельно (per-txn и дневной).

6. AutoPay (e-mandate): лимит на автоматические списания без повторной аутентификации — фиксируется в мандате; для разных категорий — разные пороги.

7. Сценарные/канальные: intents/QR могут иметь собственные валидации (анти-абьюз, velocity).

7) Безопасность и аутентификация

2FA: подтверждение в UPI-приложении (PIN/биометрия) + связка с устройством/сим-слотом/учеткой.
Device binding: анти-фрод на уровне приложения PSP.
Risk-политики в реальном времени: velocity-чек, санклист/мошеннические шаблоны, проверка имени получателя (beneficiary name display).
UPI Lite и оффлайн: микролимиты + delayed-постинг в ядро для снижения рисков.

8) Тарифы и комиссии (MDR)

• абонплату/SDK fee за эквайринг UPI,
• плату за доп. сервисы (динамический QR, reconciliation API, аннотации, отчеты),
• расходы на поддержку, диспуты и возвраты.

9) Возвраты, частичные возвраты и диспуты (ODR)

Chargeback в карточном смысле отсутствует. Возврат — это новая кредитовая операция от мерчанта плательщику, с ссылкой на исходную транзакцию.
Partial refund поддерживается (по сумме).
ODR (Online Dispute Resolution): стандартный процесс урегулирования претензий в онлайне — статусы, SLA, причина отказа, доказательства (лог оплаты, чек, товарная накладная).
Сроки: зависят от банка/PSP; закладывайте в регламенты поддержки.

10) Интеграция мерчанта: варианты

1. Статический UPI QR: минимум разработки; хорошо для POS/SMB.
2. Динамический UPI QR: сервер генерирует QR на заказ; лучшее выверение суммы/заказа.
3. Intent/Deep Link: мобильный UX без камеры; web checkout → «Открыть UPI-приложение».
4. Collect (request-to-pay): мерчант инициирует «счет», клиент подтверждает.
5. SDK/JS/Native: готовые модули PSP для Android/iOS/web с обработкой статусов.

• генерация платежного payload (VPA/сумма/метки),
• колбэк-эндпоинт на успешную/неуспешную оплату,
• reconciliation (сверка) по TID/RRN/UTR,
• ручной/автоматический refund,
• мониторинг SLA PSP/банков.

11) Сверка и отчетность (UTR, статусы)

UTR (Unique Transaction Reference) — уникальный идентификатор расчета в банковском рельсе; сохраняйте его для всех операций.
В отчетах PSP: исходные параметры (VPA, сумма, orderId), статусы (initiated, pending, success, failure), поздние обновления, возвраты.
Обязателен ежедневный auto-recon и периодический full-recon (свод с банком/PSP).

12) Оффлайн и доступность без смартфона

UPI Lite (оффлайн микроплатежи): для малых сумм; транзакции подтверждаются без сетевого запроса, постинг — позже.
UPI 123PAY / IVR / feature-phone: оплата по номеру/IVR-меню.
Tap-and-Pay (NFC-UPI): бесконтактные сценарии там, где поддержано.

13) Кросс-бордер (UPI Global)

UPI постепенно интегрируется с иностранными рельсами/страновыми партнерствами (например, сканирование индийских UPI-QR туристами или индийцами за рубежом в партнерских сетях). Поддержка и лимиты зависят от пары стран/партнеров и банка-эмитента.

14) Риски, AML/KYC, комплаенс

KYC уровни у PSP/банков влияют на лимиты.
AML/санкции: фильтры получателей/назначения, мониторинг аномалий.
Фрод-кейсинг: возврат средств невозможен без согласия мерчанта → необходима строгая верификация заказа (динамический QR, чек, гео/девайс).
Правовой режим отрасли: для отдельных вертикалей действуют ограничения (категории MCC, лицензирование, геоблок в штатах/UT). Планируйте с юристами локальную допустимость приема UPI для вашего вида бизнеса.

15) Проектирование UX и best-practices

Поверхность ошибок: явно показывайте таймер, инструкции и как повторить оплату.
Idempotency: `orderId` + ключ идемпотентности для safe-повторов.
Fallback: если Intent не открылся, предложите QR и «копировать VPA/сумму».
Лимиты в интерфейсе: предупреждайте о превышении и предлагаете дробление чеков там, где дозволено.
Надежность: ретраи по экспоненте для статуса, webhooks + pull-API.
Прозрачность: чек с UTR, сумма, дата/время, VPA мерчанта, контакт поддержки.

16) Чек-лист интеграции (P2M)

1. Получить мерчантский VPA/handle у PSP.
2. Выбрать канал: статический/динамический QR, Intent, Collect.
3. Реализовать генерацию payload и безопасные колбэки.
4. Включить reconciliation по UTR/OrderId (daily + full).
5. Настроить возвраты (частичные/полные), логи и ODR.
6. Ввести антифрод-правила (velocity, новые получатели, подсветка high-risk MCC).
7. UI/UX: подсказки, ошибки, повтор, отображение лимитов.
8. Наладить мониторинг SLA PSP/банков, алерты и отчетность.
9. Провести end-to-end тесты с реальными UPI-клиентами.
10. Регулярно актуализировать лимиты/правила (по банкам/категориям).

17) Карточка лимитов (ориентиры для проектирования)

Per-txn (розница): ориентир до ~₹1,00,000.
Per-day: суммарный дневной порог по банку/приложению; задается локально.
UPI Lite: существенно ниже обычного UPI (микроплатежи).
AutoPay (e-mandate): лимит на транзакцию без повторной 2FA — по мандату/категории.
Новые бенефициары: пониженные разовые лимиты и/или задержки.
Категории с повышенными потолками: зависят от MCC/правил банка (пример: образование/медицина/билеты/инвестиционные сценарии — по согласованию).

18) Сравнение QR-стратегий для мерчанта

19) Что учесть iGaming/высокорисковым вертикалям

Проверяйте допустимость категории у PSP/банка и соответствие локальному праву.
Ожидайте суженные лимиты и требование расширенного KYC/ODR.
Рассматривайте альтернативные рельсы для депозита/вывода и строгую сегментацию трафика.

20) Архитектурные заметки

• endpoints: `createPaymentIntent`, `generateDynamicQR`, `refund`, `reconcile`, `webhook`.
• идемпотентность через ключи и таблицу dedupe.
• очереди событий (event bus) для статусов и бухгалтерии.
• observability: метрики (успех/отказы/латентность), трассировка, алерты.
• секьюрность: HMAC-подписи вебхуков, allowlist IP PSP, secret rotation.

Резюме для продакшена

Делайте ставку на динамический QR и/или Intent.
Не хардкодьте лимиты — конфиг + актуализация по банкам/PSP.
Включайте UTR-сверку, частичные возвраты и ODR-флоу.
Покрывайте UX сценариями отказов, повторами и прозрачными чеками.
Регулярно пересматривайте политику лимитов и категорий вместе с PSP.