# Payments en Drupal Commerce: Gateways, Payment Methods, autorización, captura y reembolsos Enviado por [danieluxury](/es/user/1 "Ver perfil del usuario.") el Vie, 25 Sep 2026 - 11:55 Después de estudiar el Checkout podemos entrar en una de las partes más importantes de cualquier plataforma de comercio electrónico: **los pagos**. Cuando un cliente pulsa *Place order*, podemos tener la impresión de que ocurre una única acción: ```plaintext Cliente ↓ Paga ↓ Pedido completado ``` En realidad pueden intervenir varios conceptos y procesos diferentes. Drupal Commerce distingue claramente entre: - Payment Provider - Payment Gateway - Payment Method - Payment - Payment Workflow Además, una transacción puede pasar por operaciones como: ```plaintext Authorization Capture Void Refund ``` Comprender estas diferencias es fundamental para configurar correctamente Stripe, PayPal, Authorize.Net u otro proveedor, y también para diseñar procesos B2B, pagos manuales o integraciones personalizadas. --- ## 1. Empezar separando los conceptos Podemos comenzar con una visión general: ```plaintext Customer ↓ Payment Method ↓ Payment Gateway ↓ Payment Provider ↓ Financial transaction ``` Mientras Drupal Commerce mantiene localmente: ```plaintext Order ↓ Payment ↓ Gateway ↓ Remote transaction ``` No debemos confundir estas piezas. --- ## 2. Payment Provider El **Payment Provider** es el servicio externo que procesa realmente una transacción. Algunos ejemplos habituales son: ```plaintext Stripe PayPal Authorize.Net Adyen Braintree ``` Podemos pensar: ```plaintext Drupal Commerce ↓ Payment Provider ↓ Bank / Card Network ↓ Customer account ``` Drupal Commerce no sustituye al proveedor de pagos. Commerce necesita una integración que permita comunicarse con él. Esa integración aparece mediante un **Payment Gateway**. --- ## 3. Payment Gateway Un **Payment Gateway** representa dentro de Commerce una configuración utilizada para comunicarse con un sistema de pagos. Por ejemplo: ```plaintext Payment Gateway Stripe Production Provider: Stripe Mode: Live Currency: EUR ``` El Gateway contiene o utiliza la configuración necesaria para conectar Commerce con el proveedor. Conceptualmente: ```plaintext Drupal Commerce ↓ Payment Gateway ↓ Stripe API ↓ Stripe ``` El Gateway actúa como puente entre ambos sistemas. --- ## 4. Payment Gateway no es Payment Method Esta distinción es fundamental. Supongamos que configuramos: ```plaintext Gateway: Stripe ``` El cliente puede pagar mediante: ```plaintext Visa **** 4242 ``` Stripe es el Gateway o proveedor de la integración. La tarjeta es el Payment Method. ```plaintext PAYMENT GATEWAY Stripe PAYMENT METHOD Visa **** 4242 Expires 08/29 ``` Por tanto: ```plaintext Payment Gateway = cómo Commerce procesa el pago Payment Method = con qué paga el cliente ``` --- ## 5. Payment Method Un **Payment Method** representa información local sobre un método de pago del cliente gestionado por un proveedor. Por ejemplo: ```plaintext Customer Daniel Example Payment Methods ├── Visa **** 4242 └── Mastercard **** 1234 ``` El Payment Method puede contener información segura para identificar el método sin almacenar directamente datos sensibles como el número completo de una tarjeta. Conceptualmente: ```plaintext Drupal Commerce Payment Method Visa **** 4242 Remote reference pm_xxxxxxxxx ↓ Payment Provider Actual payment instrument ``` La información sensible puede permanecer gestionada por el proveedor. --- ## 6. Payment Methods reutilizables En determinados gateways on-site el cliente puede guardar un Payment Method. Por ejemplo: ```plaintext Customer account Saved payment methods ├── Visa **** 4242 └── Mastercard **** 1234 ``` Durante una nueva compra: ```plaintext Choose payment method ● Visa **** 4242 ○ Mastercard **** 1234 ○ Add new payment method ``` Esto permite reutilizar el método en pedidos posteriores. --- ## 7. Payment Method no significa necesariamente tarjeta Una tarjeta de crédito es solamente un ejemplo. Dependiendo del proveedor podemos tener métodos como: ```plaintext Credit Card PayPal Bank Account Wallet Provider-specific payment method ``` El Gateway determina qué tipos de Payment Methods soporta. --- ## 8. Payment Un **Payment** representa una transacción de pago asociada a un Order. Por ejemplo: ```plaintext Order #1001 Total: 120 EUR Payment Amount: 120 EUR Gateway: Stripe State: Completed ``` Podemos resumir: ```plaintext Payment Gateway = mecanismo para procesar Payment Method = instrumento del cliente Payment = transacción monetaria ``` Esta es probablemente la distinción más importante del artículo. --- ## 9. La relación completa Podemos visualizarla así: ```plaintext CUSTOMER │ ▼ PAYMENT METHOD Visa **** 4242 │ ▼ PAYMENT GATEWAY Stripe │ ▼ PAYMENT PROVIDER Stripe │ ▼ REMOTE TRANSACTION Mientras en Commerce: ORDER │ ▼ PAYMENT │ ├── Amount ├── State ├── Gateway └── Remote ID ``` --- ## 10. Un Order puede tener varios Payments No debemos asumir que: ```plaintext 1 Order = 1 Payment ``` Puede ocurrir: ```plaintext Order Total 1000 EUR Payment #1 Credit Card 600 EUR Payment #2 Bank Transfer 400 EUR ``` O: ```plaintext Order 100 EUR Initial Payment 100 EUR Refund -20 EUR ``` Por eso Commerce mantiene Payments como entidades independientes relacionadas con el Order. --- ## 11. Total del Order frente a Amount Paid El Order puede tener: ```plaintext Order Total 100 EUR ``` mientras solamente hemos recibido: ```plaintext Payments 50 EUR ``` Entonces conceptualmente: ```plaintext Order Total 100 EUR Total Paid 50 EUR Balance 50 EUR ``` Commerce puede calcular cuánto se ha pagado a partir de los Payments relacionados con el Order. Esto resulta especialmente importante para: - Pagos parciales - Pagos manuales - B2B - Capturas parciales - Reembolsos --- ## 12. Payment State Al igual que los Orders, los Payments tienen su propio estado. Podemos encontrar conceptualmente estados como: ```plaintext New Authorization Completed Partially Refunded Refunded ``` El estado describe la situación financiera de esa transacción. Esto confirma una idea que ya vimos anteriormente: ```plaintext Order State ≠ Payment State ``` --- ## 13. Order Workflow frente a Payment Workflow Supongamos: ```plaintext Order State: Fulfillment ``` Mientras: ```plaintext Payment State: Completed ``` Esto significa: ```plaintext El dinero fue recibido pero el producto todavía debe entregarse. ``` Otro escenario: ```plaintext Order State: Validation Payment State: Authorization ``` Esto puede significar: ```plaintext El dinero está autorizado pero todavía no ha sido capturado. ``` Ambos procesos deben mantenerse separados. --- ## 14. On-site Payment Gateway En un Gateway **on-site**, el proceso de pago se integra directamente con el checkout del sitio. Conceptualmente: ```plaintext Drupal Checkout Credit Card [____________] Expiry [____] CVV [___] ↓ Payment Provider API ``` Sin embargo, esto no significa necesariamente que Drupal almacene los datos sensibles de la tarjeta. Los proveedores modernos suelen utilizar técnicas como: - Tokenization - Hosted fields - JavaScript SDKs - Payment tokens Drupal puede recibir solamente una referencia segura al Payment Method. --- ## 15. Off-site Payment Gateway En un Gateway **off-site**, el usuario abandona temporalmente el checkout para completar el pago en otro sistema. Por ejemplo: ```plaintext Drupal Commerce ↓ Checkout ↓ Redirect ↓ Payment Provider ↓ Customer pays ↓ Redirect back ↓ Drupal Commerce ``` Un ejemplo conceptual típico es: ```plaintext Pay with PayPal ↓ paypal.com ↓ Approve payment ↓ Return to store ``` --- ## 16. On-site frente a Off-site Podemos resumir: ```plaintext ON-SITE Customer ↓ Drupal Checkout ↓ Provider API OFF-SITE Customer ↓ Drupal Checkout ↓ Provider Website ↓ Drupal Commerce ``` La experiencia y los requisitos técnicos son diferentes. --- ## 17. Manual Payment Gateway No todos los pagos necesitan una API externa. Podemos tener métodos manuales como: ```plaintext Bank Transfer Cash Check Invoice Cash on Delivery ``` Por ejemplo: ```plaintext Order placed ↓ Customer receives bank details ↓ Customer transfers money ↓ Administrator confirms payment ↓ Payment completed ``` Esto es especialmente útil en ciertos proyectos B2B. --- ## 18. Autorizar frente a cobrar Cuando trabajamos con tarjetas aparece una diferencia muy importante: ```plaintext Authorization ≠ Capture ``` Podemos pensar en una autorización como: > Confirmar que el importe puede cobrarse y reservar esa capacidad de pago. Mientras la captura representa: > Solicitar realmente el cobro del importe previamente autorizado. --- ## 19. Authorize and Capture El flujo más sencillo es realizar ambas operaciones inmediatamente. ```plaintext Customer pays ↓ Authorize ↓ Capture ↓ Payment completed ``` Desde el punto de vista del usuario parece una única operación. Por ejemplo: ```plaintext Order 100 EUR Customer clicks Pay ↓ Authorization 100 EUR ↓ Capture 100 EUR ↓ Payment Completed ``` Este modelo es habitual cuando queremos cobrar inmediatamente. --- ## 20. Authorize Only También podemos autorizar primero y capturar posteriormente. ```plaintext Checkout Order: 100 EUR ↓ Authorization: 100 EUR ↓ Order processing ↓ Capture: 100 EUR ↓ Completed Payment ``` Esto puede ser útil cuando existe un intervalo entre realizar el pedido y confirmar que realmente podremos cumplirlo. --- ## 21. Ejemplo de autorización y captura Supongamos que vendemos un producto físico. ```plaintext Customer places order ↓ Authorize 500 EUR ↓ Check inventory ↓ Prepare shipment ↓ Capture 500 EUR ↓ Ship ``` Así podemos evitar cobrar definitivamente antes de saber que podremos entregar el producto. --- ## 22. Payment Authorization State Después de autorizar: ```plaintext Payment Amount: 500 EUR State: Authorization ``` Posteriormente: ```plaintext Capture ↓ Payment State: Completed ``` El Payment cambia de estado conforme evoluciona la transacción financiera. --- ## 23. Capture La operación **Capture** solicita al proveedor completar el cobro de un Payment previamente autorizado. Conceptualmente: ```plaintext Payment State: Authorization Amount: 500 EUR ↓ Capture ↓ State: Completed ``` Dependiendo del proveedor puede existir también captura parcial. --- ## 24. Partial Capture Supongamos: ```plaintext Authorization 500 EUR ``` pero solamente podemos enviar parte del pedido. El Gateway podría permitir: ```plaintext Capture 300 EUR ``` Este tipo de proceso depende de las capacidades del proveedor y de la integración Commerce utilizada. No debemos asumir que todos los Gateways soportan las mismas operaciones. --- ## 25. Void Una autorización que todavía no ha sido capturada puede, cuando el proveedor lo permite, ser anulada mediante **Void**. ```plaintext Authorization 500 EUR ↓ Order canceled ↓ Void authorization ``` Conceptualmente estamos diciendo: > No vamos a utilizar esta autorización para realizar el cobro. --- ## 26. Void frente a Refund Esta diferencia es muy importante. ```plaintext VOID Authorization exists ↓ Money not captured ↓ Cancel authorization ``` Mientras: ```plaintext REFUND Money already captured ↓ Return money ``` Por tanto: ```plaintext Before capture ↓ Void After capture ↓ Refund ``` La operación exacta dependerá siempre de las capacidades del proveedor. --- ## 27. Refund Cuando un Payment ya fue completado podemos necesitar devolver dinero. Por ejemplo: ```plaintext Payment 100 EUR Completed ↓ Refund 100 EUR ↓ Payment Refunded ``` El Refund representa una operación financiera sobre un Payment existente. --- ## 28. Partial Refund No todos los reembolsos necesitan devolver el importe completo. Por ejemplo: ```plaintext Payment 100 EUR Completed ↓ Refund 25 EUR ↓ Payment Partially Refunded ``` Posteriormente podríamos devolver el resto. ```plaintext Additional Refund 75 EUR ↓ Payment Refunded ``` --- ## 29. Cancelar un Order no devuelve automáticamente el dinero conceptualmente Esta separación merece especial atención. Podemos hacer: ```plaintext Order ↓ Cancel ↓ Canceled ``` Pero si el cliente ya pagó: ```plaintext Payment ↓ Still Completed ``` Necesitamos definir qué debe ocurrir financieramente. Por ejemplo: ```plaintext Cancel Order ↓ Refund Payment ↓ Release Stock ↓ Notify ERP ``` Estas son operaciones relacionadas, pero conceptualmente independientes. --- ## 30. Refund no significa necesariamente Return Otro concepto diferente es la devolución física del producto. Podemos tener: ```plaintext Customer returns product ↓ Warehouse receives item ↓ Return approved ↓ Refund payment ``` Pero: ```plaintext Return ≠ Refund ``` Return pertenece al proceso logístico/comercial. Refund pertenece al proceso financiero. Un sistema avanzado puede necesitar modelar ambos explícitamente. --- ## 31. El Payment Gateway define sus capacidades No todos los Gateways soportan: ```plaintext Authorization Capture Partial Capture Void Refund Partial Refund Stored Payment Methods ``` Por ejemplo, un Gateway puede soportar: ```plaintext Authorize Capture Refund ``` mientras otro solamente: ```plaintext Immediate payment ``` Por eso seleccionar un proveedor de pagos requiere analizar primero los procesos del negocio. --- ## 32. Antes de elegir Stripe, PayPal u otro proveedor No deberíamos comenzar preguntando: > ¿Qué módulo de Stripe instalamos? Primero deberíamos responder: - ¿Queremos cobrar inmediatamente? - ¿Necesitamos autorización y captura posterior? - ¿Necesitamos pagos recurrentes? - ¿Necesitamos guardar Payment Methods? - ¿Necesitamos partial refunds? - ¿Qué monedas utilizamos? - ¿En qué países operamos? - ¿Qué métodos esperan nuestros clientes? Después podemos evaluar qué proveedor y módulo satisface esos requisitos. --- ## 33. Test Mode y Live Mode Los Gateways suelen tener un entorno de prueba y otro de producción. Conceptualmente: ```plaintext TEST Drupal ↓ Payment Gateway ↓ Provider Sandbox ``` y: ```plaintext LIVE Drupal ↓ Payment Gateway ↓ Provider Production ``` Durante desarrollo debemos utilizar credenciales de prueba. Los pagos no deberían convertirse accidentalmente en transacciones reales. --- ## 34. Configuración y secretos Los Payment Gateways suelen requerir datos como: ```plaintext Public Key Secret Key Merchant ID Client ID Client Secret Webhook Secret ``` No todos estos valores deberían tratarse como configuración pública exportable. Debemos distinguir entre: ```plaintext Commerce configuration ↓ Config Credentials / secrets ↓ Environment-specific secret management ``` Esto es especialmente importante cuando trabajamos con repositorios Git y varios entornos. --- ## 35. Development, Staging y Production Podemos tener: ```plaintext Development Stripe Test Test credentials Staging Stripe Test Different test credentials Production Stripe Live Production credentials ``` El modelo de despliegue debe permitir compartir la configuración funcional sin exponer credenciales sensibles. --- ## 36. Webhooks y notificaciones asíncronas No siempre conocemos el resultado definitivo de un pago inmediatamente. Por ejemplo: ```plaintext Customer ↓ Drupal ↓ Provider ↓ Processing ↓ Drupal continues ``` Posteriormente: ```plaintext Payment Provider ↓ Webhook ↓ Drupal Commerce ↓ Update Payment ``` Los proveedores pueden enviar notificaciones asíncronas cuando cambia una transacción. --- ## 37. Por qué los Webhooks son importantes Supongamos un pago off-site. ```plaintext Drupal ↓ PayPal ↓ Customer pays ``` El cliente podría cerrar el navegador antes de regresar al sitio. No podemos depender exclusivamente de: ```plaintext Customer returns to Drupal ``` para saber que el pago ocurrió. El proveedor puede informar directamente: ```plaintext PayPal ↓ Webhook ↓ Drupal ↓ Payment completed ``` Esto hace el sistema más robusto. --- ## 38. Remote ID Un Payment suele necesitar relacionarse con la transacción existente en el proveedor externo. Conceptualmente: ```plaintext Drupal Payment ID: 481 Remote ID: pi_3ABC123XYZ ``` Mientras en el proveedor: ```plaintext Payment Provider Transaction: pi_3ABC123XYZ ``` Esta relación permite posteriormente realizar operaciones como: ```plaintext Capture Void Refund ``` sobre la transacción correcta. --- ## 39. No guardar datos sensibles innecesariamente Un principio fundamental en pagos es minimizar los datos financieros sensibles gestionados directamente por nuestra aplicación. Por ejemplo, no deberíamos diseñar campos Drupal como: ```plaintext field_credit_card_number field_cvv ``` para almacenar tarjetas. Debemos utilizar las soluciones seguras proporcionadas por el Payment Provider y el módulo de integración. Conceptualmente: ```plaintext Sensitive Payment Data ↓ Payment Provider Drupal ↓ Token / Reference ↓ Safe metadata ``` --- ## 40. PCI DSS Cuando manejamos pagos con tarjeta también debemos considerar los requisitos de seguridad de la industria de pagos. La arquitectura seleccionada puede modificar significativamente las responsabilidades de cumplimiento. Una integración moderna intenta normalmente reducir la cantidad de información sensible que atraviesa directamente nuestro servidor. Este aspecto debe evaluarse junto con el Payment Provider y la implementación concreta utilizada. --- ## 41. Ejemplo B2C: pago inmediato Supongamos una tienda de ropa. ```plaintext Order Total 100 EUR ↓ Checkout ↓ Payment Method Visa **** 4242 ↓ Gateway Stripe ↓ Authorize + Capture ↓ Payment 100 EUR Completed ↓ Order Fulfillment ``` Después: ```plaintext Warehouse ↓ Shipping ↓ Order Completed ``` Payment y Order evolucionan independientemente. --- ## 42. Ejemplo B2C: autorización primero Supongamos ahora que queremos verificar stock antes de cobrar definitivamente. ```plaintext Checkout ↓ Authorize 500 EUR ↓ Payment Authorization ↓ Warehouse confirms availability ↓ Capture 500 EUR ↓ Payment Completed ↓ Ship ``` Si no podemos entregar: ```plaintext Authorization ↓ Void ↓ Cancel Order ``` --- ## 43. Ejemplo B2B: pago mediante factura Un proyecto B2B puede funcionar de manera completamente diferente. ```plaintext Distributor ↓ Checkout ↓ Purchase Order Number ↓ Order placed ↓ ERP ↓ Invoice ↓ Payment after 30 days ``` No necesitamos obligatoriamente un pago online durante checkout. Posteriormente un administrador o integración podría registrar: ```plaintext Manual Payment Bank Transfer 5000 EUR Completed ``` Esto demuestra que Commerce Payment no está limitado a tarjetas de crédito. --- ## 44. Ejemplo Off-site Supongamos: ```plaintext Customer ↓ Checkout ↓ PayPal selected ↓ Redirect to PayPal ↓ Customer approves ↓ PayPal processes ↓ Return to Drupal ↓ Order completed ``` En paralelo: ```plaintext PayPal ↓ Webhook ↓ Drupal ↓ Payment state synchronized ``` El flujo de navegador y el flujo de comunicación servidor-servidor pueden coexistir. --- ## 45. Ejemplo de reembolso Supongamos: ```plaintext Order #1001 Total: 200 EUR Payment: 200 EUR Completed ``` El cliente devuelve uno de los productos. ```plaintext Returned Product: 50 EUR ``` Podemos realizar: ```plaintext Refund 50 EUR ``` Entonces: ```plaintext Payment Original: 200 EUR Refunded: 50 EUR Net: 150 EUR State: Partially Refunded ``` El Order Workflow y el proceso de Return pueden necesitar lógica adicional, pero el Refund pertenece al Payment. --- ## 46. Payment no debería determinar por sí solo el Order Workflow Puede ser tentador implementar: ```plaintext Payment Completed ↓ Order Completed ``` Pero normalmente esto sería incorrecto para productos físicos. Un pago completado solamente significa: ```plaintext Financial obligation ↓ satisfied ``` El Order todavía puede necesitar: ```plaintext Picking Packing Shipping Delivery ``` Por tanto podríamos tener: ```plaintext Payment Completed Order Fulfillment ``` y solamente más tarde: ```plaintext Order Completed ``` --- ## 47. Tampoco debemos confundir Payment Failed con Order Canceled Supongamos que una tarjeta es rechazada. ```plaintext Payment attempt ↓ Failed ``` Eso no significa necesariamente: ```plaintext Order Canceled ``` Podemos permitir: ```plaintext Payment failed ↓ Choose another Payment Method ↓ Try again ↓ Payment completed ``` El Order puede continuar existiendo como Draft durante este proceso. --- ## 48. Idempotencia y pagos Las integraciones de pago deben diseñarse con especial cuidado para evitar ejecutar dos veces la misma operación. Por ejemplo: ```plaintext User clicks Pay ↓ Request sent ↓ Slow response ↓ User clicks Pay again ``` No queremos terminar con: ```plaintext Payment #1 100 EUR Payment #2 100 EUR ``` Los proveedores y módulos de pago modernos ofrecen mecanismos para reducir este riesgo, pero debemos considerarlo especialmente cuando desarrollamos integraciones personalizadas. --- ## 49. No implementar nosotros mismos lo que ya hace el Gateway Cuando utilizamos un módulo de integración consolidado deberíamos aprovechar su arquitectura. No deberíamos crear soluciones paralelas como: ```plaintext Custom Stripe API calls inside checkout form ``` si el Gateway ya proporciona: ```plaintext Payment Method creation Payment creation Authorization Capture Refund Webhook handling ``` Utilizar las APIs de Commerce permite que nuestro sistema continúe siendo extensible y mantenible. --- ## 50. Cómo seleccionar un Payment Gateway Antes de seleccionar un proveedor o módulo deberíamos construir una pequeña matriz de requisitos. ```plaintext Requirement Required? Credit cards Yes PayPal Yes Stored methods Yes Authorize / Capture Yes Partial refund Yes EUR Yes CHF Yes Recurring payments Future Off-site payments Optional ``` Después podemos comparar los proveedores disponibles. Esto es mucho mejor que seleccionar primero un proveedor y adaptar después el negocio a sus limitaciones. --- ## 51. Preguntas para Payment Discovery ### Proveedores - ¿Qué Payment Providers utiliza actualmente el cliente? - ¿Existen contratos existentes? - ¿Qué países soportan? - ¿Qué monedas soportan? ### Payment Methods - ¿Tarjetas? - ¿PayPal? - ¿Transferencia bancaria? - ¿Wallets? - ¿Invoice? ### Checkout - ¿Pago on-site u off-site? - ¿Pago obligatorio durante checkout? - ¿Se pueden guardar métodos? ### Transaction - ¿Authorize + Capture inmediato? - ¿Authorize Only? - ¿Cuándo se realiza Capture? ### Refunds - ¿Necesitamos refunds? - ¿Partial refunds? - ¿Quién puede ejecutarlos? ### Orders - ¿Qué debe ocurrir cuando el Payment se completa? - ¿Qué debe ocurrir cuando falla? - ¿Qué ocurre al cancelar el Order? ### Integraciones - ¿ERP? - ¿Accounting? - ¿Invoice system? - ¿Fraud service? ### Operaciones - ¿Quién gestiona refunds? - ¿Quién revisa pagos fallidos? - ¿Quién realiza captures manuales? --- ## 52. Una matriz para separar conceptos Podemos utilizar esta guía: ```plaintext ¿Quién procesa realmente el dinero? ↓ Payment Provider ¿Cómo se conecta Commerce? ↓ Payment Gateway ¿Con qué paga el cliente? ↓ Payment Method ¿Qué transacción monetaria ocurrió? ↓ Payment ¿Solo reservamos capacidad de cobro? ↓ Authorization ¿Realizamos el cobro? ↓ Capture ¿Cancelamos una autorización? ↓ Void ¿Devolvemos dinero ya cobrado? ↓ Refund ``` --- ## 53. Modelo mental completo Podemos integrar todo lo estudiado: ```plaintext CUSTOMER │ ▼ CART / ORDER │ ▼ CHECKOUT │ ▼ PAYMENT METHOD │ ▼ PAYMENT GATEWAY │ ▼ PAYMENT PROVIDER │ ├── Authorize │ ├── Capture │ ├── Void │ └── Refund │ ▼ PAYMENT │ ├── Amount ├── State ├── Gateway └── Remote transaction │ ▼ ORDER PAID STATUS ``` Mientras el Order continúa su propio proceso: ```plaintext ORDER Draft ↓ Placed ↓ Fulfillment ↓ Completed ``` Y el Payment puede seguir: ```plaintext PAYMENT New ↓ Authorization ↓ Completed ↓ Partially Refunded ↓ Refunded ``` Ambos workflows se relacionan, pero no representan lo mismo. --- ## 54. La regla de las cinco preguntas Podemos resumir el diseño de Payments mediante cinco preguntas: ```plaintext 1. ¿Quién procesa el dinero? ↓ Payment Provider 2. ¿Cómo se integra Commerce? ↓ Payment Gateway 3. ¿Con qué paga el cliente? ↓ Payment Method 4. ¿Qué operación financiera ocurrió? ↓ Payment 5. ¿Qué debemos hacer después? ↓ Order / Fulfillment / Integration logic ``` --- ## Conclusión El sistema de Payments de Drupal Commerce separa cuidadosamente las diferentes responsabilidades que intervienen en una transacción financiera. Podemos resumirlas así: ```plaintext Payment Provider = servicio que procesa realmente la transacción Payment Gateway = integración entre Commerce y el proveedor Payment Method = instrumento utilizado por el cliente Payment = registro de una transacción financiera Authorization = reserva la posibilidad de cobrar Capture = ejecuta el cobro Void = cancela una autorización Refund = devuelve dinero previamente cobrado ``` La separación más importante continúa siendo: ```plaintext Checkout = experiencia de compra Order = transacción comercial Payment = transacción financiera Shipping / Fulfillment = cumplimiento de la compra ``` Cuando entendemos estas diferencias podemos diseñar correctamente tanto una tienda B2C con Stripe como un sistema B2B con transferencias, pagos diferidos o facturación. También podemos evaluar proveedores de pago basándonos en necesidades reales en lugar de simplemente instalar el primer módulo disponible. En el siguiente artículo estudiaremos la otra gran pieza de una tienda de productos físicos: **Shipping y Fulfillment en Drupal Commerce**. Veremos Shipments, Shipping Methods, Shipping Services, Packages, perfiles de envío, tarifas, peso, zonas, promociones de envío y cómo separar correctamente el cálculo del transporte del proceso real de fulfillment. ## Course navigation: Drupal Commerce Chapter 8 of 11 - [ ← Anterior Checkout en Drupal Commerce: Flows, Steps y Panes ](/es/checkout-en-drupal-commerce-flows-steps-y-panes) - [ Siguiente → Shipping y Fullfilment en Drupal Commerce: Shipments, métodos, tarifas y entrega ](/es/shipping-y-fullfilment-en-drupal-commerce-shipments-metodos-tarifas-y-entrega) [↑ Course index](/es/node/43)