UPI India: QR, VPA y límites

1) Qué es UPI

La Interfaz de Pagos Unified (UPI) es un bus de pago nacional de la India operado por NPCI. Proporciona transferencias instantáneas 24/7 entre cuentas bancarias y aplicaciones de fintech (PSP). Para el usuario y merchant, UPI es una sola capa de direccionamiento (VPA), confirmación (2FA) y compensación, sobre la cual se construyen escenarios P2P y P2M.

• Interoperabilidad: cualquier aplicación UPI ↔ cualquier banco/cuenta.
• Direccionamiento sin detalles: VPA de la vista 'nombre @ handle' en lugar de IFSC/cuenta.
• Instantaneidad y finalidad: la traducción se confirma inmediatamente; devoluciones por separado.
• Costes bajos para el merchant: la regulación MDR/circuitos reduce el coste de recaudación.

2) Participantes del ecosistema

NPCI (esquema/switch): routing, reglas, certificación.
Bancos PSP y PSP no bancarios (aplicaciones Front-End): aplicaciones de cliente (PhonePe, Google Pay, Paytm, etc.), SDK/APIs para merchantes.
Acquirer/Issuer: banco-ecuador del merchant y banco-emisor del pagador.
Merchant PSP: proveedor de recepción de UPI para empresas (SDK, QR, Intent, reconciliation).

3) Identificadores: VPA y datos

VPA (Virtual Payment Address) es el identificador principal de UPI: 'user @ psphandle' o 'merchantname @ acquirer'.

• Se vincula a una cuenta bancaria/nodo en UPI.
• Puede ser personal (P2P) o merchant (P2M) con datos de negocio incluidos.
• Admite solicitudes de pago (collect request), facturas y metadatos (orderId, purpose, MCC).

4) Pagos QR: estático vs dinámico

QR estático

Contiene VPA/handle merchant, a veces campos fijos (MCC, nombre).
El importe es ingresado manualmente por el pagador (adecuado para cafeterías/pequeños comercios).
Pros: simplicidad, impresión una vez. Contras: riesgos de una cantidad incorrecta, más débiles que los analistas.

QR dinámico (por orden)

Se genera por cada cheque: incluye la cantidad, el IdOrden, el campo purpose, los descuentos opcionales, las etiquetas prop.
Escaneo → la aplicación del pagador abre una factura de suma fija.
Pros: menos errores, más fácil de conciliar, lealtad y evidencia anti-retorno.

Intent & Deep-Link Flow

En lugar de escanear, la aplicación de merchant ejecuta el cliente UPI por URI deeplink/Intent, pasando la suma y los metadatos.
Conveniente en e-commerce/aplicaciones, le permite construir un UX uniforme sin cámara.

5) Flujos de pago estándar

P2P (pull/push): transferencia entre usuarios por VPA/teléfono/QR.
P2M (push): el comprador inicia el pago (scan/pay).
Collect Request (pull para merchant): el merchant pone la solicitud, el comprador confirma en su aplicación UPI.
AutoPay (e-mandate): suscripción con preautorización de límite y periodicidad, el débito se inicia por mandato sin confirmación manual de cada transacción (hasta límite).

6) Límites de UPI: cómo funcionan

Los límites están determinados por las reglas del esquema, las políticas RBI/NPCI, los bancos emisores y, a veces, la categoría de merchant. Pueden variar según los participantes, el perfil de riesgo y el canal.

1. Por-transaction cap (por transacción): valor «típico» para la mayoría de los scripts de retail - hasta ~₹1,00,000 (1 lach) por pago; para las categorías seleccionadas arriba/abajo.

2. Cap por día (por día): límite para el volumen total/cole de las transacciones de la aplicación de pago/banco.

3. Límites categóricos: para ciertos MCC (por ejemplo, inversión, educación/medicina, boletos, servicios públicos), puede haber umbrales elevados/separados.

4. Nuevos destinatarios/temporizadores de riesgo: la primera vez que se transfiere a una nueva VPA, es posible reducir los límites y la velocidad de obturación.

5. UPI Lite (micropagos fuera de línea): monedero en el dispositivo/banco para pequeños pagos fuera de línea; los límites están por debajo de las UPI normales y se especifican por separado (per-txn y día).

6. AutoPay (e-mandate): límite para los cargos automáticos sin autenticación repetida: se fija en el mandato; para diferentes categorías - diferentes umbrales.

7. Script/channel: intents/QR pueden tener sus propias validaciones (anti-abuse, velocity).

7) Seguridad y autenticación

2FA: confirmación en la aplicación UPI (PIN/biometría) + ligamento con el dispositivo/SIM ranura/cuenta.
Device binding: anti-frod a nivel de aplicación PSP.
Políticas de riesgo en tiempo real: cheque velocity, plantillas de lista de espera/fraudulentas, verificación del nombre del destinatario (beneficiary name display).
UPI Lite y offline: microlimites + delayed-post en el núcleo para reducir los riesgos.

8) Tarifas y comisiones (MDR)

• abonar/SDK fee por el acervo de UPI,
• cargos por servicios adicionales (QR dinámico, reconciliation API, anotaciones, informes),
• gastos de soporte, dispouts y devoluciones.

9) Devoluciones, devoluciones parciales y dispouts (ODR)

Chargeback está ausente en el sentido de la tarjeta. La devolución es una nueva operación de crédito del merchant al pagador, con referencia a la transacción original.
La referencia parcial se admite (por importe).
ODR (Online Dispute Resolution): proceso estándar de resolución de reclamaciones en línea - estados, SLA, causa de denegación, pruebas (registro de pago, cheque, factura de producto).
Plazos: dependen del banco/PSP; insertar en los reglamentos de soporte.

10) Integración de merchant: opciones

1. UPI QR estático: mínimo de desarrollo; Bueno para POS/SMB.
2. UPI QR dinámico: el servidor genera QR por encargo; mejor conciliación de la cantidad/orden.
3. Intent/Deep Link: UX móvil sin cámara; web checkout → «Abrir una aplicación UPI».
4. Collect (request-to-pay): el merchant inicia una «cuenta», el cliente confirma.
5. SDK/JS/Native: módulos PSP listos para Android/iOS/web con procesamiento de estado.

• generación de payload de pago (VPA/suma/etiquetas),
• colback-endpoint para el pago acertado/fallido,
• reconciliation (conciliación) por TID/RRN/UTR,
• refund manual/automático,
• monitoreo de SLA PSP/bancos.

11) Conciliación y presentación de informes (UTR, estados)

UTR (Unique Transaction Reference) es un identificador de cálculo único en un riel bancario; guárdelo para todas las operaciones.
En los informes PSP: parámetros de origen (VPA, suma, orderId), estados (iniciated, pending, success, failure), actualizaciones tardías, devoluciones.
Obligatorio el auto-recon diario y el full-recon periódico (bóveda con banco/PSP).

12) Offline y disponibilidad sin smartphone

UPI Lite (micropagos fuera de línea): para pequeñas cantidades; las transacciones se confirman sin solicitud de red, posting - más tarde.
UPI 123PAY/IVR/feature-phone: pago por número/menú IVR.
Tap-and-Pay (NFC-UPI): scripts sin contacto donde se admite.

13) Border cross (UPI Global)

La UPI se está integrando progresivamente con los raíles extranjeros/asociaciones de países (por ejemplo, escaneando UPI-QR de India por turistas o indios en el extranjero en redes de socios). El soporte y los límites dependen del par de países/socios y del banco emisor.

14) Riesgos, AML/KYC, cumplimiento

Los niveles de KYC en PSP/bancos afectan los límites.
AML/sanciones: filtros de destinatarios/destino, monitoreo de anomalías.
Fred Casing: el reembolso no es posible sin el consentimiento del merchant → es necesaria una verificación estricta del pedido (QR dinámico, cheque, geo/device).
Régimen legal de la industria: existen restricciones para los verticales individuales (categorías MCC, licencias, geoblock en los estados/UT). Planifique con los abogados la aceptación local de UPI para su tipo de negocio.

15) Diseño de UX y mejores prácticas

Superficie de error: muestra explícitamente el temporizador, las instrucciones y cómo repetir el pago.
Idempotency: 'orderId' + clave de idempotencia para repeticiones seguras.
Fallback: si el Intent no se ha abierto, ofrece QR y «copia el VPA/suma».
Límites en la interfaz: avisa del exceso y sugiere el fraccionamiento de los cheques donde se permite.
Fiabilidad: retraídas por exponente para estado, webhooks + pull-API.
Transparencia: cheque con UTR, cantidad, fecha/hora, VPA merchant, contacto de soporte.

16) Lista de verificación de integración (P2M)

1. Obtener VPA/handle merchant de PSP.
2. Seleccionar canal: QR estático/dinámico, Intent, Collect.
3. Implementar la generación de payload y embutidos seguros.
4. Habilitar la reconciliación por UTR/OrderId (daily + full).
5. Configurar devoluciones (parciales/completas), registros y ODR.
6. Introduzca reglas antifraude (velocity, nuevos destinatarios, retroiluminación MCC de alto riesgo).
7. UI/UX: sugerencias, errores, repetición, visualización de límites.
8. Establecer el monitoreo de SLA PSP/bancos, alertas e informes.
9. Realizar pruebas end-to-end con clientes reales de UPI.
10. Actualizar regularmente los límites/reglas (por banco/categoría).

17) Tarjeta de límites (puntos de referencia para el diseño)

Per-txn (venta al por menor): punto de referencia hasta ~₹1,00,000.
Por día: umbral diario total por lata/aplicación; se establece localmente.
UPI Lite: sustancialmente por debajo de la UPI normal (micropagos).
AutoPay (e-mandate): límite de transacción sin repetición de 2FA - por mandato/categoría.
Nuevos beneficiarios: límites únicos reducidos y/o retrasos.
Categorías con topes elevados: dependen de los funcionarios subalternos del cuadro orgánico/reglas del banco (ejemplo: educación/medicina/pasajes/escenarios de inversión - por acuerdo).

18) Comparación de estrategias QR para merchant

19) Qué considerar iGaming/verticales de alto riesgo

Compruebe si la categoría es válida en PSP/banco y si cumple con la ley local.
Espere los límites estrechos y el requisito de KYC/ODR avanzado.
Considere los rieles alternativos para el depósito/retiro y la segmentación estricta del tráfico.

20) Notas arquitectónicas

• endpoints: `createPaymentIntent`, `generateDynamicQR`, `refund`, `reconcile`, `webhook`.
• la idempotencia a través de las claves y la tabla dedupe.
• colas de eventos (bus de eventos) para estados y contabilidad.
• observabilidad: métricas (éxito/fallas/latencia), rastreo, alertas.
• Titularidad: firmas HMAC de webhooks, allowlist IP PSP, rotación secreta.

Resumen de producción

Apueste por QR dinámico y/o Intent.
No codifique duramente los límites - configuración + actualización por banco/PSP.
Incluye la conciliación UTR, las devoluciones parciales y el flow ODR.
Cubra UX con scripts de rebote, repeticiones y cheques transparentes.
Revise periódicamente la política de límites y categorías junto con PSP.