Qué cubre la integración de pagos más allá del proceso de compra
Elegir una pasarela de pagos es una decisión de la tienda, y el intercambio que gestiona es solo un momento. La relación de pago genera datos durante semanas, y cada tipo tiene un destino diferente.
- Autorización y captura: la tienda confirma que hay fondos disponibles y luego los captura, a menudo en el momento del envío en lugar de en el del pedido
- Liquidación: el proveedor agrupa los pagos capturados y los deposita, normalmente netos de comisiones y con retraso
- Reembolsos y reembolsos parciales: el dinero se devuelve contra una transacción original, a veces mucho después de que el pedido se haya cerrado
- Devoluciones de cargo y disputas: los fondos se revierten con un código de motivo y un plazo para presentar pruebas
- Comisiones: por transacción, por método y por divisa, que es lo que separa el importe bruto del neto
Solo el primero pertenece a la tienda. Los otros cuatro pertenecen al departamento financiero, y son los que quedan sin asignar si el proveedor de pagos solo se conecta al proceso de compra y a ningún otro lugar.
¿Por qué las liquidaciones dejan de coincidir con el libro de pedidos?
Los proveedores de pago agrupan lo que capturan. Un depósito de 48.000 EUR no corresponde a un solo pedido en el ERP. Corresponde a varios cientos de capturas realizadas durante dos días, menos las comisiones, menos tres reembolsos, más una reversión de contracargo del mes anterior.
Los múltiples métodos de pago multiplican el problema. Los pagos con tarjeta se liquidan en un plazo, la domiciliación bancaria en otro y los proveedores de compra ahora y paga después en un tercero, cada uno con su propia estructura de comisiones y formato de informe. Una empresa que utiliza cuatro métodos está conciliando cuatro flujos distintos frente a un único libro de pedidos.
La moneda añade la última capa. Un pago realizado en una divisa y liquidado en otra introduce una conversión que el ERP no calculó, por lo que el importe registrado en el pedido y el importe recibido difieren en una cantidad que nadie previó.
Lo que cuesta una integración de pagos deficiente
Nadie abre un ticket cuando una liquidación no coincide con un pedido. Los costes se acumulan silenciosamente y aparecen en este orden:
- Cierres de mes que se prolongan: el departamento financiero concilia las liquidaciones con los pedidos manualmente en una hoja de cálculo, y la fecha de cierre depende de cuántas excepciones hayan surgido
- Ingresos contabilizados con retraso: los pedidos permanecen sin conciliar, por lo que los ingresos reportados van a la zaga de la actividad comercial real durante el tiempo que tarde la conciliación
- Rentabilidad de canales basada en conjeturas: las comisiones de pago no se atribuyen por pedido, por lo que el margen por canal y por producto es una estimación
- Reembolsos que se emiten dos veces: cuando el sistema de pagos y el ERP no coinciden en si se procesó un reembolso, el servicio de atención al cliente emite uno segundo
- Disputas perdidas por falta de tiempo: las pruebas de los contracargos se encuentran dispersas entre la tienda, el almacén y el portal del proveedor, y el plazo vence antes de que alguien logre reunirlas
Integración de pagos en una arquitectura componible
Antes, las empresas utilizaban un único proveedor de pagos con una sola plataforma, y el propio plugin del proveedor cubría la mayor parte. Esa configuración es poco común hoy en día. Un minorista típico del mercado medio utiliza un proveedor principal, un método regional para un mercado específico, una opción de facturación o BNPL, y un marketplace con su propio flujo de pagos.
Essentiel Antwerp es una marca de moda de lujo belga que vende a nivel internacional a través de tiendas físicas y online. Utilizando la plataforma de integración como servicio (iPaaS) Alumio, construyeron una arquitectura componible en lugar de un paquete único, operando con Microsoft Dynamics 365 Business Central para finanzas, Adobe Commerce para la tienda online, Channable para marketing y Adyen para pagos.
El punto relevante para la conciliación es lo que esa arquitectura requiere en su base. Cuando los pagos, los pedidos y los registros financieros residen en tres sistemas elegidos por separado, la conexión entre ellos debe ser gestionada en lugar de asumida, ya que ningún proveedor controla ambos extremos.
Cómo una plataforma de integración conecta los pagos con el ERP
Desglosar un depósito en los pagos que lo componen es solo el primer requisito. Cada pago debe incluir su comisión y su referencia de pedido asociada, para que el ERP pueda registrarlo contra el documento correcto. Ese trabajo requiere una capa intermedia entre el proveedor de pagos y los sistemas financieros. Una herramienta de conciliación dedicada realiza bien la correspondencia, pero aun así debe recibir datos de ambos extremos. Los complementos de los proveedores no llegan tan lejos.
La iPaaS de Alumio ocupa esa posición, conectando al proveedor de pagos con los sistemas que contabilizan el dinero. Ese trabajo adopta cuatro formas:
- Liquidaciones desglosadas: un transformador de datos divide un depósito agrupado en sus transacciones subyacentes y vincula cada una a su referencia de pedido, de modo que el ERP recibe detalles a nivel de línea en lugar de una suma global
- Comisiones atribuidas por pedido: un asignador de datos vincula cada coste de transacción al pedido que lo generó, para que el margen por canal sea una cifra exacta y no una estimación
- Reembolsos en una sola dirección: una ruta de datos transmite un reembolso en el momento en que se emite, llegando tanto al proveedor de pagos como al ERP, para que no haya discrepancias sobre si la operación ocurrió
- Evidencia centralizada: registros detallados mantienen unidos el pedido, el cumplimiento y el historial de pagos detrás de una transacción disputada, para que las respuestas a las devoluciones de cargo cumplan con los plazos
Esos flujos se configuran en lugar de construirse manualmente para cada proveedor, con el transformador de código disponible cuando la configuración no puede expresar una regla y se prefiere escribir código. Añadir un método de pago reutiliza la lógica de conciliación que ya está en funcionamiento.
Lo que aporta una integración de pagos conectada
La prueba de una integración de pagos no es si el proceso de compra convierte. Es si el departamento financiero puede cerrar el mes sin hojas de cálculo y si alguien puede determinar el margen de un pedido después de las comisiones.
Las empresas que hacen esto bien dejan de tratar a los proveedores de pagos como una decisión de tienda y empiezan a tratarlos como una decisión financiera. Al ejecutarse a través de una plataforma de integración, añadir un método de pago regional se convierte en una elección comercial en lugar de un problema de conciliación, lo cual es fundamental al entrar en mercados donde los métodos locales determinan la conversión.
Lo que la empresa obtiene a cambio es un cierre de mes que no depende de la conciliación manual, ingresos contabilizados cuando se generan en lugar de cuando se concilian, y una visión clara de lo que aporta cada canal después de las comisiones.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
