How split payments work for marketplaces — and why most implementations are wrong

The marketplace payment problem nobody talks about

When a buyer purchases from multiple sellers in a single cart, the platform needs to split the payment, collect its fee, and settle each seller — atomically. Sounds simple. It's not.

Here's what actually happens when a buyer spends R$ 1,000 on a marketplace with 3 sellers:

• Seller A should receive R$ 400
• Seller B should receive R$ 350
• Seller C should receive R$ 250
• The platform takes 12% MDR (R$ 120)
• Net to sellers: R$ 880 total

Simple arithmetic. Now add real-world complexity: Seller A has D+0 settlement (instant PIX). Seller B has D+14. Seller C has D+30 because they're a new seller with higher risk. The buyer paid via credit card with 2 installments. Seller B has a pending chargeback from last week that needs to be offset against incoming funds.

This is where most split payment implementations fall apart.

Why naive implementations break

The "transfer after settlement" anti-pattern

The most common approach: receive the full payment into one account, wait for settlement, then transfer funds to each seller. This seems logical. It's also wrong.

Problems:

• Float risk — The platform holds buyer funds in its own account. If the platform goes bankrupt between payment and settlement, seller funds are at risk. In Brazil, BACEN considers this "payment institution funds" and requires segregated accounts.
• Reconciliation hell — You now have a ledger problem. The platform received R$ 1,000 but owes R$ 880 to 3 different entities with 3 different settlement schedules. Every payment generates reconciliation work.
• Chargeback chaos — If the buyer disputes the charge 45 days later, which seller absorbs the chargeback? How do you claw back funds from a seller who already received D+0 settlement and withdrew the money?

The "multiple charges" anti-pattern

Another common approach: charge the buyer 3 times — once per seller. This solves the split problem by eliminating it. But:

• Terrible UX — The buyer sees 3 charges on their statement instead of 1. Confusion leads to disputes.
• Higher costs — 3 separate gateway transactions instead of 1. Triple the processing fees.
• Cart abandonment — Some payment methods (like PIX) generate a single QR code. You can't ask the buyer to scan 3 QR codes.

The "percentage distribution" anti-pattern

Some platforms define splits as percentages: "Seller A gets 40%, Seller B gets 35%, Seller C gets 25%." This works until you encounter rounding.

40% of R$ 1,000 = R$ 400.00. Fine. But 40% of R$ 999.99 = R$ 399.996. You can't transfer R$ 399.996. Someone gets the extra centavo. Multiply this by millions of transactions and you have a material reconciliation discrepancy.

How Revenu solves it: atomic splits with double-entry ledger

Our split API handles N:N distribution in a single atomic operation. Here's what happens under the hood when a split payment is processed:

Step 1: Payment ingress

The buyer pays R$ 1,000. Revenu receives the payment and creates a single ledger entry:

DEBIT: buyer_payment_account R$ 1,000

CREDIT: platform_clearing_account R$ 1,000

The funds land in a clearing account — not the platform's operating account.

Step 2: Atomic split execution

In the same database transaction (literally the same ACID transaction), Revenu executes the split:

DEBIT: platform_clearing_account R$ 400.00

CREDIT: seller_a_escrow R$ 400.00

DEBIT: platform_clearing_account R$ 350.00

CREDIT: seller_b_escrow R$ 350.00

DEBIT: platform_clearing_account R$ 250.00

CREDIT: seller_c_escrow R$ 250.00

DEBIT: platform_clearing_account R$ 120.00 (platform fee — deducted proportionally)

CREDIT: platform_revenue_account R$ 120.00

After this transaction, the clearing account balance is exactly R$ 0.00. Every centavo is accounted for. The ledger balances. Always.

Step 3: Per-seller settlement scheduling

Each seller's escrow account has its own settlement schedule:

• Seller A (D+0): Escrow funds are released immediately. A PIX transfer is initiated within seconds.
• Seller B (D+14): Funds sit in escrow for 14 days. If a chargeback arrives during this window, funds are blocked automatically.
• Seller C (D+30): New seller risk profile. 30-day escrow provides maximum chargeback protection.

Settlement schedules are configured per seller, per payment method, and can be overridden per transaction.

The escrow architecture

Escrow isn't just a holding period. It's a separate ledger account with its own rules:

Escrow states

Each escrow entry moves through a state machine:

• PENDING — Funds received, awaiting settlement date
• AVAILABLE — Settlement date reached, funds can be released
• BLOCKED — Chargeback or dispute received, funds frozen
• SETTLED — Funds transferred to seller's operating account
• REVERSED — Chargeback won by buyer, funds returned

Chargeback handling in split payments

This is where most implementations fail catastrophically. A buyer disputes a R$ 1,000 charge. The chargeback is for the full amount — card networks don't know about your internal splits.

Revenu handles this by:

1. Proportional allocation — The R$ 1,000 chargeback is allocated proportionally: R$ 400 to Seller A, R$ 350 to Seller B, R$ 250 to Seller C.

2. Escrow offset — If the seller still has funds in escrow, the chargeback is absorbed from escrow first.

3. Negative balance — If the seller already withdrew funds (D+0 settlement), their account goes negative. Future incoming payments offset the negative balance automatically.

4. Platform guarantee — The platform can optionally configure a guarantee policy: "if seller negative balance exceeds R$ 5,000, platform absorbs the difference."

All of this happens automatically. No manual intervention. No spreadsheets. No "let me check with finance."

Partial refunds

A buyer wants to return only Seller B's item (R$ 350). Revenu:

1. Identifies which split recipient is affected

2. Reverses only that portion of the ledger entries

3. Initiates refund to buyer for R$ 350 (minus platform fee if configured as non-refundable)

4. Debits Seller B's escrow or operating account

5. Sellers A and C are completely unaffected

The ledger remains balanced throughout. Zero manual reconciliation.

Settlement options and cash flow optimization

Settlement schedules

Sellers can be configured for:

• D+0 — Instant PIX settlement. Funds available in seconds. Higher MDR (typically 1-2% more).
• D+1 — Next business day. Common for established sellers.
• D+2 — Standard settlement. Default for most sellers.
• D+14 — Extended hold. Used for digital goods, services, or higher-risk categories.
• D+30 — Maximum protection. New sellers, high-ticket items, or categories with high dispute rates.

Each seller can have a different schedule. Each payment method can override the default. Each transaction can override the seller default.

Anticipation (receivables advance)

Sellers with D+14 or D+30 settlement can request anticipation — receiving funds before the settlement date in exchange for a discount rate. Revenu handles anticipation as a ledger operation:

DEBIT: seller_escrow R$ 350.00

CREDIT: seller_operating R$ 343.00 (after 2% anticipation fee)

CREDIT: platform_anticipation_revenue R$ 7.00

The platform earns additional revenue from anticipation. Sellers get faster access to cash. Everyone wins.

Multi-level splits: when the seller is also a marketplace

Some marketplaces have sub-sellers. A food delivery platform (Level 1) contracts restaurants (Level 2) who have delivery drivers (Level 3). A single buyer payment needs to split across 3 levels.

Revenu supports recursive splits:

• Level 1: Platform takes 15% fee
• Level 2: Restaurant receives 70%, pays delivery fee
• Level 3: Driver receives 15%

Each level has its own escrow, its own settlement schedule, and its own chargeback rules. The ledger tracks the complete fund flow from buyer to final recipient.

PIX split: real-time distribution

PIX adds another dimension to split payments. When a buyer pays via PIX:

1. Payment is received in real-time (< 2 seconds)

2. Split is executed atomically in the same transaction

3. D+0 sellers receive their share via PIX in < 10 seconds

4. The buyer sees a single PIX transaction

5. Each seller receives a separate PIX credit with full metadata

PIX splits also support the MED 2.0 protocol. If fraud is detected, Revenu traces the fund flow across all split recipients and executes chain blocking automatically.

The numbers from production

After processing over R$ 2 billion in split payments:

• Split execution time: < 15ms (p99)
• Ledger balance discrepancy: R$ 0.00 (always balanced)
• Chargeback resolution time: < 30 seconds (automatic allocation)
• Partial refund processing: < 5 seconds
• Settlement accuracy: 100% — zero manual reconciliation
• Supported split recipients per transaction: up to 50

Why this matters for your marketplace

If you're building a marketplace in Brazil, split payments aren't optional — they're the core of your business model. Your platform fee, your seller experience, your chargeback liability, and your regulatory compliance all depend on getting splits right.

The difference between a naive implementation and an atomic ledger-based split is the difference between a marketplace that works at demo scale and one that works at R$ 1 billion in GMV.

We built this because we've seen what happens when splits break. Manual reconciliation. Angry sellers. Lost funds. Regulatory audits. We've seen platforms shut down because they couldn't account for where the money went.

Revenu's split API exists so you never have to worry about any of this. One API call. N sellers. Atomic execution. Perfect ledger. Every time.