Un comprador paga, cierra la pestaña y después pregunta dónde está su compra. Otro vuelve dos veces a la página de éxito. Ninguna acción del navegador debería decidir si un pedido está pagado. La interfaz de pago conversa con el cliente; el registro financiero es responsabilidad independiente del servidor. En ventas de dominios esta diferencia importa especialmente: el siguiente paso puede transferir un activo que no se devuelve simplemente al carrito. EMPEZAR CON UN PEDIDO Antes de abrir el pago, crea un pedido interno con identificador estable, comprador, artículo, importe esperado y moneda. Piensa en un sobre cerrado que describe la operación que pretendes aceptar. Cuando llega una notificación, debe coincidir con ese sobre. Una notificación auténtica de otro pedido sigue siendo incorrecta. Un pago en dólares no debe completar un pedido en euros solo porque las cifras coinciden. Imagina un dominio de €500. Guarda 50000 céntimos de euro, no una cadena formateada con símbolo monetario. Registra descuento e importe definitivo al crear el pedido. Un cambio posterior del catálogo no debería reescribir silenciosamente una sesión existente. Define expresamente cómo cancelar el pedido anterior y crear uno nuevo. AUTENTICIDAD ANTES DE LÓGICA COMERCIAL Stripe describe la comprobación de firma usando el cuerpo original, la cabecera de firma y el secreto del endpoint. Sus bibliotecas oficiales realizan esa comprobación. Guarda el secreto en configuración del servidor, separa pruebas y producción y nunca lo incluyas en el frontend. En la revisión técnica, sigue la petición desde la entrada de red hasta su controlador. ¿Dónde se lee el cuerpo? ¿Qué middleware lo procesa? ¿Lo modifica algún proxy? El equipo debería identificar la frontera exacta de verificación. No imprimas secretos en registros para diagnosticar problemas. Anota un identificador de petición, el entorno y una categoría de fallo depurada. Distingue un fallo de autenticidad de una interrupción temporal de base de datos: requieren respuestas y alertas diferentes. RECIBIR NO ES COMPLETAR Stripe advierte que las notificaciones pueden repetirse y llegar sin un orden garantizado. Su guía de cumplimiento diferencia resultados de pago aplazados. Son realidades del transporte y del pago, no pruebas de un clic equivocado del comprador. Diseña una bandeja persistente para las notificaciones aceptadas y una transición separada del pedido. Un identificador único evita procesar dos veces una entrega, pero la operación comercial también necesita protección: un pedido completado no debe transferir otra vez su dominio. Imagina dos trabajadores llegando simultáneamente al mismo pedido. Una restricción o transacción de base de datos debe decidir la transición, no una variable del navegador ni una comprobación optimista. Usa estados que tus compañeros puedan explicar: pendiente de pago, pago confirmado, pendiente de ejecución, completado y requiere revisión. Un intento fallido o caducado conserva su propia historia. No debería sobrescribir un pago exitoso más reciente porque un mensaje antiguo llegó después. QUÉ PROBAR ANTES DEL LANZAMIENTO Prepara una tabla de resultados esperados. Una firma inválida no modifica pedidos. Un evento válido duplicado no provoca una segunda transferencia. Un pago auténtico con importe, moneda o referencia de sesión inesperados requiere revisión. El pago confirmado con el navegador cerrado debe aparecer igualmente en la cuenta. Una interrupción de base debe dejar información suficiente para recuperar con seguridad. Prueba éxito y fallo aplazados por separado. Después ensaya el caso menos vistoso: se acepta la notificación, pero el trabajador se detiene a mitad de la ejecución. La recuperación debe partir de un estado guardado, no de lo que alguien recuerde. Nunca transfieras un activo real únicamente para demostrar una pantalla verde. HACER VISIBLE LA INCERTIDUMBRE El comprador necesita distinguir «pago confirmado» de «transferencia completada». Muestra el número del pedido y el siguiente paso, sin anunciar éxito mientras el servidor espera. Para el equipo, crea una cola de revisión con motivos y una acción de conciliación contra el registro autorizado del pago. Esta es nuestra recomendación operativa, no una promesa de que instalar un webhook evita cualquier incidente. Un proyecto empieza con un nombre adecuado, pero la fiabilidad del pago forma parte de la experiencia de marca. Explora el catálogo DomainEvery: https://domainevery.com/es/domains y presupuesta verificación, recuperación y ejecución junto al diseño web. FUENTES Stripe: webhooks: https://docs.stripe.com/webhooks Stripe: endpoints y firmas: https://docs.stripe.com/events/manage-webhook-endpoints Stripe: cumplimiento con hosted Checkout: https://docs.stripe.com/checkout/fulfillment.md?payment-ui=stripe-hosted