Antes de cambiar el estado: un cliente puede haber pagado aunque WooCommerce muestre el pedido como fallido. Un timeout, un webhook rechazado o un error fatal local pueden dejar ambos sistemas desalineados. La pasarela es la fuente financiera para saber si el dinero se ha movido.
Concilia el dinero antes de tocar el pedido
Registra ID de pedido, importe, moneda, referencia de la pasarela y hora exacta. Comprueba si la transacción figura capturada, autorizada, fallida o reembolsada.
Evidencia que une pasarela y WooCommerce
- Historial de la transacción en el proveedor.
- Webhooks o callbacks y sus códigos de respuesta.
- Notas del pedido y logs de WooCommerce.
- Cambios de stock y emails ya ejecutados.
Por qué “pagado” y “fallido” pueden coexistir
- Error en el retorno: el pago termina, pero la redirección final falla.
- Webhook rechazado: WordPress no acepta o no recibe el evento.
- Error fatal local: WooCommerce falla después de que la pasarela haya cobrado.
- Timeout: la petición local expira mientras el proveedor completa el proceso.
Repara la causa para los pedidos futuros
- Concilia cada pedido afectado transacción por transacción.
- Corrige callback, webhook o error PHP.
- Actualiza manualmente solo pedidos confirmados, dejando una nota de auditoría.
- Haz un pago de prueba completo después de la corrección.
¿Error de retorno o webhook?
Si el proveedor muestra un cobro correcto pero falla el retorno visual, investiga routing y confirmación. Si el evento asíncrono no llega, céntrate en el webhook. Para Stripe consulta webhook de Stripe que no actualiza el pedido; para PayPal, pago completado pero pedido sin actualizar.
No pidas al cliente que vuelva a pagar
Hacerlo antes de revisar la transacción puede crear un cargo duplicado. Tampoco cambies pedidos en masa sin evidencia individual.
Verificación de cierre
Pasarela y WooCommerce deben coincidir, el stock y los emails deben haberse ejecutado una sola vez y un nuevo pago controlado debe actualizar el pedido automáticamente.