# Checkout clonado: tarjetas desviadas desde una tienda WooCommerce

> Una tienda WooCommerce con una copia de la pantalla de Redsys que desviaba las tarjetas. Cómo lo detecté optimizando el checkout y cómo lo limpié.

URL: https://gregoresone.es/casos-reales/checkout-clonado/
Actualizado: 2026-10-06

---

Seguridad · Tienda online

# Un pago idéntico al de Redsys. *Las tarjetas acababan en otro sitio.*

Una tienda WooCommerce llegó para una optimización. Al revisar el checkout encontré una copia de la pasarela que se quedaba con las tarjetas antes de mandar al comprador al banco. **Lo encontré porque reviso lo que nadie mira.**

Cliente:
:   Tienda online

Plataforma:
:   WooCommerce + Redsys

Trabajo:
:   Optimización y seguridad

Amenaza:
:   Formjacking

## Una tienda bonita. *Un encargo de rutina.*

La web la había hecho un freelance contratado en una plataforma externa: WordPress, WooCommerce y Redsys para cobrar. Visualmente, el trabajo era bueno.

El encargo era la optimización completa que hago a cada web que entra. Paso a paso y sin saltarme ninguno, **tampoco el que casi todo el mundo se salta.**

La optimización, paso a paso

- **Correo**Los correos de pedido salen y llegan, sin acabar en spam:
  *Revisado*
- **Seguridad**Versiones, usuarios, permisos y rastro de hackeos:
  *Revisado*
- **Imágenes**Formatos modernos y al tamaño que se muestran:
  *Optimizado*
- **WPO**Caché, CSS y JavaScript, Core Web Vitals:
  *Optimizado*
- **Checkout**Campos, pasos y paso a la pasarela de pago:
  *Aquí estaba*

## El checkout, *el gran olvidado.*

Mucha gente se obsesiona con un SEO perfecto y una web que vuele. Y luego el checkout es un desastre.

El de WooCommerce de serie ha mejorado bastante con los bloques, pero un checkout mal planteado sigue siendo **uno de los puntos por donde más ventas se pierden.** Es la página que más dinero mueve, y casi ningún freelance la toca.

Yo sí. Y esta vez, al abrirlo, **había ficheros que no pintaban nada ahí.**

## Lo que encontré *dentro del checkout.*

Código que imitaba la pantalla de pago de Redsys, servido desde la propia tienda. Tiene nombre: **skimming** o **formjacking**.

El pago se completaba en Redsys como siempre. Por eso **ni el comprador ni la tienda notaban nada.**

1. ### El comprador pulsa «Pagar»

   En lugar de ir a Redsys, ve **una copia exacta** de su pantalla, con el logo y los colores del banco.

   Mismo diseño · Servida desde el dominio de la tienda
2. ### Escribe su tarjeta

   Número, caducidad y CVV. Los teclea en la copia, **no en el banco.**
3. ### La tarjeta sale de la tienda

   El código la envía en segundo plano a **una base de datos externa.** El comprador no ve nada.

   Petición POST en segundo plano a un servidor externo
4. ### Y después, al banco de verdad

   Monta el formulario legítimo y lleva al comprador a Redsys. El pago entra, el pedido también. **Todo parece normal.**

   POST firmado a Redsys: Ds\_SignatureVersion, Ds\_MerchantParameters y Ds\_Signature (HMAC SHA-256)

## Qué hice. *Por este orden.*

- ### Cortar el robo

  Lo primero, que no saliera **ni una tarjeta más.** Fuera los ficheros y el código que montaban la pantalla falsa.
- ### Revisar la instalación entera

  Si alguien deja una trampa, puede dejar dos. Repasé el núcleo, los plugins, el tema, las subidas y la base de datos, **fichero a fichero.**
- ### Ni una puerta trasera

  Busqué **backdoors**: usuarios ocultos, tareas programadas y código que permitiera volver a entrar cuando quisieran.
- ### Un checkout bien hecho

  Pasarela oficial de Redsys: **la tarjeta solo se escribe en la web del banco.** Y un checkout optimizado, que era el encargo.

## Lo que enseña *un caso así.*

- Una web bonita no es una web segura. **Lo que no se ve también hay que revisarlo.**
- El checkout es la página que más dinero mueve. **Merece la misma atención que la portada.**
- Si no sabes quién ha tocado tu web, **revisa qué ha dejado dentro.**