Qué es un webhook y por qué tus pagos a veces 'no llegan'
Un cliente te escribe: "ya he pagado, pero mi pedido sigue como pendiente". Miras y es verdad. El cobro está en tu pasarela, pero en tu tienda no ha pasado nada. O al revés: a alguien le has cobrado dos veces sin querer. O un pedido se quedó a medias, ni pagado ni cancelado, y nadie en el equipo sabe qué hacer con él.
Casi siempre, detrás de esos líos hay la misma pieza rota. Y no es la que la gente cree. No es Stripe, ni tu banco, ni el TPV. Es el aviso que va de la pasarela a tu web justo después de cobrar. Se llama webhook. Vamos a ver qué es, por qué a veces falla y cómo saber si te está pasando a ti.
Respuesta corta
Un webhook es el mensaje automático que tu pasarela de pago (Stripe, Redsys, PayPal…) le manda a tu web para avisarla de que un cobro se ha completado. Tu tienda no se entera sola de que alguien ha pagado: espera ese aviso para marcar el pedido como pagado, mandar el email de confirmación y preparar el envío.
Cuando los pagos "a veces no llegan", casi nunca es que el dinero se pierda: es que ese aviso no llegó, llegó tarde, o tu web no supo qué hacer con él. El dinero suele estar cobrado y a salvo en la pasarela; lo que falla es la comunicación de vuelta.
La buena noticia es que es un problema conocido y con solución. La mala: no se arregla cambiando de pasarela, porque le pasa a todas por igual. Se arregla en cómo está montada la conexión.
¿Qué es un webhook, sin tecnicismos?
Piensa en el webhook como una llamada de vuelta. Tu cliente paga en la pantalla de la pasarela. En ese momento tu web todavía no sabe nada: ha mandado al cliente a pagar fuera y se queda esperando. Cuando el cobro se confirma, la pasarela "llama" a tu web a una dirección concreta y le dice: "el pago 1234 está cobrado, puedes seguir". Esa llamada es el webhook.
Con ese aviso, tu tienda hace lo suyo. Marca el pedido pagado, descuenta stock, manda el correo. Sin él, el dinero está cobrado pero tu web sigue esperando una llamada que, por lo que sea, no atendió.
Y aquí está el detalle que lo explica casi todo: esa llamada puede fallar. Como cualquier llamada.
¿Por qué a veces no llega?
Las llamadas se pierden por cosas muy mundanas. Tu web estaba caída un segundo, tardó demasiado en contestar, se reinició justo entonces, o contestó pero se lió y procesó el aviso dos veces. La pasarela no sabe si te llegó de verdad; solo sabe que no le respondiste "recibido".
Estos son los líos típicos y lo que hay detrás de cada uno:
| Lo que ves | Qué ha pasado por debajo | Qué mirar |
|---|---|---|
| Paga pero el pedido sigue "pendiente" | El aviso no llegó, o llegó y falló al procesarse | En la pasarela: ¿el cobro consta? Si sí, el fallo es el aviso, no el pago |
| Se cobra o se procesa dos veces | La pasarela reintentó el aviso y tu web lo contó dos veces | ¿Hay dos pedidos o dos emails para un mismo pago? |
| Un pedido se queda a medias | Nunca llegó ni el aviso de "confirmado" ni el de "rechazado" | Pagos en estado "en proceso" que no se resuelven solos |
| Va bien en pruebas, falla en real | El volumen real trae avisos a la vez, tarde o repetidos | ¿Falla más en horas punta o en campañas? |
La conclusión incómoda es que la mayoría de estos fallos no se ven hasta que un cliente se queja. Así que la siguiente pregunta es cómo detectarlos antes.
¿Cómo sé si me está pasando?
No hace falta programar para olerlo. Tres comprobaciones que puedes hacer tú mismo:
- Cruza pasarela y tienda. Coge un día cualquiera. Cuenta los cobros que figuran en Stripe o en tu TPV y compáralos con los pedidos marcados como pagados en tu web. Si no cuadran, tienes avisos que se perdieron.
- Mira los "pendientes" viejos. Un pedido que lleva días en "pendiente de pago" y cuyo cliente jura que pagó es casi siempre un webhook caído.
- Escucha las quejas repetidas. "Pagué y no me llegó nada" dicho por varios clientes distintos no es mala suerte. Es un patrón.
Si al cruzar los números te salen descuadres, la pregunta ya no es si pasa, sino cuánto te cuesta.
Un ejemplo con números
Pongamos un caso tipo, sin nombres. Una tienda que recibe unos 300 pedidos al mes. Si uno de cada cien avisos se pierde —una cifra nada rara cuando la conexión no contempla fallos—, son unos 3 pedidos al mes que se quedan cobrados pero en "pendiente".
Tres al mes suena a poco. Pero cada uno es un cliente escribiendo enfadado, alguien del equipo revisando a mano si pagó o no, y a veces un reembolso "por si acaso" de un pedido que en realidad sí estaba pagado. Multiplica por los meses y por lo que vale tu tiempo. En campañas fuertes —rebajas, Black Friday— el volumen sube y con él el número de avisos que se pisan, justo cuando menos margen tienes para revisar nada a mano.
Son cifras de ejemplo para ver la lógica, no una medición. Lo importante es que un fallo "pequeño" de webhook no se queda pequeño cuando el volumen crece.
¿Qué hay que hacer para que no falle?
La solución no es cambiar de pasarela. Es montar la conexión dando por hecho que los avisos a veces fallan. En la práctica son tres cosas:
- Que un aviso repetido no cuente dos veces. Si la pasarela manda el mismo "pago 1234 cobrado" tres veces, tu web tiene que reconocer que es el mismo pago y actuar una sola vez. En jerga se llama idempotencia; en cristiano, no cobrar ni preparar el pedido dos veces por el mismo dinero.
- Que si un aviso no llega, haya plan B. Las pasarelas serias reintentan el aviso durante horas si no les respondes "recibido". Tu web tiene que estar preparada para atenderlo cuando vuelva, no solo a la primera. Y ayuda tener un repaso automático que cruce pasarela y tienda cada noche y levante la mano con lo que no cuadre.
- Que quede rastro. Guardar qué avisos llegaron y qué se hizo con cada uno. Así, cuando algo falla, se ve dónde y no se adivina.
Nada de esto lo ve el cliente. Pero es la diferencia entre un cobro que se confirma solo y se concilia solo, y uno que te obliga a revisar pedidos a mano cada semana.
Si todavía estás eligiendo pasarela, la elección importa menos de lo que parece: lo comentamos en Stripe o Redsys: cuál conviene a tu negocio. Pero decidas la que decidas, lo que evita el "a veces no llega" es cómo esté montada la conexión de después del pago. Es justo la parte que cuidamos cuando montamos pagos e integraciones: que el cobro se confirme, se registre y se concilie solo, también cuando algo se tuerce.
Si te suena el descuadre y quieres saber si te está pasando, escríbenos a [email protected] y lo miramos.
Preguntas frecuentes
Un cliente ha pagado pero su pedido sigue en 'pendiente'. ¿Se ha perdido el dinero?
Casi nunca. El dinero suele estar cobrado y a salvo en tu pasarela; lo que ha fallado es el aviso (el webhook) que le dice a tu web que el cobro se ha completado. Comprueba en Stripe o en tu TPV si el cobro consta: si está, el pedido se puede marcar pagado a mano y el fallo está en la conexión, no en el pago.
¿El problema es de Stripe o Redsys, o de mi web?
Casi siempre es de cómo está montada la conexión de tu web, no de la pasarela. El fallo del webhook les pasa por igual a Stripe, Redsys, PayPal y cualquier otra, así que cambiar de pasarela no lo arregla. Lo que lo arregla es que la conexión contemple los avisos que se pierden, llegan tarde o se repiten.
¿Puedo saber si me está pasando sin ser técnico?
Sí. Coge un día cualquiera, cuenta los cobros que figuran en tu pasarela y compáralos con los pedidos marcados como pagados en tu web: si no cuadran, tienes avisos que se han perdido. Los pedidos viejos atascados en 'pendiente' cuyos clientes juran que pagaron son otra señal clara.
¿Por qué a veces se cobra o se procesa dos veces?
Porque la pasarela reintenta el aviso si no le respondes 'recibido', y una web mal preparada trata cada reintento como un pago nuevo. La solución es que la conexión reconozca que es el mismo pago y actúe una sola vez, lo que en jerga se llama idempotencia.