Asegura tus ventas al actualizar pasarelas en WooCommerce

Actualizado en July 2026

¿Puede una actualización de pasarela dejar la tienda sin cobrar justo en la campaña clave? Las migraciones mal probadas generan interrupciones, reclamaciones y sanciones contractuales con el adquirente; el responsable técnico necesita garantías operativas, trazabilidad de cambios y un plan que preserve ventas y cumplimiento PCI‑DSS.

Actualizar pasarelas de pago en WooCommerce:

• ¿pruebas obligatorias? No hay una ley española que obligue genéricamente a ejecutar pruebas en WooCommerce, pero sí puede ser requisito contractual del adquirente y una exigencia de seguridad (PCI‑DSS) y negocio. Probar en sandbox, verificar webhooks y flujos de pedido y preparar rollback minimiza riesgos
• habilitar el registro de errores y los logs mediante la configuración adecuada (editar wp-config.php para definir WP_DEBUG y WP_DEBUG_LOG o configurar el logger del servidor) y usar WP‑CLI para exportar y consultar logs, gestionar plugins y ejecutar scripts de rollback
• aplicar la matriz por pasarela y dejar plantillas de comunicación reduce el impacto operativo

¿Son obligatorias las pruebas al actualizar pasarelas?

No hay una norma general en España que exija probar cambios en producción para una tienda WooCommerce. Los requisitos cambian según el contrato con el adquirente (Redsys, BBVA, Banco Santander y otros) y las obligaciones de seguridad como PCI‑DSS y PSD2.

Si el contrato del adquirente pide homologación, la tienda debe presentar pruebas en sandbox y una conformidad escrita. PCI‑DSS exige controles de integridad y registro de cambios que implican evidencias de test.

Probar solo en producción sin documentación puede suponer sanciones contractuales o suspensión del TPV por parte del banco. La evidencia técnica es la base para cualquier reclamación posterior.

¿Qué exige normalmente un adquirente?

Los adquirentes suelen pedir: acceso a un entorno de pruebas, ejecución de casos estándar, pantallazos y logs, y una firma de conformidad técnica. El plazo típico para la homologación varía entre 2 y 10 días hábiles.

El error más frecuente en este punto es actualizar directamente en producción sin homologación ni evidencias. Eso provoca interrupciones que el adquirente puede interpretar como incumplimiento contractual.

PCI‑DSS y PSD2

PCI‑DSS pide registros de acceso, control de cambios y conservación de logs; por tanto, las pruebas deben dejar trazas. PSD2 y SCA, vigentes desde su aplicación, exigen validar métodos de autenticación 3DS2 en flujos que cambian la experiencia de pago.

La referencia oficial para controles técnicos está en el PCI Security Standards Council: PCI SSC.

Probar en staging o en producción: qué hacer primero

Probar primero en un entorno staging que reproduzca la producción evita la mayoría de fallos. Las pruebas deben cubrir tanto el pago inicial como webhooks, reembolsos y cobros recurrentes.

Si el adquirente exige pruebas en su sandbox, hay que usar ese entorno para homologación. En tiendas con suscripciones conviene simular cobros periódicos antes de tocar producción.

Un caso habitual: actualizar un plugin de pasarela en producción porque "solo son cambios menores" y perder todas las suscripciones activas por incompatibilidad de tokenización.

Entorno staging: requisitos mínimos

El staging debe usar la misma versión de PHP, WooCommerce y plugins críticos, y el mismo esquema de base de datos. El certificado SSL puede ser distinto, pero las URLs deben mapear las rutas de webhooks.

Comprobar que los endpoints de webhook en staging responden con los mismos códigos HTTP que en producción evita errores de conciliación.

Cuándo probar en producción

Probar en producción solo si el adquirente lo autoriza por escrito y si no afectará a usuarios reales (por ejemplo, simulando transacciones con tarjetas de prueba en modo sandbox del proveedor). Nunca usar tarjetas reales de clientes para test.

Si el proveedor gestiona todo off‑site (por ejemplo, pasarelas que redirigen fuera del sitio), las pruebas pueden depender del proveedor. En ese caso verificar sus logs y certificados es suficiente.

Un procedimiento paso a paso acelera la homologación y evita ambigüedades:

1. Preparar staging con claves sandbox del proveedor y, si es necesario, exponerlo temporalmente con ngrok para que la pasarela envíe webhooks a una URL pública
2. Ejecutar un pago de prueba con la tarjeta de prueba del proveedor y anotar el transaction_id
3. Comprobar el estado del pedido en WooCommerce (ej.: wp post list --post_type=shop_order --format=ids y wp post meta get _transaction_id) y revisar wp-content/debug.log con tail -n 200
4. Simular el webhook desde el proveedor o con curl: curl -i -X POST https://mi-staging/endpoint -H 'Content-Type: application/json' -H 'X-Signature: ' -d '@payload.json'
5. Verificar la firma HMAC localmente: echo -n "$(cat payload.json)" | openssl dgst -sha256 -hmac "$SECRET" para comparar con la cabecera recibida
6. Probar casos de fallo (timeout, 500 interno) y comprobación de reintentos
7. Validar reembolsos y chargebacks en sandbox
8. Exportar logs y pantallazos con timestamps y subirlos al repositorio de evidencias. Con estos pasos se puede demostrar de forma técnica que los flujos, webhooks y la tokenización funcionan antes de solicitar homologación o desplegar a producción

Checklist técnico: backup, logs y rollback con WP‑CLI

Completar una checklist técnica antes de actualizar reduce la probabilidad de fallo y acelera la reversión si algo va mal. La lista mínima debe ser explícita y comprobable; por ejemplo, 12 pasos típicos y verificables antes de un deploy a producción son:

1. Snapshot del servidor/VM
2. Export completo de la base de datos
3. Backup de wp-content y uploads
4. Bloquear jobs/colas y planificar cron
5. Activar modo mantenimiento o deshabilitar checkout
6. Habilitar logs y rotación (WP_DEBUG/servidor)
7. Desplegar en staging y ejecutar la matriz E2E
8. Validar webhooks y tokenización en sandbox
9. Exportar evidencias (pantallazos, IDs, logs)
10. Obtener conformidad escrita del adquirente si procede
11. Ejecutar deploy a producción con scripts de rollback listos
12. Monitorizar 72 horas y emitir informe post‑despliegue

Crear backups completos y preparar comandos de rollback permite restaurar en minutos. También conviene registrar un snapshot del servidor y de la base de datos.

Tener logs habilitados (WordPress, PHP, pasarela) antes del cambio permite demostrar qué ocurrió durante la actualización.

Backups y comandos WP‑CLI

Crear un export de base de datos:

bash wp db export backup_pre_tpv_20250609.sql

Crear copia de wp-content:

bash tar -czf wp-content_backup_20250609.tar.gz wp-content

Restaurar base de datos si hay que revertir:

bash wp db import backup_pre_tpv_20250609.sql wp cache flush

Habilitar logs y depuración

Activar registro de errores en WordPress:

php define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false);

Habilitar logs de pasarela en sandbox y configurar rotación con retención mínima de 30 días. Registrar los webhooks y exportar el primer archivo de logs antes del cambio.

Plan de rollback y validación

Preparar pasos claros: bloqueo de pedidos, restauración de BD, restauración de wp-content, desincronización de colas. Validar rollback en staging antes de usarlo en producción.

Un criterio de aceptación: tras rollback el checkout vuelve al estado anterior y las transacciones procesadas en ventana se reconcilian sin discrepancias.

Matriz de pruebas por pasarela: redsys, stripe, PayPal, TPV

Una matriz con criterios concretos ayuda a decidir qué probar para cada pasarela. Las columnas deben ser medibles y los valores claros (Sí/No/Plazo).

La tabla siguiente permite comparar requisitos: disponibilidad de sandbox, soporte 3DS2, webhooks de prueba, tokenización, datos de prueba públicos, tiempo típico de homologación, y necesidad de conformidad firmada.

Casos de prueba críticos por pasarela

Redsys: pago con SCA correcto, rechazo SCA, reembolso, conciliación sin webhook. Stripe: pago tokenizado, fallo en webhook, chargeback. PayPal: captura retrasada, reembolso parcial. Para cada caso anotar datos de prueba, resultado esperado y criterio de aceptación.

Datos de prueba y resultados esperados

Usar números de tarjeta de prueba oficiales del proveedor. Criterio de aceptación: el pedido cambia de pendiente a processing/completed y el webhook queda registrado en logs con código 200.

Para que la matriz de pruebas sea práctica, conviene documentar por cada pasarela un conjunto mínimo de casos con datos de prueba y el resultado esperado. Ejemplo resumido:

1. Pago exitoso (Stripe: tarjeta 4242 4242 4242) → pedido pasa a processing/completed y webhook devuelve 200
2. SCA/3DS challenge (Stripe 4000 0027 6000 3184 para 3DS) → flujo de autenticación activo y pedido pasa a processing tras autenticación
3. Autorización denegada (números de fallo del proveedor) → pedido queda en failed/pending y no se crea transacción
4. Reembolso total y parcial → reembolso registrado en pasarela y nota en pedido
5. Suscripción: cobro recurrente tokenizado → primer cobro y cobros siguientes simulados exitosos
6. Webhook perdido o replay → webhook reintentado y reconciliación en orden. Para cada caso registre: payload usado, cabeceras (signature), ID de transacción esperado, estado final del pedido en WooCommerce y ubicación del log donde se guarda la evidencia. Esta estructura permite entregar a un adquirente pruebas reproducibles y a auditoría los artefactos necesarios (pantallazos, IDs, logs con marca temporal)

Automatizar pruebas E2E y scripts CI para pasarelas

Automatizar reduce fallos humanos y acelera homologación. Un pipeline mínimo despliega la rama a staging, ejecuta tests E2E y valida webhooks antes de aprobar el despliegue a producción.

Los tests deben interactuar con el sandbox de la pasarela y comprobar que el pedido pasa a estado correcto y que el webhook se registra con código 200.

Esto funciona bien en teoría, pero en la práctica hay que aislar credenciales y simular colas de mensajes para reproducir latencia real.

Ejemplo básico de test con cypress

Archivo test_checkout.spec.js (resumen):

javascript cy.visit('/checkout'); cy.fillBillingForm(); cy.choosePayment('stripe_sandbox'); cy.submitOrder(); cy.waitForWebhook('payment_intent.succeeded'); cy.getOrderStatus().should('contain','processing');

Pipeline sugerido

1. Deploy a staging
2. Ejecutar tests E2E
3. Validar logs de webhook
4. Notificar resultados por Slack o email

Si el pipeline falla, bloquear merge a producción hasta resolver el error.

Errores reales que rompen ventas y cómo evitarlos

Los errores más frecuentes son: actualizar en producción sin staging, probar solo pagos exitosos y olvidar validar webhooks y suscripciones. Estos fallos producen pérdida de ingresos y trabajo de conciliación contable.

Un caso concreto: una tienda actualizó el plugin de TPV y las tarjetas tokenizadas dejaron de enviarse al nuevo esquema. Resultado: 120 suscripciones fallidas en 48 horas y reclamaciones de clientes.

La mayoría de guías dicen que "probar el checkout basta". Lo que omiten la mayoría es que hay que probar reembolsos, chargebacks y conciliación bancaria.

Fallos en webhooks

Problema típico: URL de webhook antigua o firma HMAC incorrecta. Consecuencia: pedidos que quedan en estado pendiente sin actualizar.

Solución práctica: validar con curl y comparar la respuesta del endpoint. Ejemplo:

bash curl -i -X POST https://staging.tienda.es/wp-json/wc/v3/webhooks/test

Problemas con tokenización y suscripciones

Problema típico: el nuevo plugin cambia el identificador del token y rompe los cobros recurrentes. Resultado: suscripciones canceladas por fallos de pago.

Solución práctica: exportar tokens en staging, comprobar migración y simular cobros recurrentes antes de desplegar en producción.

Monitorización y métricas tras la actualización

Monitorizar las métricas clave durante 72 horas permite decidir si mantener el cambio o revertirlo. Las métricas deben tener umbrales claros para alertas automáticas.

Métricas mínimas: tasa de fallos de pago, webhooks fallidos por hora, tasa de conversión del checkout, tiempo medio de respuesta API, tickets de soporte y reembolsos.

Valores de alerta recomendados:

• fallos de pago por encima de 3% por 1 hora
• webhooks fallidos superiores a 5/h
• caída de conversión superior a 10% respecto a baseline

Herramientas y configuraciones

Usar Sentry para errores, New Relic o Datadog para rendimiento y un canal de alertas (Slack/email) con umbrales definidos. Registrar incidentes con hora, descripción y logs adjuntos.

Comunicación a clientes y adquirente

Avisar a clientes con un mensaje claro que incluya hora de inicio y fin previstos, canal de soporte y efectos esperados en compras. Informar al adquirente con resultados de pruebas en sandbox, logs y pantallazos si lo solicita.

Si prefiere, el responsable técnico puede encargar una revisión previa con un equipo externo que valide la matriz de pruebas y el rollback.

Preguntas frecuentes

¿Las pruebas en sandbox sustituyen las pruebas en producción?

No sustituyen la validación final en producción cuando el adquirente lo exige; sirven para verificar flujos y reducir riesgo. Sandbox detecta problemas lógicos y de integración, pero no reproduce latencia real ni comportamientos del banco.

¿Cuánto tarda la homologación con redsys o un TPV?

Tarda normalmente entre 2 y 10 días hábiles según la complejidad y la carga del banco. El trámite exige documentación de pruebas y, en muchos casos, firma de conformidad.

¿Es obligatorio guardar logs para PCI‑DSS?

Sí, PCI‑DSS exige conservar registros de acceso y cambios y demostrar controles de integridad. Guardar logs de la actualización facilita auditorías y defender reclamaciones.

¿Puedo usar tarjetas reales para probar en producción?

No usar tarjetas reales de clientes para testing. Para pruebas en producción solicitar autorización explícita del adquirente y emplear tarjetas de prueba o transacciones de importe reducido controladas.

¿Qué comandos WP‑CLI son críticos para rollback?

Comandos clave: exportar e importar BD con wp db export/import, activar modo mantenimiento y restaurar plugins o themes con wp plugin install/activate y wp theme install/activate. Mantener scripts preconfigurados reduce el tiempo de restauración.

¿Vale la pena automatizar pruebas de pasarela?

Sí, automatizar E2E con Cypress o Playwright y ejecutar en CI acelera homologación y reduce errores humanos. Automatizar conviene para tiendas con más de 100 pedidos diarios y suscripciones.

¿Qué métricas vigilar las primeras 72 horas?

Vigilar fallos de pago, webhooks fallidos, tasa de conversión del checkout, tiempo de respuesta API, tickets de soporte y reembolsos. Definir umbrales de alerta reduce el tiempo de detección.

El plan concreto

Resumen de acciones priorizadas para actualizar una pasarela sin romper ventas:

1. Preparar staging idéntico y acceso sandbox
2. Ejecutar la matriz de pruebas completa (pagos, webhooks, reembolsos, suscripciones)
3. Crear backups y scripts WP‑CLI para rollback
4. Automatizar E2E en CI
5. Desplegar con monitorización 72 h y umbrales claros

Frase de ejecución: realizar las pruebas en sandbox y obtener la homologación escrita del adquirente antes de desplegar en producción tiende a reducir el riesgo de interrupción y sanciones.

Si desea que el equipo técnico evalúe el plan y prepare la matriz de pruebas específica para su tienda, se puede solicitar una revisión técnica puntual antes de la actualización.

• Evita perder licencias o descargas en tiendas digitales
• Tu hosting no te hace PCI aunque cobres en tu web

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.