Un pago puede aparecer como autorizado en la pasarela mientras el pedido sigue pendiente en WooCommerce. También puede ocurrir que un pedido se complete correctamente, pero el ERP, la herramienta de reservas o el sistema de facturación no reciba la información a tiempo. Los webhooks WooCommerce sirven precisamente para evitar esa desconexión: notifican a otro sistema cuando sucede un evento relevante en la tienda.
No sustituyen a una pasarela de pago ni corrigen una configuración bancaria incompleta. Su función es distinta: transportar eventos entre aplicaciones para que la operativa no dependa de revisiones manuales, exportaciones periódicas o procesos que se ejecutan demasiado tarde.
Un webhook es una notificación HTTP que WooCommerce envía a una URL externa cuando ocurre una acción determinada. Por ejemplo, al crear un pedido, actualizarlo, reembolsarlo o eliminarlo. En vez de que un sistema externo consulte continuamente si hay novedades, WooCommerce le comunica el cambio en el momento en que se produce.
La notificación incluye datos en formato JSON. Según el tema elegido, puede contener información del pedido, cliente, productos, importes, estado, método de pago o envío. El sistema receptor procesa esos datos y devuelve una respuesta HTTP correcta, normalmente un código 200 o 201.
La ventaja es clara cuando hay varias piezas conectadas: WooCommerce cobra, una aplicación emite la factura, el ERP descuenta existencias y una plataforma de atención al cliente crea una tarea de seguimiento. Cada sistema recibe el evento que necesita sin que el equipo tenga que intervenir pedido a pedido.
Un webhook no es lo mismo que una API. La API permite solicitar datos o ejecutar acciones bajo demanda. El webhook envía un aviso automático tras un evento. En proyectos complejos, ambos mecanismos suelen trabajar juntos: el webhook avisa de que hay un nuevo pedido y el sistema receptor usa la API para consultar información adicional o actualizar un campo concreto.
La utilidad depende de la operación. Una tienda pequeña que solo gestiona unos pocos pedidos desde el propio panel puede no necesitar automatizaciones externas. Sin embargo, cuando la venta activa procesos fuera de WordPress, los webhooks reducen retrasos y errores de coordinación.
Son especialmente útiles para sincronizar pedidos con un ERP, generar facturas, registrar ventas en un CRM, avisar a un proveedor logístico, dar acceso a una membresía o enviar datos a una plataforma de reservas. También ayudan en tiendas con procesos de revisión, por ejemplo cuando los pedidos pagados requieren validación documental o preparación desde distintos almacenes.
En pagos, conviene distinguir dos niveles. La pasarela puede recibir una confirmación asíncrona del banco y actualizar el pedido en WooCommerce. Después, un webhook de WooCommerce puede informar a otro sistema de que ese pedido ya está procesando o completado. Mezclar ambas notificaciones es una fuente habitual de problemas: una procede de la entidad de pago y la otra de la tienda.
Con RedSys, Ceca, Bizum u otros medios de pago, el primer objetivo debe ser siempre que la notificación de la pasarela actualice correctamente el estado del pedido. Solo después tiene sentido encadenar automatizaciones externas basadas en ese estado.
La configuración se realiza desde el área de ajustes avanzados de WooCommerce, en la sección de webhooks. Para crear uno nuevo se debe asignar un nombre identificable, seleccionar el estado activo, definir el tema del evento y añadir la URL de entrega del sistema receptor.
El nombre importa más de lo que parece. En instalaciones con varias integraciones, una etiqueta como “ERP – pedido completado – producción” facilita detectar qué proceso falla y evita modificar el webhook equivocado meses después.
No todos los eventos sirven para la misma tarea. Si se debe crear un registro interno en cuanto el cliente hace el pedido, puede interesar el evento de pedido creado. Si el proceso solo debe arrancar cuando el cobro esté confirmado, es más seguro usar una actualización asociada a un estado concreto, como procesando o completado.
La elección depende del producto y del flujo de pago. Una tienda que vende productos físicos suele usar “procesando” como señal de pago confirmado y pedido pendiente de preparación. En productos virtuales o servicios, “completado” puede ser el estado más adecuado. No conviene asumir que ambos estados son equivalentes en todas las configuraciones.
También hay que evitar lanzar acciones irreversibles demasiado pronto. Enviar un pedido a fabricación, emitir una factura definitiva o conceder acceso de larga duración tras un evento de creación puede generar incidencias si el pago termina fallando, queda pendiente o se cancela.
WooCommerce permite definir un secreto de entrega. Con él, la plataforma firma la petición mediante una cabecera. El servidor receptor debe validar esa firma antes de aceptar los datos.
Este paso evita que un tercero envíe solicitudes falsas a la URL del webhook simulando pedidos o reembolsos. La URL debe usar HTTPS y el secreto debe tratarse como una credencial: no se publica, no se inserta en código visible y se reemplaza si existe sospecha de exposición.
La seguridad no termina ahí. El endpoint receptor debe comprobar el método HTTP, limitar los datos aceptados, registrar intentos anómalos y aplicar controles de acceso cuando sea necesario. Recibir un JSON válido no demuestra por sí solo que el evento sea legítimo.
Un sistema externo no debe asumir que cada webhook llegará una sola vez. Las redes fallan, los servidores responden tarde y WooCommerce puede reintentar una entrega. Por eso el receptor debe ser idempotente: si recibe dos veces el mismo evento, el resultado final debe ser el mismo que si lo hubiera recibido una sola vez.
La práctica habitual es guardar el identificador del webhook o del pedido junto con el tipo de evento procesado. Antes de crear una factura, un envío o un registro en CRM, el sistema comprueba si esa acción ya se ejecutó. Si existe, responde correctamente sin duplicar el proceso.
Esto es decisivo en operaciones de cobro. Un segundo aviso nunca debería generar un segundo cargo, una nueva suscripción, dos albaranes o dos correos de acceso. La automatización debe proteger el negocio incluso cuando la entrega no sea perfecta.
También es recomendable responder rápido. Si el receptor necesita procesar cálculos pesados, consultar varios servicios o generar documentos, debe aceptar la notificación y enviar el trabajo a una cola interna. Mantener la petición abierta hasta terminar todo el proceso aumenta la probabilidad de tiempos de espera y reintentos.
Un webhook bien configurado puede fallar por detalles externos a WooCommerce: un certificado SSL inválido, una redirección, reglas de firewall, autenticación mal planteada o un servidor que bloquea solicitudes entrantes. Por eso las pruebas deben hacerse con pedidos reales de prueba y no solo revisando que la URL parece correcta.
Conviene validar al menos cuatro escenarios: pago aceptado, pago rechazado, pedido reembolsado y reintento de entrega. Si la tienda trabaja con productos virtuales, físicos, cupones o impuestos complejos, hay que comprobar que el sistema receptor interpreta bien los importes y estados en cada caso.
Los registros de entrega de WooCommerce permiten revisar la respuesta obtenida de cada intento. Un código 401 suele indicar un problema de autenticación o firma. Un 404 apunta a una URL incorrecta. Los códigos 500 reflejan un fallo en el sistema receptor. Si hay redirecciones 301 o 302, es preferible corregir la URL final en lugar de confiar en que el servicio las siga siempre.
En desarrollos a medida, conviene trabajar primero con un entorno de pruebas. Las credenciales, las URLs y los estados de pedido pueden variar entre staging y producción. Activar una integración sin separar ambos entornos puede terminar enviando pedidos de prueba a contabilidad, logística o clientes reales.
El error más común es ejecutar una acción crítica basándose en un estado incorrecto. Un pedido “pendiente de pago” no debe activar un servicio, y un pedido “cancelado” no debe continuar hacia preparación. Revisar el ciclo completo del pedido es más fiable que automatizar solo a partir del nombre de un evento.
Otro fallo habitual es confiar exclusivamente en el webhook para mantener datos críticos sincronizados. Los webhooks son muy rápidos, pero una arquitectura profesional debe poder recuperar eventos pendientes. Una tarea de conciliación diaria mediante API o exportación controlada permite detectar pedidos que no llegaron al sistema externo por una caída temporal.
También conviene evitar enviar más información de la necesaria. Si el ERP solo requiere identificador, productos, impuestos y dirección de envío, no es necesario replicar todos los datos del cliente en cada plataforma. Menos datos expuestos significan menos superficie de riesgo y menos complejidad de mantenimiento.
Cuando la tienda depende de una integración bancaria española, la implementación debe respetar el orden lógico: pasarela correctamente instalada, notificaciones de pago verificadas, estados de WooCommerce coherentes y, después, webhooks hacia herramientas externas. Codection trabaja precisamente en esa capa técnica donde la operativa de pago y las extensiones de WordPress deben comportarse como un único proceso.
Antes de automatizar el siguiente paso de un pedido, define qué evento demuestra de verdad que ese paso debe ocurrir, qué sucede si el aviso se repite y cómo recuperarás una entrega perdida. Esa decisión previa vale más que cualquier webhook creado con prisa.
Nota: Hay una valoración incrustada en esta entrada, por favor, visita esta entrada para valorarla.
Análisis addon Bizum Tickera: requisitos, funcionamiento y criterios para activar pagos móviles en la venta…
Compara Ceca vs Stripe para reservas en WordPress: comisiones, integración, pagos, devoluciones y qué opción…
Aprende cómo funciona la tokenización en pagos online, qué datos protege, cuándo permite cobros recurrentes…
Aprende a proteger claves API en WordPress para evitar fraudes, errores de integración y accesos…
Ya está disponible la versión 2.2 de Contact Form 7 – Integración con RedSys, y…
Una auditoría de pagos WordPress detecta cobros fallidos, pedidos desincronizados y errores de configuración antes…