Tu servidor está online pero los pagos no entran
Tu servidor puede marcar 100% de uptime y aun así no entrar un solo pago. Acá es donde se nota la falta de un monitoreo de ruta de pagos. Le pasó a un fundador de SaaS que perdió USD 3.200 en un fin de semana: el endpoint de webhooks de Stripe devolvía error 500 y su panel de UptimeRobot mostraba todo en verde.
El monitoreo de ruta de pagos es la práctica de verificar todo el recorrido que hace una transacción, no solo si el servidor responde. Cubre la carga de Stripe.js en el navegador, la respuesta del endpoint de webhooks, la conexión del servidor con la API de Stripe o Paddle, el certificado SSL del subdominio de pagos y la resolución DNS. Si cualquiera de esos eslabones se rompe, el cliente no puede pagar y vos no te enterás.
En 30 segundos
- El uptime mide que el servidor responde un HTTP 200, no que se procesen los cobros.
- Un webhook de Stripe que tira 500 deja al cliente cobrado y a tu base de datos sin registro.
- El caso del fundador de SaaS: USD 3.200 perdidos en un fin de semana con uptime al 100%.
- Un certificado SSL vencido en el subdominio de pagos rompe los webhooks en silencio, porque Stripe exige TLS estricto.
- Una regla de CSP mal puesta bloquea Stripe.js y el formulario de pago nunca aparece.
¿Por qué el uptime no garantiza que funcionen los pagos?
Acá está la trampa. Tu monitor tradicional hace ping, recibe un 200 en la home, ve la RAM normal y te dice que todo anda bárbaro. Pero nada de eso toca el flujo de plata.
El caso que dispara toda esta discusión es claro: el fundador miraba un dashboard impecable mientras Stripe le rebotaba cada webhook con un 500. ¿Cuánto tardó en darse cuenta? Todo un fin de semana, y recién cuando vio que la facturación no cuadraba.
El punto es que “servidor online” y “negocio cobrando” son dos cosas distintas. Un check de uptime confirma la primera. La segunda necesita que verifiques cada componente del recorrido, y eso es justo lo que UptimeRobot no ve. Más contexto en gestionar credenciales de pago en Workers.
¿Qué puntos de fallo tiene la ruta de pagos?
Mirá el contraste entre lo que ve un monitoreo clásico y lo que mide un monitoreo de ruta de pagos. La diferencia explica por qué tanta gente se entera tarde.
| Componente | Monitoreo tradicional (uptime) | Monitoreo de ruta de pagos |
|---|---|---|
| Servidor responde ping | Sí | Sí |
| HTTP 200 en la home | Sí | Sí |
| Stripe.js inicializa en el checkout | No | Sí |
| Endpoint /webhooks/stripe devuelve 200 | No | Sí |
| El servidor alcanza la API de Stripe | No | Sí |
| SSL del subdominio de pagos vigente | No | Sí |
| El subdominio de pagos resuelve por DNS | No | Sí |
Cada fila donde aparece un “No” es un agujero. Y son agujeros silenciosos: no te llega ninguna alerta porque, técnicamente, el servidor está vivo.
Fallos silenciosos de webhooks: por qué Stripe se da por vencido
Ponele que tu webhook tira una excepción. Stripe lo reintenta varias veces, no recibe el 200 que espera, y después de un rato se rinde. El cliente ya pagó, la tarjeta ya se debitó, pero tu base de datos no tiene idea de que esa compra existió.
El resultado es feo: un cliente enojado que pagó y no recibió nada, más ingresos que no podés ni contabilizar. Lo peor es que el reintento de Stripe es generoso pero finito. Si tu endpoint estuvo caído todo el fin de semana, esos eventos se pierden y los tenés que reconstruir a mano desde el dashboard de Stripe. Cubrimos ese tema en detalle en guardar logs de transacciones fallidas.
La lógica de reintentos está bien documentada en la guía oficial de webhooks de Stripe. Conviene leerla antes de asumir que “Stripe se va a encargar”.
¿Cómo bloquean los CSP headers el formulario de pago?
Este es el clásico que te muerde después de un cambio “inofensivo”. Tocás las reglas de tu CDN (Cloudflare, en el caso original), apretás un poco la Content Security Policy, y sin querer dejás afuera el dominio desde donde carga Stripe.js.
¿Qué ve el cliente? La página de checkout se ve perfecta, el botón está ahí, pero donde debería aparecer el formulario de tarjeta hay un spinner que gira para siempre. Nadie completa la compra. Se van.
Y vos no tenés ni un log de error 500 para guiarte, porque del lado del servidor todo respondió 200. El fallo vive entero en el navegador del cliente. Si no probás el checkout real con una tarjeta de test después de cada cambio de CDN, este se te escapa.
Certificados SSL vencidos y webhooks que no llegan
Otro silencioso. El certificado SSL de tu subdominio de pagos (algo tipo pay.tudominio.com) se vence. La página todavía abre, eso sí, con el cartel de advertencia del navegador. Un humano lo ve y desconfía. Lo explicamos a fondo en automatizar el despliegue de cambios críticos.
Pero el problema real es invisible: Stripe exige TLS estricto para enviar webhooks, así que con el certificado vencido directamente rechaza la conexión y los eventos nunca llegan a tu servidor. No hay 500, no hay timeout obvio, no hay alerta. El cobro pasó del lado de Stripe y tu sistema quedó a ciegas hasta que alguien revisa los logs.
Acá la infraestructura importa. Si tu hosting o VPS está en un proveedor serio como donweb.com, con renovación automática de certificados, te sacás de encima al menos esta categoría de fallo. El resto del monitoreo igual lo tenés que armar vos.
¿Cómo implementar monitoreo real de ruta de pagos?
No necesitás una herramienta carísima para arrancar. Necesitás chequear los eslabones correctos. Estos son los checks mínimos:
- Verificá que Stripe.js carga e inicializa. Un check headless que abra el checkout y confirme que el objeto de Stripe existe en el navegador, no solo que la página devuelve 200.
- Monitoreá el endpoint de webhooks como endpoint, no como página. Hacé un POST de prueba a /webhooks/stripe y confirmá que responde 200, no que el dominio está vivo.
- Probá la conexión saliente a la API. Un curl programado desde tu servidor hacia la API de Stripe te dice si el firewall o el DNS te están cortando la salida.
- Vigilá la fecha de vencimiento del SSL del subdominio de pagos. Alertá con 14 días de anticipación, no el día que vence.
- Confirmá la resolución DNS del subdominio. Si pay.tudominio.com deja de resolver, el checkout muere sin avisar.
La idea de fondo: cada check debe simular lo que hace un cliente o lo que hace Stripe, no lo que hace un robot de uptime.
Casos reales de pérdida de ingresos sin alertas
Tres situaciones, un patrón. Todas pasaron inadvertidas porque el monitoreo miraba el lugar equivocado. Te puede servir nuestra cobertura de herramientas de CI/CD para deploys seguros.
El fundador de Reddit que abrió esta nota perdió USD 3.200 con webhooks en 500 y uptime al 100%. El segundo caso es el del SSL vencido en el subdominio de pagos: la página cargaba con advertencia, pero los webhooks rebotaban contra el TLS estricto y nadie lo notó hasta el cierre contable. El tercero es el de los CSP headers después de un cambio de CDN, con el formulario de tarjeta atrapado en un spinner eterno mientras los clientes abandonaban el carrito uno tras otro.
Ninguno tuvo alerta. Esa es la moraleja incómoda.
Errores comunes al monitorear pagos
- Confiar solo en el uptime del servidor. Un 200 en la home no dice nada del checkout. Corrección: agregá checks específicos para Stripe.js y el endpoint de webhooks.
- No probar el checkout después de tocar el CDN. Un cambio de CSP rompe Stripe.js sin generar ningún error de servidor. Corrección: pasá una tarjeta de test real tras cada cambio de reglas en Cloudflare o tu CDN.
- Tratar el subdominio de pagos como secundario. El SSL de pay.tudominio.com se vence y Stripe deja de mandar webhooks. Corrección: monitoreá ese certificado con la misma prioridad que el del dominio principal.
- Asumir que los reintentos de Stripe te cubren. Son finitos. Si tu endpoint estuvo caído un fin de semana, esos eventos se pierden. Corrección: alertá apenas el endpoint deje de responder 200, no días después.
Preguntas Frecuentes
¿Qué es el monitoreo de ruta de pagos?
Es la verificación de todo el recorrido de una transacción, desde la carga de Stripe.js en el navegador hasta la respuesta del endpoint de webhooks y el estado del SSL del subdominio de pagos. A diferencia del monitoreo de uptime, confirma que el cliente puede pagar de verdad, no solo que el servidor responde.
¿Por qué mi servidor está online pero no recibo pagos?
Porque el uptime mide que el servidor responde, no que el flujo de pago funcione. Las causas más comunes son webhooks que devuelven error 500, Stripe.js bloqueado por reglas de CSP, o un certificado SSL vencido en el subdominio de pagos que hace que Stripe rechace los webhooks.
¿Cómo monitorear que los webhooks de Stripe funcionen?
Hacé un POST de prueba al endpoint /webhooks/stripe y confirmá que devuelve un 200, en vez de chequear solo que el dominio está vivo. Configurá una alerta inmediata si el endpoint deja de responder correctamente, porque los reintentos de Stripe son finitos y se rinden tras varios intentos fallidos.
¿Cuál es la diferencia entre uptime de servidor y funcionalidad de pagos?
El uptime confirma que el servidor responde un HTTP 200 y que la RAM está normal. La funcionalidad de pagos depende de varios eslabones extra: Stripe.js, el endpoint de webhooks, la conexión saliente a la API y el SSL del subdominio. El servidor puede estar al 100% mientras los pagos están caídos.
¿Qué hace que un certificado SSL vencido rompa los pagos?
Stripe exige TLS estricto para enviar webhooks. Si el certificado del subdominio de pagos se vence, Stripe rechaza la conexión y los eventos nunca llegan a tu servidor. La página todavía carga con la advertencia del navegador, así que el fallo queda invisible hasta que revisás los logs.
Conclusión
El monitoreo de uptime resuelve una pregunta vieja: ¿el servidor está prendido? Pero el negocio no vive de eso, vive de cobrar. El caso de los USD 3.200 perdidos muestra que un dashboard verde puede convivir con un flujo de pagos roto durante días.
Lo accionable es concreto: sumá checks que prueben Stripe.js en el navegador, el endpoint de webhooks como endpoint real, la conexión saliente a la API y el vencimiento del SSL del subdominio de pagos. Y cada vez que toques las reglas de tu CDN, pasá una tarjeta de test antes de irte. El uptime te dice que el servidor vive. El monitoreo de ruta de pagos te dice que estás cobrando, que es lo único que paga las cuentas.
