Respuesta breve: el pago se autorizó en la pasarela, pero el mensaje que se lo comunica a WooCommerce nunca llegó o fue rechazado. El pedido se queda en “pendiente de pago” mientras el dinero sí se ha movido.
Por qué es peor que un error visible
Nada parece roto —la tienda está online y el checkout funciona para nuevas visitas, solo el estado del pedido es incorrecto—. Mientras tanto se ha cobrado a clientes que esperan, y eso convierte un fallo técnico en un problema de confianza rápido.
Dónde falla la confirmación
- El endpoint de webhook/IPN es inalcanzable, redirige o devuelve error.
- Un plugin de seguridad o firewall bloquea las peticiones servidor-a-servidor de la pasarela.
- La URL de retorno sigue apuntando a un dominio de staging o antiguo tras una migración: causa clásica.
- Una capa de caché intercepta el endpoint y devuelve una respuesta almacenada.
- La clave de firma de la pasarela cambió y la validación falla.
Revisa el registro de entregas de webhook/IPN del panel de la pasarela: suele mostrar las entregas fallidas y el estado HTTP que devolvió tu web.
Concilia con cuidado
- Exporta los pedidos afectados con horas e importes.
- Contrástalos con la lista de transacciones de la pasarela para saber cuáles se pagaron.
- Actualiza solo los pedidos confirmados, con una nota explicando por qué.
- Revisa el stock, porque los cambios manuales de estado pueden no haber ajustado el inventario.
Nunca completes en masa los pedidos pendientes sin contrastarlos con transacciones reales: enviarás pedidos impagados u ocultarás fallos de pago auténticos.
Corrige la causa y verifica
Conciliar los pedidos existentes es remediar; la reparación es restablecer la vía de confirmación. Haz un pedido controlado y confirma que el estado cambia solo, que sale el correo y baja el stock, y luego revisa el registro de la pasarela por entregas fallidas en cola.
CRITERIO DE INCIDENTE WP REPAIR
Reconstruye el incidente antes de corregirlo
Pendiente de pago puede significar que no hubo pago, que el callback no llegó o fue rechazado. Hay que conciliar antes de cambiar estados en masa.
- 1
Exporta IDs, horas, importes, monedas y referencias de pasarela.
- 2
Crúzalos con transacciones y entregas de webhook de la pasarela.
- 3
Revisa URL de callback, secreto de firma, firewall y caché.
- 4
Actualiza solo pedidos pagados confirmados con nota y revisión explícita de stock.
Qué debe quedar verificado
- Cada pedido histórico tiene una decisión de pago documentada.
- Un nuevo pedido controlado cambia de estado automáticamente.
- El webhook devuelve éxito y stock/correo se ejecutan una sola vez.
Fuentes técnicas oficiales
Continúa el diagnóstico
Esta guía explica el diagnóstico. Si la web está afectada ahora, la intervención debe preservar una vía de vuelta y verificar el recorrido real del negocio.
Ver el servicio de reparación urgente →SOBRE ESTE SÍNTOMA
Preguntas frecuentes de esta guía.
Si la tienda se ve bien y checkout funciona para nuevos clientes, ¿se puede romper el sistema de pago?+
Sí. Este problema particular deja a la tienda con un aspecto completamente normal, ya que los pagos fueron genuinamente autorizados en el gateway, pero el mensaje diciendo WooCommerce sobre él nunca llegó o fue rechazado, por lo que sólo el estado de las órdenes afectadas está mal mientras que todo lo demás funciona.
¿Es seguro marcar a granel todas las órdenes pendientes como completas para eliminar el retraso?+
No, nunca hacer esto sin igualar cada pedido a una transacción real primero. Pedidos pendientes a granel-completar riesgos de envío de productos que nunca se pagaron realmente, o enmascarar los fallos de pago genuinos que necesitan manejo separado.
¿Cuál es una razón común por la que la devolución de pagos deja de funcionar justo después de una migración del sitio?+
El webhook o IPN callback URL registrado con el gateway puede todavía apuntar en el sitio de puesta en escena o el antiguo dominio después de la migración. Ya que el gateway envía su confirmación a cualquier URL que tenga en el archivo, esto rompe silenciosamente la conexión hasta que se actualiza el endpoint.
Después de reconciliar las órdenes atascadas, ¿está el problema realmente arreglado?+
Reconciliar los pedidos existentes es la reparación, no la reparación. Confirme que la ruta de devolución de llamada en sí se restablece mediante la colocación de un orden controlado y la verificación de las actualizaciones de estado automáticamente, el correo electrónico envía, y stock disminuye, a continuación, compruebe el registro del gateway para cualquier otra entrega fallida en cola.