Flujo de checkout composable paso a paso
Cada etapa involucra a uno o más de los componentes y la clave está en la orquestación
En la publicación pasada te conté como un checkout en arquitectura composable involucra varios componentes especializados que colaboran entre sí (si aún no lo lees, en breve te cuento como puedes hacerlo).
En la publicación de hoy, quiero contarte como un checkout composable suele seguir una secuencia de pasos bien definida, donde cada etapa involucra a uno o más de los componentes mencionados en la publicación pasada.
A continuación, te describo un flujo típico a alto nivel, paso a paso:
1. Validación del carrito
Al iniciar el checkout, el sistema verifica que el carrito esté en condiciones válidas para proceder.
Esta validación incluye comprobar que los ítems aún estén disponibles en inventario, que las cantidades no excedan límites, que los precios y descuentos estén actualizados y que no haya inconsistencias.
En arquitecturas modernas, el workflow de checkout arranca con una serie de validaciones en el frontend para asegurarse de que “todo está en orden” antes de pasar a pasos más complejos.
Por ejemplo, se valida que cada producto del carrito se pueda entregar (¿tiene método de envío seleccionado?), que el carrito tenga un cálculo de precios vigente y que los pagos previstos cubren el total.
Cualquier discrepancia se resuelve aquí: si un precio estaba desactualizado, se recalcula; si falta elegir algún detalle (ej. tipo de envío), se solicita.
Estas verificaciones suelen ocurrir mediante llamadas al Commerce engine (que recalcule el carrito, aplique promociones activas, reserve stock temporalmente, etc.).
Si algún check falla (p. ej., inventario insuficiente para un producto), se notifica al usuario para corregir antes de continuar.
La idea es entrar a las siguientes fases con un carrito “sano”.
2. Recolección de dirección y método de entrega
Una vez el carrito es válido, el siguiente paso pide al usuario los datos de envío.
En la UI del checkout (frontend), el cliente proporciona su dirección de entrega; si el sistema soporta guest checkout (comprar sin registrarse y sin iniciar sesión), este es el momento donde también ingresa email y datos de contacto.
El frontend envía la dirección al backend (Commerce engine o BFF), que la guarda asociada al carrito.
Inmediatamente, con esa dirección, el sistema busca las opciones de envío disponibles (por ejemplo: envío estándar, exprés, recogida en tienda) según la localidad y tipo de productos.
Esto puede implicar consultar un servicio de tarifas de envío o reglas definidas en el OMS.
El usuario recibe las opciones con sus costos y elige un método de entrega.
En algunos diseños, en cuanto la dirección es ingresada se invoca también al servicio de validación de direcciones para autocompletar o corregir errores (por ejemplo, sugerir la region/ciudad correcta si hace falta).
Todo este flujo es típicamente sincrónico: el usuario no avanza hasta que se haya establecido una dirección válida y un método de envío seleccionado, porque de ello dependen cálculos de costos en los siguientes pasos.
Una buena práctica aquí es calcular cuanto antes los detalles de envío y es recomendable fijar la dirección en el Cart lo antes posible para determinar métodos de envío aplicables y calcular impuestos oportunamente.
3. Cálculo de impuestos y total
Con la dirección de entrega y el método de envío decidido, el sistema procede a calcular los impuestos y costos de envío exactos, y totalizar la orden.
Si existe un microservicio de impuestos, se le envían los detalles del carrito (productos, cantidades, destino) y devuelve los montos de impuesto a aplicar.
De igual modo, se confirma el costo del envío seleccionado – ya sea una tarifa fija configurada o una cotización en tiempo real con el proveedor logístico.
Estos valores se suman al subtotal de productos del carrito para obtener el total final que el usuario deberá pagar, típicamente desglosado (subtotal, envío, impuestos, descuentos, total).
Esta etapa asegura que antes de ingresar al pago, ambas partes (cliente y sistema) tengan claridad del monto.
Desde el punto de vista técnico, suele ser el commerce engine quien consolida estas cifras: muchas plataformas headless permiten actualizar el Cart con la dirección y método de envío, tras lo cual una llamada de recalculate o get totals devuelve ya los impuestos y fees incorporados.
Es esencial que esta operación sea exacta y rápida. Algunas optimizaciones posibles incluyen: cachear tasas de impuestos comunes, precalcular tarifas de envío en segundo plano al seleccionar método, etc., para no demorar al usuario.
Al finalizar este paso, el carrito se convierte prácticamente en una “orden pre-firmada” pendiente solo del pago.
4. Integración con el proveedor de pago (PSP)
Llega el momento crítico de cobrar al cliente. En un checkout composable, la integración de pagos suele dividirse en dos partes: una fase sincrónica donde se inicia el proceso de pago intercambiando datos entre el eCommerce y el PSP, y otra fase asíncrona donde se reciben notificaciones del PSP según el resultado.
Concretamente, cuando el usuario procede a pagar, el frontend puede hacer uso de las herramientas del PSP (por ejemplo, cargar un formulario seguro o redirigir a una pasarela) para recopilar los datos de tarjeta u otro método.
Es común que el frontend obtenga un token del PSP para la tarjeta, de modo que ningún dato sensible pase por tus servidores.
A continuación, tu backend invoca la API del PSP enviando el monto a cobrar, el token (o redirigiendo si es un método externo como PayPal) y posiblemente un identificador de transacción.
El PSP entonces procesa la transacción: si requiere autenticación 3DS Secure u otro challenge, lo gestiona, y finalmente responde con una aprobación (autorización exitosa), rechazo o estado pendiente.
El sistema de checkout recibe esa respuesta.
Si es aprobado, generalmente procedes al siguiente paso (confirmar orden).
Si es rechazo, se informa al usuario para que intente otro método o corrija datos; si es pendiente (por ejemplo, esperando transferencia bancaria), se podría pausar el flujo hasta confirmar.
Un detalle técnico clave es manejar la asincronía: algunos PSP envían confirmaciones vía webhooks a tu sistema backend (por ejemplo, confirmando captura de fondos), lo cual puede ocurrir ligeramente después de la interacción del usuario. Por ello, el diseño suele incluir un componente que escucha notificaciones del PSP (fase asíncrona) para actualizar el estado del pago en tu orden.
Además, es recomendable registrar un recurso de Pago en tu sistema (como un objeto Payment ligado al carrito/orden) donde guardar la información de la transacción, respuesta del PSP, ID de autorización, etc., lo cual facilita trazabilidad y manejo de excepciones.
En resumen, este paso involucra fuertemente al PSP y requiere considerar la seguridad (usar tokenización, cumplir PCI DSS) y la experiencia de usuario (no introducir demasiada fricción en el pago, aunque ocurran redirecciones externas).
5. Confirmación y creación de la orden
Con el pago autorizado, el checkout procede a confirmar la compra creando la orden final en el sistema.
Aquí, típicamente el Commerce engine/OMS toma el carrito validado y lo transforma en una orden persistida con un identificador único (número de orden) y estado inicial (por ejemplo “Pago Aprobado” o “Orden Creada”).
Esto implica guradar en la base de datos de órdenes todos los detalles: los ítems comprados, costo total, info de cliente, dirección de envío, método de pago usado (y referencia de pago), etc.
En un monolito, este era simplemente el siguiente paso en la transacción; en un sistema distribuido, es una llamada API (ej: POST /orders) al servicio responsable de órdenes con los datos del carrito y pago.
Es fundamental que este paso sea atómico y a prueba de duplicados: debemos evitar casos como crear dos órdenes para un solo pago o confirmar una orden sin haber cobrado.
Por ello, se suelen usar mecanismos de idempotencia – por ejemplo, cada intento de checkout lleva un requestId único de tal forma que si por error el pedido de creación se envía dos veces, el sistema lo reconozca y no duplique la orden.
Una vez la orden se genera con éxito, se devuelve al frontend un mensaje de confirmación con el número de pedido.
La UX aquí idealmente muestra una pantalla de éxito (Thank you page) con el resumen de la compra.
Desde la perspectiva del usuario, el proceso terminó: ya pagó y tiene su confirmación.
En un backend distribuido, sin embargo, aún quedan cosas por hacer tras crear la orden, como veremos en el siguiente paso.
Cabe mencionar que este momento de transición pago→orden es crítico en consistencia: si ocurrara un fallo en este instante (por ejemplo, el servicio de orden no responde tras cobrar), la arquitectura debe ser capaz de recuperarse (quizá confirmando la orden vía un proceso compensatorio o reintentando la creación más tarde usando el idempotency key).
Diseñar correctamente para que pago y orden queden sincronizados es un reto importante en checkout distribuidos.
6. Orquestación post-checkout (OMS, ERP, fulfillment)
Una vez registrada la orden, el enfoque composable confía en la orquestación de procesos backend para completar el ciclo.
El servicio de checkout o el commerce engine suele emitir un evento de "orden creada" que notifica a los sistemas interesados.
El Order Management System (OMS) recibe la orden y empieza a trabajar: quizás genera un número interno o formatea la orden para otros sistemas (a veces el número de orden final se genera durante la exportación al OMS).
El OMS confirma el inventario final (bloqueando stock para esa orden en su sistema) y puede desencadenar el flujo de fulfillment (cumplimiento): envía la orden al ERP o al Warehouse Management System (WMS) correspondiente para prepararla.
Si hay un ERP involucrado (sistema financiero/contable), la orden puede ser transmitida también a ese sistema vía integración (ej: para facturación o registro contable).
Asimismo, se suele disparar aquí el envío de la confirmación por email/SMS al cliente con los datos de su compra – esto se hace de manera asíncrona típicamente, tras la creación de la orden, para no retrasar el checkout principal.
En general, todas estas acciones posteriores (actualizar inventario global, notificar al a la bodega, generar etiqueta de envío, etc.) ocurren fuera de la interacción en tiempo real con el usuario, mediante una combinación de llamadas API backend a backend y mensajería de eventos.
Por ejemplo, el checkout service publica un evento OrderPlaced en un bus de mensajes; un listener del OMS lo consume y ejecuta su lógica, luego publica OrderPacked cuando esté listo para envío, y así sucesivamente en un flujo de eventos que reflejan el avance del fulfilment.
Lo importante es que el diseño composable separa el checkout (proceso de compra del cliente) del fulfilment (proceso de entrega interno), conectándolos de forma desacoplada.
De esta manera, si el OMS o el WMS estuvieran lentos, el cliente no sufre espera al comprar; ya tiene su orden confirmada y el sistema podrá completar la entrega en segundo plano (y mantenerlo informado del progreso).
Finalmente, el OMS actualizará el estado de la orden (ej. “Enviado” cuando se despacha) y eso podría reflejarse en la cuenta del cliente o en notificaciones, cerrando el ciclo de vida de esa orden.
Conclusión
Como vemos, el checkout composable abarca desde que el cliente inicia la compra hasta que la orden se encola para su cumplimiento.
A diferencia de un monolito, aquí intervienen varios servicios y pasos explícitos.
La clave está en la orquestación: que todos estos componentes encajen y se coordinen sin fisuras.
Lograrlo requiere pensar en consideraciones de diseño específicas, las cuales te contaré en la siguiente publicación.
Aquí puedes leer la publicación anterior sobre como es la arquitectura de un checkout composable, sus componentes principales y cual es su responsabilidad dentro del sistema.