Elegir entre un checkout integrado y uno alojado parece, a primera vista, una decisión de interfaz. En una opción, el cliente permanece dentro de la experiencia visual del comercio. En la otra, un proveedor especializado ofrece una parte o toda la fase de pago.
En la práctica, es una decisión de arquitectura.
Cambia quién proporciona los elementos que recogen los datos de pago, qué sistemas forman parte de la ruta crítica, cuánto control tiene el comercio sobre la experiencia, cómo evoluciona la integración, cuál es la superficie de seguridad y cómo puede cambiar el alcance del cumplimiento normativo.
No hay un formato universalmente mejor. Hay un formato más adecuado al nivel de control, riesgo, capacidad técnica y estrategia de producto de cada operación.
¿Qué es un checkout integrado?
El checkout integrado, conocido en el mercado brasileño como «checkout transparente», describe una experiencia en la que el consumidor completa la compra sin percibir una salida significativa del entorno del comercio.
Puede implementarse de varias formas.
El comercio puede construir la página e integrar componentes del proveedor. Puede utilizar campos alojados o iframes para recoger datos sensibles. Puede tokenizar la credencial en el navegador y enviar únicamente el token al backend. También puede utilizar API de pago manteniendo toda la experiencia visual bajo su marca.
Por eso, «transparente» describe más la experiencia de usuario que un único diseño técnico.
¿Qué es un checkout alojado?
Un checkout alojado es una página de pago proporcionada por un PSP u otro proveedor especializado.
El comercio normalmente crea una sesión o intención, redirige al consumidor al entorno del proveedor y recibe después el resultado mediante el retorno del navegador y eventos de servidor.
La página alojada puede encargarse de la recogida de datos de tarjeta, los métodos locales, la autenticación, las validaciones y parte de la lógica de presentación.
La principal ventaja es externalizar una parte relevante de la superficie de pago.
¿Un checkout alojado implica abandonar por completo la marca?
No necesariamente.
Muchos proveedores permiten personalizar el logotipo, los colores, el idioma y elementos básicos de la experiencia.
Aun así, existe una diferencia entre personalización y control total.
Con una página alojada, el comercio acepta los límites impuestos por el componente externo. Esto puede ser positivo porque reduce el mantenimiento, pero también puede limitar experimentos de UX muy específicos.
¿Qué son los hosted fields?
Los hosted fields son campos de pago proporcionados por el proveedor e incorporados a la página del comercio, normalmente mediante iframes o mecanismos equivalentes.
Visualmente, el checkout puede parecer nativo. Técnicamente, el proveedor controla los elementos que reciben los datos sensibles.
Este modelo busca combinar una experiencia integrada con una menor exposición directa del comercio a los datos de tarjeta.
Pero los detalles importan. La forma de entregar los elementos y las partes de la página que participan en la recogida influyen en el alcance y las responsabilidades de seguridad.
¿Un iframe y los hosted fields son siempre lo mismo?
No.
Un iframe es una técnica para incorporar contenido. Los hosted fields son un patrón de producto en el que el procesador aloja campos específicos.
Un checkout puede utilizar un único iframe con toda el área de pago o varios frames para campos separados.
Lo que importa para la seguridad y el cumplimiento es de dónde proceden realmente los elementos de recogida y cómo puede afectar al flujo la página del comercio.
¿Qué es direct post?
Direct post es un diseño en el que la página del comercio participa en la creación de los campos que recogen datos, pero el navegador envía esos datos directamente al procesador.
Esto se parece a los hosted fields porque el backend del comercio puede no recibir el PAN.
Sin embargo, desde el punto de vista del alcance, existe una diferencia importante: la página del comercio interviene directamente en la aceptación de los datos de tarjeta.
El PCI Security Standards Council distingue explícitamente estos modelos en sus criterios de elegibilidad.
¿Por qué importa el origen de los elementos?
Porque una página comprometida puede manipular el recorrido del pago.
Aunque los datos se envíen directamente al PSP, un script malicioso en el entorno del comercio puede alterar el DOM, sustituir campos, interceptar información o cambiar el destino del usuario según la arquitectura.
Externalizar el procesamiento no elimina la necesidad de proteger el sitio web.
PCI DSS v4.x refuerza los controles de las páginas de comercio electrónico precisamente porque el entorno del comercio puede afectar a la seguridad del flujo incluso cuando el procesamiento está externalizado.
¿El checkout alojado elimina PCI DSS?
No.
Externalizar la recogida y el procesamiento puede reducir el alcance aplicable, pero no significa que desaparezcan todas las responsabilidades.
La elegibilidad para los cuestionarios y requisitos depende del diseño técnico y de todos los criterios aplicables.
Por ejemplo, el PCI SSC explica que, en determinados escenarios aptos para SAQ A, los elementos de la página de pago deben proceder de proveedores validados y siguen debiendo cumplirse otros criterios.
La seguridad del sitio, la integridad de las redirecciones y las vulnerabilidades siguen siendo relevantes.
¿Qué cambia con PCI DSS v4.x para el comercio electrónico?
La norma aumentó la atención sobre los ataques mediante scripts y el compromiso de la página de pago.
Incluso los comercios que externalizan el procesamiento pueden tener obligaciones relacionadas con la seguridad del sitio que influye en el recorrido.
Esto importa porque «no almaceno tarjetas» nunca ha significado «mi página no puede sufrir un ataque».
El checkout empieza antes del primer campo sensible.
¿Qué modelo reduce más el alcance técnico?
En general, cuanto más se delegan la recogida y el procesamiento en un proveedor validado, menor suele ser la superficie controlada directamente por el comercio.
Una redirección completa suele transferir al proveedor más responsabilidad operativa sobre la página de pago que un formulario construido por el propio comercio.
Pero cualquier afirmación sobre el alcance debe contrastarse con el diseño real y los criterios actuales de PCI DSS.
Arquitecturas visualmente parecidas pueden tener implicaciones diferentes.
¿El checkout integrado convierte mejor?
No hay una respuesta universal.
Mantener al consumidor en el mismo dominio puede reducir la sensación de ruptura y dar más control sobre la experiencia. Puede ayudar en algunos recorridos.
Por otro lado, una página alojada muy bien optimizada puede convertir mejor que un checkout propio mal construido.
La conversión depende de la confianza, el rendimiento, los métodos de pago, la claridad, los errores, la autenticación, el móvil, la latencia y la familiaridad.
El modelo técnico es solo una variable.
¿La redirección siempre aumenta el abandono?
No necesariamente.
Si el proveedor es rápido y fiable y la transición está bien explicada, el impacto puede ser pequeño.
En algunos mercados, los usuarios están acostumbrados a páginas de bancos, monederos digitales y métodos que abren otro entorno de forma natural.
El mayor problema es la sorpresa.
Cuando el consumidor no entiende por qué ha salido de la página o no consigue volver, aumenta la fricción.
¿El móvil cambia esta decisión?
Sí.
Las pantallas más pequeñas hacen más perceptible cualquier ruptura. Al mismo tiempo, los monederos digitales y las aplicaciones bancarias ya crean flujos entre aplicaciones de forma natural.
Un checkout integrado necesita un comportamiento excelente del teclado, el autocompletado, la validación, el foco y la adaptación a distintas pantallas.
Un checkout alojado debe cargar rápido y conservar el contexto al volver.
Probar solo en escritorio no es suficiente.
¿Quién controla la experiencia de error?
En un checkout propio, el comercio puede controlar con bastante detalle los mensajes, el estado visual y la recuperación.
En uno alojado, parte de la experiencia depende del proveedor.
Esto puede ser una ventaja cuando el PSP ya gestiona decenas de casos límite, o una desventaja cuando el comercio necesita un lenguaje y una lógica muy específicos.
Una buena decisión tiene en cuenta cuántos errores necesitan realmente personalización y cuánto cuesta mantener esa lógica internamente.
¿Quién controla los nuevos métodos de pago?
Las páginas alojadas suelen poder añadir nuevos métodos con menos trabajo para el comercio cuando el proveedor ya los admite.
En un checkout integrado, cada método puede exigir integración, componentes, estados y pruebas adicionales.
En operaciones internacionales, esta diferencia crece rápidamente.
La empresa debe decidir si quiere controlar la capa de presentación de cada método o delegar parte de ella.
¿Y Pix?
Pix funciona bien en ambos modelos.
Un checkout propio puede generar una solicitud de pago, mostrar un código QR y actualizar el estado en la página. Un checkout alojado puede encapsular ese recorrido.
La diferencia sigue siendo la responsabilidad de UX e integración.
En ambos casos, la confirmación debe realizarse en el servidor mediante eventos y consultas, sin depender únicamente del navegador.
¿Y 3DS?
3DS añade otra capa a la experiencia.
En un checkout propio, la integración debe gestionar con cuidado las redirecciones, los iframes, los desafíos de autenticación, el retorno y los estados.
Un checkout alojado puede abstraer parte de ese flujo.
Esta abstracción reduce la complejidad, pero también ofrece menos control sobre los detalles del recorrido.
¿Cómo cambia la tokenización el checkout integrado?
La tokenización permite que el navegador entregue la credencial directamente a un entorno seguro y reciba un token que el backend utiliza en operaciones posteriores.
Esto reduce la necesidad de que el servidor del comercio manipule el PAN.
Aun así, es necesario evaluar cómo recoge el dato la página y qué componentes están dentro del alcance.
Tokenizar no convierte automáticamente cualquier implementación en el equivalente de una página completamente alojada.
¿Tener un checkout propio significa almacenar tarjetas?
No.
Es posible mantener una experiencia propia sin almacenar PAN, utilizando componentes y tokenización de proveedores.
Almacenar tarjetas por cuenta propia es una decisión mucho más exigente y rara vez necesaria para la mayoría de los comercios.
La distinción entre «controlo la interfaz» y «controlo el vault» es fundamental.
¿Cómo afecta el checkout a la portabilidad entre PSP?
Un checkout muy acoplado a componentes exclusivos de un PSP puede aumentar el coste de cambiar de proveedor.
Un checkout totalmente propio con abstracción de tokenización también puede sufrir dependencia del proveedor si los tokens no son portables.
La portabilidad debe analizarse por capas: interfaz, token, autenticación, API y datos operativos.
Tener varios PSP en el backend no garantiza la portabilidad si la recogida de datos de tarjeta depende de un único proveedor.
¿Es compatible multi-PSP con un checkout alojado?
Puede serlo, pero la decisión de enrutamiento cambia.
Si cada PSP tiene su propia página, el comercio puede tener que elegir al proveedor antes de redirigir al cliente.
Esto reduce las oportunidades de enrutamiento una vez creada la sesión.
Una capa de checkout independiente puede conservar más libertad de elección, siempre que los tokens y las credenciales puedan utilizarse en las rutas deseadas.
¿Son compatibles los hosted fields con Smart Routing?
Sí, siempre que la estrategia de tokenización lo permita.
Si el token generado solo funciona en un PSP, la ruta queda elegida implícitamente durante la recogida.
Si existe un vault o una tokenización con la portabilidad adecuada, el enrutamiento puede seguir siendo flexible.
Esta es una de las preguntas más importantes para una arquitectura multi-PSP.
¿Qué ocurre si el proveedor del checkout sufre una caída?
Una página alojada crea una dependencia directa de la disponibilidad del proveedor durante el recorrido.
Un checkout propio también depende del PSP para tokenizar y procesar.
La diferencia está en dónde aparece el fallo y qué alternativas existen.
Si la operación utiliza varios PSP, conviene planificar si puede ofrecer otro camino cuando el componente principal no esté disponible.
¿Es posible hacer failover del checkout?
Sí, pero es más complejo que cambiar la URL de una API.
El cliente puede haber introducido ya datos en un componente. Un token puede pertenecer al proveedor que ha fallado. La autenticación puede estar en curso.
Un failover seguro debe comprender el estado y evitar pedir al cliente que repita pasos sin necesidad.
¿Cómo se mide el rendimiento del checkout?
El tiempo de carga es solo el principio.
Conviene medir el tiempo hasta que el formulario es interactivo, el tiempo hasta la tokenización, la latencia de creación de la intención, el tiempo de autenticación, la tasa de error del componente y el tiempo total hasta la confirmación.
Este desglose muestra si el problema está en la página, el SDK, el PSP o la autorización.
¿Qué es una buena estrategia de fallback?
El fallback debe planificarse por etapas.
Si el SDK no carga, puede haber otro componente. Si falla la tokenización, puede ser necesario otro método. Si la autorización falla por motivos técnicos, puede existir otra ruta.
No existe un fallback genérico llamado «volver a intentarlo».
Cada etapa tiene riesgos distintos.
¿Cómo gestionar la analítica sin recoger datos sensibles?
El checkout necesita métricas, pero los scripts de analítica no deberían tener acceso innecesario a los campos de pago.
Los componentes alojados ayudan a crear aislamiento.
Aun así, deben gobernarse las etiquetas y los scripts de terceros de la página, porque pueden comprometer la experiencia o el sitio web.
La minimización es una buena regla: cada script debe tener únicamente el acceso que necesita.
¿Qué cambia para las pruebas A/B?
Un checkout propio ofrece más libertad para experimentar con el orden de los campos, los mensajes, el diseño y los componentes.
En uno alojado, la superficie de prueba es menor.
Pero una mayor libertad también implica más responsabilidad para no perjudicar la accesibilidad, la seguridad y la conversión.
No todos los experimentos de UX deben entrar en el área de recogida de datos sensibles.
¿El checkout alojado acelera la salida al mercado?
A menudo, sí.
Una empresa puede lanzar métodos y países utilizando una página ya preparada, sin construir todas las variantes desde el principio.
Esto resulta valioso para validar un producto.
Más adelante, la operación puede decidir internalizar partes de la experiencia si la ganancia de control justifica el coste.
La arquitectura puede evolucionar.
¿Cuándo tiene más sentido un checkout integrado?
Tiene sentido cuando el control de UX es estratégico, el equipo tiene capacidad de ingeniería y seguridad y la operación necesita integrar profundamente el pago en el recorrido.
Los marketplaces complejos, los productos con flujos específicos y las empresas que optimizan la conversión a gran escala pueden valorar ese control.
Pero el beneficio debe superar el coste permanente de mantenimiento.
¿Cuándo tiene más sentido un checkout alojado?
Tiene sentido cuando la velocidad, la reducción de complejidad y la cobertura de métodos son prioritarias.
Es una buena opción para empresas que no quieren convertir la página de pago en un producto de infraestructura propio.
También puede ser la mejor opción para mercados nuevos en los que el comercio aún no conoce todas las particularidades locales.
¿Existe un término medio?
Sí.
Los hosted fields, los elementos integrados, los SDK y los componentes modulares crean un abanico entre la redirección completa y el formulario totalmente propio.
Ese abanico permite elegir qué responsabilidades conservar.
Por eso, la decisión no debería ser binaria basándose únicamente en el aspecto de la pantalla.
¿Cómo elegir objetivamente?
Empieza por los requisitos de negocio.
¿Cuánto control de UX es realmente necesario? ¿Cuántos métodos y países deben admitirse? ¿Qué madurez tiene el equipo de seguridad? ¿Existe una estrategia multi-PSP? ¿Importa la portabilidad de los tokens? ¿Cuánto tiempo hay para el lanzamiento?
Después, compara el coste de operar cada diseño.
La solución técnicamente más flexible puede ser la más cara desde el punto de vista organizativo.
¿Debe decidir únicamente la seguridad?
No, pero debe ser un requisito innegociable.
Es posible construir un checkout propio seguro y un checkout alojado mal integrado.
La cuestión es que cada diseño crea responsabilidades diferentes.
La decisión debe reunir a producto, ingeniería, seguridad, pagos y cumplimiento normativo.
¿Cómo documentar la arquitectura del checkout?
Un buen diagrama debería mostrar el navegador, el dominio del comercio, los componentes de terceros, el destino de los datos de tarjeta, la tokenización, el backend, los PSP, 3DS y los webhooks.
Si el equipo no puede señalar exactamente por dónde pasa el PAN, existe una carencia de comprensión.
La documentación también debe indicar qué scripts pueden afectar a la página.
¿El retorno del navegador confirma el pago?
No.
Redirigir de vuelta a la tienda es un mecanismo de experiencia.
La confirmación financiera debe obtenerse mediante API, webhook o consulta de servidor según el método.
Confiar en los parámetros del navegador como fuente definitiva abre la puerta a inconsistencias y manipulaciones.
¿Cómo gestionar a un usuario que cierra la página alojada?
El backend debe mantener activa la intención y conciliar su estado independientemente de la sesión.
El usuario puede pagar y cerrar la pestaña antes de volver.
Si el sistema depende del retorno para marcar el éxito, perderá ventas legítimas.
Este principio se aplica a cualquier checkout con redirección.
¿Cómo se conecta el checkout con el resto de la infraestructura?
Es la puerta de entrada, no todo el sistema.
Tras la recogida vienen la autenticación, la autorización, la captura, los webhooks, los reembolsos, la conciliación y los contracargos.
La arquitectura ideal permite cambiar la experiencia de checkout sin obligar a todos esos dominios a conocer los detalles del componente visual.
¿Pueden coexistir checkouts integrados y alojados?
Sí.
Una empresa puede utilizar un checkout propio en su mercado principal y una página alojada en países concretos. Puede mantener hosted fields para tarjetas y redirigir a monederos digitales. Puede utilizar enlaces de pago alojados en canales de soporte y un checkout integrado en el comercio electrónico.
La elección puede hacerse por canal y método, no para toda la empresa.
¿Cuál es la diferencia central entre los dos modelos?
El checkout integrado prioriza el control de la experiencia y la integración profunda, asumiendo mayor responsabilidad técnica.
El checkout alojado prioriza la delegación y la velocidad, aceptando límites de personalización y una mayor dependencia de la experiencia del proveedor.
Entre los extremos existen componentes híbridos.
La mejor elección es la que explicita quién controla cada parte del flujo.
El checkout es infraestructura, no solo una pantalla
La página de pago define cómo se recogen las credenciales, dónde se evalúa el riesgo, cómo aparece la autenticación, qué PSP interviene y qué datos quedan bajo la responsabilidad del comercio.
Por eso, la elección entre checkout integrado y alojado debe tratarse como una decisión de arquitectura.
Una buena interfaz convierte. Una buena arquitectura también protege, escala, aporta observabilidad y permite evolucionar sin convertir cada cambio de PSP en una reconstrucción completa del recorrido.