Pago de Stripe completado, pedido aún pendiente: el webhook que nadie configuró

Pago de Stripe completado, pero el pedido nunca llegó

Este cliente pagó, pero la tienda nunca se enteró.

El dinero llegó, el pedido sigue pendiente y nadie recibió un error ni nada remotamente parecido. Así que en realidad nadie sabe que algo va mal.

Hola, soy Kevin, dirijo Wavect y solo este año hemos revisado más de 50 productos hechos con vibe coding.

Y los bugs que de verdad más dolieron fueron aquellos en los que no se trataba del código en sí, sino de los bordes, cuando tu código interactuaba con el código de otra persona.

¿Por qué no llega mi webhook de Stripe? Nunca se registró

En muchos casos, por ejemplo, simplemente un webhook no estaba bien configurado cuando, por ejemplo, tienes algún tipo de flujo de pago o algo así y el evento de pago simplemente no llega o no llegó.

Y en muchas de estas aplicaciones que hemos revisado, sobre todo las fintech, por ejemplo, había webhooks: pagas, por ejemplo, por un producto o un servicio y tu aplicación normalmente te redirige a un proveedor de pagos externo. Y ese proveedor de pagos, una vez completado el pago, envía un webhook, básicamente la notificación a tu propio backend, a tu propio servidor, de que el pago se ha completado o de que no se completó o de cualquier otro estado intermedio. Y tu aplicación normalmente reacciona a eso.

Pero muchas veces estos vibe coders simplemente olvidan que también tienen que configurar cosas fuera de su propia aplicación, de su propia infraestructura, por ejemplo, en el panel de Stripe o PayPal o lo que sea, solo para asegurarse de que de verdad te envían esa notificación a tu propia aplicación web.

Así que, aunque en local todo parezca funcionar, tengas tus tests, incluso puede que tengas tests end-to-end y todo eso, aun así en producción, cuando de verdad tienes usuarios reales, puede que no llegue.

Y básicamente tienes un bug grave, porque no hay peor experiencia en el mundo que comprar algo y pensar que no lo vas a recibir. Eso es una mierda, ¿sabes?

Y tampoco hay que olvidar que cuando pruebas, normalmente pruebas el camino feliz, o ahí es básicamente donde pones tu atención principal.

¿Qué pasa cuando Stripe envía el mismo webhook dos veces?

Y la siguiente parte es que, si uno de estos pagos, por ejemplo, o estas notificaciones no se entregan correctamente, por ejemplo, por Stripe o por cualquier otro proveedor de pagos, normalmente lo siguen reintentando. Así que puede que lo hayas configurado todo correctamente, pero luego recibes una notificación y, por la razón que sea, tu servidor devuelve un código de error o algo no funcionó como debía, y Stripe envía otra notificación, y otra, y otra.

Y si tu backend o tu algoritmo no es idempotente, básicamente lo registras como varios pagos, aunque en realidad sea un solo pago. Y eso, por razones obvias, es un problema.

Y la cosa empeora: puede que estas notificaciones no lleguen en el orden correcto o en el orden que suponías, puede que lleguen tarde, puede que lleguen, como he dicho, varias veces.

¿Cómo evito los webhooks falsos? Verifica la firma

Y siguiendo un poco con ese ejemplo, Stripe envía esa notificación a tu backend. Si lo piensas, eso significa que el endpoint al que Stripe envía esa notificación tiene que ser público al menos de alguna forma, porque si no, ¿cómo podría un servicio externo en internet llamar a tu aplicación y enviarte esa notificación?

Para asegurarte de que ningún proveedor de pagos no autorizado o falso, ni un usuario malicioso, pueda enviarte estas notificaciones falsas para hacer como si hubieran pagado, lo cual es igual de malo, solo que al revés. Y para eso tienes distintos mecanismos para evitarlo, desde listas blancas de IP hasta firmas de webhook, etcétera.

Pero son cosas que la IA a veces hace, porque la IA es muy buena aplicando buenas prácticas. Pero muchas veces también tienes que señalarlas explícitamente, porque tu criterio te dice: oye, tengo que hacer esto, si no, estoy jodido o estoy hundido.

La petición agotó el tiempo: ¿se hizo el pago?

Y también hay a menudo, digamos, errores ambiguos o confusos que recibes en tu aplicación. Por ejemplo, un timeout, un gran ejemplo. Si envías una petición a un servicio externo o a un backend externo, que puede ser cualquier cosa, y recibes un timeout, solo tienes la información de que, vale, la petición agotó el tiempo, no recibí la respuesta, al menos no a tiempo.

Lo que significa, en teoría, que tu acción, lo que de verdad querías hacer, puede haberse ejecutado correctamente, puede haber fallado o puede ejecutarse más tarde, lo que sea. Y estas son cosas, ciertos casos límite con los que tienes que lidiar, y hay muchos más de los que normalmente imaginas.

Errores silenciosos y claves de API caducadas: cómo detectarlos

Y lo peor de todo, cuando construyes aplicaciones, son los errores silenciosos. Cosas que no te gritan. Porque cuando tu servidor se cae, te das cuenta, al menos cuando tienes usuarios o usas tu aplicación tú mismo. Pero cuando algo simplemente falla en silencio, puede que no te des cuenta en absoluto.

Pero a menudo puede manifestarse de otra manera, por ejemplo, que los usuarios simplemente dejan de usar tu servicio. No se registran. No vuelven. No compran en tu tienda online porque quizá el pago falla y simplemente desisten, lo que sea.

Y estos son errores silenciosos que pueden acabar con negocios, que pueden tener enormes consecuencias según el contexto del bug.

Así que, cuando trabajas con secretos, obviamente quieres que esas contraseñas, claves de API, lo que sea, sobre todo como vibe coder, o en general es simplemente una buena práctica, caduquen en algún momento, a menudo o casi siempre. Porque cuando se filtran, cuando caen en malas manos, cuando se filtran a internet de alguna manera, obviamente se pueden usar, y eso es un problema. Pero cuando caducan, tu aplicación tampoco funciona, así que también tienes que mantener eso. Así que estos también son posibles errores crípticos que puedes recibir, del tipo: ¿por qué algo ya no funciona? Funcionaba desde hacía semanas, meses, años. Eso es mantenimiento.

5 preguntas antes de dar por terminada una integración

Así que me gusta pensar, digamos, en cuatro o cinco cosas clave que siempre deberías tener en cuenta cuando das por terminada una funcionalidad o un producto. La primera sería: ¿qué podría salir mal aquí, en realidad? Cuando pago algo, ¿qué podría salir mal? Pues podría pasar que el pago no se complete o que se cobre dos veces.

Y la siguiente es: cuando una de estas situaciones malas ocurre de verdad, ¿cómo lo notamos? ¿Tenemos algún tipo de monitorización? ¿Recibimos una notificación? ¿Recibimos feedback de los usuarios de alguna forma, lo cual en general siempre es algo muy bueno?

Y la siguiente es: ¿cómo nos recuperamos cuando algo realmente sale mal? Cuando los datos están corruptos, cuando hemos perdido datos o cuando simplemente no estamos seguros de cuál es el estado real de la aplicación. ¿Pagó esa persona?

¿Qué es lo correcto? Y todas estas son cosas que son problemas reales en el mundo real.

Lo siguiente es: quizá tienes todo esto, pero ¿a quién se alerta? ¿Quién es responsable? ¿Quién responde a tiempo, lo arregla, lo gestiona y hace qué?

Y la última es: ¿cómo probamos realmente todo eso?

Y eso también es algo que los vibe coders suelen hacer mal, sobre todo los que vinieron a nosotros. Muchas veces no sabíamos que ya habían lanzado la cosa con el cliente. Y cuando arreglaban algo, lo subían de inmediato a producción y ni siquiera lo probaban. Y las cosas simplemente estaban rotas.

Así que, para resumir, conectar una API es solo el primer paso; el trabajo de verdad suele estar en lo aburrido, es decir, en todo lo que viene después, en el mantenimiento, en las pruebas, en la monitorización, en todo lo que garantiza que esto funcione de verdad bajo presión real.