India: UPI e IMPS generan datos de pago distintos y colas de problemas distintas

«El cliente pagó por UPI, así que el dinero ya es nuestro»: mal comienzo para una investigación, y con IMPS pasa lo mismo. En la pantalla del comprador puede haber una confirmación; en la caja, un pedido abierto; en el proveedor, un evento posterior, y en el extracto bancario, un movimiento sin un número de pedido claro. No son cuatro pagos. Son cuatro vistas de una misma operación que el procesamiento debe vincular antes de aumentar el saldo disponible.

Conviene comparar UPI e IMPS como mecanismos de pago, no como aplicaciones. El nombre de la aplicación responde a dónde pulsó el botón el usuario. No determina el contrato del receptor, el conjunto de pruebas, la actividad permitida ni el procedimiento de devolución. A continuación se tratan operaciones comerciales legales; disponer de un método de pago indio no abre por sí solo el mercado de los juegos de azar.

Primero defina qué se ha integrado exactamente

NPCI describe UPI como un sistema de pagos inmediatos construido sobre la infraestructura de IMPS. Para aceptar pagos comerciales se necesita un adquirente, que define la categoría del comercio y proporciona la integración. Una dirección UPI, un QR o el salto a una aplicación no convierten una cuenta personal corriente en un producto comercial acordado. La descripción de NPCI es útil para entender los roles de los participantes, pero los ejemplos antiguos de escenarios de usuario no pueden tomarse automáticamente como la especificación vigente para un lanzamiento.

En IMPS, el enrutamiento habitual usa el número de cuenta y el IFSC; la documentación también describe la combinación del número móvil con el MMID. El IFSC corresponde a la ruta bancaria y el MMID al esquema de identificación correspondiente. No sustituyen al merchant order ID. NPCI fija un límite de IMPS de 500 000 INR por operación, salvo SMS e IVR; cada banco puede limitar con más rigor el canal disponible para el cliente.

Qué campos no conviene fusionar

La ficha de pago recomendada debe incluir el número interno del pedido, el número de intento, el tipo de riel, el identificador de pago del proveedor, la reference bancaria en su forma original, el importe, la moneda, la hora de creación y la hora de confirmación. Los datos de destino se guardan en una instantánea aparte: para UPI, la dirección de pago correspondiente y el contexto comercial; para una transferencia bancaria, la cuenta y el código bancario. El registro en sí no debe contener PIN, OTP ni contraseñas bancarias.

¿Por qué hace falta precisamente una instantánea? Los datos de pago pudieron cambiarse después de crear el pedido, y el cliente pudo pagar con la instrucción antigua. Si el sistema solo muestra el receptor actual, la investigación se convierte en una discusión sobre la memoria. Se necesitan las condiciones entregadas a ese intento concreto y el abono real en ese momento. Además, que coincidan importe y hora es solo una pista de búsqueda, no una prueba de que el dinero pertenezca a un pedido determinado.

No obligue al operador a adivinar qué significa el campo «UTR» en el informe de un intermediario. Pida un glosario: quién generó el valor, si es único dentro del banco o de toda la integración, si se conserva tras una devolución y si sirve para consultar el estado. Una interfaz puede mostrar la reference del cliente y otra el identificador de la pasarela. La falta de una correspondencia documentada genera costos reales de soporte.

La página de éxito y el estado del dinero van por separado

Razorpay, por ejemplo, tiene los eventos payment.authorized y payment.captured; su documentación advierte que el webhook transmite el estado en el momento del evento, aunque el objeto ya haya cambiado. Es el modelo de una pasarela concreta, no estados universales de UPI. Para la caja propia sirve el mismo principio: verificar la autenticidad del evento, cotejar importe y pedido, guardar el estado original y contabilizar el asiento financiero una sola vez.

Imaginemos un caso de estudio: el pedido venció a las 12:05 y la confirmación llegó a las 12:06. No se puede, al mismo tiempo, declarar el intento definitivamente impagado, emitir un nuevo pago y volver a contabilizar automáticamente el anterior. Cree una cola de confirmaciones tardías. Esa cola debe decidir si se restablece el pedido o si se tramita una devolución según el procedimiento aprobado. En ambos casos, el usuario recibe un resultado claro y contabilidad conserva el vínculo con el intento original.

La reversión tras una falla y la devolución de una compra son procesos distintos

Las reglas del RBI sobre operaciones fallidas distinguen entre un cargo sin abono al receptor y un pago UPI en el que el comercio no recibió la confirmación. La tabla publicada indica, para esos casos, T+1 y T+5 respectivamente, con compensación si se supera el plazo. Son plazos para corregir determinadas fallas técnicas, no una promesa de devolver cualquier compra en el mismo tiempo. T es la fecha natural de la operación. Tabla del RBI.

Por eso el ticket debe recibir primero una categoría. ¿Hubo cargo? ¿Hay un abono confirmado? ¿El pedido se canceló por una razón comercial o la operación no se completó? ¿Se ejecutó un refund aparte? Si simplemente se le transfiere al cliente el mismo importe con una nueva transferencia, la operación original quedará abierta, y un reversal automático tardío puede generar un doble reembolso.

El pago inmediato no describe su contrato de liquidación

La pregunta «cuándo tiene el dinero el comercio» exige nombrar la cuenta. Puede ser una cuenta comercial o intermedia acordada en el contrato de adquirencia. El saldo interno del PSP, el saldo disponible y el abono en la cuenta corriente de la empresa no son sinónimos. Pida un modelo de settlement report: gross, comisión, retenciones fiscales, devoluciones, reserva y net. Después compruebe que el net aparece realmente en el extracto bancario.

Aclare también los límites por separado: por operación, por día, por tipo de pagador, por categoría de comercio y por canal. Una cifra de un FAQ antiguo no puede convertirse en el límite universal de todos los pagos UPI. En el piloto se prueban los importes límite autorizados y los rechazos normales; fraccionar pagos para eludir controles no es admisible.

El límite para los proyectos de juego

La ley india Promotion and Regulation of Online Gaming Act, 2025 prohíbe en su sección 7 facilitar pagos para un online money gaming service; la definición de juegos con dinero no se limita a los juegos de azar. MeitY publica además reglas y notificaciones de 2026. Una licencia de juego extranjera no autoriza a aceptar esos pagos en India. Antes de hablar de una integración se necesita un dictamen jurídico actualizado sobre el producto concreto, las normas aplicables y las resoluciones judiciales.

El criterio práctico de preparación es simple: el equipo debe reconstruir un pago desde los datos de pago mostrados hasta el abono, después hasta la liquidación al comercio y una posible devolución. Si eso solo se logra con capturas de pantalla y mensajes de chat, la integración aún no está lista para crecer, aunque las primeras diez transferencias se hayan acreditado al instante.