El pago por solicitud es el flujo que todo cliente de dinero móvil conoce de memoria sin pensar en él. Un comercio pide dinero, aparece una solicitud en el teléfono del cliente, este introduce su PIN y listo. Es el patrón de pago más usado en los mercados que adoptaron pronto el dinero móvil, y parece no costar ningún esfuerzo. Esa facilidad es fruto de una cantidad sorprendente de ingeniería que trabaja duro para ser invisible. Basta con fallar en una parte para que la magia se convierta en un cobro doble, un pago atascado o un comercio que entregó mercancía a cambio de dinero que nunca llegó.
Esto es lo que realmente ocurre detrás de la solicitud, y lo que hace falta para que sea instantánea, segura e incapaz de cobrar dos veces.
Dos formas en que llega la solicitud
Hay dos mecanismos detrás de "aparece una solicitud", y importan porque tienen distinto alcance y distintos modos de fallo.
El mecanismo clásico es el SIM Application Toolkit (STK): código que se ejecuta en la propia tarjeta SIM, por eso puede mostrar una petición de PIN segura en un teléfono básico sin ninguna aplicación instalada. Con el STK los primeros sistemas de dinero móvil llegaron a todo el mundo: el menú y la introducción del PIN se controlan desde la SIM, a través de la red, en un aparato que no tiene nada más. El mecanismo moderno es la notificación de aplicación: un aviso a una aplicación de smartphone que abre una pantalla de confirmación. Ambos acaban en el mismo punto: el cliente autoriza y un cobro recorre su ciclo de vida. Una plataforma que merezca la pena admite los dos, porque la base de clientes usa los dos.
El cobro es una máquina de estados
La idea más importante del pago por solicitud es que un cobro no es un evento: es una máquina de estados con un conjunto explícito y bien definido de estados y transiciones. Tratarlo como una llamada de "enviar y olvidar" es la raíz de la mayoría de los incidentes en producción. Los estados son, más o menos:
- Pendiente: el comercio ha pedido un cobro; la solicitud se ha enviado; el sistema espera al cliente.
- Autorizado: el cliente introdujo su PIN y confirmó; el sistema ha comprobado saldo y límites y está registrando el movimiento.
- Completado: el libro mayor ha registrado asientos equilibrados; el dinero se ha movido; el comercio puede entregar.
- Rechazado / Caducado / Fallido: el cliente lo rechazó, la solicitud caducó o falló una comprobación; no se movió dinero y el cobro se cierra limpiamente.
Cada cobro está exactamente en uno de estos estados en todo momento, y solo puede avanzar por transiciones definidas. No es burocracia: es lo que hace que el flujo sea comprensible y recuperable. Cuando algo falla, la pregunta siempre es "¿en qué estado está este cobro y qué transición se atascó?", una pregunta con respuesta, en lugar de un encogimiento de hombros.
Cómo se entera el comercio del resultado
El sistema del comercio necesita saber si el cobro se completó: para imprimir un recibo, entregar la mercancía, actualizar un pedido. Hay dos formas de averiguarlo, y la diferencia entre ellas es la que separa una integración torpe de una limpia.
- Consulta periódica (polling). El comercio pregunta una y otra vez al endpoint de estado: "¿ya está?". Funciona, pero es ineficiente y lento: consulte demasiado y sobrecarga la API; consulte poco y el cliente espera de pie en la caja.
- Webhooks. La plataforma envía al comercio un callback firmado en el instante en que el cobro cambia de estado. El comercio se entera en un momento, sin llamadas inútiles, y recibe un evento claro sobre el que actuar. Esta es la primitiva correcta, y una plataforma bien construida la usa por defecto, con la consulta como respaldo.
Lo que lo hace fiable
Tres propiedades convierten una demostración que funciona en un sistema sobre el que un comercio puede construir un negocio.
Idempotencia: el antídoto contra el cobro doble
Las redes reintentan. Si la petición "crear cobro" de un comercio caduca y la reenvía, no debe crearse un segundo cobro. Cada petición de creación lleva una clave de idempotencia; la plataforma la registra, y una repetición con la misma clave devuelve el cobro original en lugar de iniciar uno nuevo. La misma disciplina protege el paso de confirmación. La garantía que siente el cliente, "solo me cobraron una vez", es esta propiedad, aplicada en el punto donde se mueve el dinero, no una comprobación optimista en la aplicación.
Webhooks firmados
Un webhook es una llamada HTTP no solicitada que llega al servidor del comercio afirmando que un pago se completó. ¿Por qué creerla? Porque cada callback va firmado: una firma HMAC-SHA256 calculada sobre el contenido con un secreto compartido que solo conocen la plataforma y el comercio. El comercio recalcula la firma y rechaza todo lo que no coincida, lo que hace inútiles para un atacante los falsos avisos de "le han pagado". Y como las redes fallan, los webhooks se reintentan con espera creciente hasta que se confirman, de modo que una caída momentánea del comercio no hace perder el evento: se reenvía hasta que su servidor responde con éxito.
Caducidad
Un cobro sin confirmar no puede quedarse abierto para siempre. Si el cliente se marcha sin introducir el PIN, el cobro debe caducar limpiamente en lugar de quedar como una obligación abierta que podría completarse misteriosamente una hora después. Una ventana de caducidad acotada y predecible es lo que mantiene la visión del comercio coherente con la del cliente.
Los casos límite que separan los sistemas reales de las demostraciones
El camino feliz (enviar, confirmar, completar) es el cuarto fácil del trabajo. Los fallos interesantes viven en los huecos:
- El cliente confirma, pero la red pierde el acuse de recibo. El cobro está
completeden la plataforma; el comercio nunca se enteró. El reintento del webhook existe precisamente para esto. El manejador del comercio también debe ser idempotente, para que un evento "completado" reenviado no haga entregar la mercancía dos veces. - Dos confirmaciones compiten. Una confirmación reintentada no debe registrarse dos veces. La clave de idempotencia y la máquina de estados garantizan juntas que la segunda confirmación vea "ya completado" en lugar de mover dinero otra vez.
- El cobro caduca en el mismo instante en que el cliente confirma. La máquina de estados debe definir un único ganador: la transición es atómica, así que el cobro queda autorizado o caducado, nunca ambos, y se informa claramente al cliente.
- Conciliación. Al final del día, cada cobro
completeddebe corresponder a un conjunto equilibrado de asientos y a un registro de liquidación. Como el ciclo de vida del cobro y el libro mayor están unidos, completar es registrar, la conciliación sale por construcción y no por investigación.
Una cronología práctica
Esto es lo que ocurre, segundo a segundo, cuando un comercio cobra 1.250 a un cliente por la compra. Los tiempos son típicos, no garantizados.
| Tiempo | Qué ocurre | Estado del cobro |
|---|---|---|
| 0,0 s | El cajero introduce el número del cliente y el importe; la caja envía una petición de creación de cobro con una clave de idempotencia | Pendiente |
| 0,3 s | La plataforma valida al comercio y al cliente y envía la solicitud | Pendiente |
| 2–20 s | El cliente lee el nombre del comercio y el importe e introduce el PIN | Pendiente |
| +0,2 s | El núcleo comprueba PIN, saldo y límites, y registra asientos equilibrados | Completado |
| +0,5 s | Un webhook firmado llega al comercio; cliente y comercio reciben confirmaciones | Completado |
| Más tarde | El saldo del comercio se liquida al banco según su calendario | Completado, liquidado |
La lectura y el tecleo del cliente dominan el tiempo. Todo lo que hace la plataforma tarda muy por debajo de un segundo, por eso la experiencia parece instantánea cuando funciona, y el raro paso lento se nota enseguida.
Construir bien el lado del comercio
La mitad de una integración fiable de pago por solicitud vive en el sistema del comercio. Un buen manejador de webhooks:
- Verifica la firma antes de confiar en nada del contenido.
- Es idempotente: una segunda entrega del mismo evento no cambia nada.
- Responde rápido y hace el trabajo pesado después, para que la plataforma no agote el tiempo y reintente sin necesidad.
- Empareja por la referencia del cobro, nunca solo por importe y número de teléfono.
- Recurre al endpoint de estado si no llega ningún evento en la ventana esperada, en lugar de dar por fallido el cobro.
- Registra cada evento que recibe, para poder responder a las disputas con datos.
Elegir la ventana de caducidad
La caducidad es un equilibrio. Demasiado corta, y los clientes que buscan el teléfono ven morir el cobro antes de confirmar. Demasiado larga, y los comercios esperan con la mercancía en el mostrador, mientras llegan solicitudes obsoletas cuando el cliente ya se ha ido. La mayoría de los operadores fija entre uno y dos minutos para pagos presenciales, y más para solicitudes remotas, como una factura enviada a un cliente en su casa. Sea cual sea la ventana, muéstrela: un cajero que sabe que la solicitud dura un minuto sabe cuándo volver a intentarlo.
Detalles que notan los clientes
Pequeñas decisiones en la pantalla de la solicitud deciden si los clientes confían en ella:
- Mostrar el nombre registrado del comercio, no un código interno, para que el cliente sepa quién pide.
- Mostrar con claridad el importe y la referencia antes del campo del PIN.
- Ofrecer una opción clara de rechazo, para que un cliente que no esperaba la solicitud pueda rechazarla en lugar de ignorarla.
- Confirmar con palabras y por mensaje: un recibo con el comercio, el importe y la referencia, en pantalla y por SMS.
- Advertir sobre solicitudes inesperadas. Los estafadores envían solicitudes con la esperanza de que el cliente apruebe por reflejo; una línea breve como "Apruebe solo si está pagando a este comercio" reduce ese riesgo.
Un ciclo de vida, todos los canales
La pieza final para hacerlo bien es que el pago por solicitud no debe ser un caso especial conectado por separado en la aplicación, la caja y la API. Debe ser un único ciclo de vida de cobro que todos los canales impulsan: un cliente que escanea el QR de un comercio, un comercio que envía un cobro desde un terminal punto de venta y un socio que llama a la API para desarrolladores crean todos el mismo tipo de cobro, que pasa por los mismos estados, registra en el mismo libro mayor y emite los mismos webhooks firmados. Constrúyalo una vez, bien, y cada canal hereda las garantías.
¿Pago por solicitud, QR o número de caja?
El pago por solicitud es una de tres formas habituales de cobrar a un cliente. Cada una encaja en una situación distinta:
| Método | Quién lo inicia | Funciona en teléfonos básicos | Ideal para |
|---|---|---|---|
| Pago por solicitud | El comercio | Sí, mediante solicitudes en la SIM | Cajas y puntos de cobro donde el comercio conoce el importe |
| Código QR | El cliente escanea | No, necesita una aplicación de smartphone | Tiendas con muchos clientes de smartphone; códigos estáticos para pequeños comerciantes |
| Número de caja o de facturador | El cliente lo introduce | Sí, por USSD | Cualquier comercio; la alternativa universal |
A los comercios les va mejor cuando pueden aceptar los tres, y la plataforma los trata como el mismo tipo de pago llegando por caminos distintos.
Fraude en torno a las solicitudes
Como una solicitud pide al cliente que apruebe un pago, atrae la ingeniería social. El patrón habitual es un estafador que dispara solicitudes y luego llama al cliente haciéndose pasar por el proveedor para convencerle de que apruebe. Las defensas actúan en varios niveles: mostrar de forma destacada el nombre verificado del comercio que pide; limitar cuántas solicitudes puede enviar un comercio al mismo número en poco tiempo; vigilar a los comercios cuyas solicitudes se rechazan o denuncian en su mayoría; y recordar a los clientes, una y otra vez, que el proveedor nunca les pedirá aprobar un pago por teléfono. El alta de comercios también importa, porque un comercio verificado con identidad rastreable es una mala herramienta para el fraude.
Medir el pago por solicitud
| Indicador | Por qué importa |
|---|---|
| Tasa de aprobación | La proporción de solicitudes que aprueban los clientes; una caída repentina apunta a problemas de entrega o confusión |
| Tiempo de aprobación | Cuánto tardan los clientes; tiempos largos indican pantallas poco claras o entrega lenta |
| Tasa de caducidad | Solicitudes que mueren sin respuesta; ajustar la ventana de caducidad y las indicaciones a los cajeros |
| Éxito de webhooks al primer intento | Con qué fiabilidad reciben los comercios los resultados sin reintentos |
| Solicitudes inesperadas denunciadas | Una señal temprana de intentos de fraude |
Más allá del mostrador: solicitudes remotas
El mismo mecanismo funciona cuando el cliente no está en la caja. Un colegio puede enviar solicitudes de cuotas a los padres, una empresa de servicios puede pedir el pago de una factura, un repartidor puede pedir el pago al llegar. Las solicitudes remotas necesitan algunos ajustes: una caducidad más larga, una descripción clara de lo que se paga, el nombre verificado de quien pide y una referencia que el cliente reconozca en una factura o mensaje. La máquina de estados, la firma y la idempotencia siguen exactamente igual, por eso un único ciclo de vida de cobro sirve igual a la caja, a la factura y a la API.
Probar una integración de pago por solicitud
Antes de que un comercio pase a producción, ejecute estos casos en el entorno de pruebas:
- aprobar, rechazar y dejar caducar una solicitud, y comprobar que el sistema del comercio muestra el resultado correcto en cada caso;
- enviar dos veces la misma petición de creación con la misma clave de idempotencia y confirmar que solo existe un cobro;
- hacer fallar el endpoint de webhooks del comercio durante unos minutos y confirmar que los eventos llegan cuando se recupera;
- enviar un webhook con una firma errónea y confirmar que el comercio lo rechaza;
- intentar un cobro por encima del límite del cliente y confirmar que se rechaza limpiamente;
- comprobar que los reembolsos remiten al cobro original.
Una integración que supere estas pruebas se comportará bien en su día de más actividad.
Preguntas frecuentes
¿Y si el cliente no tiene conexión de datos?
Las solicitudes en la SIM funcionan a través de la red móvil sin datos. Para las solicitudes de aplicación, los clientes sin datos pueden pagar igualmente introduciendo el número de caja del comercio por USSD.
¿Puede un comercio cobrar a un cliente sin su aprobación?
No. El cobro solo se completa cuando el cliente lo autoriza con su PIN. El comercio puede solicitar; solo el cliente puede aprobar.
¿Cómo se gestionan los reembolsos?
Un reembolso es una nueva transacción del comercio al cliente, vinculada al cobro original. El original queda en el historial, para que ambas partes vean lo que se pagó y lo que se devolvió.
¿Qué debe hacer un cajero si el cliente dice que aprobó pero la caja no muestra nada?
Esperar el resultado en lugar de cobrar dos veces. La caja debe consultar el estado del cobro con su referencia. Si el cobro se completó, el resultado aparecerá en un momento; si caducó, el cajero puede enviar una nueva solicitud con seguridad. Nunca acepte una captura de pantalla de una confirmación como prueba de pago.
¿Es seguro el pago por solicitud para importes elevados?
Los límites del nivel del cliente se aplican exactamente igual que en cualquier otro pago, y el paso del PIN es el mismo. Para pagos empresariales elevados, los comercios suelen combinar una solicitud con una referencia de factura, para que ambas partes puedan vincular el pago a un documento.
Hecho así, el pago por solicitud parece instantáneo y hace imposible cobrar dos veces, no porque nada falle nunca, sino porque cada fallo tiene un estado definido, un reintento y un camino de vuelta a la coherencia. Eso es lo que entrega PesaBridge, en las aplicaciones y en la API para desarrolladores, sobre un único ciclo de vida de cobro.