- Frontend · Lógica de negocio e integraciones
- 2023 — 2026
- Next.js · React · TypeScript · Pages Router
El origen
Entró por WiperAgency, una agencia de marketing que también hacía desarrollos a medida bajo la submarca Flexy Store. Comenzó en 2023, con el grueso del trabajo en los últimos meses de ese año, y después siguió sumando funcionalidad: upgrades de planes, nuevas pasarelas, nuevos países.
Éramos dos personas en frontend. La otra venía de maquetado y no manejaba JavaScript ni frameworks, así que toda la lógica, las integraciones y la arquitectura de cliente quedaron a mi cargo.
El planteo
Un e-commerce de asistencia al viajero es un cotizador antes que una tienda: el precio depende del destino, las fechas, la cantidad de pasajeros y sus edades. Encima de eso hay que emitir un voucher real, cobrar en cinco o seis países con pasarelas distintas, y atribuir cada venta a la tienda correcta.
La restricción que definió el proyecto no fue de negocio sino de infraestructura, y apareció cuando el desarrollo ya estaba encaminado: el servidor del cliente no podía correr Node. Todo lo que sigue son consecuencias de esa línea.
El cierre
El sitio sigue en producción bajo el mismo dominio, vendiendo en varios países. La lección fue que las restricciones de infraestructura se relevan antes de elegir el framework, no después: buena parte del trabajo consistió en devolverle a un Next.js sin servidor aquello que Next.js resuelve con servidor.
Problemas y soluciones
El cliente sólo disponía de servidores IIS y no podía montar un entorno Node. El proyecto era Next.js y estaba pensado con SSR para SEO y tiempos de carga, así que quedaban descartadas las rutas dinámicas y cualquier `getServerSideProps`.
Estrategia híbrida SSG/CSR. El país pasó a ser un parámetro (`/home?argentina`) en vez de una ruta dinámica, se prerenderizó como estático lo que casi no cambiaba —las coberturas, por ejemplo— y el resto se resolvió en cliente cuidando la hidratación. Servido desde Apache con pm2 y reglas de reescritura.
Las pasarelas de pago cambiaron varias veces y no eran las mismas en cada país. Empezamos con Decidir en Argentina y d-local en el resto de la región, después migramos a Mercado Pago, y probamos Transbank en Chile e Izipay en Perú.
El frontend nunca tocó datos de tarjeta. Cada checkout se monta embebido —Mercado Pago inyecta sus propios inputs dentro de contenedores con los ids que define, Izipay va en iframe— y los datos vuelven cifrados a la API, que cierra la transacción y responde si el pago pasó. Cambiar de pasarela quedó acotado a montar un checkout más, sin tocar el resto del flujo de compra.
El mismo sitio tenía que vender bajo distintas tiendas: los países de la región, y además vendedores externos con su propia atribución de ventas. En paralelo, atención telefónica necesitaba cotizar y cerrar ventas sin pasar por el sitio público.
La tienda sale del parámetro de la URL, así que un mismo checkout atribuye la compra a un país o a un vendedor sin duplicar sitio. Para atención telefónica, el backoffice arma la misma cotización y genera un link que cae directo en el checkout, con el plan elegido y los pasajeros ya cargados; sólo queda completar datos y pagar.
