Después de reconstruir una tienda hackeada deben coincidir la verificación de seguridad y la de negocio. Puede desaparecer la redirección conocida y, aun así, calcularse mal un impuesto, duplicarse un webhook o mostrarse la cuenta de otro cliente.
Usa identidades sintéticas, pagos sandbox y una matriz escrita de aprobado o fallido.
Prepara datos de prueba aislados
Crea un cliente, productos, cupón y correos dedicados. Etiqueta cada pedido e impide que ventas, preparación o contabilidad lo procesen.
No uses tarjetas reales ni teléfonos o emails ajenos. Configura claves de pruebas y desactiva cualquier captura real. Anota totales y rutas esperados.
Prueba el aislamiento del carrito
Añade, actualiza y elimina productos simples y variables como invitado y cliente. Comprueba que sesiones, cookies y caché no muestren el carrito de una persona a otra.
Prueba móvil, idiomas, monedas y navegación atrás. Inspecciona consola y red buscando scripts o dominios desconocidos. Confirma existencias y límites.
Revisa catálogo y productos
Contrasta precios, variaciones, ofertas programadas, clases fiscales, stock, descargas y límites de compra con los registros del negocio. Busca productos o cupones creados durante el incidente.
Una plantilla limpia no convierte los datos del catálogo en fiables. Registra y aprueba cada corrección manual.
Prueba los cálculos del checkout
Verifica validación de facturación y envío, impuestos, transportistas, cupones, recargos, redondeo de moneda y consentimiento. Compara el total del navegador con pedido y proveedor.
Prueba notas y cargas permitidas con contenido sintético. Un error no debe crear prematuramente pedido o pago. Comprueba caché, WAF y CAPTCHA.
Prueba los resultados de pago
Utiliza casos sandbox de éxito, rechazo, cancelación, desafío de autenticación y timeout con reintento. Confirma dominios oficiales y ausencia de código desconocido.
Debe existir una sola transacción por pedido intencionado, con estado y notas correctos y sin efectos duplicados tras refrescar o repetir el webhook. Prueba reembolsos por el flujo aprobado.
Prueba webhooks y colas
Comprueba firma, TLS, reintentos e idempotencia. Revisa Action Scheduler y WP-Cron buscando tareas fallidas o demoradas.
Entrega eventos duplicados y desordenados en sandbox y confirma que el estado final siga la lógica del proveedor sin duplicar stock ni email. Prueba aparte suscripciones y reservas.
Ensaya fallos y recuperación
Simula rechazo de validación, pago fallido, webhook retrasado, recarga del navegador y reintento de red. El cliente debe ver un estado veraz y poder continuar sin doble pedido o cargo.
Comprueba que soporte localiza la transacción mediante referencias autorizadas si WooCommerce y proveedor difieren.
Prueba la gestión de pedidos
Verifica visibilidad, búsquedas, filtros, cambios de estado, reducción y restitución de stock, facturas, transporte, ERP y reembolsos. Confirma que los pedidos recuperados siguen intactos.
No ejecutes en bloque acciones antiguas. Registra cada ID sintético para limpiarlo y conecta contabilidad o preparación únicamente con canales de prueba.
Prueba las cuentas de cliente
Comprueba registro, entrada y salida, restablecimiento, MFA si corresponde, historial, direcciones, descargas y procesos de eliminación o exportación.
Un usuario de prueba no debe acceder al pedido o descarga de otro. Revisa roles, contraseñas de aplicación y sesiones. Excluye tokens de seguridad de Analytics y logs.
Prueba correo transaccional y analítica
Verifica mensajes a clientes y equipo, Reply-To, aceptación del proveedor y llegada al buzón. Asegura que no queden colas de spam ni destinatarios desconocidos.
Analytics debe registrar una compra una sola vez, después de la confirmación del servidor o pago, respetando consentimiento y sin datos personales ni campos del pedido. Filtra las conversiones de QA.
Asigna responsables operativos
Nombra propietarios de alertas de pago, tareas fallidas, diferencias de pedidos, cambios de archivos e informes de clientes. Define umbrales y un canal independiente de escalado.
Documenta cuándo se retirarán usuarios sandbox, pedidos, excepciones y accesos temporales. Monitorizar sin una persona responsable no es un control de aceptación.
Repite los indicadores del incidente
Reproduce las condiciones originales de referrer, móvil o primera visita, ciclos cron y calentamiento de caché. Comprueba la lista autorizada de scripts del checkout y monitoriza cambios durante las pruebas.
Confirma que no quedan administradores, DNS, CDN, Tag Manager, pagos o secretos desconocidos y que las copias restauran correctamente. Solicita revisión independiente cuando hubo manipulación del pago. Comparte matriz e IDs censurados, nunca tarjetas, secretos, clientes ni malware públicamente.