Qué importa primero: El cliente puede haber pagado a pesar de que WooCommerce registró un tiempo de espera, fallo de llamada o error fatal local. La transacción pasarela es la fuente financiera de la verdad para si los fondos se mueven.
Qué indica realmente este síntoma
Cambiar la orden a Procesamiento sin pruebas puede cumplir una orden no pagada, mientras que volver a intentar el pago puede crear un cargo duplicado.
Recopila pruebas antes de cambiar nada
- Registro de identificación de pedido, cantidad, moneda, referencia pasarela y hora exacta.
- Comprueba el panel de control pasarela para el estado capturado, autorizado, fallido o reembolsado.
- Coincide con pasarela webhook/API logs con WooCommerce logs y notas de pedido.
- Inspecciona stock y los efectos secundarios de correo electrónico antes de cualquier cambio de estado manual.
Causas más habituales
- Fallo en la página de retorno: El pago tuvo éxito, pero la redirección orientada al cliente falló.
- Webhook rechazado: La devolución de llamada pasarela no pudo autenticarse ni llegar a WordPress.
- Local fatal después del pago: WooCommerce se estrelló al actualizar el pedido.
- ambigüedad del tiempo de espera: La petición se cronometró mientras que el pasarela se completó asíncronamente.
Secuencia segura de diagnóstico y reparación
- Reconcile cada transacción de orden afectada por transacción.
- Corregir el llamada de retorno, webhook o error fatal para pedidos futuros.
- La actualización solo confirmó los pedidos pagados con una nota de auditoría y el manejo deliberado de stock.
- Ejecute un pago de prueba controlado a través del ciclo completo.
Cómo distinguir entre las causas probables
No trates Fallo en la página de retorno y Webhook rechazado como causas equivalentes. El pago tuvo éxito, pero la redirección orientada al cliente falló. En cambio, la devolución de llamada pasarela no pudo autenticarse ni llegar a WordPress. Para distinguirlas, usa estas dos comprobaciones: Registro de identificación de pedido, cantidad, moneda, referencia pasarela y hora exacta; y comprueba el panel de control pasarela para el estado capturado, autorizado, fallido o reembolsado. Con esos datos podrás decidir si conviene aplicar la primera acción controlada —Reconcile cada transacción de orden afectada por transacción— o si debes conservar el estado actual y ampliar la investigación.
En una tienda activa, reproduce el problema con un pedido de prueba controlado y sigue el mismo recorrido de pago, stock, impuestos y notificaciones que usan los clientes. No cambies varios componentes del checkout a la vez, porque destruirías la evidencia necesaria para atribuir el fallo. Documenta la fecha y hora exactas, la URL o transacción afectada, el último estado correcto conocido y cada cambio realizado durante el diagnóstico. Ese registro permite distinguir una reparación reproducible de una desaparición temporal del síntoma.
Qué no debes hacer
No pida al cliente que vuelva a pagar hasta que se haya comprobado la transacción pasarela.
Cómo verificar la reparación
- Gateway y WooCommerce están de acuerdo en el estado de pago final.
- Stock, el correo electrónico y los efectos secundarios de cumplimiento ocurren exactamente una vez.
- Un nuevo pago controlado se actualiza automáticamente.
Que el síntoma visible desaparezca no es suficiente. Cierra la incidencia solo cuando la acción original que fallaba, el recorrido de negocio relacionado y los registros relevantes confirmen que el problema ha desaparecido.