WooCommerce / Pagos
WooCommerce: el pago falla pero al cliente se le ha cobrado
Respuesta corta
El pago y la actualización del pedido son dos pasos separados. Cuando el proveedor confirma un pago pero WooCommerce nunca recibe, acepta o termina de procesar esa confirmación, el dinero se cobra y el pedido se queda pendiente, fallido o cancelado. Compara el registro de eventos del proveedor, las notas del pedido y el registro de la pasarela para un pedido afectado: el primer punto en el que no coinciden es donde se perdió la confirmación.
Síntomas
- El panel del proveedor muestra un cobro correcto; el pedido de WooCommerce está Pendiente de pago, Fallido o Cancelado.
- Al cliente se le cobró pero no recibió el email de confirmación del pedido, o el pedido no existe.
- Los pedidos pasan a Procesando horas después, o solo cuando el cliente se pone en contacto.
- Al cliente se le cobró dos veces y hay dos pedidos, solo uno de ellos pagado.
Causas más comunes
- La notificación nunca llegó a la tienda. El callback o webhook de servidor a servidor del proveedor fue bloqueado por un firewall, un WAF, la protección contra bots de la CDN, la autenticación básica, un plugin de modo mantenimiento o un bloqueo geográfico.
- La notificación fue redirigida. Una redirección de HTTP a HTTPS o de www a sin www en la URL de callback. Muchos proveedores consideran una redirección como entrega fallida.
- La notificación fue rechazada. Un secreto de webhook o una clave de firma incorrectos, por ejemplo tras recrear el endpoint del webhook o al mezclar claves de prueba y reales.
- La tienda falló al procesarla. Un error PHP en el código que se ejecuta cuando un pedido se paga (stock, emails, una sincronización con el ERP) interrumpió la actualización.
- El pedido ya no estaba pendiente. El tiempo de reserva de stock lo canceló antes de que llegara una confirmación tardía, o el cliente pagó desde una pestaña antigua.
- La redirección era la única confirmación. El cliente cerró la ventana tras pagar o tras 3D Secure, y la tienda dependía de la redirección del navegador en lugar de una notificación del servidor.
- No se pudo localizar el pedido. Números de pedido personalizados, multisitio o una referencia de pedido cambiada impiden que el plugin de la pasarela encuentre el pedido.
Diagnóstico
1. Elige un pedido afectado y reconstruye su cronología
De tres fuentes, apunta cada evento con su hora exacta:
| Fuente | Qué anotar |
|---|---|
| Panel del proveedor de pagos | Pago creado, autorizado, capturado; intentos de notificación o webhook y sus respuestas |
| Notas del pedido en WooCommerce | Cambios de estado y mensajes de la pasarela, con hora |
| Registro de la pasarela (WooCommerce → Estado → Registros) | Notificaciones entrantes, resultados de validación, errores |
El primer evento que aparece en el proveedor pero no en la tienda es donde se perdió la confirmación.
2. Revisa el registro de entregas del proveedor
La mayoría de los proveedores muestran cada intento de notificación o webhook con su código de respuesta. Léelos:
- Timeout o error de conexión: la tienda no respondió a tiempo, o la petición nunca llegó.
- 3xx: la URL de callback redirige; actualízala a la URL final.
- 401 / 403: la autenticación, un plugin de seguridad o un WAF la bloquearon.
- 400: el plugin de la pasarela la rechazó, a menudo por una firma o un secreto que no coinciden.
- 500: PHP falló al procesarla. Busca un error fatal a esa hora.
3. Confirma que la petición llegó al servidor
Busca en el log de acceso del servidor web peticiones a la URL de callback a las horas que indica el proveedor. La URL depende del plugin de la pasarela: a menudo una URL ?wc-api= o un endpoint REST. Si no hay ninguna entrada, la petición se bloqueó antes de llegar a PHP: CDN, WAF o firewall.
4. Busca errores durante el procesamiento del pedido
Si la notificación llegó a la tienda y fue aceptada, averigua qué pasó después: una entrada fatal-errors, un error PHP o una acción programada fallida en el mismo minuto. El código enganchado a woocommerce_payment_complete o a los cambios de estado del pedido se ejecuta dentro de la petición de la notificación; si falla, puede que el pedido nunca se guarde como pagado.
Registros y comprobaciones técnicas
- Proveedor: registro de eventos e historial de entregas de webhooks o notificaciones de los pagos afectados.
- WooCommerce → Estado → Registros: el origen de registro de la pasarela y
fatal-errors. - Logs de acceso y de errores del servidor web para la URL de callback.
- WooCommerce → Ajustes → Productos → Inventario: el tiempo de reserva de stock que cancela los pedidos no pagados.
- Herramientas → Acciones programadas: acciones fallidas o pendientes creadas alrededor de la hora del pago.
- Registros del plugin de seguridad, de la CDN y del WAF en busca de peticiones bloqueadas a la URL de callback.
Soluciones
- Haz accesible la URL de callback: exclúyela de los desafíos del WAF, la protección contra bots, el modo mantenimiento, la autenticación básica y la caché. Usa la URL final, sin redirecciones.
- Corrige el secreto del webhook en los ajustes de la pasarela para que coincida con el endpoint configurado en el proveedor, por separado para modo prueba y modo real.
- Arregla el código que falla durante el procesamiento del pago, y lleva el trabajo lento (sincronizaciones con el ERP, llamadas externas) a tareas en segundo plano para que la petición de la notificación termine rápido.
- Asegúrate de que las notificaciones de servidor están activadas, para que el pedido no dependa de que el navegador del cliente vuelva a la tienda.
- Cuadra los pedidos afectados: para cada pago correcto sin pedido pagado, verifica importe, divisa y cliente, y después completa o recrea el pedido con las herramientas normales de la pasarela o de WooCommerce, con una nota que describa la verificación.
Qué no hacer
- No desactives la verificación de la firma «para que funcione». Permite que cualquiera marque pedidos como pagados.
- No borres los pedidos fallidos o cancelados: son la evidencia y el vínculo con el pago.
- No reembolses ni vuelvas a cobrar a los clientes antes de cuadrar ambos lados.
- No subas el tiempo de reserva de stock como solución. Oculta las confirmaciones tardías en lugar de arreglarlas.
Cuándo recurrir a un experto
Recurre a un ingeniero cuando los cobros sin pedido se siguen produciendo, cuando no sabes qué pedidos están afectados, cuando los registros del plugin de la pasarela no muestran nada, o cuando el fallo está en código a medida que se ejecuta después del pago.
Problemas relacionados
- WooCommerce / Integraciones Webhooks de WooCommerce que fallan: cómo diagnosticarlos Registros de entrega, códigos de respuesta, firmas y por qué WooCommerce desactiva un webhook tras varias entregas fallidas seguidas.
- WooCommerce / Checkout El checkout de WooCommerce no funciona: cómo diagnosticar la causa raíz Determina primero si el fallo ocurre antes de la petición del checkout, durante ella o después de la respuesta de la pasarela. El panel de red y los registros PHP suelen revelar qué capa falla.
- WooCommerce / Pedidos Pedidos de WooCommerce que no aparecen o son incorrectos Antes de dar un pedido por perdido, revisa todos los estados, los borradores y el proveedor de pagos. Los totales incorrectos suelen venir de impuestos, cargos, cupones o recálculos.
- WooCommerce / Rendimiento Problemas con Action Scheduler en WooCommerce Acciones programadas vencidas, fallidas y atascadas: cómo funciona la cola, por qué se detiene y cómo arreglarlo sin perder trabajo pendiente.
Preguntas frecuentes
¿Por qué WooCommerce dice que el pago falló si al cliente se le cobró?
Porque la tienda no recibió o no pudo procesar la confirmación del proveedor. Causas habituales: una URL de notificación bloqueada o redirigida, un secreto de webhook incorrecto, un error PHP mientras se actualizaba el pedido, o un pedido que ya estaba cancelado cuando llegó la confirmación.
¿Por qué se canceló el pedido si el cliente pagó?
Con la gestión de inventario activada, WooCommerce cancela los pedidos no pagados al terminar el tiempo de reserva de stock. Si la confirmación llega después, encuentra un pedido cancelado. Las confirmaciones tardías suelen ser síntoma de que los webhooks o notificaciones fallan en los primeros intentos.
¿Puedo marcar el pedido como procesando sin más?
Solo después de confirmar el pago en el panel del proveedor y comprobar importe, divisa y cliente. Añade una nota al pedido explicando qué se verificó. Y arregla también la causa, o volverá a pasar.
¿Cómo encuentro todos los pedidos afectados?
Exporta los pagos correctos del proveedor en el periodo afectado y crúzalos con los pedidos de WooCommerce por número de pedido, ID de transacción o importe y email. Los pagos sin un pedido pagado que les corresponda son los que hay que cuadrar.