El split de pagos define cómo se asigna el importe de una operación entre los participantes, como el vendedor y la plataforma. Ese reparto debe seguirse hasta la liquidación, los reembolsos y la transferencia efectiva. Para operar con seguridad, conserva la regla aplicada al pedido, identifica a cada beneficiario y concilia los movimientos por operación. Una suma correcta en el checkout aún no demuestra que cada participante haya recibido lo que le corresponde.
El problema aparece cuando producto llama split a todo, ingeniería guarda solo el importe total y finanzas necesita explicar una diferencia días después. La venta puede estar capturada, la comisión reconocida en el control operativo y la transferencia aún pendiente. Cada afirmación describe una etapa distinta.
Esta guía propone un diseño operativo para conectar esas etapas. Los números son totalmente ficticios; las políticas de tarifas y devoluciones se han elegido para que el cálculo sea reproducible. No representan precios, resultados ni funcionalidades de ningún proveedor.
¿Cuál es la diferencia entre split, captura, liquidación y transferencia al beneficiario?
El split determina a quién corresponde cada parte según la regla de la operación. La captura, en un flujo de tarjeta con autorización y captura separadas, confirma el avance del importe autorizado hacia el cobro. La liquidación describe el cumplimiento de las obligaciones financieras en el flujo aplicable. La transferencia al beneficiario, o payout, envía los fondos al destinatario definido y puede producirse en otro momento y depender de condiciones propias.
Un pedido con dos vendedores puede tener una captura y varias asignaciones. También puede tener capturas por envío, cuando se admitan, cada una con su reparto. Por tanto, contar vendedores no determina cuántas capturas hay. Utilizar dos instrumentos para que el cliente complete una compra es otro diseño, frecuentemente denominado split tender.
El ledger registra la memoria financiera de estas operaciones. Permite explicar partes, obligaciones, costes y ajustes, pero un asiento interno no ejecuta por sí mismo una transferencia externa. Esta distinción evita mostrar como recibido un importe que solo existe como expectativa.
En la aplicación, mantén separados el estado del pago, el de la asignación y el de la transferencia. Para profundizar en las transiciones del pago, consulta la guía de autorización, captura, anulación y reembolso. Una etiqueta única como completado elimina información necesaria para la operativa.
¿Quién participa y quién asume cada responsabilidad?
Antes de la API, diseña la relación entre comprador, vendedor, plataforma y proveedores de pagos. Identifica quién vende al comprador, quién habilita al beneficiario, quién recibe la instrucción financiera y quién responde por tarifas, devoluciones y disputas. El nombre comercial de una plataforma no resuelve estas preguntas.
El Banco Central explica que los marketplaces también pueden actuar como subadquirentes en determinados modelos, mientras que otras relaciones de venta tienen un encuadre diferente. El papel ejercido efectivamente importa para la clasificación, según las preguntas frecuentes sobre liquidación centralizada, en la pregunta sobre marketplaces (se abre en una pestaña nueva ↗), consultadas el 22/10/2026. La existencia de un campo de split en la integración no sustituye este análisis.
Convierte las responsabilidades aprobadas en reglas verificables: quién soporta la tarifa original, quién soporta la devolución, quién cubre un saldo insuficiente y quién recibe un posible ajuste. Registra también quién puede cambiar esas reglas y a partir de qué operación se aplica el cambio. Desarrollo implementa el modelo validado para ese negocio; no debe deducir obligaciones jurídicas a partir de un porcentaje.
El artículo sobre gateway, PSP, adquirente y subadquirente ayuda a organizar estos papeles técnicos. La elección de la integración debe confirmar qué funciones ejecuta realmente cada contratado.
¿En qué momento se envía el reparto al proveedor?
La respuesta depende del producto, del método y del flujo de captura. Averigua si el reparto se informa en la autorización, en la captura, en una configuración registrada previamente o mediante otro recurso documentado. Verifica también cómo corregir una instrucción y qué ocurre cuando falta o no es válida.
Como ejemplo específico, la documentación de split de transacciones de Adyen (se abre en una pestaña nueva ↗), consultada el 22/10/2026, describe instrucciones de asignación en operaciones de pago, captura y reembolso. Esto ilustra por qué la integración debe conocer la semántica de cada operación. No significa que todos los PSP acepten el mismo payload ni ofrezcan la misma combinación de recursos.
En la propuesta de esta guía, cada pedido mantiene una versión de la regla de reparto. La instrucción enviada debe poder rastrearse hasta esa versión y hasta el importe de esa captura. Si el pedido cambia antes de la captura, genera una nueva revisión autorizada y conserva la anterior para auditoría.
Un cambio en la comisión de hoy no debe recalcular silenciosamente una venta de ayer. Tampoco basta con guardar que se ha enviado la solicitud: sigue la confirmación e investiga los rechazos o diferencias en la asignación. La aplicación debe distinguir entre regla calculada, instrucción aceptada y movimiento confirmado.
¿Qué debe formar parte del contrato de reparto?
Empieza por la base de cálculo: precio de los artículos, transporte, descuento, comisión y tarifa no son intercambiables. Define qué componentes pertenecen a cada participante y en qué orden se realizan los cálculos. Un descuento financiado por la plataforma puede tener un efecto distinto del financiado por el vendedor.
Asocia a cada parte una identidad interna, el beneficiario correcto, la moneda, el importe y la referencia de la operación externa cuando esté disponible. Conserva la regla de redondeo y la versión de la política. Evita identificar al beneficiario solo por el nombre mostrado, que puede cambiar y no es una clave financiera fiable.
Trabaja con importes monetarios exactos, como unidades mínimas enteras, y distribuye los posibles céntimos residuales mediante un criterio determinista y aprobado. La suma de las partes debe cuadrar con el importe definido para esa etapa. No ocultes un céntimo adicional en la comisión sin registrar la regla que lo asignó.
Esta estructura también debe representar lo que aún no ha ocurrido. Una parte calculada puede estar esperando confirmación; otra puede estar reservada para una devolución. Separar estos importes impide que la misma disponibilidad financie dos salidas concurrentes. El saldo visible, el saldo elegible para transferencia y el dinero ya transferido deben tener definiciones distintas en el producto.
Ejemplo ficticio: ¿cómo repartir un pedido de R$ 200?
Considera un pedido de R$ 200, sin transporte ni descuento, con un solo vendedor y la plataforma. La comisión elegida para el ejemplo es del 10 % sobre el importe bruto: R$ 20. La tarifa ficticia de procesamiento es del 3 % sobre los mismos R$ 200: R$ 6. En este contrato imaginario, la plataforma soporta íntegramente esa tarifa.
La parte del vendedor es de R$ 180, calculada como R$ 200 menos R$ 20 de comisión. La plataforma tiene R$ 20 de comisión bruta y R$ 14 después del coste de R$ 6. El neto agregado es de R$ 194, que cuadra con los R$ 180 del vendedor más los R$ 14 de la plataforma. Aún no se ha realizado ninguna transferencia.
Observa la base: retirar R$ 6 antes de calcular la comisión produciría otro acuerdo. Aplicar el 10 % sobre R$ 194 daría R$ 19,40, incompatible con la política elegida. Por eso, la interfaz debe explicar el origen de cada número, en lugar de mostrar solo un porcentaje y un neto.
El ejemplo no contempla impuestos, anticipación, pagos a plazos, cambio de divisas, reservas ni otros gastos. Estas exclusiones delimitan el cálculo. Si algún componente existe en la operación real, debe entrar como movimiento identificado y tener un responsable definido, sin quedar absorbido en una diferencia inexplicada al cierre.
¿Cómo registrar el ejemplo en el ledger operativo?
Un modelo posible registra, en la captura confirmada, R$ 200 por cobrar al procesador, R$ 180 de obligación con el vendedor y R$ 20 de comisión de la plataforma. La tarifa añade R$ 6 de gasto y reduce en R$ 6 el importe por cobrar. El resultado esperado del procesador pasa a ser R$ 194.
En términos de asientos, el primero carga R$ 200 en el derecho de cobro operativo y abona R$ 180 en la obligación con el vendedor y R$ 20 en la comisión. El segundo carga R$ 6 de gasto y abona R$ 6 en el derecho de cobro. Es una propuesta didáctica de control operativo que debe adaptarse al modelo validado por la empresa; no es un plan contable oficial ni una prueba de titularidad jurídica de los fondos.
Cuando se produzca la liquidación, el movimiento debe cancelar el derecho de cobro correspondiente y reconocer la posición financiera confirmada. No generes otros R$ 200 de ingresos al importar el archivo: este confirma el hecho ya esperado o muestra una discrepancia. La referencia debe conectar los registros.
Conserva captura, tarifa y liquidación como hechos distintos. Si la tarifa esperada era de R$ 6 y el informe indica otro importe, abre una diferencia identificada. La guía de ledger de pagos profundiza en la relación entre transacción, asiento y saldo sin exigir una columna mutable para cada situación.
¿Cómo funciona un reembolso parcial de R$ 50?
Continúa el ejemplo sin una transferencia previa. El cliente recibe un reembolso de R$ 50. La política ficticia determina que la comisión se revierta proporcionalmente al importe devuelto y que no se devuelva la tarifa original de R$ 6. Es una hipótesis del caso, no una regla universal de procesamiento.
R$ 50 corresponden al 25 % del pedido. El vendedor soporta R$ 45 y la plataforma revierte R$ 5 de comisión. Quedan R$ 135 para el vendedor, R$ 15 de comisión bruta y R$ 9 para la plataforma después de la tarifa original. El agregado restante es de R$ 144: R$ 194 menos R$ 50, o R$ 135 más R$ 9.
En el control operativo, la reversión reduce en R$ 45 la obligación con el vendedor y en R$ 5 la comisión, con una contrapartida de R$ 50 en la posición financiera correspondiente a la etapa del reembolso. Si el importe aún no se ha liquidado, el derecho de cobro puede ser la contrapartida; si ya se ha liquidado, el modelo debe representar la salida o la obligación de devolver en el lugar correcto.
La documentación de split de reembolsos de Adyen (se abre en una pestaña nueva ↗) ilustra instrucciones específicas y limitaciones por método. Consulta las reglas del proveedor utilizado: no des por hecho que un reembolso parcial repite automáticamente la proporción del pago original.
¿Y si el reembolso corresponde a un artículo concreto?
En un carrito con varios vendedores, devolver el 25 % del total no significa cargar el 25 % a cada beneficiario. Si solo se ha devuelto un artículo, la reversión debe seguir la relación de ese artículo con el vendedor, la comisión, el descuento y el posible transporte. La política debe decidir cómo tratar los componentes compartidos.
Guarda la asignación original por artículo o por unidad comercial compatible con el negocio. Así, el reembolso puede señalar la parte que revierte. Si el sistema solo ha conservado el porcentaje final del carrito, podría ser imposible reconstruir con seguridad quién debe soportar la devolución.
Controla también el importe que sigue siendo elegible para reembolso. Las solicitudes ya en procesamiento pueden consumir parte de ese límite, según el diseño y las restricciones del proveedor. Dos equipos no pueden liberar simultáneamente el mismo saldo reembolsable basándose en lecturas antiguas.
En el caso de R$ 200, los R$ 45 y R$ 5 son correctos solo porque hemos elegido un vendedor y la reversión proporcional de la comisión. Si la comisión incluyera una parte fija no reversible, la cuenta cambiaría. Atención al cliente debe poder explicar esa diferencia con la política de la operación original, sin aplicar retroactivamente una regla recién editada.
¿Qué cambia cuando ya se ha transferido dinero al vendedor?
Abre ahora una rama separada del ejemplo: antes del reembolso de R$ 50, la plataforma ya había transferido R$ 100 al vendedor. La obligación restante con él era de R$ 80. Con la reversión de R$ 45, esa obligación baja a R$ 35. La parte neta de la plataforma sigue siendo de R$ 9 con las premisas anteriores.
La posición agregada restante cuadra en R$ 44: R$ 194 menos la transferencia de R$ 100 menos el reembolso de R$ 50. Esos R$ 44 corresponden a R$ 35 aún debidos al vendedor más R$ 9 de la plataforma. La transferencia anterior no ha desaparecido y no puede restarse de nuevo al calcular el saldo.
Si el importe que debe revertirse supera la obligación aún abierta, el diseño debe representar la exposición y la forma de recuperación prevista contractualmente. Cambiar un saldo en la base de datos no devuelve el dinero que ya ha llegado a la cuenta del vendedor. Una compensación futura también debe identificarse y conciliarse.
En otra rama, sin ninguna transferencia previa, un reembolso íntegro de R$ 200 dejaría el coste de R$ 6 a cargo de la plataforma, bajo la hipótesis de que la tarifa no se devuelve. La diferencia exige cobertura; no autoriza a crear ingresos ni a reducir arbitrariamente el importe devuelto al cliente.
¿Cómo entran los contracargos y las reservas en el reparto?
Una disputa exige un historial propio, vinculado al pago y a los artículos implicados. La política de un reembolso voluntario no determina automáticamente la responsabilidad de un contracargo. Define con los responsables del negocio cómo se tratarán las pruebas, los cargos, las posibles reversiones y las tarifas en el contrato efectivo.
En el sistema, separa la apertura de la disputa, el bloqueo o reserva operativa y el cargo financiero confirmado. Una reserva reduce la disponibilidad definida por el producto; no equivale necesariamente a dinero que ha salido. Mezclar estos eventos puede descontar dos veces al vendedor la misma exposición.
También puede existir un reembolso previo del pago disputado. Relaciona las referencias y verifica los movimientos externos antes de reconocer otra pérdida definitiva. El objetivo no es ignorar el segundo evento, sino explicar si es una nueva obligación, una etapa provisional o una diferencia que debe impugnarse.
La guía sobre contracargos, disputas y pruebas profundiza en ese ciclo. Aquí, el requisito de arquitectura es conservar la relación entre el caso y sus partes financieras. Una posible reversión favorable debe compensar los movimientos adecuados, sin borrar el historial ni liberar una transferencia antes de la confirmación exigida.
¿Cómo conciliar pedido, reparto, liquidación y transferencia?
Utiliza una trazabilidad que permita partir del pedido y llegar a cada captura, parte, tarifa, reembolso y transferencia. Después, recorre el camino inverso: todo movimiento externo debe encontrar una operación interna o una excepción investigable. La igualdad de importe y fecha, por sí sola, no basta para identificarlo.
La conciliación debe distinguir entre expectativa y confirmación. En el ejemplo, R$ 194 era el neto esperado antes de la devolución. El informe puede mostrar captura, tarifa y reembolso en registros o periodos diferentes. Comparar solo el ingreso bancario con las ventas del día mezcla etapas y produce falsas alarmas.
Como referencia concreta de informe, el Balance Platform Accounting Report de Adyen (se abre en una pestaña nueva ↗) describe cambios de saldo, transferencias, payouts y costes. Los campos y la periodicidad son específicos de ese proveedor; la aplicación debe mapear los documentos realmente disponibles en su flujo.
Investiga las diferencias por beneficiario y por operación antes de cerrar el agregado. Un error positivo en una cuenta puede compensar numéricamente otro negativo en otra y ocultar ambos. La guía de conciliación de pagos organiza el paso de la venta a la confirmación financiera y el tratamiento de estas excepciones.
¿Cómo tratar los fallos, los eventos repetidos y la concurrencia?
Una solicitud de transferencia con timeout queda sin resultado conocido hasta que las evidencias resuelvan la duda. No envíes otra transferencia con una identidad distinta solo porque se haya perdido la primera respuesta. Conserva la intención, la referencia externa disponible y la reserva del importe mientras la operación sea indeterminada.
Una propuesta de ejecución segura vincula cada operación financiera a una identidad estable y publica sus efectos internos de forma atómica. Reprocesar la misma confirmación debe recuperar el resultado anterior, sin crear otra comisión, obligación ni transferencia. Los eventos distintos de una misma operación deben seguir siendo distinguibles cuando representen efectos legítimos diferentes.
Para la concurrencia, considera dos procesos que intentan liberar una transferencia mientras otro reserva un reembolso. No pueden consumir la misma disponibilidad. Realiza la decisión y la reserva dentro de un límite transaccional adecuado, con restricciones que sigan siendo válidas tras un fallo del proceso.
Los eventos fuera de orden requieren un cuidado similar. Una notificación antigua no debe deshacer una confirmación posterior solo por llegar la última. Conserva la evidencia y aplica transiciones compatibles con el ciclo documentado. Cuando los datos externos sean contradictorios, genera una excepción trazable y suspende la acción que dependa de esa confirmación.
¿Cómo investigar una parte asignada al beneficiario equivocado?
Considera otro incidente ficticio, independiente de los cálculos anteriores: el pedido y el total liquidado son correctos, pero una parte se ha asignado al vendedor equivocado. El primer paso es conservar la instrucción original, la versión de la regla y las referencias confirmadas. Compara el registro que debía utilizar el pedido con el destinatario efectivamente indicado y con el movimiento externo.
Si el error está solo en la asociación del informe interno, corrige esa asociación de forma auditable, sin inventar una transferencia. Si la asignación externa es incorrecta, la resolución depende de una operación documentada y permitida en esa etapa. Un asiento compensatorio interno puede explicar la obligación, pero no demuestra que los fondos hayan cambiado de beneficiario en el proveedor.
Durante la investigación, señala el importe afectado y suspende la transferencia que dependa de esa confirmación, conforme al control aprobado para la operación. Evita bloquear indefinidamente importes ajenos al problema. Registra responsable, hipótesis, evidencia necesaria y condición de cierre.
El cierre exige demostrar tanto el ajuste interno como su efecto externo, cuando lo haya. Después, prueba la causa: reutilización de datos de registro, referencia intercambiada, regla antigua o error de correlación. Una suma global que sigue cuadrando no cierra este incidente, porque el derecho de cada participante todavía puede estar representado incorrectamente.
¿Qué probar antes de habilitar la operación?
Convierte el ejemplo en pruebas de conservación del valor. Confirma R$ 200 brutos, R$ 6 de tarifa, R$ 180 del vendedor y R$ 14 netos de la plataforma. Tras el reembolso de R$ 50, confirma R$ 135 y R$ 9. En la rama con una transferencia previa de R$ 100, confirma R$ 35 y R$ 9, con un total de R$ 44.
Prueba por separado la comisión fija, la comisión porcentual, el descuento por financiador, el carrito con varios vendedores y el céntimo residual. En cada escenario, la suma debe cuadrar con la base correspondiente. No reutilices una respuesta esperada que presuponga proporcionalidad en un caso de devolución por artículo.
En las pruebas de fallo, interrumpe el proceso entre reserva y envío, entre envío y respuesta y entre confirmación y registro local. Reentrega eventos, altera el orden y fuerza dos acciones concurrentes. El resultado esperado debe declarar qué movimientos existen, cuáles esperan confirmación y qué acciones quedan bloqueadas.
Finaliza con un cierre reproducible a partir de los informes externos disponibles. Producto y finanzas deben poder explicar el extracto de un vendedor, incluidas las devoluciones posteriores a una transferencia. La operación está lista para avanzar cuando esa explicación puede señalar reglas, referencias y movimientos concretos, sin depender de editar manualmente el saldo para que los números coincidan.