Una actualización de Stripe, PayPal, Redsys o un plugin de facturación puede afectar cobros, permisos y datos: aplicarla sin pruebas ni copias en producción expone a ventas perdidas, reclamaciones e incidencias de protección de datos.
Índice
Anuncio
Actualizar pagos exige pruebas documentadas
Una actualización que afecta cobros o datos personales requiere una copia restaurable, control de versiones, pruebas y una decisión de publicar o revertir; ante una brecha, el RGPD prevé hasta 72 horas para notificar cuando proceda.
Prueba no equivale a diligencia
La evidencia debe incluir fecha, responsable, versión previa y nueva, método probado y resultado. Defina un plazo de conservación en su política interna según la finalidad, el principio de minimización, las obligaciones fiscales, los contratos y los plazos de reclamación aplicables.
Cuándo demorar también es riesgo
Demorar también eleva el riesgo si hay una vulnerabilidad explotada, PHP sin soporte o una API próxima a dejar de aceptarse.
Pruebe el cobro completo antes de publicar
Antes de pasar a producción, valide por pasarela un pago aprobado, uno rechazado, un reembolso y un webhook: el aviso automático que confirma a WooCommerce cada operación.
| Situación | Pruebas mínimas | Evidencia a guardar | Decisión |
|---|---|---|---|
| Parche menor de pasarela | 4 operaciones por método | Capturas, IDs y registros | Publicar si los 4 casos coinciden |
| Cambio mayor de WooCommerce | Pago, rechazo, reembolso y correo | Versiones y pedido de prueba | Revertir si cambia el estado |
| Cambio de PHP o API | Webhook y conciliación adicionales | Log técnico y saldo comprobado | Publicar solo con compatibilidad confirmada |
| Suscripciones activas | Alta, renovación, fallo y baja | Eventos y correos enviados | Revertir ante cargos duplicados |
El webhook falla sin romper el checkout
Un webhook puede fallar aunque el checkout funcione: revise URL, secreto de firma, reintentos y registros. Antes de revertir, confirme en la pasarela si el pago está pendiente, autorizado, capturado o reembolsado; la reversión del código no cancela por sí sola una operación ya procesada.
Las suscripciones exigen cuatro pruebas
Para suscripciones, pruebe alta, renovación, rechazo por tarjeta caducada y cancelación o reembolso; compruebe también PHP, WooCommerce y la extensión.
Cuando aparezcan cobros fallidos, cargos duplicados o pagos autorizados sin pedido tras una actualización, no conviene resolverlos únicamente creando pedidos manuales. Suspenda nuevos despliegues, identifique el alcance por fecha, método de pago e identificador de transacción y concilie los datos de WooCommerce con el panel de la pasarela y la cuenta bancaria. Determine si el pago está autorizado, capturado, reembolsado o pendiente antes de actuar. Si hay clientes afectados, informe de forma clara del estado y del plazo previsto, evitando solicitar por correo datos de tarjeta.
Mantenga una lista de incidencias, decisiones y reembolsos para poder justificar la trazabilidad del caso ante una reclamación, una devolución bancaria o una consulta contable.
RGPD y PCI tras cambiar el flujo de datos
Un cambio de pasarela exige revisar RGPD y PCI DSS si modifica responsables, alojamiento o registros; PSD2 y el Real Decreto-ley 19/2018 importan si cambia SCA o 3D Secure 2.
PCI no elimina la responsabilidad propia
Cuando la pasarela captura los datos de tarjeta en su propio entorno, puede reducir el alcance PCI DSS de la PYME, pero no elimina su responsabilidad sobre la configuración, los accesos, la seguridad de WordPress ni el cuestionario de autoevaluación que resulte aplicable. La PYME no debe guardar números completos de tarjeta, CVV ni claves API.
Una llave de seguridad USB añade una segunda prueba física para entrar en cuentas críticas de WordPress, correo y pasarelas. Resulta útil cuando varias personas gestionan cobros o claves API.
- Reduce el riesgo de acceso con contraseñas robadas a cuentas administradoras.
- Permite separar el acceso personal de los accesos compartidos que nunca deberían existir.
- Ayuda a revocar el acceso de un proveedor saliente sin cambiar el proceso de cobro.
PSD2 cambia el flujo de autenticación
Pruebe una tarjeta que complete 3D Secure 2 y otra en la que se rechace; revise el tratamiento de datos, los contratos y la privacidad si entra un proveedor.
Si la actualización introduce un nuevo proveedor, cambia el alojamiento de registros o permite que un tercero acceda a pedidos y datos de clientes, la PYME debe identificar qué datos se transfieren, con qué finalidad y quién actúa como responsable o encargado del tratamiento. El contrato de encargo debe reflejar instrucciones, medidas de seguridad, subencargados y, si existen, transferencias internacionales. Ante una incidencia de seguridad, documente desde cuándo se conoce, qué datos y personas podrían estar afectados, las medidas de contención y la valoración del riesgo; el responsable debe notificar a la autoridad de control sin dilación indebida y, cuando proceda, dentro de las 72 horas desde que tuvo conocimiento de la brecha.
En PCI DSS, use el cuestionario de autoevaluación aplicable a su integración y confirme que ningún registro de WordPress conserva datos sensibles de autenticación.
Lo que más preguntan
¿Debo actualizar ya un plugin de pago vulnerable?
Sí, si existe un parche para una vulnerabilidad confirmada, priorice la actualización tras crear una copia restaurable y probarla fuera de producción. Si no hay parche compatible, limite accesos, desactive la función afectada y documente la medida temporal.
¿Quién responde por PCI DSS en WooCommerce?
La pasarela cubre gran parte de PCI DSS si captura la tarjeta en su propio entorno. La PYME sigue siendo responsable de no guardar tarjeta, CVV o claves API expuestas dentro de WordPress.
¿Debo cambiar la privacidad tras actualizar?
Debe revisarla si cambian proveedor, cookies, ubicación de datos o personas con acceso. Revise también el contrato de encargo y el registro de actividades exigido por el RGPD.
¿Qué hago si hay pagos sin pedido?
Pare nuevos cambios, compare el identificador de transacción con los pedidos y revise el webhook de inmediato. Conserve hora, importe, ID de pago y registro técnico antes de reembolsar o crear pedidos manuales.
¿Cuánto tiempo debo guardar las pruebas?
Guarde los registros internos entre 12 y 24 meses como criterio práctico de trazabilidad. El plazo concreto puede variar por obligaciones fiscales, contratos y el tipo de incidencia.
¿Puedo actualizar directamente en la web pública?
Puede hacerlo solo en cambios muy acotados y tras una copia restaurable, pero no es la opción segura para componentes de pago. Un entorno de pruebas reduce el daño si fallan webhooks, suscripciones o facturas.
- Actualizar con pruebas reduce más riesgo que mantener un plugin vulnerable por miedo.
- Un checkout visible no prueba que el dinero, el pedido y el webhook estén coordinados.
- RGPD y PCI DSS exigen revisar el flujo real de datos, no solo el proveedor de pago.
- La copia restaurable y el registro de evidencias permiten acreditar una respuesta diligente.
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.