Cómo funciona el split de pagos para marketplaces — y por qué la mayoría de las implementaciones están mal

El problema de pagos en marketplaces que nadie menciona

Cuando un comprador adquiere de múltiples vendedores en un solo carrito, la plataforma necesita dividir el pago, cobrar su tasa y liquidar a cada vendedor — atómicamente. Suena simple. No lo es.

Esto es lo que realmente pasa cuando un comprador gasta R$ 1.000 en un marketplace con 3 vendedores:

• Vendedor A debería recibir R$ 400
• Vendedor B debería recibir R$ 350
• Vendedor C debería recibir R$ 250
• La plataforma cobra 12% de MDR (R$ 120)
• Neto a vendedores: R$ 880 total

Aritmética simple. Ahora agregue complejidad del mundo real: Vendedor A tiene liquidación D+0 (PIX instantáneo). Vendedor B tiene D+14. Vendedor C tiene D+30 porque es un vendedor nuevo con mayor riesgo. El comprador pagó con tarjeta de crédito en 2 cuotas. Vendedor B tiene un chargeback pendiente de la semana pasada que necesita compensarse contra los fondos entrantes.

Aquí es donde la mayoría de las implementaciones de split payments se desmoronan.

Por qué las implementaciones ingenuas fallan

El anti-patrón "transferir después de liquidar"

El enfoque más común: recibir el pago completo en una cuenta, esperar la liquidación y luego transferir fondos a cada vendedor. Parece lógico. También es incorrecto.

Problemas:

• Riesgo de float — La plataforma mantiene los fondos del comprador en su propia cuenta. Si la plataforma quiebra entre el pago y la liquidación, los fondos de los vendedores están en riesgo.
• Infierno de reconciliación — Ahora tiene un problema de ledger. La plataforma recibió R$ 1.000 pero debe R$ 880 a 3 entidades diferentes con 3 cronogramas de liquidación diferentes.
• Caos de chargebacks — Si el comprador disputa el cargo 45 días después, ¿qué vendedor absorbe el chargeback? ¿Cómo recupera fondos de un vendedor que ya recibió liquidación D+0 y retiró el dinero?

El anti-patrón "múltiples cobros"

Otro enfoque común: cobrar al comprador 3 veces — una por vendedor. Esto resuelve el problema de split eliminándolo. Pero:

• UX terrible — El comprador ve 3 cargos en su estado de cuenta en vez de 1
• Costos más altos — 3 transacciones de gateway separadas. Triple de tasas de procesamiento
• Abandono de carrito — Algunos métodos de pago (como PIX) generan un único código QR. No puede pedir al comprador que escanee 3 QR codes

Cómo Revenu lo resuelve: splits atómicos con ledger de partida doble

Nuestra API de split maneja distribución N:N en una sola operación atómica. Esto es lo que pasa internamente cuando se procesa un split payment:

Paso 1: Ingreso del pago

El comprador paga R$ 1.000. Revenu recibe el pago y crea un único asiento contable:

DÉBITO: cuenta_pago_comprador R$ 1.000

CRÉDITO: cuenta_clearing_plataforma R$ 1.000

Los fondos aterrizan en una cuenta de clearing — no en la cuenta operativa de la plataforma.

Paso 2: Ejecución atómica del split

En la misma transacción de base de datos (literalmente la misma transacción ACID), Revenu ejecuta el split:

DÉBITO: cuenta_clearing_plataforma R$ 400,00

CRÉDITO: escrow_vendedor_a R$ 400,00

DÉBITO: cuenta_clearing_plataforma R$ 350,00

CRÉDITO: escrow_vendedor_b R$ 350,00

DÉBITO: cuenta_clearing_plataforma R$ 250,00

CRÉDITO: escrow_vendedor_c R$ 250,00

Después de esta transacción, el saldo de la cuenta clearing es exactamente R$ 0,00. Cada centavo está contabilizado.

Paso 3: Programación de liquidación por vendedor

Cada cuenta escrow de vendedor tiene su propio cronograma de liquidación:

• Vendedor A (D+0): Fondos liberados inmediatamente vía PIX instantáneo
• Vendedor B (D+14): Fondos en escrow por 14 días. Si llega un chargeback, los fondos se bloquean automáticamente
• Vendedor C (D+30): Perfil de riesgo de vendedor nuevo. 30 días de escrow

La arquitectura de escrow

El escrow no es solo un período de retención. Es una cuenta de ledger separada con sus propias reglas:

Estados del escrow

Cada entrada de escrow pasa por una máquina de estados:

• PENDING — Fondos recibidos, esperando fecha de liquidación
• AVAILABLE — Fecha de liquidación alcanzada, fondos pueden liberarse
• BLOCKED — Chargeback o disputa recibida, fondos congelados
• SETTLED — Fondos transferidos a la cuenta operativa del vendedor
• REVERSED — Chargeback ganado por comprador, fondos devueltos

Manejo de chargebacks en split payments

Un comprador disputa un cargo de R$ 1.000. El chargeback es por el monto completo — las redes de tarjetas no saben de sus splits internos.

Revenu maneja esto mediante:

1. Asignación proporcional — El chargeback de R$ 1.000 se asigna proporcionalmente a cada vendedor

2. Compensación de escrow — Si el vendedor aún tiene fondos en escrow, el chargeback se absorbe del escrow primero

3. Saldo negativo — Si el vendedor ya retiró fondos, su cuenta queda negativa. Pagos futuros compensan automáticamente

4. Garantía de plataforma — La plataforma puede configurar una política de garantía opcional

Todo esto sucede automáticamente. Sin intervención manual. Sin planillas.

Reembolsos parciales

Un comprador quiere devolver solo el artículo del Vendedor B (R$ 350). Revenu:

1. Identifica qué recipiente del split está afectado

2. Revierte solo esa porción de los asientos contables

3. Inicia reembolso al comprador por R$ 350

4. Debita el escrow o cuenta operativa del Vendedor B

5. Vendedores A y C no son afectados en absoluto

El ledger permanece balanceado durante todo el proceso. Zero reconciliación manual.

Opciones de liquidación

Los vendedores pueden configurarse para:

• D+0 — Liquidación PIX instantánea. Fondos disponibles en segundos
• D+1 — Próximo día hábil. Común para vendedores establecidos
• D+2 — Liquidación estándar. Default para la mayoría
• D+14 — Retención extendida. Para bienes digitales o categorías de mayor riesgo
• D+30 — Protección máxima. Vendedores nuevos o ítems de alto valor

Anticipación de recibibles

Vendedores con liquidación D+14 o D+30 pueden solicitar anticipación — recibir fondos antes de la fecha de liquidación a cambio de una tasa de descuento. Revenu maneja la anticipación como una operación de ledger, generando ingreso adicional para la plataforma.

Splits multinivel: cuando el vendedor también es un marketplace

Algunos marketplaces tienen sub-vendedores. Una plataforma de delivery (Nivel 1) contrata restaurantes (Nivel 2) que tienen repartidores (Nivel 3). Un solo pago del comprador necesita dividirse en 3 niveles.

Revenu soporta splits recursivos. Cada nivel tiene su propio escrow, su propio cronograma de liquidación y sus propias reglas de chargeback. El ledger rastrea el flujo completo de fondos desde el comprador hasta el recipiente final.

PIX split: distribución en tiempo real

PIX agrega otra dimensión a los split payments. Cuando un comprador paga vía PIX:

1. Pago recibido en tiempo real (< 2 segundos)

2. Split ejecutado atómicamente en la misma transacción

3. Vendedores D+0 reciben su parte vía PIX en < 10 segundos

4. El comprador ve una única transacción PIX

5. Cada vendedor recibe un crédito PIX separado con metadatos completos

Los splits PIX también soportan el protocolo MED 2.0. Si se detecta fraude, Revenu rastrear el flujo de fondos a través de todos los recipientes del split y ejecuta bloqueo en cadena automáticamente.

Los números de producción

Después de procesar más de R$ 2 mil millones en split payments:

• Tiempo de ejecución del split: < 15ms (p99)
• Discrepancia de balance del ledger: R$ 0,00 (siempre balanceado)
• Tiempo de resolución de chargebacks: < 30 segundos (asignación automática)
• Procesamiento de reembolsos parciales: < 5 segundos
• Precisión de liquidación: 100% — zero reconciliación manual
• Recipientes de split soportados por transacción: hasta 50

Por qué esto importa para su marketplace

Si está construyendo un marketplace, los split payments no son opcionales — son el núcleo de su modelo de negocio. Su tasa de plataforma, la experiencia de sus vendedores, su responsabilidad por chargebacks y su cumplimiento regulatorio dependen de que los splits funcionen correctamente.

La diferencia entre una implementación ingenua y un split atómico basado en ledger es la diferencia entre un marketplace que funciona en demo y uno que funciona a R$ 1 mil millones en GMV.

Construimos esto porque vimos lo que pasa cuando los splits fallan. Reconciliación manual. Vendedores furiosos. Fondos perdidos. Auditorías regulatorias.

La API de split de Revenu existe para que usted nunca tenga que preocuparse por nada de esto. Una llamada API. N vendedores. Ejecución atómica. Ledger perfecto. Cada vez.