Opciones de checkout para una tienda Magento 2 con Hyvä: qué funciona de verdad

Se ha comprometido con Hyvä. La tienda es rápida, la carga de JavaScript cayó un orden de magnitud, y entonces llega al checkout, la única página que Hyvä no reconstruye por usted de forma nativa. Todos los proyectos con Hyvä llegan a esta bifurcación, y cada opción tiene coste y dependencia reales, así que conviene decidir de forma deliberada en lugar de caer en una por defecto.

Estas son las opciones de checkout que existen de verdad y se mantienen a agosto de 2026, lo que cuesta cada una en realidad y cuál elegiríamos para qué tipo de tienda.

Sobre las fuentes y el alcance. Las licencias, precios y números de versión de Hyvä se mueven: trate cada cifra de aquí como de agosto de 2026 y confírmela en el sitio del propio proveedor antes de presupuestar. Este artículo está escrito desde la experiencia de ingeniería más la documentación actual del proveedor; no se deriva del código de una tienda concreta. El repositorio en el que se redactó es el sitio de marketing en Laravel de Emyrix, no una instalación de Magento, así que no había ninguna configuración de Hyvä, versión de Magewire ni sobreescritura de checkout que inspeccionar. Leer esas restricciones en su tienda es una auditoría de código, no un artículo de blog, y es lo primero que haríamos en un proyecto real.

Por qué el checkout de Luma es un problema bajo Hyvä

Hyvä elimina deliberadamente RequireJS, KnockoutJS y jQuery del frontend y los sustituye por Alpine.js (~15 KB comprimidos) y Tailwind. El checkout Luma por defecto de Magento está construido precisamente sobre el stack que Hyvä eliminó: view models de Knockout, uiComponents, RequireJS. Los dos no comparten página.

Así que «mantener el checkout de Luma» en una tienda Hyvä significa en realidad una de dos cosas:

• Ejecutar el módulo de theme fallback (opción 2), que vuelve a activar todo el stack de frontend de Luma, pero solo en /checkout. Su tienda Hyvä rápida le pasa al usuario a una página pesada justo en el momento en que va a pagar.
• Sustituir el checkout por algo construido para Hyvä.

La diferencia de rendimiento es la cuestión de fondo. Hyvä cita hasta 13 veces más rápido en carga móvil para su propio checkout frente al de Luma. Alcance o no esa cifra, la dirección es real: los ~90 KB de Knockout más el coste de arranque de RequireJS caen directamente sobre el LCP y el INP del checkout, la página donde la lentitud le cuesta dinero.

Opción 1 — Hyvä Checkout oficial (Magewire)

La opción nativa. Hyvä Checkout es un módulo comercial construido sobre Magewire —un port a Magento del Livewire de Laravel— más Alpine.js y Tailwind. La lógica se queda en el servidor, en PHP; Magewire sincroniza el estado con el navegador y Alpine gestiona la interactividad, así que construye el checkout como construye el resto de Magento, y no en una aplicación JS aparte.

• Coste (agosto de 2026, verifíquelo): 1.000 € de pago único por una instalación de Magento con dominios y vistas de tienda ilimitados, incluido un año de actualizaciones y soporte; después 250 €/año, o 1.000 € por un paquete de cinco años. Se entrega a través de Private Packagist.
• Licencia: desde que el tema base de Hyvä pasó a código abierto en noviembre de 2025 (OSL 3.0 + AFL 3.0), Hyvä Checkout ya no requiere una licencia de pago del tema: es una compra independiente.
• Stack: Magewire v3 (magewirephp/magewire 3.x), componentes PHP renderizados en el servidor conectados a Alpine a través de un objeto $wire.
• Pagos: amplio y creciente; la mayoría de las pasarelas habituales tienen integraciones preparadas para Magewire, pero confirme su PSP concreto antes de comprometerse.
• Despliegue: se puede acotar por vista de tienda, e incluso ejecutarse en una tienda Luma a través del theme fallback, así que puede pilotarlo en una vista de tienda antes de ir a por todas.

Esfuerzo/riesgo: de bajo a moderado. Tiene soporte oficial y la mayor base instalada, exactamente lo que quiere debajo de un checkout. La personalización es PHP primero, así que un equipo de Magento es productivo rápido. Un componente de Magewire es una clase PHP, no un view model en JS:

class ShippingMethod extends \Magewirephp\Magewire\Component
{
    public array $method = [];

    public function updatedMethod($value): void
    {
        // Runs server-side and re-renders the component — no custom JS.
    }
}

Opción 2 — Checkout de Luma a través del módulo de theme fallback

hyva-themes/magento2-theme-fallback (gratuito, código abierto) desactiva el tema Hyvä para las rutas configuradas y las renderiza sobre un tema Luma/blank tradicional. Apúntelo a checkout/* y su checkout de Luma existente —y cada extensión que se engancha a él— sigue funcionando sin tocarlo.

Cuándo es correcto: un puente barato durante la migración, o una tienda con personalizaciones profundas y caras del checkout de Luma que todavía no puede reescribir.

La pega: está enviando todo el stack de Luma en su página más importante, lo que deshace buena parte de la razón por la que pasó a Hyvä. Trátelo como un parche provisional con una fecha de sustitución en el calendario, no como un destino.

Opción 3 — Hyvä React Checkout (comunitario)

Distinto del producto comercial: hyva-themes/magento2-react-checkout es un checkout gratuito, de código abierto y basado en React, mantenido por la comunidad de Hyvä (friends-of-hyva). Es anterior al producto en Magewire y sigue manteniéndose en 2026.

Cuándo es correcto: tiene un equipo de React, quiere control total en código abierto y está cómodo asumiendo el trabajo de integración, incluido conectar cada método de pago por su cuenta.

La pega: reintroduce un runtime de React y un segundo paradigma de frontend en una tienda que por lo demás es Alpine/Magewire, y el soporte comunitario es más escaso que el del producto comercial. Para la mayoría de los equipos, el checkout oficial en Magewire es la opción de menor riesgo; elija React solo por una razón concreta.

Opción 4 — One-step checkouts de terceros

Amasty, Mageplaza, OneStepCheckout y otros venden one-step checkouts, y la mayoría anuncia «soporte para Hyvä». Lea esa afirmación con cuidado, porque significa dos cosas muy distintas:

• Renderizado nativo en Hyvä: el checkout está construido o portado de verdad para Hyvä (Alpine/Tailwind). Amasty tiene una asociación oficial con Hyvä y distribuye paquetes compatibles con Hyvä para su checkout, aunque algunos complementos Pro necesitan paquetes de compatibilidad aparte ligados a una suscripción activa; verifíquelo por versión de módulo.
• Luma vía theme fallback: la extensión mantiene su tienda en Hyvä pero renderiza la propia página del checkout en Luma. El one-step checkout de Mageplaza, por ejemplo, funciona a través del theme fallback. Eso es la opción 2 con etiqueta de producto, con el mismo compromiso de rendimiento.

Cuándo es correcto: necesita específicamente el conjunto de funciones de ese proveedor (fecha de entrega, envoltorio de regalo, control granular de campos) y lo renderiza de forma nativa en Hyvä.

La pega: confirme —por escrito, para su versión exacta— si el checkout se renderiza en Hyvä o cae a Luma. Hyvä mantiene un tracker público de módulos de compatibilidad para comprobar el estado por extensión.

Opción 5 — Desarrollo a medida en Magewire

Si sus requisitos son realmente inusuales —de presupuesto a carrito en B2B, envíos divididos, un flujo de PSP a medida—, puede construir el checkout directamente sobre Magewire en lugar de doblar un producto para que encaje. Consigue exactamente el flujo que quiere, en el mismo modelo PHP primero de Hyvä Checkout.

La pega: ahora es dueño de cada integración de pago, de cada caso límite y del impacto de cada actualización de Magento en su checkout, el trabajo que el producto comercial amortiza entre toda su base de clientes. Se justifica solo cuando ninguna opción existente puede alcanzar sus requisitos.

Opción 6 — Checkout headless / desacoplado

Puede poner delante de las APIs de Magento una PWA (PWA Studio, Alokai/Vue Storefront) o una app a medida en Next.js para el checkout. Pero si eligió Hyvä, ya eligió no ir headless: Hyvä existe para conseguir un rendimiento de clase PWA sin el coste operativo de una PWA. Atornillar un checkout headless a una tienda Hyvä renderizada en el servidor le deja con dos frontends que mantener y una frontera de hidratación en el peor sitio posible. Sensato solo si ya es headless en todo lo demás.

Comparación

Qué opción encaja con qué tienda

• La mayoría de las tiendas Hyvä: Hyvä Checkout oficial. Rendimiento nativo, soporte oficial, personalización PHP primero, despliegue por vista de tienda. Es la opción por defecto por buenas razones.
• Presupuesto ajustado / a mitad de migración: theme fallback, explícitamente como parche provisional con fecha de sustitución.
• Inversión existente fuerte en un OSC (Amasty/Mageplaza): manténgalo solo si se renderiza de forma nativa en Hyvä; si no, planifique la migración.
• B2B, muchos SKU, o un PSP o flujo inusual: parta de Hyvä Checkout y extiéndalo; baje a un desarrollo a medida en Magewire solo si sus puntos de extensión no llegan de verdad.
• Organización muy centrada en React que quiere código abierto: Hyvä React Checkout, con los ojos abiertos ante el intercambio de integración y soporte.
• Ya completamente headless: un checkout headless, pero entonces probablemente no está en Hyvä para empezar.

Trampas de la migración

• Métodos de pago: lo primero que se rompe. Una pasarela con una interfaz pulida en Luma puede no tener ninguna integración con Magewire/Hyvä. Haga inventario de cada PSP activo y confirme el soporte antes de elegir un checkout.
• Métodos de envío y lógica de tarifas: los transportistas a medida y la lógica de tarifas por tabla suelen vivir en el servidor y sobreviven, pero cualquier interfaz de envío renderizada con Knockout necesita portarse.
• Extensiones que se enganchan al checkout: mensajes de regalo, fecha de entrega, atributos de pedido, módulos de recargo: cada uno necesita una versión nativa de Hyvä o desaparece en silencio del checkout nuevo.
• GTM / analítica: los eventos checkout_* y de compra del dataLayer de Luma, basados en Knockout, no se dispararán en un checkout nuevo. Vuelva a implementar sus eventos de embudo y compra de GA4/GTM y vuelva a probar la atribución de principio a fin. Esto se olvida de forma rutinaria hasta que el informe de ingresos parece raro.
• Pruebas: como invitado y con sesión; cada combinación de pago × envío; carritos virtuales y descargables; casos límite de impuestos y descuentos; y móvil en concreto. El checkout es donde «se ve bien» y «funciona de verdad» más se separan.

Qué elegiríamos

Para la gran mayoría de los proyectos con Hyvä: Hyvä Checkout oficial. El precio es modesto comparado con lo que cuesta una página 13 veces más lenta o un checkout caído, el modelo de Magewire mantiene productivo a un equipo de Magento, y «con soporte oficial y la mayor base instalada» vale muchísimo en la página que cobra el dinero. Recurra al theme fallback solo como un parche provisional con fecha, y a un desarrollo a medida en Magewire solo cuando un requisito real no deje otra puerta abierta.

Fuentes

• Hyvä Checkout — producto y precios
• Hyvä Checkout — documentación
• Changelog de Hyvä Checkout (Magewire v3)
• El tema Hyvä pasa a código abierto (Atwix)
• Hyvä React Checkout (GitHub)
• Tracker de módulos de compatibilidad de Hyvä (GitLab)

Emyrix construye y optimiza tiendas Magento y Adobe Commerce, incluidas migraciones a Hyvä y trabajo de checkout y rendimiento. Si está sopesando el checkout para un proyecto con Hyvä y quiere una recomendación directa para su stack, escríbanos.