Un pedido pagado marcado Fallido o Cancelado puede detener preparación, devolver stock y enviar un email incorrecto aunque el proveedor conserve el dinero. Puede causarlo un webhook fuera de orden, limpieza de impagados, timeout o automatización.
No cambies todos a Procesando en masa. Demuestra el pago e identifica quién escribió el estado.
Concilia proveedor y tienda
Para cada pedido compara importe, moneda, referencia y hora. Confirma si el proveedor muestra Capturado, Autorizado, Revertido, Disputado o Reembolsado.
Crea una tabla sin tarjeta ni datos completos del cliente.
Si el proveedor es incierto, pausa preparación. La etiqueta de WooCommerce no prueba por sí sola el pago.
Lee la cronología de notas
Las notas privadas suelen mostrar intentos, stock, webhooks y transiciones. Léelas en orden e identifica el último estado correcto.
Secuencia útil:
pedido creado
pago iniciado
pago confirmado
estado cambiado por pasarela o tarea
efectos de stock, email y logísticaCompara zonas horarias antes de concluir que llegaron desordenados.
Revisa orden y reintentos de webhooks
La red no garantiza el orden. Un evento antiguo “pago fallido” puede llegar después de una captura si el handler no comprueba el objeto actual.
Inspecciona historial, ID y estado de API. La entrega repetida no debe repetir stock o logística.
No reproduzcas eventos sin saber qué hace la integración con un pedido ya pagado.
Compara la fecha de creación del evento con la fecha de entrega y con la versión actual del objeto de pago. El handler no debe aceptar una transición antigua solo porque llega más tarde. En métodos asíncronos, define qué eventos pueden avanzar o revertir el estado y cuáles son informativos.
Comprueba la cancelación de impagados
WooCommerce puede cancelar pedidos tras el periodo de reserva de stock. Si la confirmación tarda más, cron cancela antes de recibir el pago.
Revisa ajustes de inventario y Action Scheduler alrededor de la transición. Aumentar la reserva ayuda a métodos lentos, pero retiene stock más tiempo.
Elige el valor según comportamiento real y asegúrate de que el webhook recupera un pago genuino.
Comprueba cómo se reserva y devuelve el stock. Si la tarea de cancelación ya repuso unidades y después entra el pago, restaurar el pedido sin volver a reservar puede vender más de lo disponible. Los cupones limitados también pueden haberse liberado y necesitan conciliación.
Inspecciona pasarela y PHP
Relaciona la transición con logs de pasarela, WooCommerce y PHP. Un timeout puede interpretarse como fallo aunque el proveedor capture después.
No trates timeout como rechazo definitivo. El código propio debe consultar la referencia estable antes de crear otro cargo o estado final.
Corrige fatals y colas antes de reintentar.
Busca procesos que escriban casi a la vez: retorno del navegador, webhook, consulta programada y ERP. Conserva el ID del evento y el actor en notas. La lógica debe consultar el estado actual antes de guardar, no decidir con un objeto cargado minutos antes.
Encuentra escritores externos
ERP, logística, suscripciones, fraude y código propio pueden cambiar estados. Busca el nombre de integración y revisa hooks de pago, cancelación y fallo.
$order = wc_get_order( $order_id );
if ( $order && $order->is_paid() ) {
// No degradar solo por un evento local antiguo.
}Es un patrón defensivo; la evidencia del proveedor y las reglas comerciales deciden.
Corrige pedidos afectados
Tras verificar la captura, restaura el estado mediante WooCommerce o la herramienta oficial. Añade una nota con referencia y motivo.
Comprueba si el stock volvió, se enviaron emails o logística canceló. Corrige cada efecto una vez.
Nunca crees un segundo pago para que el estado parezca normal.
Revisa qué mensaje recibió el cliente. Un email de fallo seguido de una confirmación sin explicación puede provocar otro intento o una disputa. Tras verificar el pago, comunica el estado real y el plazo de preparación sin detalles internos de la pasarela.
Verifica el ciclo reparado
Prueba éxito, rechazo, confirmación tardía y webhook repetido en sandbox. Un pago capturado debe alcanzar su estado y no degradarse por un evento obsoleto.
Revisa que Cancelado real y reembolso sigan funcionando.
Fuerza un orden de eventos invertido si el sandbox lo permite. El resultado final debe depender del estado autoritativo, y cada efecto —stock, email, factura y logística— ejecutarse como máximo una vez.
El mantenimiento recurrente debe comparar capturas del proveedor con pedidos Fallidos, Cancelados y Pendientes antiguos. Alertar estas contradicciones evita fallos de preparación y atención al cliente.