Ver el checkout no basta al actualizar pagos locales

Que el checkout cargue no garantiza que puedas cobrar. Tras actualizar una pasarela local, el banco puede rechazar la autorización, fallar el 3DS o no llegar el webhook que confirma el pedido. El resultado son pagos aparentemente completados, pedidos pendientes y ventas que tu equipo quizá detecte demasiado tarde.

Las actualizaciones para sitios con plugins de pagos locales exigen copia de seguridad, pruebas en staging y una compra completa validada en producción. Antes y después de cada cambio, comprueba checkout, autorización bancaria, 3DS, redirección, webhook, creación de pedido, email, conciliación y reembolso.

Resumen del proceso

Sigue este orden y no agrupes cambios.

1. Haz inventario: apunta versiones, pasarelas activas, credenciales y métodos de respaldo.
2. Crea una copia restaurable: guarda archivos, base de datos y registros antes del primer cambio.
3. Aísla un staging: usa claves sandbox, callbacks propios y correos dirigidos a un buzón interno.
4. Actualiza uno por uno: empieza por el componente menos crítico y anota el resultado.
5. Prueba un cobro completo: valida tarjeta, 3D Secure 2, retorno, webhook, pedido, email y reembolso.
6. Concilia: compara WooCommerce con el panel de Redsys, Stripe, PayPal o el banco.
7. Activa contingencia: pausa solo el medio afectado y deja otro método disponible.

Una prueba válida termina en la conciliación, no en la página de gracias.

Define una ventana sin campañas

Programa el cambio en una franja con poco tráfico y sin campañas de email, anuncios o lanzamientos. En comercios de Madrid que concentran pedidos entre las 18:00 y las 22:00, una actualización a media mañana reduce el número de compras que pueden quedar a medias.

Decide qué cambio vas a hacer

Escribe una línea por cada elemento que pretendes cambiar: WordPress, WooCommerce, PHP, tema, plugin de Redsys, extensión de Bizum o plugin de seguridad. Si no puedes explicar qué se actualiza y por qué, aplaza el cambio.

Prepara inventario, copia y riesgo

Reúne los datos técnicos y crea una vuelta atrás comprobada. Una copia de seguridad sirve solo si puede restaurarse y si contiene tanto los archivos como la base de datos.

Anota versiones y ajustes críticos

En WordPress, abre Escritorio > Actualizaciones y apunta las versiones de WordPress, WooCommerce, PHP, tema activo y plugins de cobro. En WooCommerce > Estado, guarda una captura de la pestaña Estado y otra de Registros.

Comprueba que la copia restaura

Genera una copia de archivos y otra de base de datos desde el hosting o desde tu sistema de backups. Deben incluir la carpeta wp-content, la base de datos completa, los ajustes de WooCommerce y los registros recientes de pago.

Clasifica el riesgo del cobro

Usa esta tabla para decidir qué medios requieren una prueba reforzada. El riesgo aumenta cuando existe redirección bancaria, firma criptográfica o webhook, que es el aviso automático que envía el proveedor a WooCommerce tras cobrar.

Aísla un staging sin cobros reales

Crea una copia de pruebas que no pueda cobrar ni enviar correos a clientes. El staging es una versión privada de la tienda donde puedes romper algo sin que se rompa la venta real.

Separa claves y direcciones

En el panel de Redsys, Stripe, PayPal o tu banco, activa el entorno de pruebas cuando exista y coloca sus credenciales en staging. Las claves sandbox permiten simular operaciones, pero no mueven dinero real.

Bloquea correos y acceso público

Configura el envío de emails de staging hacia un buzón interno, por ejemplo [email protected]. A continuación, crea un pedido de prueba y confirma que ni el cliente original ni una dirección externa reciben mensajes.

Replica lo que afecta al pago

Iguala en staging la versión de PHP, WordPress, WooCommerce, tema y extensiones activas. Replica también reglas de firewall, CDN y caché, porque un bloqueo de seguridad puede impedir la llamada del webhook aunque el plugin esté bien configurado.

Actualiza por capas y prueba compras

Actualiza un componente, prueba y registra el resultado antes del siguiente. Este método identifica el origen de un fallo en minutos y no en días.

Sigue una secuencia trazable

Primero actualiza en staging los plugins no relacionados con cobros. Después actualiza el plugin de la pasarela, prueba, actualiza WooCommerce, prueba otra vez y deja WordPress o PHP para una fase separada.

Haz una compra de extremo a extremo

Crea un producto oculto de prueba con un importe entre 0,50 y 2 euros, si el proveedor permite importes bajos. Haz una compra como invitado y otra con un usuario registrado, porque algunos plugins tratan de forma distinta los pedidos de cada tipo.

Después revisa, en este orden:

• La redirección vuelve a la página de gracias sin error.
• El proveedor marca la operación como autorizada o capturada.
• WooCommerce crea un pedido con número y cliente correctos.
• El webhook cambia el pedido a procesando o completado.
• El email transaccional llega al buzón de prueba.
• El cobro aparece en el panel del proveedor con la misma referencia.

Prueba también el camino malo

Simula un pago rechazado y una cancelación durante la redirección. El cliente debe ver un mensaje claro, el pedido no debe quedar como pagado y el sistema no debe enviar un email de compra confirmada.

Antes de pasar del staging de WordPress a producción, repite una comprobación breve de la configuración real antes de abrir el cambio al tráfico habitual. Verifica que cada pasarela usa las credenciales de producción y no las credenciales sandbox, que la URL de retorno bancario y la URL del webhook de pago apuntan al dominio correcto, y que el secreto o la firma configurados coinciden con los datos del proveedor. Conserva una copia de seguridad WordPress previa al despliegue y anota qué claves estaban activas, sin copiarlas en documentos compartidos.

Después de una compra real autorizada, confirma que no queda ningún pedido pendiente de pago y realiza, cuando la política del proveedor lo permita, un reembolso en WooCommerce para validar también el flujo posterior al cobro.

Valida webhooks, pedidos y conciliación

Confirma que el proveedor notifica el cobro y que WooCommerce lo refleja bien. Un webhook es un aviso automático entre sistemas cuando el banco confirma el pago.

Revisa firmas y eventos recibidos

Abre el panel de la pasarela y busca los eventos recientes de webhook o notificaciones. Comprueba que la URL configurada coincide exactamente con la de producción y que la respuesta recibida es correcta, normalmente un código HTTP 200.

Cuadra estados y dinero

Compara el pedido de WooCommerce con la operación en el proveedor. Busca tres casos: cobro aprobado sin pedido, pedido pagado sin cobro y pedido duplicado.

Conserva registros con límites

Guarda los logs de error, referencias de transacción y hora de los cambios durante el plazo interno que haya definido tu negocio. Restringe el acceso a esos registros, porque pueden incluir IP, correo, nombre o identificadores vinculados a una compra.

Los registros de pago deben servir para investigar incidencias sin convertirse en un repositorio innecesario de datos personales. Guarda únicamente la información necesaria para conciliar y atender devoluciones o reclamaciones, como identificador de pedido, referencia de transacción, importe, estado, fecha y mensajes técnicos depurados. Evita almacenar números completos de tarjeta, códigos de seguridad, secretos API o contenido sensible de las notificaciones. Limita el acceso a administradores autorizados, protege las copias y define un plazo de conservación conforme a las obligaciones fiscales, contractuales y de privacidad aplicables a tu país y proveedor.

Si necesitas compartir un caso con Redsys TPV virtual, el banco o una pasarela, envía referencias y logs redactados, no capturas que expongan datos innecesarios del cliente.

Contén el fallo sin perder ventas

Pausa solo el medio afectado y mantén disponible una forma alternativa de pago. El objetivo es seguir vendiendo mientras se identifica el fallo.

Activa una alternativa ya probada

Desactiva la pasarela que falla desde WooCommerce > Ajustes > Pagos y deja visibles Stripe, PayPal, transferencia o contra reembolso, si ya estaban configurados y probados. No actives una nueva pasarela durante la crisis si nunca se ha validado.

Decide si debes revertir

Revierte solo el componente que cambió justo antes del fallo y que puedes relacionar con los registros. Si el pago funcionaba antes de actualizar la pasarela y deja de funcionar después, vuelve a la versión previa de ese plugin primero.

Vigila las primeras horas

Revisa cada 30 minutos los pedidos pendientes, fallidos y cancelados durante las primeras 2 horas. Después compara al final del día el total cobrado por el proveedor con el total de pedidos pagados en WooCommerce.

La vigilancia no debería depender solo de una revisión manual cada 30 minutos. Configura alertas sobre los registros de WooCommerce, el panel de la pasarela y el sistema de monitorización del sitio para detectar respuestas HTTP fallidas en webhooks, un aumento anómalo de pagos rechazados, pedidos que permanecen pendientes más tiempo del habitual o diferencias entre importes cobrados y pedidos pagados. Define un umbral adaptado a tu volumen: por ejemplo, investigar de inmediato tres errores consecutivos de webhook o una tasa de rechazo que duplique la media de la última semana.

Si se supera el umbral, activa la contingencia de métodos de pago: pausa la opción afectada, conserva alternativas ya validadas y registra la hora y las referencias de las operaciones impactadas.

Lo que más preguntan

Las dudas siguientes ayudan a decidir sin convertir una actualización en una apuesta.

¿Puedo actualizar WooCommerce automáticamente?

No conviene actualizar WooCommerce automáticamente si la tienda usa tarjeta, Bizum, Redsys, Stripe o PayPal. Hazlo manualmente tras probar en staging, porque puede cambiar el checkout, los pedidos o la compatibilidad con extensiones.

¿Cómo sé si redsys funciona tras actualizar?

Redsys funciona tras actualizar cuando el banco autoriza, WooCommerce cambia el pedido y la operación aparece en el panel del banco. Comprueba también la notificación firmada y prueba una cancelación antes de cerrar el cambio.

¿Debo probar bizum después de actualizar?

Sí, prueba Bizum después de cualquier cambio en WooCommerce, la pasarela o PHP. Haz una operación desde móvil y confirma retorno, pedido, email y registro de cobro.

¿Qué hago si hay un cobro sin pedido?

Localiza la referencia en el proveedor, guarda los logs y busca el webhook asociado antes de reembolsar. Si no puedes crear el pedido manualmente con datos fiables, pausa la pasarela y abre incidencia con el banco o proveedor.

¿Qué actualizaciones puedo automatizar?

Puedes automatizar parches menores ya validados y actualizaciones de seguridad con alertas activas. Mantén manuales los cambios de WooCommerce, PHP, APIs de pago, plugins de checkout y extensiones de suscripción.

Cierra el cambio con control

Documenta el resultado y deja preparada la siguiente actualización. Anota fecha, versiones anteriores y nuevas, pruebas hechas, referencias de pago y cualquier ajuste de configuración.

No cierres la incidencia hasta que haya pasado una jornada de ventas normal sin cobros huérfanos, pedidos pendientes anómalos ni errores de webhook.

• El error legal de actualizar plugins de pago a ciegas
• Borrar plugins inactivos puede borrar ajustes clave

Josu Barrios

Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online. Contamos con experiencia en seguridad web, optimización de rendimiento, actualizaciones, copias de seguridad y resolución de incidencias técnicas, ayudando a que cada sitio funcione de forma rápida, estable y protegida. Nuestro enfoque combina soporte técnico profesional, buenas prácticas de seguridad y seguimiento continuo para ofrecer un servicio fiable, transparente y orientado a resultados reales.