UPI: el comprador volvió a la tienda, pero ¿se puede entregar el pedido?

El cliente cerró la app de pagos y volvió a la tienda. Para la interfaz, el recorrido terminó. Para el pedido, la pregunta principal sigue abierta: ¿recibió el comercio una confirmación de pago UPI verificable del pago correcto? En UPI conviene diseñar dos cadenas relacionadas: el recorrido del comprador mediante Intent o QR y la verificación independiente del resultado del lado del negocio.

La base deben ser los registros de pago verificados del lado del comercio. La forma de mostrar al comprador la solicitud de pago y la forma de confirmar la entrega del pedido son partes distintas del sistema. Si se mezclan, una experiencia de usuario atractiva puede ocultar un proceso operativo poco fiable.

Primero, entienda la mecánica

NPCI describe UPI como un sistema de pagos instantáneos y enumera las formas de integración para comercios, incluidos QR e Intent. Esto ayuda a entender los términos, pero no garantiza que cada variante descrita históricamente esté disponible para un negocio concreto. Preguntas frecuentes de NPCI sobre UPI.

• Intent: la página de pago abre una app de pagos compatible con los datos de la operación, donde el comprador continúa el pago.
• QR: el comprador escanea los datos de pago codificados con una app adecuada.
• Collect: en el modelo de solicitud, se envía al pagador una petición a su identificador UPI para que la apruebe.

Esta mecánica se describe en los materiales de producto de NPCI. Una descripción antigua debe leerse como explicación de cómo funciona el flujo, no como prueba de que hoy esté disponible. Folleto de producto de NPCI.

Las reglas aplicables deben comprobarse por separado. Por ejemplo, PayU orienta a los comercios nuevos hacia Intent y QR y reserva Collect para excepciones definidas. Antes de construir la integración en torno a la solicitud, verifique con su proveedor qué variante admite. La aceptación de pagos comerciales y las transferencias P2P personales no son intercambiables. Documentación de PayU.

Vincule el proceso a un solo pedido

Consideremos una compra hipotética de 2 400 rupias indias. El comercio crea su propio número de pedido y, a través de un proveedor aprobado, inicia un flujo admitido. El importe, la moneda y el destinatario esperados deben quedar vinculados a ese número. Que el usuario vuelva al sitio es un evento de la interfaz, pero por sí solo no basta para entregar el producto.

Por ejemplo, la guía de Razorpay exige verificar la firma del pago y describe cómo obtener el estado mediante el panel, las notificaciones o la API. La recomendación para completar el pedido está ligada al estado captured. Es terminología de Razorpay: con otro proveedor hay que identificar el estado de finalización documentado equivalente. Pasos de integración de Razorpay.

En su propio proceso, empareje el pago verificado con el pedido esperado. Compruebe los identificadores asociados, el importe y la moneda, así como que el resultado pertenezca al esquema acordado del comercio. Conserve el motivo por el que el pedido pasó a estado pagado, para que soporte pueda reconstruir la secuencia de eventos.

Prevea una respuesta tardía

En nuestro ejemplo, el comprador nota la demora y vuelve a pulsar el botón de pago. El proceso debe mantener el vínculo de los intentos con la compra original, en lugar de crear varios pedidos independientes que luego son difíciles de conciliar.

Diseñe un reprocesamiento seguro de las notificaciones: un pedido ya completado no debe provocar una segunda entrega del producto. Si los mensajes llegan en otro orden, use las reglas de estados documentadas y las verificaciones del proveedor. Son recomendaciones sobre cómo construir la integración, no una afirmación de que todos los sistemas UPI se comportan igual.

Ante un resultado incierto, muestre un estado de espera claro y un número de caso. No declare un rechazo solo porque se agotó el tiempo en el navegador ni pida pagar de nuevo mientras el primer intento no esté verificado. Defina de antemano quién se encarga del análisis, qué fuentes acreditan el resultado y cómo se escala el problema al proveedor.

Pruebe por separado el cierre de la pestaña y el regreso al pedido más tarde. El comprador debe ver el estado actual de su pedido y el empleado, un historial de intentos comprensible. Continuar la sesión del usuario no debe exigir cambiar a mano datos de pago por comodidad de la interfaz.

No sustituya la verificación por una prueba cómoda

Una captura de pantalla ayuda a localizar el caso, pero no reemplaza el registro en los datos de pago a los que el comercio tiene acceso. El personal nunca debe pedir que se revele el UPI PIN. NPCI también advierte que escanear un QR e introducir el PIN sirve para enviar un pago, no para recibir dinero. Avisos de NPCI sobre fraude.

Para un reembolso, use el procedimiento establecido, no una solicitud para «recibir» dinero. NPCI recomienda dirigir las consultas de estado y los reclamos del comercio al banco adquirente. FAQ de NPCI para comercios.

El QR caducó y el dinero llegó después

En el escenario didáctico propuesto, la tienda reserva el producto diez minutos y luego cierra el pedido no pagado. Más tarde llega el aviso de un pago exitoso vinculado a ese pedido. Aunque un QR o una solicitud concretos tengan plazo de validez, el tiempo de reserva del producto y el resultado de pago admisible deben definirse por separado según las reglas del proveedor. Que expire un temporizador de la interfaz no equivale a una conciliación financiera.

Elija de antemano el proceso para un pago tardío: comprobar si el pedido aún puede cumplirse, ofrecer al cliente una solución acordada o tramitar un reembolso admitido. No entregue automáticamente un producto que ya no está disponible ni pierda el ingreso porque el registro del pedido quedó «cerrado». La excepción debe tener un responsable y un vínculo con el intento original.

Un pedido puede recibir dos pagos exitosos

Evitar una segunda entrega del producto no elimina la necesidad de ocuparse del dinero sobrante. Si el comprador repitió el pago y ambos intentos realmente se completaron, registre dos objetos financieros y un solo pedido. Haga la corrección posterior según el procedimiento autorizado del proveedor. Ocultar el segundo registro para tener un estado bonito es más peligroso que mostrar el pago sobrante en la cola de revisión.

Soporte necesita un guion de conversación neutral: localizar el pedido, revisar los intentos, comunicar el resultado establecido y el plazo de la próxima actualización. Pedir «envíe otra captura» no debe sustituir el acceso a datos verificados. Pruebe por separado estos casos en los dispositivos y flujos admitidos por el proveedor: que funcione un regreso desde una app no demuestra que todas las apps y sistemas operativos se comporten igual.

Del nombre UPI no se puede deducir la disponibilidad internacional, las fuentes de fondos admitidas ni el coste. Confirme el producto y el contrato concretos. Una buena integración combina un recorrido claro para el comprador con un resultado verificable de forma independiente del lado del comercio.