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 - за мандатом/категорією.
Нові бенефіціари: знижені разові ліміти та/або затримки.
Категорії з підвищеними стелями: залежать від МСС/правил банку (приклад: освіта/медицина/квитки/інвестиційні сценарії - за погодженням).

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.