← Volver al blog

Pagos y webhooks: lo que importa después del botón de pagar

Imagina que acabas de pagar y la pantalla se queda esperando. ¿Se confirmó tu reserva? ¿Debes intentarlo otra vez? Esa duda inquieta. Y detrás puede haber otra persona intentando darte una respuesta. Al conectar pagos, me parece esencial pensar en ambas: quien compra y quien necesita entender qué pasó para ayudar.

Ilustración de un recibo, un evento validado y una ficha de pedido conectados.
El aviso de pago se verifica antes de actualizar el pedido. Ilustración conceptual generada con IA; no representa una transacción real.

Qué cuenta el aviso de un pago

Un webhook es un aviso que un servicio envía a tu aplicación cuando sucede algo. Stripe los utiliza, por ejemplo, para comunicar una confirmación bancaria o una disputa que llega más tarde. El aviso trae información sobre lo ocurrido; la aplicación debe relacionarlo con el pedido y decidir qué hacer.Stripe: recepción y procesamiento de webhooks ↗

Vuelvo a esa reserva. La persona vuelve al sitio después de pagar y quiere saber si ya está lista. Que haya llegado a esa pantalla no basta para confirmarla. Hace falta que la aplicación reconozca la confirmación del proveedor y sepa a qué reserva pertenece.

Si esa confirmación aún no llega, el mensaje debería decirlo con calma y explicar el siguiente paso. «Tu pago está en revisión» puede orientar mejor que una pantalla vacía, siempre que describa lo que está ocurriendo. Y antes de pedir que alguien pague otra vez, hay que revisar el intento anterior.

Antes de confirmar, comprobar a quién corresponde

Stripe pide verificar la firma del aviso utilizando el cuerpo original de la petición, sin modificarlo. Esa comprobación ayuda a verificar su origen. Después hay otra tarea: leer lo que dice y comprobar si corresponde procesarlo en la aplicación.Stripe: recepción y procesamiento de webhooks ↗

Para la reserva, revisaría que el identificador del pago corresponda al pedido esperado y que se cumplan sus condiciones de confirmación. Recibir un aviso auténtico no basta para confirmar cualquier reserva. Guardar esa relación también le dará al equipo un punto de partida si necesita ayudar al cliente.

Qué pasa si el aviso llega dos veces

Stripe advierte que un webhook puede llegar más de una vez y que los avisos no tienen garantizado el orden de entrega. Por eso la aplicación necesita reconocer lo que ya procesó. También debe evitar que un aviso antiguo cambie hacia atrás el estado de un pedido que ya estaba confirmado.Stripe: recepción y procesamiento de webhooks ↗

Otra situación ocurre cuando la aplicación envía una solicitud a Stripe, pierde la respuesta y vuelve a intentarlo. Para reconocer reintentos de una misma operación, Stripe ofrece claves de idempotencia, con condiciones que dependen de la API utilizada. Este mecanismo y el control de avisos repetidos resuelven partes distintas del proceso.Stripe: solicitudes idempotentes ↗

En la reserva del ejemplo, recibir dos veces el mismo aviso no debería provocar dos confirmaciones. Y si la persona cambia su compra, revisaría si se trata de una operación nueva. Separar el intento de cobro de los avisos recibidos ayuda a entender qué se está repitiendo en cada caso.

Dar al equipo una forma de ayudar

Al recibir un aviso, conviene guardarlo de forma duradera antes de confirmar su recepción. Después, la aplicación puede procesarlo y conservar una forma de retomar el trabajo si falla. Así queda preparado un camino para revisar lo pendiente, en lugar de depender de que todo salga bien a la primera.

La persona que atiende al cliente necesita saber qué reserva espera confirmación, qué ocurrió con el pago y qué referencia debe consultar. A veces bastará con revisar el estado existente o corregir una asociación. Tener esas opciones claras evita que «intenta pagar otra vez» sea la única respuesta disponible.

He trabajado con PHP y Laravel en integraciones con Stripe para distintos clientes. Cada producto necesita decidir cuándo confirma una compra, cómo la cancela y qué hace si algo queda pendiente. La librería me ayuda a conectar las piezas; esas decisiones requieren entender cómo trabaja el negocio y qué espera quien compra.

Volver a mirar el proceso como cliente

Antes de entregar, probaría una reserva completa. Después enviaría dos veces el mismo aviso, dejaría llegar uno antiguo y provocaría un fallo tras guardar un evento. En cada prueba revisaría el estado de la reserva y el mensaje que recibe la persona, además de la respuesta del servidor.

Al terminar, volvería a la pregunta del principio: si pago y algo tarda, ¿entiendo qué está pasando? Y si pido ayuda, ¿puede alguien responderme con información? Cuidar esas dos respuestas es una forma muy concreta de cuidar la confianza que una persona deposita en el producto cuando decide pagar.

Fuentes y lecturas relacionadas