¿Cómo testearías un flujo de compra y pago de extremo a extremo?

Cubre el camino feliz y luego los riesgos propios del dinero: tarjetas rechazadas y autorizadas parcialmente, timeouts en los que el cargo sale bien pero se pierde la respuesta, envíos duplicados, devoluciones totales y parciales, moneda y redondeo, la interacción de impuestos y descuentos, y el stock cambiando a mitad de la compra. Usa las tarjetas de prueba del sandbox del proveedor, y verifica lo que registró el backend en vez de fiarte de la pantalla de confirmación.

El camino feliz lleva diez minutos; todo lo valioso está en los modos de fallo, porque este es el flujo donde un bug cuesta dinero directamente. El caso que siempre testeo primero es la transacción interrumpida: el proveedor autoriza el cargo y luego la respuesta no vuelve nunca, expira, o el usuario cierra la pestaña. ¿Existe el pedido? ¿Se le ha cobrado al cliente sin nada a cambio? Ese es el peor resultado de todo el sistema y necesita lógica de conciliación, no esperanza. Junto a eso, el doble clic en enviar, y volver atrás y reenviar, que debería ser idempotente en vez de cobrar dos veces. Después las respuestas concretas del proveedor con sus tarjetas de prueba del sandbox: rechazos, fondos insuficientes, tarjeta caducada, y una tarjeta que dispare autenticación adicional, porque esa ruta tiene su propia redirección y sus propias formas de romperse. Luego la aritmética del dinero: monedas con distinto número de decimales, redondeo en un descuento porcentual, impuestos aplicados antes o después del descuento, y un cupón que supere el total del pedido. También el stock llegando a cero mientras el cliente está en la pantalla de pago. Y verifico contra la base de datos y el panel del proveedor, nunca contra la página de confirmación.