Los frameworks modernos de mitigación de bots (Cloudflare Turnstile, DataDome, Akamai Bot Manager, Shape Security) y los motores de detección de fraude empresarial (Sift, Riskified, Stripe Radar) han evolucionado su paradigma. Ya no dependen exclusivamente de listas negras estáticas de direcciones IP. En su lugar, analizan la continuidad del estado a lo largo de todo el ciclo de vida de la interacción del usuario.

Al extraer datos de Single Page Applications (SPAs) dinámicas o automatizar flujos de compra (checkouts) de múltiples pasos, la decisión entre rotar una IP o mantener la persistencia (stickiness) no es un detalle operativo secundario. Es una bifurcación de arquitectura crítica que determina si las transacciones se completan con éxito o si las sesiones son purgadas silenciosamente por los sistemas de seguridad.

       PIPELINE TÍPICO DE CHECKOUT MULTI-PASO Y RIESGOS DE INVALIDACIÓN DE ESTADO
       
+---------------+     +---------------+     +---------------+     +---------------+
| 1. Auth/Login | --> | 2. Añadir Cesta| --> | 3. Envío      | --> | 4. Stripe/3DS |
+---------------+     +---------------+     +---------------+     +---------------+
  Sesión TCP 1          Sesión TCP 2          Sesión TCP 3          Sesión TCP 4
  TLS: JA4 Client       TLS: JA4 Client       TLS: JA4 Client       TLS: JA4 Client
  IP: 185.24.xx.1       IP: 185.24.xx.1       IP: 92.40.xx.88       IP: 92.40.xx.88
                                                     ^
                                     [ CAÍDA DE NODO RESIDENCIAL ]
                                     - Cambio de IP: Discrepancia de ASN
                                     - Invalidación de TLS Session Ticket
                                     - PICO DE RISK SCORE -> 403 FORBIDDEN

1. Resumen Ejecutivo y el Problema de las Caídas de Sesión a Mitad del Flujo

En la ingeniería de automatización de redes existe una tensión fundamental entre el anonimato mediante rotación y la integridad del estado mediante persistencia:

  • Proxies Rotativos: Ideales para mitigar el bloqueo por límite de peticiones (rate-limiting) en endpoints sin estado (stateless) y de alto rendimiento (paginación de búsquedas, indexación de catálogos públicos, volcados masivos de datos).
  • **Sesiones Persistentes (Sticky Sessions):** Indispensables siempre que la capa de aplicación mantenga el estado entre múltiples peticiones HTTP mediante cookies, memoria caché en servidor (sesiones en Redis o Memcached), tickets de sesión TLS o tokens de seguridad criptográficos (concesiones OAuth2 bearer, tokens CSRF, PaymentIntents de Stripe).

El fallo de infraestructura ocurre cuando los ingenieros intentan ejecutar flujos transaccionales con estado a través de redes de proxies residenciales estándar. Estos proveedores suelen comercializar sesiones persistentes de "10 minutos" o "30 minutos". Sin embargo, en la práctica, estas redes enrutan el tráfico a través de nodos P2P domésticos sumamente inestables (smartphones con aplicaciones monetizadas mediante SDKs, televisores inteligentes o routers domésticos comprometidos).

En el momento en que el usuario residencial pierde la cobertura Wi-Fi, cierra su portátil o el sistema operativo activa el modo de ahorro de batería, el socket TCP se destruye. El balanceador backconnect del proveedor intercepta la conexión caída y, de forma transparente pero catastrófica, redirige la siguiente petición a través de una IP completamente distinta.

Para un motor antifraude, una mutación de IP entre un POST /cart/checkout y un POST /api/v1/payment_intents representa una señal unívoca de secuestro de sesión (session hijacking). Como resultado, la transacción se aborta, la reserva de inventario se libera y la huella digital (fingerprint) del navegador queda marcada permanentemente.

2. Anatomía de un Checkout Interrumpido: Telemetría y Detección de Fraude

Para comprender por qué una mutación de IP a mitad del flujo resulta letal en procesos autenticados, debemos analizar la telemetría de red que registra el servidor de destino a lo largo de un embudo de compra real.

===================================================================================
TRAZA DE UN CHECKOUT: MUTACIÓN DE TELEMETRÍA Y RESPUESTA WAF
===================================================================================
Paso 1: Autenticación (POST /api/auth/login)
  - IP del Cliente: 80.12.45.112 (Orange France, AS12479)
  - Cabeceras: Set-Cookie: __Secure-SessionId=a8f9b...; Domain=.target.com; Secure; HttpOnly
  - Huella TLS (JA4): t13d1516h2_8daaf6152771_b186095e22b6
  - Acción del Motor de Riesgo: Huella base registrada. Risk Score: 12/100 (Aprobado).

Paso 2: Reserva de Inventario (POST /checkout/reserve)
  - IP del Cliente: 80.12.45.112 (Consistente)
  - Cabeceras: Cookie: __Secure-SessionId=a8f9b...
  - Acción en Backend: Redis vincula SessionId -> Cesta: [SKU-89211], Lock TTL: 420s.

Paso 3: Envío de Dirección y Cálculo de Impuestos (POST /checkout/shipping)
  - [NODO RESIDENCIAL OFFLINE - ROTACIÓN FORZADA EN GATEWAY BACKCONNECT]
  - IP del Cliente: 176.159.201.44 (Free SAS, AS12322) [MUTADA]
  - GeoIP: Desplazamiento Lat/Long de 48.8566, 2.3522 (París) a 43.6047, 1.4442 (Toulouse)
  - Velocidad de Red: 680 km/h calculados en una ventana de 450 ms.
  - Acción del Motor de Riesgo: Alerta disparada: Anomalía de Geovelocidad. Risk Score: 68/100.

Paso 4: Tokenización de Pago (POST https://api.stripe.com/v1/tokens)
  - IP del Cliente: 176.159.201.44 (Free SAS)
  - Petición: Envío de datos de tarjeta + Stripe Radar Fingerprint.
  - Verificación: Stripe detecta discrepancia entre la IP de inicialización del comercio (Orange)
    y la IP de tokenización de la tarjeta (Free).
  - Intervención Antifraude: Riskified / Sift evalúa la divergencia de sesión:
    * Delta IP: TRUE
    * Delta ASN: TRUE (AS12479 -> AS12322)
    * Fallo en Reanudación TLS: El cliente envió un ClientHello sin Session Ticket válido.
  - Resultado: HTTP 402 Card Declined / HTTP 403 Forbidden. Cuenta en lista negra.
===================================================================================

Mecanismos de Detección Heurística Antifraude

Cuando la dirección IP muta a mitad de una transacción, los sistemas de seguridad ejecutan validaciones en tiempo real:

1. Vectores de Geovelocidad (Cálculo de Velocidad Imposible)

Si la Petición N se origina en París en el instante $T_1$, y la Petición N+1 proviene de Toulouse en el instante $T_2$, el sistema calcula la velocidad aparente de desplazamiento:

$$V = \frac{\text{FórmulaDeHaversine}(Loc_1, Loc_2)}{T_2 - T_1}$$

Si $V > 900\text{ km/h}$, el cortafuegos bloquea la sesión de inmediato al considerarla un relevo no autorizado de proxy o una sesión interceptada.

2. Invalidación de la Caché de Sesión TLS

Durante la fase de negociación, TLS 1.3 utiliza tickets de sesión (NewSessionTicket) para reanudaciones rápidas (0-RTT/1-RTT). Si el proxy rota el nodo emisor en segundo plano, el nuevo peer carece del estado criptográfico acordado previamente. El servidor de destino observa un handshake completo e inesperado desde una IP desconocida pero que transporta cookies emitidas para otra conexión. Esta divergencia incrementa de forma crítica la puntuación de amenaza en sistemas como DataDome y Akamai.

3. Vinculación IP Cliente-Pasarela de Pago

Pasarelas como Stripe Radar, Adyen y Braintree cotejan la IP que tokeniza los datos del método de pago con la IP que interactuó originalmente con el backend del comercio. Un cambio de Sistema Autónomo (ASN) durante este intervalo activa de forma automática un desafío 3D-Secure (3DS) estricto o el rechazo directo del cargo bajo sospecha de fraude.

3. Por Qué Fallan Inevitablemente los Proxies Residenciales "Sticky"

La gran mayoría de los proveedores comerciales venden "IPs Residenciales Persistentes" garantizando duraciones teóricas de 10, 30 o 60 minutos. Desde el punto de vista del diseño de redes, esta promesa es estructuralmente inviable sobre infraestructuras P2P.

       FRAGILIDAD ESTRUCTURAL DE LAS REDES RESIDENCIALES P2P
       
+------------------------+
| Script de Automatización|
+------------------------+
            |
            | (Petición HTTP estándar)
            v
+--------------------------------------------------------+
| Balanceador Backconnect del Proveedor                  |
| (Mantiene mapeo: ?session_id=worker_01)                |
+--------------------------------------------------------+
            |
            +-----------------------+
            |                       |
            v (Reenvío TCP)         v (Failover por desconexión)
+-----------------------+   +-----------------------+
| Nodo Residencial A    |   | Nodo Residencial B    |
| (Portátil doméstico   |   | (Smart TV en otra     |
| conectado vía SDK)    |   | ciudad y otro ISP)    |
+-----------------------+   +-----------------------+
      | (Cierre de tapa)          |
      X [SOCKET MUERTO]           v (Nueva IP no deseada)
                                 Plataforma de Destino / WAF

Las redes residenciales se nutren de acuerdos de monetización mediante SDKs integrados en aplicaciones móviles gratuitas, extensiones de navegador o software VPN comercial. Como consecuencia, el proveedor de proxies no posee, administra ni monitoriza el hardware físico que termina la conexión.

Puntos Críticos de Fallo en Nodos Residenciales

  • Renovación de DHCP y Conmutación Wi-Fi: Los terminales móviles alternan constantemente entre redes Wi-Fi y celdas 4G/5G en función de la cobertura. Cada renegociación de enlace destruye el socket TCP y fuerza la asignación de una nueva IP pública.
  • Gestión Energética del Sistema Operativo: Mecanismos como Android Doze o los límites de ejecución en segundo plano de iOS suspenden la conectividad de los SDKs tras 10 a 60 segundos con la pantalla bloqueada.
  • Interrupciones en el Dispositivo Anfitrión: Los usuarios domésticos apagan sus equipos, reinician sus routers o se desplazan fuera del alcance de la red local, liquidando las conexiones activas.
  • Reasignación Forzada del Gateway: El balanceador de carga del proveedor monitoriza los nodos mediante paquetes de sondeo ICMP/TCP. Si el Nodo A no responde a un pulso, el proxy reasigna automáticamente el session_id al Nodo B. El script de scraping no recibe un código de error de red: recibe una IP completamente diferente sin notificación previa.

Comparativa Técnica: Proxies Residenciales vs. Enlaces Móviles Dedicados

Métrica / Propiedad de RedGateway Residencial P2PGateway Celular Dedicado (Proxym)Impacto en Procesos de Compra
Terminación FísicaDispositivo doméstico (Móvil/PC/IoT)Módem Industrial 5G (Teltonika RUTX50)Alta tasa de fallo de hardware vs. 99,9% de disponibilidad
Control del EnlaceCompartido / P2P volátilTarjeta SIM Empresarial dedicadaCaídas involuntarias vs. Control absoluto del cliente
Persistencia Real MáximaDe 2 a 12 minutos (Impredecible)Ilimitada (Horas, Días o Semanas)Crítico: Flujos de compra largos completados con éxito
Mecanismo de RotaciónConmutación por fallo no controladaDeterminista mediante llamada a REST APICero mutaciones accidentales a mitad de transacción
Identidad de Red (ASN)ISP Residencial / Fibra ópticaOperador Móvil Tier-1 (Orange, SFR, Free)El CGNAT móvil ofrece máxima reputación antifraude
Modelo de FacturaciónPago por GB consumido (€8 - €15/GB)Tarifa Plana Mensual (€80/puerto, 200 GB)El alto consumo no degrada los costes operativos

4. La Garantía del Hardware Dedicado: Módems 5G Industriales

Para erradicar por completo las caídas intempestivas de sesión, es indispensable desacoplar la capa física de los dispositivos de consumo no gestionados. Esto exige una arquitectura sustentada en hardware de red industrial respaldado por líneas de conectividad móvil corporativas.

       ARQUITECTURA DE PROXY CELULAR 5G DEDICADO
       
 [ Worker de Automatización ] 
         |
         | Autenticación HTTP Connect / SOCKS5
         v
 +-----------------------------------------------------------------------+
 | INFRAESTRUCTURA PROXYM                                                |
 |                                                                       |
 |   +---------------------------------------------------------------+   |
 |   | Router Industrial Teltonika (RUTX50 / TRB500)                 |   |
 |   | - SIM Empresarial Dedicada (Orange / SFR / Bouygues / Free)   |   |
 |   | - Módem Celular Industrial Quectel 5G                         |   |
 |   | - Contexto PDP Activo y Persistente con la Operadora          |   |
 |   +---------------------------------------------------------------+   |
 |                                   |                                   |
 |                Hook de Control Determinista por Hardware              |
 |                 POST /api/proxies/{assignmentId}/rotate               |
 +-----------------------------------|-----------------------------------+
                                     |
                                     v (Túnel GTP-U / Portador 5G SA)
 +-----------------------------------------------------------------------+
 | NÚCLEO EPC/5GC DE LA OPERADORA MÓVIL (POOL CGNAT TIER-1)              |
 |                                                                       |
 |   IP Pública: 80.12.35.198 (Compartida con miles de terminales reales)|
 |   Clasificación en Motores de Riesgo: "Usuario Móvil Legítimo"       |
 +-----------------------------------------------------------------------+
                                     |
                                     v
                          [ Plataforma Web Destino ]

Capa Celular: Contexto PDP y Portadores de Datos

A diferencia de las conexiones de banda ancha residencial, sujetas a liberaciones periódicas de concesiones DHCP locales, un módem celular mantiene su enlace con el núcleo de red del operador (Evolved Packet Core / 5G Core) mediante túneles de datos permanentes:

  • Contexto PDP (Packet Data Protocol): Al inicializarse, el módem físico establece un Contexto PDP con el Gateway GPRS Support Node (GGSN) o la User Plane Function (UPF) del operador de telecomunicaciones.
  • Túnel GTP: El tráfico del cliente viaja encapsulado en un túnel GPRS Tunneling Protocol User Plane (GTP-U). La IP pública asignada por el Carrier-Grade NAT (CGNAT) permanece invariablemente anclada a ese canal de comunicación hasta que la interfaz se reinicializa deliberadamente mediante comandos AT de control (por ejemplo, secuencias AT+CFUN).

Proxym despliega hardware industrial Teltonika (series RUTX50 y TRB500) con tarjetas SIM dedicadas de los principales operadores franceses (Orange, SFR, Bouygues Telecom, Free Mobile).

Este diseño aporta dos pilares técnicos innegociables:

  1. **Persistencia Indefinida (Infinite Stickiness):** La IP no rota al cabo de 5, 10 o 30 minutos. La dirección se mantiene fija durante todo el tiempo que demande el proceso: minutos, horas o días continuados.
  2. Rotación Determinista: La renovación de IP se ejecuta exclusivamente cuando su infraestructura emite una llamada autenticada a la API REST (POST /api/proxies/{assignmentId}/rotate). En ese instante, el módem renegocia el enlace celular en la capa física, obteniendo una nueva IP pública móvil desde el pool CGNAT del operador en pocos segundos.

Demostración Matemática: Probabilidad de Supervivencia de la Sesión

Podemos modelar la fiabilidad de una sesión de automatización sin cortes involuntarios de IP a través de una función de supervivencia $R(t)$.

En una red de proxies residenciales convencionales, la desconexión sigue un proceso de Poisson no homogéneo, donde la probabilidad de fallo se incrementa exponencialmente con el tiempo $t$:

$$R_{\text{residencial}}(t) = e^{-\lambda t}$$

Donde $\lambda$ representa la tasa de fallo del nodo (inducida por pérdida de cobertura, suspensión de la aplicación o apagado del dispositivo). Mediciones empíricas en entornos de producción sitúan la vida media de un nodo residencial en $t_{1/2} \approx 420\text{ segundos}$ ($\lambda \approx 0.00165$).

Para un flujo de compra de 8 pasos que requiera 6 minutos (360 segundos), la probabilidad de que la sesión finalice con la misma IP es:

$$R_{\text{residencial}}(360) = e^{-0.00165 \times 360} = e^{-0.594} \approx 55.2\%$$

Esto implica que prácticamente la mitad de las transacciones automatizadas fallarán por interrupción de la persistencia de red.

Por el contrario, en un entorno celular industrial dedicado, la tasa de fallo operativo depende únicamente del tiempo medio entre fallos (MTBF) del hardware de telecomunicaciones, haciendo que el riesgo de caída fortuita sea virtualmente nulo durante la ventana de operación:

$$R_{\text{dedicado}}(t) \approx 0.9998 \quad \forall \; t \in [0, 86400\text{ segundos}]$$

5. Patrones Operativos: Cuándo Mantener la Persistencia vs. Cuándo Rotar

Una arquitectura robusta de web scraping y automatización de compras requiere una máquina de estados estricta. Rotar la IP indiscriminadamente provoca bloqueos de cuenta por sospecha de intrusión; mantener la persistencia indefinidamente satura los límites de peticiones y atrae baneos sobre el segmento de red.

+------------------------------------------------------------------------------------+
|                      PATRÓN DE MÁQUINA DE ESTADOS DETERMINISTA                     |
+------------------------------------------------------------------------------------+

  [ Inicialización del Worker ]
             |
             v
+--------------------------+
| Test de Estado del Proxy | <--------------------------------------------+
+--------------------------+                                              |
             |                                                            |
             v                                                            |
+--------------------------+                                              |
| 1. FASE DE CALENTAMIENTO |                                              |
| - IP Persistente         |                                              |
| - Carga de cookies       |                                              |
+--------------------------+                                              |
             |                                                            |
             v                                                            |
+--------------------------+                                              |
| 2. EMBUDO DE CHECKOUT    |                                              |
| - IP Estricta Persistente|                                              |
| - Pago y Confirmación    |                                              |
+--------------------------+                                              |
             |                                                            |
             +-----------------------+                                    |
             |                       |                                    |
    (Transacción Exitosa)    (Bloqueo Crítico / WAF)                      |
             |                       |                                    |
             v                       v                                    |
+--------------------------+   +------------------------------------+     |
| 3. REGISTRO DE DATOS     |   | 3b. AISLAMIENTO DE PERFIL          |     |
| - Guardar ID de orden    |   | - Limpieza de estado y cookies     |     |
+--------------------------+   +------------------------------------+     |
             |                                  |                         |
             +-------------------+--------------+                         |
                                 |                                        |
                                 v                                        |
                 +-------------------------------+                        |
                 | 4. DISPARAR LLAMADA A LA API  |                        |
                 | POST /api/proxies/.../rotate  |                        |
                 +-------------------------------+                        |
                                 |                                        |
                                 v                                        |
                 +-------------------------------+                        |
                 | 5. ESPERAR RECONEXIÓN PDP     |                        |
                 | - Polling a /status hasta OK  | -----------------------+
                 +-------------------------------+

Casos de Uso para Sesiones Persistentes (Sticky Sessions)

  • **Maduración de Perfiles y Navegación Previa (Cookie Farming):** Los perfiles de navegador automatizados necesitan acumular cookies e historial de navegación creíble. Estas acciones deben ejecutarse bajo una IP constante para evitar alertas por accesos concurrentes desde orígenes dispersos.
  • Sesiones Autenticadas (OAuth, Paneles de Usuario, SSO): Modificar la dirección IP durante la navegación interna de una plataforma activa los controles de robo de tokens de sesión, invalidando las credenciales de acceso de inmediato.
  • **Procesos de Compra (Checkouts):** Desde que se añade el artículo al carrito hasta que se procesa el cobro con la pasarela bancaria, el binomio IP/TLS debe permanecer rigurosamente idéntico.
  • Scraping Interactivo con Estado: Extracción en portales que emplean tokens de un solo uso (nonces) o validaciones intermedias calculadas dinámicamente en el contexto de navegación actual.

Casos de Uso para Rotación Inmediata

  • Finalización Exitosa de Transacción: Una vez renderizada la página de confirmación (/checkout/thank-you) y almacenados los identificadores de la compra, la sesión ha concluido. Se debe forzar la rotación para desvincular la siguiente cuenta de la anterior.
  • Alternancia de Cuentas de Usuario: Jamás se deben gestionar dos identidades diferentes desde la misma IP móvil de forma consecutiva sin reiniciar antes la conexión celular.
  • Intercepción por Regla WAF (HTTP 403 / Desafío Cloudflare): Si el scraper recibe un bloqueo definitivo de IP durante la fase de extracción inicial, debe solicitar una rotación inmediata antes de reintentar la solicitud.
  • Scraping Masivo Sin Estado: Para indexar catálogos públicos, sitemaps o motores de búsqueda donde no se requiere autenticación, rotar la IP por cada hilo de trabajo distribuye el volumen y anula los bloqueos por frecuencia.

6. Implementaciones en Producción: Python y Go

Los siguientes desarrollos muestran cómo gestionar sesiones persistentes complejas combinadas con rotación de hardware bajo demanda mediante la API REST de Proxym.

Implementación A: Python 3 con Playwright y API REST de Proxym

El siguiente script utiliza Playwright para ejecutar un flujo de compra continuo garantizando que la IP no cambie accidentalmente durante el proceso. La rotación de hardware solo se invoca cuando la transacción culmina con éxito o si se detecta un bloqueo irrecuperable.

#!/usr/bin/env python3
"""
Framework de Automatización: Sesión Persistente con Rotación de Hardware Determinista
Dependencias: pip install playwright requests
"""

import os
import time
import logging
import requests
from typing import Dict, Any, Optional
from playwright.sync_api import sync_playwright, BrowserContext, Page, Error as PlaywrightError

# Configuración de logs estructurados
logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s [%(levelname)s] (%(threadName)s) %(message)s"
)
logger = logging.getLogger("ProxymPipeline")

class ProxymController:
    """Controla la rotación física del módem industrial Teltonika vía API de Proxym."""
    
    BASE_URL = "https://proxym.io/api"

    def __init__(self, api_key: str, assignment_id: str):
        self.api_key = api_key
        self.assignment_id = assignment_id
        self.headers = {
            "Authorization": f"Bearer {self.api_key}",
            "Content-Type": "application/json"
        }

    def trigger_rotation(self) -> bool:
        """Ordena al módem reiniciar el contexto PDP para obtener una nueva IP CGNAT."""
        url = f"{self.BASE_URL}/proxies/{self.assignment_id}/rotate"
        logger.info(f"Solicitando rotación de hardware en el puerto: {self.assignment_id}")
        
        try:
            response = requests.post(url, headers=self.headers, timeout=30)
            if response.status_code in [200, 202]:
                data = response.json()
                logger.info(f"Comando de rotación aceptado: {data}")
                return self._wait_for_ip_propagation()
            else:
                logger.error(f"Fallo en la rotación: HTTP {response.status_code} - {response.text}")
                return False
        except requests.RequestException as e:
            logger.error(f"Error de comunicación con la API de Proxym: {str(e)}")
            return False

    def _wait_for_ip_propagation(self, timeout_sec: int = 45) -> bool:
        """Monitoriza el estado del módem hasta que restablece el portador celular."""
        logger.info("Esperando reconexión del enlace celular 5G...")
        start_time = time.time()
        time.sleep(5)  # Tiempo base de desconexión física del módem
        
        while time.time() - start_time < timeout_sec:
            url = f"{self.BASE_URL}/proxies/{self.assignment_id}/status"
            try:
                res = requests.get(url, headers=self.headers, timeout=10)
                if res.status_code == 200:
                    status_data = res.json()
                    if status_data.get("status") == "ONLINE":
                        logger.info(f"Módem en línea. Nueva IP Pública: {status_data.get('current_ip')}")
                        return True
            except requests.RequestException:
                pass
            time.sleep(3)
            
        logger.error("Tiempo límite agotado esperando la reconexión celular.")
        return False


class PersistentCheckoutWorker:
    """Ejecuta compras multi-paso asegurando la persistencia estricta de la red."""

    def __init__(self, proxy_server: str, proxy_auth: Dict[str, str], proxym_ctrl: ProxymController):
        self.proxy_server = proxy_server
        self.proxy_auth = proxy_auth
        self.proxym_ctrl = proxym_ctrl

    def run_checkout_flow(self, user_data: Dict[str, Any]) -> bool:
        with sync_playwright() as p:
            # Enrutamiento de Playwright a través del puerto 5G dedicado
            browser = p.chromium.launch(
                headless=True,
                args=[
                    "--disable-blink-features=AutomationControlled",
                    "--no-sandbox"
                ]
            )

            context: BrowserContext = browser.new_context(
                proxy={
                    "server": self.proxy_server,
                    "username": self.proxy_auth["user"],
                    "password": self.proxy_auth["password"]
                },
                viewport={"width": 1920, "height": 1080},
                user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 "
                           "(KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36"
            )

            page: Page = context.new_page()

            try:
                logger.info("Paso 1: Verificación de IP de Salida")
                page.goto("https://httpbin.org/ip", timeout=30000)
                logger.info(f"IP Detectada: {page.inner_text('pre')}")

                # Paso 2: Autenticación en la plataforma y reserva de cesta
                logger.info("Paso 2: Inicio de sesión y asignación de inventario")
                page.goto("https://example.com", wait_until="networkidle")
                
                # Paso 3: Envío de datos de facturación (Persistencia de IP requerida)
                logger.info("Paso 3: Rellenando datos de envío")
                time.sleep(2) 

                # Paso 4: Tokenización segura de la tarjeta de crédito
                logger.info("Paso 4: Procesamiento de pago mediante pasarela")
                time.sleep(3)

                logger.info("