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:
Checkout Flow
↓
Steps
↓
PanesComprender 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:
Checkout Flow
Login
↓
Order Information
↓
Review
↓
Payment
↓
CompleteOtro negocio podría necesitar un proceso mucho más sencillo:
Checkout Flow
Payment
↓
CompleteMientras que un proyecto B2B podría tener:
Checkout Flow
Company Information
↓
Billing Information
↓
Purchase Order
↓
Review
↓
CompleteEl 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:
CHECKOUT FLOW
Login
↓
Address
↓
Shipping
↓
Payment
↓
Review
↓
CompleteMientras:
ORDER WORKFLOW
Draft
↓
Fulfillment
↓
CompletedPodemos resumir:
Checkout Flow
= qué pasos sigue el comprador
Order Workflow
= en qué estado está la transacciónAmbos 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:
Checkout Flow
Payment Information
↓
Review
↓
CompleteMientras el Payment puede encontrarse en:
New
↓
Authorization
↓
CompletedO posteriormente:
Completed
↓
Partially Refunded
↓
RefundedPodemos pensar:
Checkout Flow
= experiencia del comprador
Order Workflow
= ciclo de vida del pedido
Payment Workflow
= ciclo de vida del dinero4. Checkout Flow y Order Type
Normalmente un Checkout Flow se asocia a un Order Type.
Por ejemplo:
Order Type
Physical Order
↓
Checkout Flow
Physical CheckoutMientras otro Order Type podría utilizar:
Order Type
Digital Order
↓
Checkout Flow
Digital CheckoutEsto permite que diferentes tipos de transacción tengan experiencias de compra diferentes.
Por ejemplo:
Physical Order
Address
↓
Shipping
↓
Payment
↓
ReviewMientras:
Digital Order
Payment
↓
ReviewNo 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:
Checkout Flows
├── Default Checkout
├── B2B Checkout
├── Digital Products Checkout
└── Subscription CheckoutEl 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
Step 1
Customer Information
↓
Step 2
Shipping
↓
Step 3
Payment
↓
Step 4
ReviewVentajas posibles:
- Divide formularios grandes
- Reduce la cantidad de información visible simultáneamente
- Permite organizar procesos complejos
Single-page checkout
Checkout
Customer Information
Shipping
Payment
ReviewPuede 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:
Login
Order Information
Review
Payment
CompletePodemos imaginar un checkout así:
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:
Contact Information
Billing Information
Shipping Information
Payment Information
Coupon Redemption
Order Summary
Review
Completion MessagePodemos pensar:
Checkout Flow
↓
Step
↓
Pane
↓
Información / interacción específica9. Steps contienen Panes
Supongamos que tenemos:
Step:
Order InformationDentro podemos tener:
Contact Information
Billing Information
Shipping Information
Coupon RedemptionVisualmente:
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:
ORDER INFORMATION
Contact Information
Billing Information
Shipping Information
Coupon
REVIEW
Review
PAYMENT
Payment Process
COMPLETE
Completion Message
DISABLED
Pane A
Pane BLos 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:
DisabledPor ejemplo, una tienda digital podría no necesitar:
Shipping InformationMientras una tienda B2B podría no necesitar:
Guest CheckoutLa 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:
Email
customer@example.comEl 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:
Order
│
└── Billing Profile
│
├── Name
├── Company
├── Address
└── Other fieldsDurante 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:
Customer
Profiles
├── Home
│ └── Quito
│
└── Office
└── GuayaquilDurante checkout el usuario podría seleccionar:
Billing address:
○ Home
● Office
○ Add new addressEsto evita tener que escribir la información completa en cada compra.
15. Billing y Shipping son conceptos diferentes
Un cliente puede tener:
Billing Address
↓
Dirección utilizada para facturacióny:
Shipping Address
↓
Dirección donde se entregará el productoPueden coincidir:
Billing
│
└── Main Street 10
Shipping
│
└── Main Street 10o ser diferentes:
Billing
Company Headquarters
Shipping
WarehouseCommerce 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:
Shipping Information
│
├── Shipping Profile
│
└── Shipping MethodEl usuario podría introducir:
Shipping Address
Daniel Example
Main Street 10
Berlin
Germanyy seleccionar:
Shipping Method
○ Standard Shipping 5 EUR
● Express Shipping 15 EUREl 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:
Payment Method
○ Credit Card
● PayPal
○ Bank TransferEste 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:
Payment Information Pane
≠
Payment itselfEl 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:
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:
Your Order
Laptop Pro
1 × 1000 EUR
Mouse
2 × 50 EUR
Promotion
-100 EUR
Shipping
+10 EUR
Tax
+190 EUR
Total
1200 EUREsto 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:
Thank you for your order.
Order number:
2026-00124
We have sent the confirmation
to customer@example.comEste 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:
Anonymous Visitor
↓
Cart
↓
Checkout
↓
Email + customer information
↓
Order placedNo es obligatorio crear una cuenta.
Esto se conoce como:
Guest CheckoutLa posibilidad de permitir Guest Checkout puede configurarse por Checkout Flow.
22. Checkout con usuarios registrados
Otra opción es exigir autenticación.
Anonymous
↓
Login / Register
↓
CheckoutEsto 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:
Visitor
↓
Checkout
↓
Create account
↓
Continue purchaseO 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:
Cart
↓
Contact Information
↓
Shipping Address
↓
Shipping Method
↓
Payment Information
↓
Review
↓
Place Order
↓
CompleteEste flujo funciona bien para muchos e-commerce tradicionales.
25. Checkout B2B
Un checkout B2B puede ser muy diferente.
Por ejemplo:
Authenticated Distributor
↓
Company Information
↓
Purchase Order Number
↓
Delivery Address
↓
Requested Delivery Date
↓
Review
↓
Submit OrderEl pago podría no ocurrir durante checkout.
Quizás el cliente tenga condiciones:
Payment Terms
Net 30 daysPor tanto:
Checkout
↓
Order placed
↓
Invoice generated
↓
Payment laterCommerce 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.
Cart
↓
Contact Information
↓
Payment
↓
Review
↓
CompleteNo necesitamos:
Shipping Address
Shipping Method
CarrierEsto puede justificar un Checkout Flow diferente.
27. Checkout para servicios
Supongamos que vendemos una consultoría.
Podríamos necesitar:
Contact Information
↓
Company Information
↓
Project Details
↓
Preferred Date
↓
Payment
↓
ReviewAquí 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:
Project Information
Project name
[________________]
Reference number
[________________]
Comments
[________________]O:
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:
Order Field
field_purchase_order_numbery:
Checkout Pane
Purchase Order Information
↓
edita
↓
field_purchase_order_numberPodemos pensar:
Field
= almacenamiento
Checkout Pane
= interacciónEsta 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:
Order
Customer Reference
ABC-2026-123Pero si queremos preguntar:
¿Qué texto debe grabarse en este producto?
eso pertenece a:
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:
Customer
↓
Saved Profiles
Order
↓
Products
Product Variation
↓
Weight
Price
SKUEl 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:
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:
Shipping Address
↓
determina
↓
Available Shipping MethodsTambién:
Billing Country
↓
puede afectar
↓
TaxesO:
Payment Gateway
↓
puede requerir
↓
Billing InformationPor 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:
Shipping Method
↓
necesita conocer
↓
Shipping Addresso 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:
Shipping Information
Country
Germany
Postal Code
[empty]El usuario no debería avanzar si Postal Code es obligatorio.
También podemos tener validaciones comerciales.
Requested delivery date
↓
must be
↓
at least 3 business days
after order dateLos 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:
Shipping Country
↓
Tax calculation
Shipping Method
↓
Shipping adjustment
Coupon
↓
Promotion adjustmentPor tanto el total puede evolucionar durante el checkout.
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 EUREl 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:
Place OrderConceptualmente:
Order
State:
Draft
Cart:
TRUE
↓
Checkout completed
↓
Place transition
↓
Order
State:
Fulfillment / Validation / Completed
según workflow
Cart:
FALSEEsta 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.
Checkout Complete
↓
Order placed
↓
Order number generated
↓
Confirmation email
↓
ERP integration
↓
Stock processing
↓
FulfillmentNo 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:
Checkout
↓
collect information
Order Workflow
↓
manage transaction state
Payment
↓
manage money
ERP integration
↓
manage external synchronization
Fulfillment
↓
manage deliveryEsta 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:
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 purchaseDespués podemos traducirlo:
Login Pane
Billing Information Pane
Shipping Information Pane
Custom PO Number Pane
Payment Information Pane
Review Pane
Completion PaneSolamente entonces comenzamos a configurar Commerce.
41. Ejemplo completo B2C
Supongamos una tienda de ropa.
El proceso podría ser:
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 confirmationMientras el Order puede evolucionar:
Draft
↓
Fulfillment
↓
Completedy el Payment:
New
↓
CompletedTres procesos relacionados, pero independientes.
42. Ejemplo completo B2B
Supongamos ahora una empresa industrial.
El cliente debe estar autenticado.
Podríamos diseñar:
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 approvalObserve que quizá no exista Payment durante checkout.
El Order Workflow podría ser:
Draft
↓
Review
↓
Approved
↓
Fulfillment
↓
CompletedEsto 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:
¿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 apropiadoOtra solicitud:
El usuario debe escribir un texto diferente para cada camiseta.
Ahora:
¿Pertenece a toda la transacción?
↓
No
¿Pertenece a una línea específica?
↓
Sí
Entonces:
Order Item FieldEste 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:
¿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 Workflow46. Modelo mental completo
Podemos conectar todo lo estudiado hasta ahora.
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
↓
CompletedDurante checkout pueden intervenir además:
Profiles
Payments
Shipping
Taxes
Promotions
AdjustmentsPero cada concepto mantiene su propia responsabilidad.
47. La regla de las cinco preguntas
Podemos resumir el diseño de checkout con cinco preguntas:
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 WorkflowConclusión
Drupal Commerce trata el checkout como una experiencia configurable y extensible alrededor del Order.
Podemos resumir sus componentes principales:
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 operativoLa separación más importante que debemos mantener es:
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 entregaCuando 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.