Condiciones de pago aplazado: permite que tus clientes profesionales paguen por factura

PrestaShop no incluye de forma nativa un flujo de trabajo para condiciones de pago aplazado ni límites de crédito; las rutas del back office indicadas abajo cubren PrestaShop 1.6, 1.7, 8 y 9, aunque las etiquetas cambian ligeramente entre versiones. Las condiciones, las decisiones de crédito y la contabilidad son responsabilidad tuya y de tu asesor contable, no de la plataforma.

En B2C, el cliente paga antes de que la caja salga de tu almacén. En B2B, la caja sale primero y el dinero llega 30, 60 o incluso 90 días después, porque el comprador no es una persona con una tarjeta, sino una empresa con un ciclo de cuentas a pagar. Un responsable de compras no puede pagar con tarjeta en el proceso de pago: el pedido pasa por aprobación, recibe un código presupuestario y finanzas lo liquida en una tanda fija. Obligar al pago inmediato con tarjeta saca al comprador de su propio flujo de compras, que es justo donde los pedidos se atascan y mueren. Ofrecer "pago por factura" elimina esa fricción. El problema es que PrestaShop incluye módulos de pago offline (transferencia bancaria, cheque) que validan un pedido sin capturar dinero, pero no tiene un flujo nativo completo para condiciones aplazadas / límite de crédito. Por eso, la pregunta real que responde este artículo es concreta y limitada: ¿cómo se conectan realmente unas condiciones de pago aplazado al proceso de pago de PrestaShop: qué método de pago, qué estado de pedido, qué control por grupo y cómo impides que un cliente haga pedidos por encima de su límite de crédito?

Este es el artículo de implementación del clúster. Decidir qué empresas merecen condiciones de pago en primer lugar, la verificación, la solicitud de crédito, es otro trabajo, tratado en solicitudes de cuenta profesional. Aquí asumimos que el cliente ya está aprobado y preguntamos: ¿qué tiene que hacer ahora PrestaShop?

Qué significa "pagar por factura" a nivel de PrestaShop

Si quitamos el vocabulario financiero, un pedido con pago aplazado es simplemente un pedido que PrestaShop acepta sin capturar dinero y después mantiene como no pagado hasta que lo marques manualmente como pagado. Para que eso funcione limpiamente, deben cumplirse tres condiciones:

• Un método de pago que no cobre dinero. El cliente llega al paso de pago, elige "Pagar por factura" y el pedido se valida: sin PSP, sin tarjeta, sin redirección. PrestaShop ya admite este patrón: el módulo nativo ps_wirepayment (transferencia bancaria) hace exactamente eso, colocando el pedido en un estado no pagado y mostrando al cliente tus datos bancarios. Un método de condiciones aplazadas usa el mismo mecanismo con un texto distinto en la factura.
• Un estado de pedido que diga "nos deben dinero". El pedido no debe quedar en "Pago aceptado". Necesita un estado donde paid = 0, pero el pedido sea real y pueda enviarse: puede ser el estado nativo En espera de pago por transferencia bancaria o, mejor aún, un estado personalizado que crees tú (ver más abajo).
• Una barrera para que solo los compradores B2B aprobados vean el método. A un cliente minorista nunca se le debe ofrecer "pagar más tarde". Esa barrera es un grupo de clientes: la misma mecánica de grupos en la que se apoya el resto de este clúster.

Si aciertas con esas tres piezas, lo demás es proceso, no plataforma.

Paso 1, Limita el método a un grupo B2B aprobado

En Clientes → Grupos, ya tendrás (o deberías crear) un grupo para cuentas profesionales verificadas; llámalo Profesionales, Condiciones aprobadas. La creación de grupos y lo que puede ver cada grupo es un tema aparte; si todavía no gestionas precios/visibilidad por grupo, empieza por grupos de clientes en PrestaShop.

La palanca que realmente oculta el método está en Pago → Preferencias / Métodos de pago (la etiqueta exacta varía según la versión), dentro de la sección de restricciones de módulos de pago. Allí configuras restricciones por grupo junto con restricciones por moneda y país para cada módulo de pago. Restringe tu módulo de pago por factura únicamente al grupo Profesionales, Condiciones aprobadas. A partir de ahí, el método aparece en el proceso de pago para un comprador aprobado y simplemente no existe para todos los demás: sin código condicional en el tema, sin riesgo de que un comprador minorista se encuentre con pago a 30 días. Por debajo, esas opciones se guardan en la tabla de restricciones PREFIX_module_group (normalmente ps_module_group) y se aplican cuando el núcleo monta las opciones de pago disponibles para el grupo del cliente actual; tú solo le estás dando el grupo correcto.

Paso 2, Crea un estado de pedido específico (no reutilices "En espera de pago")

Puedes enviar estos pedidos al estado estándar "En espera de pago por transferencia bancaria", pero eso ensucia tu panel: los pedidos reales por transferencia y los pedidos con factura a 60 días parecen idénticos, y pierdes la posibilidad de filtrar "qué está a plazo y envejeciendo". Crea un estado diseñado para esto en Parámetros de la tienda → Configuración de pedidos → Estados. Indicadores recomendados:

El interruptor interno más importante es paid en el estado de pedido (el objeto OrderState y su propiedad paid). Cuando es 0, PrestaShop sigue tratando el pedido como pendiente, de modo que puedes filtrar los pedidos no pagados/a plazo en una sola lista (PrestaShop no tiene un libro de antigüedad de saldos por cobrar nativo; eso requiere un módulo dedicado) y el pedido no infla tus totales de "pago aceptado". Cuando más tarde recibes la transferencia bancaria, mueves el pedido a Pago aceptado y PrestaShop lo concilia. ¿Qué consigues con eso? Un back office donde "el dinero que aún nos deben" es una lista filtrada, no una conjetura.

Paso 3, El módulo de pago: aceptar el pedido sin capturar nada

Un módulo de pago con condiciones aplazadas hace cuatro cosas, y solo cuatro:

• Muestra la opción para el grupo aprobado (mediante hookPaymentOptions, que devuelve un PaymentOption: el equivalente moderno del antiguo hookPayment).
• Valida el pedido sin captura llamando a validateOrder() y pasando el ID de tu estado personalizado "En condiciones de pago" en lugar de PS_OS_PAYMENT. Esa es la única línea que distingue un pedido a plazo de un pedido pagado.
• Escribe las condiciones en el pedido: el plazo neto (30/60/90), la fecha de vencimiento y una referencia de pago, para que aparezcan en la factura generada.
• Opcionalmente bloquea por límite de crédito antes de validar (Paso 4).

La llamada única que distingue un pedido a plazo de uno pagado es el estado de pedido que entregas a validateOrder(). La transferencia bancaria pasa Configuration::get('PS_OS_BANKWIRE'); un pedido con tarjeta pagado pasa PS_OS_PAYMENT; tu pedido a plazo pasa el ID del estado personalizado que creaste en el Paso 2. Nada más cambia:

// Inside your module's validation controller, after building the cart total.
// $customerCredit and $this->id are the module's own values.
$termsStateId = (int) Configuration::get('MYTERMS_OS_ON_TERMS'); // your custom "On payment terms" state

$this->module->validateOrder(
    (int) $cart->id,
    $termsStateId,                       // NOT PS_OS_PAYMENT – order is real but unpaid
    $cart->getOrderTotal(true, Cart::BOTH),
    $this->module->displayName,           // payment method name shown on the order
    null,                                // optional message
    array(),                             // extra vars (terms text, due date, reference)
    (int) $cart->id_currency,
    false,
    $customer->secure_key
);

La parte limpia de hacerlo así: como usas la ruta estándar de validateOrder(), el pedido, la factura, el correo electrónico al cliente y el historial del pedido los genera el núcleo exactamente igual que con cualquier otro pago: sin proceso de pago bifurcado, sin nada que volver a parchear en la siguiente actualización de PrestaShop. No estás forzando la plataforma; estás usando el espacio que ya ofrece para "el pago ocurre fuera del sistema", que es exactamente lo que hace la transferencia bancaria.

Paso 4, Haz cumplir el límite de crédito antes de crear el pedido

Esta es la pieza que los comerciantes se saltan más a menudo y la que más lamentan. Cada cliente con condiciones debería tener un límite de crédito: el total máximo de facturas no pagadas que vas a permitir. Sin aplicación automática, un cliente con un límite de 2.000 EUR y 1.800 EUR ya pendientes puede hacer tranquilamente otro pedido de 900 EUR, y tú te enteras cuando vence.

PrestaShop no tiene un campo nativo de límite de crédito, así que lo implementas en el paso de prevalidación del módulo:

• Guarda el límite por cliente: un campo personalizado simple (una columna en la tabla customer o una pequeña tabla del módulo indexada por id_customer) leído en el hook de pago.
• Antes de validateOrder(), suma el saldo abierto del cliente: total de pedidos en tu estado "En condiciones de pago" (o cualquier estado donde paid = 0) que aún no se hayan saldado. Basta con un único SUM(total_paid_tax_incl) sobre las filas relevantes de orders para ese id_customer.
• Si saldo abierto + total de este carrito supera el límite, no muestres la opción como disponible, o muéstrala desactivada con un mensaje: "Este pedido supera tu crédito disponible. Por favor, salda las facturas pendientes o paga con tarjeta." El método de tarjeta para venta minorista debe seguir ofreciéndose como alternativa para no perder la venta.

La consulta del saldo abierto es el núcleo de la comprobación. Suma el total con impuestos incluidos de los pedidos de un cliente que siguen en un estado no pagado, para que puedas compararlo con su límite antes de validar:

SELECT COALESCE(SUM(o.total_paid_tax_incl), 0) AS open_balance
FROM ps_orders o
JOIN ps_order_state os ON os.id_order_state = o.current_state
WHERE o.id_customer = 42       -- the buyer
  AND os.paid = 0              -- unpaid states only: your "On terms" + bank-wire-awaiting
  AND o.valid = 1;             -- ignore carts that never became real orders

Léelo en el hook de pago, añade el total del carrito actual y compáralo con el límite almacenado. ¿Y eso qué cambia? El límite deja de ser un número en una hoja de cálculo que revisas después y se convierte en una regla que el proceso de pago aplica en tiempo real: la deuda incobrable se evita en la puerta, no se persigue más tarde.

Paso 5, La factura tiene que cobrar por ti

Con condiciones de pago, la factura de PrestaShop no es un recibo: es el instrumento que consigue que cobres, así que debe incluir todo lo que el departamento de cuentas a pagar del comprador necesita para liquidarla sin tener que escribirte. La factura PDF de PrestaShop la genera el objeto OrderInvoice y se renderiza mediante la plantilla HTMLTemplateInvoice; los campos que debes asegurarte de que aparezcan son:

• Un número de factura único (el núcleo se encarga de esto cuando el pedido llega a un estado apto para factura).
• Las condiciones de pago y la fecha de vencimiento explícita: "30 días netos, vence el 14 de julio de 2026", no solo "30 días netos".
• Tus datos bancarios para la transferencia.
• Una referencia de pago que el comprador debe indicar, para que una transferencia entrante se concilie con la factura correcta en lugar de convertirse en un ingreso misterioso.
• Cualquier descuento por pronto pago (por ejemplo, 2/10 Net 30) expresado con palabras.

La forma gratuita de añadir texto sobre banco y condiciones es el pie de factura nativo en Parámetros de la tienda → Configuración de pedidos → Facturas; la forma estructurada, fechas de vencimiento por cliente, referencias por pedido, resumen de saldo pendiente, recordatorios por lotes para lo vencido, es precisamente para lo que existe un módulo de gestión de facturas dedicado. Si envías unas pocas facturas al mes, el pie de factura sirve; cuando las cuentas por cobrar se convierten en un libro real, querrás que el estado del pedido, la fecha de vencimiento y la referencia se generen y se sigan automáticamente, no que se escriban a mano.

Net 30 vs Net 60 vs descuento por pronto pago: qué ofrecer realmente

No ofrezcas una única condición genérica a todo el mundo. Vincula el plazo a la relación y gradúalo mediante el grupo de clientes, de forma que la barrera del método de pago del Paso 1 también codifique la generosidad de las condiciones:

Como cada nivel es un grupo, puedes tener tres instancias del método (Net 30, Net 60, prepago) y dejar que la restricción por grupo decida cuál ve cada comprador. Un cliente en su segundo pedido nunca ve Net 60; una cuenta consolidada nunca tiene que pedirlo.

La realidad de flujo de caja que estás aceptando

Una advertencia honesta, porque la plataforma no puede arreglarla: las condiciones implican que has pagado el stock y el envío mientras el dinero está a 30–60 días vista. Con 20.000 EUR/mes de ingresos B2B en Net 30, aproximadamente un mes de ingresos está permanentemente en tránsito; con Net 60, dos. Esa brecha de capital circulante es una decisión de negocio, no un ajuste de PrestaShop: finánciala con fondos propios, una línea de crédito o factoring. Lo que PrestaShop sí puede hacer, y lo que entregan los pasos anteriores, es garantizar que siempre conozcas el tamaño exacto de esa brecha: una lista filtrada de pedidos a plazo no pagados, con antigüedad visible delante de ti y límites aplicados antes de añadir el siguiente.

Preguntas frecuentes

¿Puedo gestionar condiciones de pago aplazado solo con el módulo nativo de transferencia bancaria de PrestaShop?

En parte. El módulo nativo ps_wirepayment ya te da gratis la pieza más difícil: un método de pago que valida un pedido sin capturar dinero y lo deja en un estado no pagado. Restríngelo a tu grupo aprobado y tendrás un flujo funcional de "pago por factura". Lo que no te da es un límite de crédito, un estado de pedido "a plazo" distinto del de transferencia bancaria, cálculo de fecha de vencimiento ni recordatorios de vencidos: esos son los huecos que cubre un módulo dedicado de B2B Deferred Payment Terms. Para unas pocas cuentas de confianza, transferencia bancaria restringida más una hoja de cálculo manual es un punto de partida legítimo.

¿Cómo impido que un cliente haga un pedido que supera su límite de crédito?

No hay un campo nativo de límite de crédito, así que la comprobación debe ejecutarse en el hook de pago antes de llamar a validateOrder(). Suma el saldo abierto del cliente (el SQL del Paso 4), añade el total del carrito actual y compáralo con un límite por cliente que guardes tú. Si lo supera, no muestres la opción de condiciones; vuelve a la tarjeta para no perder la venta. La decisión debe tomarse antes de crear el pedido; comprobarlo después solo es informar, no aplicar la regla.

¿Un pedido "a plazo" estropeará mis cifras de ventas e ingresos?

Solo si lo dejas en un estado "pagado". La solución es el indicador paid = 0 en tu estado de pedido personalizado (Paso 2): entonces PrestaShop mantiene el pedido fuera de los totales de ingresos aceptados y te permite filtrarlo como pendiente. Cuando llega la transferencia, mueves el pedido a Pago aceptado y las cifras se concilian. Reutilizar el estado de transferencia bancaria funciona técnicamente, pero mezcla pedidos reales por transferencia con facturas a 60 días, así que pierdes la vista de "qué está envejeciendo".

¿PrestaShop controla qué facturas están vencidas?

No de forma nativa. El núcleo sabe que un pedido está no pagado (por el estado del pedido), pero no tiene libro de cuentas por cobrar, campo de fecha de vencimiento ni concepto de "vencido". Puedes aproximarlo con una lista filtrada de pedidos más la fecha de vencimiento en el pie de factura, pero cuando envías más que unas pocas facturas al mes, el seguimiento manual se rompe: esa vista de antigüedad y los recordatorios por lotes son exactamente lo que añade un módulo dedicado de cuentas por cobrar/gestión de facturas.

¿Es lo mismo que una venta B2B exenta de IVA?

No: son independientes. Las condiciones aplazadas tratan sobre cuándo llega el dinero; la exención de IVA trata sobre cuánto impuesto se cobra. Un pedido a plazo puede incluir IVA completo, y una venta B2B dentro del mismo país en Net 30 también. Si tus clientes con condiciones son empresas transfronterizas de la UE, probablemente querrás ambas cosas: condiciones para la parte de flujo de caja y Automatic EU VAT Checker para la exención por inversión del sujeto pasivo. Se configuran por separado y no dependen una de otra.

Dónde encaja esto en el conjunto B2B

El pago aplazado es una capacidad de una configuración B2B adecuada, no toda la configuración. Si estás construyendo la venta profesional desde cero, empieza por la visión general, vender B2B en PrestaShop, y después añade las piezas: mostrar precios netos a compradores profesionales, automatizar la exención de IVA de la UE y la verificación que decide quién merece condiciones en primer lugar: verificar clientes profesionales antes de darles acceso. Los dos módulos que hacen el trabajo pesado en esta página son B2B Deferred Payment Terms (el método restringido, el límite de crédito, la vista de antigüedad) y Automatic EU VAT Checker (para que los mismos compradores aprobados también obtengan su exención transfronteriza). Si aciertas con la barrera, el estado de pedido y la comprobación del límite de crédito, "pagar por factura" deja de ser una hoja de cálculo de riesgo y se convierte en otra forma más de completar la compra para tus compradores aprobados: la forma que su departamento de compras ya espera.