Un pedido llega al checkout, el cliente selecciona Bizum, confirma el pago desde su banco y vuelve a la tienda. Sin embargo, WooCommerce mantiene el pedido como pendiente o muestra un error. Cuando se busca por qué falla Bizum WooCommerce, el problema rara vez está en un único punto: intervienen la configuración del banco, la pasarela, WordPress, el servidor y el flujo real de pago.
La forma más rápida de resolverlo no es cambiar ajustes al azar. Hay que identificar en qué momento se rompe la operación: antes de redirigir al banco, durante la autenticación, al regresar al sitio o al recibir la notificación del pago. Esa diferencia reduce mucho el tiempo de diagnóstico.
Por qué falla Bizum en WooCommerce: localiza el punto de ruptura
Bizum para ecommerce suele estar habilitado dentro del contrato de adquisición de la entidad bancaria y se procesa mediante una pasarela como RedSys o Ceca, según el banco y la integración instalada. Por eso, aunque el comprador vea Bizum como método de pago, el origen del fallo puede ser bancario, técnico o de configuración.
Si el cliente no puede seleccionar Bizum, el fallo está normalmente en la disponibilidad del método. Si llega a la pantalla bancaria pero recibe un rechazo, hay que revisar la operación y las condiciones contratadas. Si el banco confirma el cargo pero el pedido sigue pendiente, la prioridad es la notificación al sitio y la actualización del estado del pedido.
Conviene hacer una prueba con un pedido nuevo y anotar la hora exacta, el importe, el número de pedido y el mensaje mostrado. Estos datos permiten cruzar los registros de WooCommerce, del plugin y de la plataforma bancaria sin trabajar a ciegas.
1. Bizum no está activado para el comercio
Tener una cuenta bancaria que permite pagar con Bizum como particular no implica que el comercio pueda cobrar con Bizum online. La entidad debe activar ese método en el terminal virtual o en el contrato de pasarela. En algunos casos, el comercio tiene RedSys operativo con tarjeta, pero Bizum aún no figura entre los métodos habilitados.
Revise la documentación recibida del banco o consulte directamente con su gestor. Debe confirmar que Bizum está activado para ecommerce, para el entorno correcto y para el número de terminal asignado. También conviene verificar si existen límites de importe, restricciones por sector o requisitos adicionales de validación.
No intente resolver un rechazo de autorización modificando claves de WordPress si el banco todavía no ha habilitado el servicio. Es una causa frecuente y se detecta antes de entrar en ajustes técnicos.
2. Credenciales de pruebas y producción mezcladas
Las pasarelas bancarias separan habitualmente el entorno de pruebas del entorno real. Cada uno puede tener su propio código de comercio, terminal, secreto de firma y URL de operación. Un plugin configurado con credenciales de prueba en un sitio en producción puede redirigir de forma incorrecta o devolver errores de autenticación y firma.
Compruebe que todos los datos pertenecen al mismo entorno. No basta con cambiar el selector de «pruebas» a «producción» en WooCommerce: las credenciales, la clave secreta y, cuando aplique, las URL configuradas en el panel bancario también deben corresponder a producción.
Tras guardar los cambios, vacíe la caché de página y de objetos. Si la tienda usa un CDN, revise que no esté sirviendo una versión antigua de la página de checkout o bloqueando parámetros necesarios en el retorno.
3. La clave de firma es incorrecta o se ha copiado con formato erróneo
La firma protege la comunicación entre el comercio y la pasarela. Si la clave secreta no coincide, contiene espacios añadidos, caracteres modificados o pertenece a otro terminal, el banco puede rechazar la solicitud antes de presentar Bizum al cliente.
Este error es especialmente habitual al copiar la clave desde un PDF, un email o el panel de la entidad. Algunas claves deben transformarse o tratarse con un formato específico según la versión de la pasarela y el plugin. No asuma que una contraseña visible se pega siempre de forma literal.
Use la guía técnica del plugin que tenga instalado y confirme qué tipo de clave solicita el campo. Si el registro indica un error de firma, no cambie otros parámetros hasta validar este dato. Una firma inválida suele impedir cualquier operación, tanto con Bizum como con tarjeta si comparten terminal.
4. El importe, la moneda o el pedido no cumplen las condiciones
WooCommerce calcula el importe final incluyendo impuestos, cupones, gastos de envío y redondeos. La pasarela recibe ese total en el formato exigido por su API. Un descuento mal implementado, un plugin de multicurrency o una extensión que altera el precio al final del checkout puede generar una cantidad inválida.
Bizum para comercios se opera normalmente en euros. Si la tienda permite dólares u otras divisas, hay que definir qué ocurre antes de enviar al comprador a la pasarela: conversión controlada a EUR, ocultación del método para esa moneda o una configuración compatible con el adquirente. Mostrar Bizum para un pedido que llega en una divisa no aceptada crea errores difíciles de interpretar.
También revise pedidos de importe cero, productos con precios dinámicos y totales con demasiados decimales. Una prueba con un producto simple, sin cupón ni envío, ayuda a separar un fallo general de un conflicto en el cálculo del carrito.
5. La URL de notificación no llega a WordPress
El pago puede haberse completado correctamente y, aun así, el pedido permanecer pendiente. En ese escenario, el problema suele estar en la notificación servidor a servidor que la pasarela envía a la tienda. Esa notificación es la que permite validar el resultado y cambiar el pedido a procesando, completado o fallido según corresponda.
La URL debe ser pública, usar HTTPS válido y no requerir inicio de sesión. Un firewall, una regla de seguridad, protección por contraseña, mantenimiento activo o una restricción geográfica puede bloquearla. También pueden interferir reglas de WAF del hosting, configuraciones de Cloudflare o plugins que bloquean solicitudes POST externas.
Revise los logs de la pasarela y los registros de WooCommerce. Si el banco marca la operación como autorizada pero no hay una entrada de notificación en el sitio, pida al proveedor de hosting que revise las solicitudes entrantes y sus códigos de respuesta. Un error 403, 404 o 500 ofrece una pista concreta; un pedido pendiente por sí solo no.
6. Caché, optimización o seguridad rompen el checkout
Las herramientas de rendimiento son útiles, pero no deben tratar el checkout como una página estática. Minificar JavaScript, retrasar scripts, combinar archivos o cachear respuestas puede afectar los campos y procesos que el plugin de pago necesita para generar la operación.
Excluya del sistema de caché las páginas de carrito, finalizar compra, cuenta y las rutas de retorno o notificación que utilice la pasarela. Si usa optimización de JavaScript, pruebe a excluir los scripts del gateway y de WooCommerce. Haga los cambios de uno en uno: desactivar cinco plugins a la vez puede solucionar el síntoma sin revelar la causa.
Los plugins de seguridad merecen la misma revisión. Protecciones contra bots, validaciones de nonce demasiado estrictas y bloqueos de IP pueden afectar una solicitud legítima del banco. La solución correcta es crear una excepción limitada para el endpoint necesario, no rebajar toda la seguridad del sitio.
7. Hay un conflicto con el tema, otro plugin o el checkout por bloques
No todos los plugins de pasarela funcionan igual con el checkout clásico y el Checkout Block de WooCommerce. Si Bizum desaparece, no carga correctamente o falla al confirmar únicamente en el checkout por bloques, compruebe la compatibilidad declarada por el desarrollador de la extensión.
El tema también puede modificar plantillas, campos de pago y eventos de JavaScript. Las personalizaciones de checkout, plugins de facturación, sistemas de suscripción y herramientas de conversión suelen intervenir en el mismo flujo. Actualizar WooCommerce sin actualizar la extensión de pago, o al revés, puede introducir incompatibilidades.
La prueba técnica más útil consiste en reproducir el caso en un entorno staging con un tema estándar y los plugins mínimos. Si Bizum funciona allí, reactive componentes de forma progresiva. Si falla incluso en una instalación reducida, la investigación debe centrarse en las credenciales, el servidor o la configuración bancaria.
8. El pedido se crea, pero el estado no se actualiza como espera
No todos los productos requieren el mismo estado final. Un pedido con productos físicos suele pasar a procesando tras el cobro, mientras que uno con productos virtuales y descargables puede completarse automáticamente. Extensiones de reservas, donaciones, tickets o membresías pueden añadir sus propias reglas.
Antes de considerar que Bizum ha fallado, compruebe la nota del pedido y el identificador de transacción. Puede que el pago esté registrado y el comportamiento corresponda a una regla de negocio, una automatización o una personalización del estado. Esto es distinto de un pago autorizado que nunca recibió confirmación técnica.
9. Falta información para escalar el caso
Si necesita abrir una consulta con el banco, el hosting o el soporte del plugin, entregue evidencias concretas. Incluya número de pedido, fecha y hora, importe, modo de operación, código o mensaje de error, logs de WooCommerce y resultado visible en el panel de la pasarela. Oculte siempre las claves secretas y cualquier dato personal del comprador.
Una captura del error ayuda, pero los registros marcan la diferencia. Permiten saber si WooCommerce generó la solicitud, si la pasarela la rechazó, si el cliente canceló o si la notificación no alcanzó el servidor. Sin esa secuencia, el soporte solo puede proponer hipótesis.
Cuando la tienda combina WooCommerce con reglas de checkout, reservas, donaciones o desarrollo propio, puede ser más eficiente revisar la integración completa que aplicar parches sucesivos. Codection trabaja precisamente en este tipo de implementaciones de pasarelas y extensiones para WordPress, donde la compatibilidad real del flujo de cobro importa tanto como activar una opción.
Un pago no debería convertirse en un misterio para el cliente ni para el equipo que administra la tienda. Con una prueba controlada, registros completos y una revisión ordenada de banco, pasarela y WordPress, cada error deja de ser genérico y pasa a tener una causa que se puede corregir.
(Ninguna valoración todavía)
Cargando…