# Checkout en Drupal Commerce: Flows, Steps y Panes Enviado por [danieluxury](/es/user/1 "Ver perfil del usuario.") el Vie, 25 Sep 2026 - 11:53 Una vez que comprendemos Products, Variations, Orders y Workflows, podemos estudiar el proceso mediante el cual el cliente transforma un carrito en una compra completada: **el Checkout**. El Checkout es una de las partes más visibles de cualquier tienda online. Es el momento donde el cliente proporciona información como: - Datos personales - Dirección de facturación - Dirección de envío - Método de envío - Método de pago - Cupones - Información adicional del pedido y finalmente confirma la compra. Drupal Commerce organiza este proceso alrededor de tres conceptos fundamentales: ```plaintext Checkout Flow ↓ Steps ↓ Panes ``` Comprender esta arquitectura nos permite construir procesos de compra muy diferentes sin tener que desarrollar un checkout completamente desde cero. --- ## 1. Qué es un Checkout Flow Un **Checkout Flow** define cómo será el proceso de checkout para un determinado Order. Podemos pensar en él como la estructura general de la experiencia de compra. Por ejemplo: ```plaintext Checkout Flow Login ↓ Order Information ↓ Review ↓ Payment ↓ Complete ``` Otro negocio podría necesitar un proceso mucho más sencillo: ```plaintext Checkout Flow Payment ↓ Complete ``` Mientras que un proyecto B2B podría tener: ```plaintext Checkout Flow Company Information ↓ Billing Information ↓ Purchase Order ↓ Review ↓ Complete ``` El Checkout Flow debe reflejar la información y las decisiones necesarias para completar una compra. --- ## 2. Checkout Flow no es Order Workflow Esta diferencia es fundamental. El **Checkout Flow** describe la experiencia del usuario durante la compra. El **Order Workflow** describe el ciclo de vida comercial del Order. Por ejemplo: ```plaintext CHECKOUT FLOW Login ↓ Address ↓ Shipping ↓ Payment ↓ Review ↓ Complete ``` Mientras: ```plaintext ORDER WORKFLOW Draft ↓ Fulfillment ↓ Completed ``` Podemos resumir: ```plaintext Checkout Flow = qué pasos sigue el comprador Order Workflow = en qué estado está la transacción ``` Ambos procesos están relacionados, pero tienen responsabilidades distintas. --- ## 3. Checkout Flow tampoco es Payment Workflow También debemos mantener separado el proceso de pago. Por ejemplo: ```plaintext Checkout Flow Payment Information ↓ Review ↓ Complete ``` Mientras el Payment puede encontrarse en: ```plaintext New ↓ Authorization ↓ Completed ``` O posteriormente: ```plaintext Completed ↓ Partially Refunded ↓ Refunded ``` Podemos pensar: ```plaintext Checkout Flow = experiencia del comprador Order Workflow = ciclo de vida del pedido Payment Workflow = ciclo de vida del dinero ``` --- ## 4. Checkout Flow y Order Type Normalmente un Checkout Flow se asocia a un **Order Type**. Por ejemplo: ```plaintext Order Type Physical Order ↓ Checkout Flow Physical Checkout ``` Mientras otro Order Type podría utilizar: ```plaintext Order Type Digital Order ↓ Checkout Flow Digital Checkout ``` Esto permite que diferentes tipos de transacción tengan experiencias de compra diferentes. Por ejemplo: ```plaintext Physical Order Address ↓ Shipping ↓ Payment ↓ Review ``` Mientras: ```plaintext Digital Order Payment ↓ Review ``` No necesitamos pedir una dirección de envío cuando no existe ningún producto físico. --- ## 5. Podemos tener varios Checkout Flows Una instalación Commerce puede disponer de múltiples Checkout Flows. Por ejemplo: ```plaintext Checkout Flows ├── Default Checkout ├── B2B Checkout ├── Digital Products Checkout └── Subscription Checkout ``` El Order Type puede definir cuál utilizar por defecto. Commerce también dispone de un sistema de resolución que permite determinar dinámicamente qué Checkout Flow corresponde utilizar cuando un proyecto necesita lógica más avanzada. --- ## 6. Single-page frente a multi-page checkout Drupal Commerce permite construir checkout de una o varias páginas. ### Multi-page checkout ```plaintext Step 1 Customer Information ↓ Step 2 Shipping ↓ Step 3 Payment ↓ Step 4 Review ``` Ventajas posibles: - Divide formularios grandes - Reduce la cantidad de información visible simultáneamente - Permite organizar procesos complejos ### Single-page checkout ```plaintext Checkout Customer Information Shipping Payment Review ``` Puede funcionar mejor cuando el proceso es pequeño y queremos reducir la navegación entre páginas. No existe una respuesta universal. La elección depende del negocio, de la cantidad de información necesaria y de la experiencia que queremos ofrecer. --- ## 7. Qué es un Step Un **Step** representa una etapa dentro del Checkout Flow. Por ejemplo: ```plaintext Login Order Information Review Payment Complete ``` Podemos imaginar un checkout así: ```plaintext STEP Order Information │ ├── Contact Information ├── Billing Information ├── Shipping Information └── Coupon ``` Un Step actúa como contenedor de uno o varios Panes. --- ## 8. Qué es un Pane Un **Checkout Pane** es un componente que recopila o muestra una parte específica de la información durante el checkout. Por ejemplo: ```plaintext Contact Information Billing Information Shipping Information Payment Information Coupon Redemption Order Summary Review Completion Message ``` Podemos pensar: ```plaintext Checkout Flow ↓ Step ↓ Pane ↓ Información / interacción específica ``` --- ## 9. Steps contienen Panes Supongamos que tenemos: ```plaintext Step: Order Information ``` Dentro podemos tener: ```plaintext Contact Information Billing Information Shipping Information Coupon Redemption ``` Visualmente: ```plaintext Checkout Flow ┌─────────────────────────────┐ │ Step: Order Information │ │ │ │ Contact Information │ │ │ │ Billing Information │ │ │ │ Shipping Information │ │ │ │ Coupon │ └─────────────────────────────┘ ↓ ┌─────────────────────────────┐ │ Step: Review │ │ │ │ Review Pane │ │ Order Summary │ └─────────────────────────────┘ ``` Esto permite construir el checkout mediante componentes pequeños y reutilizables. --- ## 10. El constructor visual de Checkout Drupal Commerce incluye una interfaz administrativa para organizar los Checkout Panes. Conceptualmente podemos tener: ```plaintext ORDER INFORMATION Contact Information Billing Information Shipping Information Coupon REVIEW Review PAYMENT Payment Process COMPLETE Completion Message DISABLED Pane A Pane B ``` Los Panes pueden: - Moverse entre Steps - Reordenarse - Configurarse - Deshabilitarse Esto permite personalizar considerablemente el checkout sin desarrollar código. --- ## 11. Disabled Panes No todos los Panes disponibles tienen que utilizarse. Podemos mover un Pane a la sección: ```plaintext Disabled ``` Por ejemplo, una tienda digital podría no necesitar: ```plaintext Shipping Information ``` Mientras una tienda B2B podría no necesitar: ```plaintext Guest Checkout ``` La existencia de un Pane no implica que deba formar parte de nuestro proceso. --- ## 12. Contact Information Uno de los Panes habituales recopila la información de contacto del comprador. Por ejemplo: ```plaintext Email customer@example.com ``` El email puede utilizarse posteriormente para: - Confirmación del pedido - Notificaciones - Identificación del cliente - Creación de una cuenta Incluso cuando permitimos Guest Checkout necesitamos normalmente una forma de contactar al comprador. --- ## 13. Billing Information Commerce utiliza **Customer Profiles** para representar información del cliente como nombres y direcciones. El Order dispone de un Billing Profile. Conceptualmente: ```plaintext Order │ └── Billing Profile │ ├── Name ├── Company ├── Address └── Other fields ``` Durante checkout, el comprador puede introducir o seleccionar esta información. --- ## 14. Customer Profiles Los Profiles son entidades independientes. Esto permite reutilizar información entre diferentes Orders. Por ejemplo: ```plaintext Customer Profiles ├── Home │ └── Quito │ └── Office └── Guayaquil ``` Durante checkout el usuario podría seleccionar: ```plaintext Billing address: ○ Home ● Office ○ Add new address ``` Esto evita tener que escribir la información completa en cada compra. --- ## 15. Billing y Shipping son conceptos diferentes Un cliente puede tener: ```plaintext Billing Address ↓ Dirección utilizada para facturación ``` y: ```plaintext Shipping Address ↓ Dirección donde se entregará el producto ``` Pueden coincidir: ```plaintext Billing │ └── Main Street 10 Shipping │ └── Main Street 10 ``` o ser diferentes: ```plaintext Billing Company Headquarters Shipping Warehouse ``` Commerce permite manejar estos conceptos separadamente cuando Shipping está presente. --- ## 16. Shipping Information Pane Cuando utilizamos Commerce Shipping aparece información adicional durante el checkout. Conceptualmente: ```plaintext Shipping Information │ ├── Shipping Profile │ └── Shipping Method ``` El usuario podría introducir: ```plaintext Shipping Address Daniel Example Main Street 10 Berlin Germany ``` y seleccionar: ```plaintext Shipping Method ○ Standard Shipping 5 EUR ● Express Shipping 15 EUR ``` El método seleccionado puede generar posteriormente un Shipping Adjustment dentro del Order. --- ## 17. Payment Information Pane Cuando Commerce Payment está habilitado, el checkout puede presentar un **Payment Information Pane**. Por ejemplo: ```plaintext Payment Method ○ Credit Card ● PayPal ○ Bank Transfer ``` Este Pane puede estar relacionado también con la información de facturación necesaria para el Payment Gateway seleccionado. El Pane recopila la información necesaria para preparar el pago. Pero debemos recordar: ```plaintext Payment Information Pane ≠ Payment itself ``` El Pane forma parte de la experiencia del checkout. El Payment es una entidad comercial independiente. --- ## 18. Review Pane Antes de completar la compra normalmente resulta útil mostrar una etapa de revisión. Por ejemplo: ```plaintext REVIEW ORDER Products Laptop Pro 1 × 1,000 EUR Shipping Express Shipping 15 EUR Billing Daniel Example ... Payment Credit Card TOTAL 1,205 EUR [ Place order ] ``` El objetivo es permitir que el comprador confirme que la información es correcta antes de finalizar. --- ## 19. Order Summary Commerce puede mostrar un resumen del Order durante diferentes Steps. Por ejemplo: ```plaintext Your Order Laptop Pro 1 × 1000 EUR Mouse 2 × 50 EUR Promotion -100 EUR Shipping +10 EUR Tax +190 EUR Total 1200 EUR ``` Esto permite mantener visible el contexto comercial mientras el usuario introduce información. --- ## 20. Completion Message Después de completar el checkout podemos mostrar un mensaje de confirmación. Por ejemplo: ```plaintext Thank you for your order. Order number: 2026-00124 We have sent the confirmation to customer@example.com ``` Este mensaje pertenece al Checkout Flow. No debemos confundirlo con: - Order Workflow - Order confirmation email - Payment confirmation Son responsabilidades diferentes. --- ## 21. Guest Checkout Drupal Commerce puede permitir que usuarios anónimos completen una compra. Conceptualmente: ```plaintext Anonymous Visitor ↓ Cart ↓ Checkout ↓ Email + customer information ↓ Order placed ``` No es obligatorio crear una cuenta. Esto se conoce como: ```plaintext Guest Checkout ``` La posibilidad de permitir Guest Checkout puede configurarse por Checkout Flow. --- ## 22. Checkout con usuarios registrados Otra opción es exigir autenticación. ```plaintext Anonymous ↓ Login / Register ↓ Checkout ``` Esto puede tener sentido cuando: - El catálogo es privado - Tenemos pricing B2B - Necesitamos identificar al cliente - Existen contratos comerciales - Los pedidos requieren permisos específicos En un sitio B2C, en cambio, obligar al usuario a crear una cuenta puede ser innecesario. --- ## 23. Registro durante Checkout Commerce puede combinar checkout y registro. Por ejemplo: ```plaintext Visitor ↓ Checkout ↓ Create account ↓ Continue purchase ``` O podemos permitir Guest Checkout y gestionar posteriormente la creación de cuenta. La decisión debería basarse en la experiencia comercial que queremos ofrecer. --- ## 24. Checkout B2C Un checkout tradicional podría ser: ```plaintext Cart ↓ Contact Information ↓ Shipping Address ↓ Shipping Method ↓ Payment Information ↓ Review ↓ Place Order ↓ Complete ``` Este flujo funciona bien para muchos e-commerce tradicionales. --- ## 25. Checkout B2B Un checkout B2B puede ser muy diferente. Por ejemplo: ```plaintext Authenticated Distributor ↓ Company Information ↓ Purchase Order Number ↓ Delivery Address ↓ Requested Delivery Date ↓ Review ↓ Submit Order ``` El pago podría no ocurrir durante checkout. Quizás el cliente tenga condiciones: ```plaintext Payment Terms Net 30 days ``` Por tanto: ```plaintext Checkout ↓ Order placed ↓ Invoice generated ↓ Payment later ``` Commerce no obliga a que todas las compras utilicen una tarjeta de crédito durante checkout. --- ## 26. Checkout para productos digitales Un producto digital puede necesitar un flujo mucho más sencillo. ```plaintext Cart ↓ Contact Information ↓ Payment ↓ Review ↓ Complete ``` No necesitamos: ```plaintext Shipping Address Shipping Method Carrier ``` Esto puede justificar un Checkout Flow diferente. --- ## 27. Checkout para servicios Supongamos que vendemos una consultoría. Podríamos necesitar: ```plaintext Contact Information ↓ Company Information ↓ Project Details ↓ Preferred Date ↓ Payment ↓ Review ``` Aquí aparecen campos que no existen en un checkout tradicional. Podemos extender Commerce mediante Checkout Panes personalizados cuando el negocio lo requiere. --- ## 28. Checkout Panes personalizados Una de las fortalezas de Commerce es que los Panes son extensibles. Podemos crear un Pane personalizado para recopilar información específica. Por ejemplo: ```plaintext Project Information Project name [________________] Reference number [________________] Comments [________________] ``` O: ```plaintext Delivery Instructions □ Loading dock required Preferred delivery date [____________] Contact person [____________] ``` Este Pane puede guardar información en el Order o en otra entidad relacionada. --- ## 29. ¿Order Field o Checkout Pane? Estos conceptos no son alternativas directas. Un Field define dónde vive el dato. Un Checkout Pane define cómo interactuamos con ese dato durante checkout. Por ejemplo: ```plaintext Order Field field_purchase_order_number ``` y: ```plaintext Checkout Pane Purchase Order Information ↓ edita ↓ field_purchase_order_number ``` Podemos pensar: ```plaintext Field = almacenamiento Checkout Pane = interacción ``` Esta distinción es muy útil cuando desarrollamos funcionalidad personalizada. --- ## 30. Información del Order frente a información del Order Item Supongamos que queremos preguntar: > ¿Cuál es el número de referencia del cliente? Si aplica a toda la compra: ```plaintext Order Customer Reference ABC-2026-123 ``` Pero si queremos preguntar: > ¿Qué texto debe grabarse en este producto? eso pertenece a: ```plaintext Order Item Engraving: "Daniel" ``` El Checkout Pane o Add to Cart form puede recoger ambos tipos de información, pero debemos almacenar cada dato en la entidad correcta. --- ## 31. Información que ya conocemos antes del Checkout No todo debe preguntarse durante checkout. Podemos conocer previamente: ```plaintext Customer ↓ Saved Profiles Order ↓ Products Product Variation ↓ Weight Price SKU ``` El checkout debería pedir únicamente la información que todavía necesitamos para completar la transacción. Esto puede mejorar significativamente la experiencia del usuario. --- ## 32. No convertir Checkout en un formulario gigante Un error frecuente consiste en utilizar checkout para recopilar cualquier información imaginable. Por ejemplo: ```plaintext First name Last name Company Department Position Phone Mobile Fax Birthday Tax ID Company registration Marketing preferences Industry Company size ... ``` Antes de añadir cada campo debemos preguntarnos: > ¿Necesitamos realmente esta información para completar la compra? Si no es necesaria, quizá pertenezca a otro proceso. Un checkout más sencillo suele ser más fácil de utilizar y mantener. --- ## 33. Dependencias entre Panes Algunos Panes necesitan información producida por otros. Por ejemplo: ```plaintext Shipping Address ↓ determina ↓ Available Shipping Methods ``` También: ```plaintext Billing Country ↓ puede afectar ↓ Taxes ``` O: ```plaintext Payment Gateway ↓ puede requerir ↓ Billing Information ``` Por eso el orden de los Panes puede tener consecuencias funcionales. --- ## 34. No todos los Panes pueden moverse arbitrariamente Aunque el constructor permite mucha flexibilidad, debemos comprender las dependencias existentes. Un Pane puede necesitar que cierta información esté disponible previamente. Por ejemplo: ```plaintext Shipping Method ↓ necesita conocer ↓ Shipping Address ``` o un proveedor de pagos específico puede requerir una determinada estructura de Checkout Flow. La interfaz permite reorganizar componentes, pero la arquitectura del negocio continúa imponiendo restricciones. --- ## 35. Checkout y validación Cada Step puede necesitar validar información antes de permitir al usuario continuar. Por ejemplo: ```plaintext Shipping Information Country Germany Postal Code [empty] ``` El usuario no debería avanzar si Postal Code es obligatorio. También podemos tener validaciones comerciales. ```plaintext Requested delivery date ↓ must be ↓ at least 3 business days after order date ``` Los Panes personalizados pueden implementar este tipo de lógica. --- ## 36. Checkout y recalculación del Order La información proporcionada durante checkout puede modificar el cálculo del pedido. Por ejemplo: ```plaintext Shipping Country ↓ Tax calculation Shipping Method ↓ Shipping adjustment Coupon ↓ Promotion adjustment ``` Por tanto el total puede evolucionar durante el checkout. ```plaintext Cart Subtotal 100 EUR After coupon Subtotal 100 EUR Promotion -10 EUR After shipping Subtotal 100 EUR Promotion -10 EUR Shipping +8 EUR After tax Subtotal 100 EUR Promotion -10 EUR Shipping +8 EUR Tax +17 EUR Total 115 EUR ``` El checkout proporciona progresivamente el contexto necesario para calcular el total correcto. --- ## 37. Checkout y Place Order En algún momento el usuario realiza la acción definitiva: ```plaintext Place Order ``` Conceptualmente: ```plaintext Order State: Draft Cart: TRUE ↓ Checkout completed ↓ Place transition ↓ Order State: Fulfillment / Validation / Completed según workflow Cart: FALSE ``` Esta es la conexión principal entre el Checkout Flow y el Order Workflow. El checkout prepara la transacción. La transición de placement hace que el Order entre formalmente en su ciclo operativo. --- ## 38. Qué ocurre después de Checkout Una vez completado el checkout pueden ocurrir diferentes procesos. ```plaintext Checkout Complete ↓ Order placed ↓ Order number generated ↓ Confirmation email ↓ ERP integration ↓ Stock processing ↓ Fulfillment ``` No todo esto pertenece al Checkout Flow. El checkout termina cuando ha cumplido su objetivo: recopilar la información necesaria y permitir completar la compra. --- ## 39. El Checkout Flow no debería gestionar todo el negocio Es tentador colocar lógica en checkout porque es el punto donde tenemos al cliente delante. Pero debemos separar responsabilidades. Por ejemplo: ```plaintext Checkout ↓ collect information Order Workflow ↓ manage transaction state Payment ↓ manage money ERP integration ↓ manage external synchronization Fulfillment ↓ manage delivery ``` Esta separación produce sistemas más mantenibles. --- ## 40. Diseñar Checkout desde los requerimientos Antes de configurar un Checkout Flow deberíamos escribir primero qué necesita el negocio. Por ejemplo: ```plaintext Customer must: 1. Identify themselves 2. Select billing address 3. Select shipping address 4. Choose shipping method 5. Enter purchase order number 6. Choose payment method 7. Review the order 8. Confirm purchase ``` Después podemos traducirlo: ```plaintext Login Pane Billing Information Pane Shipping Information Pane Custom PO Number Pane Payment Information Pane Review Pane Completion Pane ``` Solamente entonces comenzamos a configurar Commerce. --- ## 41. Ejemplo completo B2C Supongamos una tienda de ropa. El proceso podría ser: ```plaintext CART Classic T-Shirt Black / M 2 × 25 EUR ↓ CHECKOUT STEP 1 Login Login or continue as guest STEP 2 Order Information Contact Information Shipping Information Shipping Method Payment Information Coupon STEP 3 Review Products Addresses Shipping Payment Totals STEP 4 Payment Process payment STEP 5 Complete Order confirmation ``` Mientras el Order puede evolucionar: ```plaintext Draft ↓ Fulfillment ↓ Completed ``` y el Payment: ```plaintext New ↓ Completed ``` Tres procesos relacionados, pero independientes. --- ## 42. Ejemplo completo B2B Supongamos ahora una empresa industrial. El cliente debe estar autenticado. Podríamos diseñar: ```plaintext CHECKOUT STEP 1 Company Information Billing profile Delivery profile STEP 2 Commercial Information Purchase Order Number Cost Center Requested Delivery Date Internal Reference STEP 3 Shipping Delivery Method STEP 4 Review Products Prices Taxes Commercial references Delivery information STEP 5 Complete Order submitted for approval ``` Observe que quizá no exista Payment durante checkout. El Order Workflow podría ser: ```plaintext Draft ↓ Review ↓ Approved ↓ Fulfillment ↓ Completed ``` Esto demuestra por qué Checkout y Workflow deben diseñarse independientemente. --- ## 43. Ejemplo de decisiones de arquitectura Supongamos que el cliente solicita: > Durante checkout necesitamos que el comprador escriba el número de orden de compra de su empresa. Podemos razonar: ```plaintext ¿Pertenece a toda la transacción? ↓ Sí Entonces: Order Field field_purchase_order_number ¿Dónde lo introduce el usuario? ↓ Checkout Entonces: Checkout Pane personalizado o componente apropiado ``` Otra solicitud: > El usuario debe escribir un texto diferente para cada camiseta. Ahora: ```plaintext ¿Pertenece a toda la transacción? ↓ No ¿Pertenece a una línea específica? ↓ Sí Entonces: Order Item Field ``` Este tipo de razonamiento evita colocar datos en entidades incorrectas. --- ## 44. Preguntas para el Discovery de Checkout Antes de configurar el Checkout Flow deberíamos responder: ### Usuarios - ¿Permitimos Guest Checkout? - ¿Es obligatorio iniciar sesión? - ¿Permitimos registro durante checkout? ### Customer Information - ¿Qué datos del comprador necesitamos? - ¿Necesitamos empresa? - ¿Necesitamos Tax ID? - ¿Necesitamos teléfono? ### Billing - ¿Necesitamos Billing Profile? - ¿Puede reutilizar direcciones guardadas? ### Shipping - ¿Existen productos físicos? - ¿Necesitamos Shipping Address? - ¿Cuándo se elige Shipping Method? ### Payment - ¿Se paga durante checkout? - ¿Qué Payment Gateways existen? - ¿Necesitamos Billing Information específica? ### Commercial Information - ¿Necesitamos Purchase Order Number? - ¿Customer Reference? - ¿Delivery instructions? - ¿Requested date? ### Review - ¿Qué debe confirmar el usuario? - ¿Necesitamos aceptar Terms and Conditions? ### Completion - ¿Qué información mostramos después de comprar? - ¿Order number? - ¿Payment information? - ¿Next steps? --- ## 45. Una matriz para decidir dónde implementar algo Podemos utilizar esta guía conceptual: ```plaintext ¿Es un dato que debemos almacenar? ↓ Field ¿Debemos pedirlo durante checkout? ↓ Checkout Pane ¿Representa una página o fase de la experiencia? ↓ Checkout Step ¿Define todo el proceso de checkout? ↓ Checkout Flow ¿Representa el estado comercial del pedido? ↓ Order Workflow ¿Representa el estado del dinero? ↓ Payment Workflow ``` --- ## 46. Modelo mental completo Podemos conectar todo lo estudiado hasta ahora. ```plaintext PRODUCT ↓ VARIATION ↓ ADD TO CART ↓ ORDER ITEM ↓ ORDER ↓ CART / DRAFT ↓ CHECKOUT FLOW │ ├── Step │ ├── Pane │ ├── Pane │ └── Pane │ ├── Step │ ├── Pane │ └── Pane │ └── Complete ↓ PLACE ORDER ↓ ORDER WORKFLOW ↓ Fulfillment ↓ Completed ``` Durante checkout pueden intervenir además: ```plaintext Profiles Payments Shipping Taxes Promotions Adjustments ``` Pero cada concepto mantiene su propia responsabilidad. --- ## 47. La regla de las cinco preguntas Podemos resumir el diseño de checkout con cinco preguntas: ```plaintext 1. ¿Qué información necesitamos del comprador? ↓ Checkout Panes 2. ¿Cómo queremos agruparla? ↓ Checkout Steps 3. ¿Cuál es el recorrido completo? ↓ Checkout Flow 4. ¿Dónde debe almacenarse cada dato? ↓ Order / Order Item / Profile / Payment 5. ¿Qué sucede cuando termina? ↓ Place Order + Order Workflow ``` --- ## Conclusión Drupal Commerce trata el checkout como una experiencia configurable y extensible alrededor del Order. Podemos resumir sus componentes principales: ```plaintext Checkout Flow = proceso completo de checkout Step = etapa del proceso Checkout Pane = componente que recopila o presenta información Customer Profile = información reutilizable del cliente Order = transacción que estamos preparando Place Order = punto donde la compra entra en su ciclo operativo ``` La separación más importante que debemos mantener es: ```plaintext Checkout Flow = experiencia para realizar la compra Order Workflow = ciclo de vida de la transacción Payment Workflow = ciclo de vida del dinero Shipping / Fulfillment = proceso de entrega ``` Cuando mantenemos estas responsabilidades separadas podemos adaptar Commerce tanto a un checkout B2C sencillo como a procesos B2B complejos sin convertir el sistema en una colección de excepciones. En el siguiente artículo estudiaremos una de las partes que aparece dentro del checkout pero que tiene una arquitectura propia: **Payments en Drupal Commerce**. Veremos Payment Gateways, Payment Methods, Payments, estados, autorización frente a captura, pagos on-site y off-site, refunds y cómo relacionar correctamente el estado del dinero con el estado del Order. ## Course navigation: Drupal Commerce Chapter 7 of 11 - [ ← Anterior Orders, Order Items y Workflows en Drupal Commerce ](/es/orders-order-items-y-workflows-en-drupal-commerce) - [ Siguiente → Payments en Drupal Commerce: Gateways, Payment Methods, autorización, captura y reembolsos ](/es/payments-en-drupal-commerce-gateways-payment-methods-autorizacion-captura-y-reembolsos) [↑ Course index](/es/node/43)