Si el proveedor confirma el cobro pero WooCommerce mantiene Pendiente de pago, el checkout creó el pedido pero la confirmación no lo actualizó. Puede fallar el webhook, retorno del navegador, tarea programada o respuesta de API.
No pidas pagar otra vez. Relaciona el cobro existente y protege la preparación frente a omisión y duplicación.
Confirma que el pago corresponde
Compara importe, moneda, hora, referencia del cliente y merchant reference. Usa ID de transacción y número de pedido, pero nunca tarjeta.
Comprueba si el proveedor muestra Capturado, Autorizado, Pendiente o Revertido. Una pantalla de éxito no garantiza que se capturaran fondos.
Añade una nota privada con el estado verificado sin cambiar todavía el pedido manualmente.
Lee notas y log de pasarela
Las notas muestran inicio, método y callbacks recibidos. Relaciónalas con WooCommerce > Estado > Registros.
Correlaciona:
- ID de pedido
- ID de transacción
- payment intent o merchant reference
- ID de webhook
- horas y zonas horariasAnonimiza secrets, firmas, tokens y datos personales.
Comprueba la entrega del webhook
En el panel de la pasarela localiza el evento de confirmación. Un 404 sugiere endpoint incorrecto; 403, firewall; 500, error de aplicación; timeout, respuesta lenta aunque quizá se procesara.
No lo reenvíes repetidamente hasta confirmar idempotencia. Una integración correcta reconoce eventos ya procesados, pero el código propio puede duplicar efectos.
Conserva el ID y cuerpo sensible solo en el sistema autorizado.
Verifica la firma y el tipo de evento antes de confiar en él. Un evento de autorización no equivale necesariamente a captura, y un evento legítimo dirigido a otra cuenta o entorno no debe actualizar producción. Comprueba también el orden: algunos proveedores reintentan y entregan eventos fuera de secuencia.
Verifica la URL tras cambios
Migraciones, HTTPS, mantenimiento e idiomas pueden alterar la URL. Confirma que el endpoint de WooCommerce coincide con el configurado y responde públicamente con SSL válido.
Excluye webhooks de caché, login y challenges amplios. Crea una excepción de firewall estrecha según requisitos oficiales.
No desactives la protección de toda la web.
El retorno del navegador y el webhook cumplen funciones distintas. El cliente puede cerrar la pestaña y el webhook debe completar el pedido; a la inversa, una página de gracias visible no sustituye la confirmación firmada. Prueba ambos caminos por separado.
Inspecciona PHP y acciones
Relaciona el webhook con errores PHP. Un fatal en la pasarela o en un hook de pedido puede detener el proceso después del cobro.
Algunas integraciones encolan trabajo. Busca acciones fallidas o atrasadas del pedido y corrige base de datos, cron o PHP antes de reintentar una.
No borres las acciones: son evidencia y pueden representar pagos sin procesar.
Revisa personalizaciones de estado
Un ERP, logística o código propio puede devolver un pedido pagado a Pendiente. Busca actor y hora en notas y hooks de payment_complete.
Usa la API de finalización, no cambios directos en base de datos:
$order = wc_get_order( $order_id );
if ( $order && ! $order->is_paid() ) {
$order->payment_complete( $transaction_id );
}Es ilustrativo. Verifica la transacción y prioriza la herramienta de recuperación de la pasarela.
Concilia y repara
Clasifica cada caso como pagado, autorizado, fallido o incierto mediante evidencia del proveedor. Solo después actualiza WooCommerce o reproduce un evento verificado.
Corrige endpoint, SSL, firewall, error del plugin, cron o hook de estado. Conserva la trazabilidad en notas privadas.
No envíes emails ni prepares dos veces.
Concilia también stock y cupones. Si el pedido permaneció Pendiente, una reserva puede haber caducado o una automatización puede no haberse ejecutado. Antes de forzar el estado, confirma que completar el pago no venderá unidades inexistentes ni reutilizará un cupón indebidamente.
Verifica la siguiente transacción
Ejecuta una compra controlada y confirma transición automática desde Pendiente al estado pagado correcto. Revisa stock, emails, importe, ID de transacción y activación de preparación.
Prueba también la recepción repetida del mismo webhook: no debe duplicar cambios.
El mantenimiento recurrente debe alertar sobre pedidos Pendientes antiguos con pago confirmado, webhooks fallidos y colas acumuladas. La conciliación es reparación urgente y control continuo.