Métodos de pago según el método de envío

Las opciones de pago que debe ofrecer una tienda en línea dependen de cómo se vaya a entregar el pedido: el contra reembolso (COD) solo tiene sentido con un transportista que realmente cobre el dinero en la puerta o en un punto de recogida, mientras que un transportista de palés B2B puede requerir el pago por adelantado. Odoo estándar ofrece los mismos proveedores de pago sin importar el método de envío elegido (solo la función opcional Click & Collect vincula su propia opción «Pagar en tienda» a la recogida en tienda), y su flujo de pago sin conexión (en el que se basa el COD) muestra textos de transferencia bancaria y una página de espera dependiente de JavaScript que encajan con una transferencia bancaria, no con un paquete pagado en el momento de la entrega.

La capa de pago y envío de eYssen resuelve ambos problemas. El módulo eyssen_delivery_payment permite que cada método de envío declare exactamente qué proveedores de pago pueden ofrecerse con él, hace que el proceso de compra valide las opciones de COD frente a la dirección de entrega, y reescribe las pantallas posteriores a la compra para que un cliente con COD lea «su pedido ha sido confirmado; pague al recibirlo» en lugar de instrucciones de transferencia bancaria. El módulo complementario payment_custom_skip_status hace que la redirección a la página de confirmación del pedido sea fiable para todos los métodos de pago sin conexión, al omitir la página intermedia de estado del pago en el servidor.

Ver también

• Pago contra reembolso (COD) — cómo se calcula el importe de COD a cobrar por cada entrega saliente, y el filtro antifraude Utánvét Ellenőr

• Entrega condicionada al pago — retener las entregas salientes hasta que se pague el pedido

• Estado y fechas de entrega — progreso y fechas de entrega en los pedidos y las facturas

• Integración con GLS, Integración con Foxpost y Integración con MPL — las integraciones de transportista que incluyen los proveedores de COD

Cómo se filtran los métodos de pago según el método de envío

Cada método de envío (Inventario ‣ Configuración ‣ Métodos de envío) incorpora una pestaña Proveedores de pago con un único campo, Adquirentes de pago habilitados. Se trata de una lista blanca:

• Cuando la lista está vacía, no cambia nada: al comprador se le ofrecen todos los proveedores de pago que, por lo demás, sean compatibles con el pedido (habilitados, publicados, y que coincidan con los límites de país, divisa e importe).

• Cuando la lista está rellenada, solo los proveedores incluidos superan la comprobación de compatibilidad mientras este método de envío esté seleccionado. Dado que los métodos de pago se derivan de los proveedores que superan el filtro, excluir un proveedor también elimina sus métodos de pago del paso de pago.

El comprador ve el efecto de inmediato: al cambiar el método de envío en el proceso de compra cambia el conjunto de opciones de pago que se muestran en el paso de pago.

Importante

Los métodos de envío incluidos con las integraciones de GLS, Foxpost y MPL vienen con su lista Adquirentes de pago habilitados rellenada de antemano con únicamente el proveedor de COD propio de ese transportista. De forma predeterminada, seleccionar uno de estos métodos de envío ofrece por tanto solo COD. Añada los proveedores en línea de la tienda (tarjeta, transferencia bancaria, …) a la lista de cada método de envío para ofrecer una combinación de opciones.

Cuando quedan varios proveedores, se clasifican por especificidad: cada uno de los campos Países, Divisas y Importe máximo establecido en un proveedor de pago cuenta como un punto, y los proveedores con mayor puntuación tienen prioridad sobre los genéricos. Esta clasificación no cambia el orden de las opciones de pago mostradas al comprador (que sigue la secuencia propia de los métodos de pago); decide qué proveedor atiende un método de pago compartido: cuando dos proveedores pueden atender el mismo método (por ejemplo, dos proveedores detrás de un único método «Pagar con tarjeta»), el proveedor compatible más específico es el que procesa realmente la transacción.

Contra reembolso en el proceso de compra

Los proveedores de pago pueden llevar un indicador técnico de COD. La capa compartida en sí no marca ningún proveedor como COD; el indicador lo establecen las integraciones de transportista para sus propios proveedores de tipo Pago contra entrega, de modo que el comportamiento de COD solo aparece una vez que se instala al menos un módulo de transportista (GLS, Foxpost o MPL). Para los proveedores marcados, el proceso de compra se comporta de forma distinta en tres aspectos:

• La disponibilidad sigue la dirección de entrega. Para los proveedores normales (en línea), Odoo comprueba el límite Países del proveedor frente a la dirección (de facturación) del cliente, y sus límites de divisa e importe frente al pedido. Para los proveedores de COD, la comprobación de compatibilidad se repite con la dirección de entrega en su lugar: un proveedor de COD limitado a Hungría se ofrece para un paquete destinado a un punto de recogida húngaro incluso cuando la dirección de facturación es extranjera, y se oculta cuando el propio paquete sale del país.

• Las pantallas de pago pendiente eliminan el texto de transferencia bancaria. El flujo de pago sin conexión muestra normalmente el encabezado Finalice su pago, un código QR de aplicación bancaria y un bloque de Comunicación con la referencia de la transferencia. Para COD, el encabezado pasa a ser Gracias por su pedido y se ocultan los bloques de QR y de referencia. Las transferencias bancarias reales conservan las pantallas originales sin modificar.

• La tarjeta de confirmación del pedido se vuelve verde. En la página de confirmación del pedido, un pago COD pendiente se muestra como una tarjeta verde de éxito en lugar de la tarjeta azul «esperando el pago», y la tarjeta muestra el Pending Message del proveedor —de forma predeterminada «Su pedido ha sido confirmado. Pague al recibirlo.» (en húngaro: «Rendelésed visszaigazolásra került. Kérjük, fizess átvételkor.»).

screenshot: delivery-payment-cod-confirmation-card

menu

(webshop) Checkout ‣ place the order with a Payment on Delivery provider

shows

The webshop order confirmation page after placing a cash-on-delivery order, with the green success card showing the provider's pending message instead of the blue "waiting for payment" card.

highlight

The green confirmation card (red frame).

module

eyssen_delivery_payment

notes

English UI, light theme, 1440px width.

Cada integración de transportista incluye su propio proveedor de COD:

Transportista	Proveedor de pago COD	Documentación
GLS	Pago contra entrega	Integración con GLS
Foxpost	FoxPost COD, con tarjeta de crédito en el casillero automático o en la entrega (se proporciona con un Importe máximo de 150 000, en la divisa principal de la compañía — HUF para una tienda húngara)	Integración con Foxpost
MPL	MPL COD, con tarjeta de crédito en el punto de recogida o en la entrega	Integración con MPL

Cada opción de COD también se oculta automáticamente cuando no existe en el sitio web ningún método de envío publicado de su transportista, o cuando el carrito no contiene productos físicos.

Nota

La lista blanca restringe de forma fiable los proveedores de pago en línea. Los proveedores de COD se validan por su propia vía (frente a la dirección de entrega), por lo que una opción de COD habilitada perteneciente a un transportista distinto puede seguir ofreciéndose aunque no figure en la lista del método de envío seleccionado; son sus propias reglas de publicación del transportista y de productos físicos las que la ocultan. Para eliminar por completo una opción de COD de la tienda, deshabilite o despublique su proveedor de pago en lugar de confiar únicamente en la lista blanca.

Importante

La tarjeta verde y el texto «Su pedido ha sido confirmado» son textos orientados al cliente; el propio pedido de venta no se confirma automáticamente por un pago COD pendiente. El postprocesamiento de pago estándar solo marca el presupuesto como enviado, asigna la referencia de pago y envía el correo de estado del pago; confirmar el pedido (y con ello crear la entrega) sigue siendo un paso de back office, o cualquier automatización de confirmación de pedidos que la tienda ya utilice.

El importe realmente cobrado en la puerta no es simplemente el total del pedido: se calcula por cada entrega saliente (transferencia) en el momento de generar la etiqueta de envío —un único importe que cubre todos los paquetes de la transferencia—, teniendo en cuenta los envíos parciales, las líneas de servicio y los anticipos facturados. Consulte Pago contra reembolso (COD) para ver el cálculo completo, y para el filtro de reputación Utánvét Ellenőr que puede ocultar el COD a clientes poco fiables.

Confirmación del pedido sin pago en línea

Con cualquier método de pago sin conexión (COD, transferencia bancaria), ninguna pasarela de pago llega a confirmar la transacción; esta simplemente queda como pendiente. Odoo estándar resuelve esto con una página intermedia de estado del pago («Espere, por favor…») cuyo JavaScript consulta periódicamente al servidor y luego redirige al cliente a la confirmación del pedido. Si ese JavaScript no llega a ejecutarse —un paquete de recursos bloqueado o roto, una extensión de privacidad agresiva, un script bloqueado en esa página—, el cliente se queda atrapado en la página de espera y puede creer que el pedido ha fallado.

El módulo payment_custom_skip_status elimina esta fragilidad en el lado del servidor. Cuando el cliente llega a la página de estado del pago con exactamente una transacción sin conexión siendo supervisada en su sesión de compra, en estado pendiente, el servidor responde con una redirección directa a la página de confirmación del pedido: la página de espera nunca llega a mostrarse, y no interviene ningún script del navegador. Cualquier otra situación (proveedores en línea, una transacción con error o cancelada, una sesión caducada) pasa a la página estándar, de modo que la gestión de reintentos y errores sigue funcionando exactamente igual que antes.

Nota

La redirección, de forma deliberada, no finaliza la transacción en el acto. El trabajo posterior —marcar el presupuesto como enviado, generar la referencia de pago, enviar el correo de estado del pago— queda a cargo de la acción planificada estándar Payment: Post-process transactions, que se ejecuta cada 10 minutos. Los clientes ven su página de confirmación al instante; el papeleo se pone al día en cuestión de minutos.

Nota

La omisión se aplica a todos los métodos de pago personalizados sin conexión, no solo al COD: los clientes que pagan por transferencia bancaria también llegan directamente a la página de confirmación del pedido, donde las instrucciones de pago del proveedor (los datos bancarios de su Pending Message) siguen mostrándose en la tarjeta de confirmación; la referencia de transferencia Comunicación aparece ahí en cuanto la acción Payment: Post-process transactions la asigna, en unos minutos.

Configuración

Instalar eyssen_delivery_payment instala automáticamente payment_custom_skip_status como dependencia; este último no tiene ajustes propios.

Para controlar qué opciones de pago ofrece cada método de envío:

1. Vaya a Inventario ‣ Configuración ‣ Métodos de envío y abra un método de envío.

2. En la pestaña Proveedores de pago, rellene Adquirentes de pago habilitados con todos los proveedores que puedan ofrecerse junto con este método —normalmente el proveedor de COD del transportista más el proveedor de tarjeta en línea de la tienda. Deje la lista vacía para permitir todos los proveedores compatibles.

Para influir en qué proveedor atiende un método de pago ofrecido por varios proveedores, establezca los límites de disponibilidad en cada proveedor de pago (Sitio web ‣ Configuración ‣ Comercio electrónico: proveedores de pago, pestaña Configuración): Países, Divisas y Importe máximo. Cuantos más de estos defina un proveedor, mayor será su prioridad cuando se pague un método de pago compartido.

El texto de COD orientado al cliente procede del Pending Message de cada proveedor de COD y puede editarse libremente en el formulario del proveedor.

Nota

Los mensajes pendientes de COD se aprovisionan automáticamente al instalar el módulo (una migración puntual también los aplicó al actualizar a la versión 18.0.1.1): todo proveedor de COD cuyo Pending Message esté vacío o siga conteniendo el texto genérico predeterminado «waiting for approval» recibe el texto de COD, en inglés y —cuando el idioma húngaro está instalado— en húngaro. Un proveedor cuyo mensaje se haya personalizado en todos los idiomas instalados se deja sin modificar (si el texto en inglés o en húngaro sigue teniendo el valor predeterminado, ambos se sustituyen por el texto de COD).

Importante

La acción planificada Payment: Post-process transactions debe estar activa para que los pedidos con COD y con transferencia bancaria reciban su procesamiento posterior tras omitir la página de estado. Odoo la activa automáticamente al habilitar un proveedor de pago; no la archive.

Uso

1. El administrador rellena la lista Adquirentes de pago habilitados en cada método de envío, emparejando cada transportista con las opciones de pago que tengan sentido para él.

2. En el proceso de compra, el comprador selecciona un método de envío, por ejemplo un transportista con casillero automático.

3. En el paso de pago, solo se ofrecen las opciones de pago permitidas para ese método de envío, y las opciones de COD aparecen o desaparecen en función de la dirección de entrega.

4. El comprador elige Pago contra entrega y confirma. Se le redirige directamente a la página de confirmación del pedido, que muestra una tarjeta verde con el texto «Su pedido ha sido confirmado. Pague al recibirlo.»; la página de espera nunca se muestra, y la redirección no necesita JavaScript en la página de estado.

5. El back office confirma el pedido como de costumbre; al generar la etiqueta de envío, el importe exacto a cobrar se calcula por cada entrega saliente tal y como se describe en Pago contra reembolso (COD).

Alcance y módulos

• eyssen_delivery_payment — la lista blanca Adquirentes de pago habilitados por método de envío, el indicador de COD con compatibilidad según la dirección de entrega y la selección de proveedor basada en especificidad, y las pantallas de pago pendiente y confirmación de COD reescritas.

• payment_custom_skip_status — la omisión, en el lado del servidor, de la página de espera de estado del pago para las transacciones sin conexión pendientes, lo que hace que la redirección a la confirmación del pedido sea independiente del JavaScript del navegador.

El importe dinámico de COD por entrega lo proporciona eyssen_delivery_cod y está documentado en Pago contra reembolso (COD); los propios proveedores de COD se incluyen con las integraciones de transportista (Integración con GLS, Integración con Foxpost, Integración con MPL).