If you run a SaaS marketplace, you’re not just shipping code—you’re clearing money for hundreds of developers with wildly different geographies, taxes, and payout preferences. The difference between a thriving ecosystem and a Slack full of angry threads is whether your money movement mirrors your commercial rules. Here’s the playbook that took a European SaaS platform from monthly guesswork to deterministic split settlements, predictable refunds, and FX that never leaks into the developer experience.
What was broken (and why developers noticed first)
Revenue flowed, but cash logic lagged. The marketplace captured card payments on a single EU acquirer, batched proceeds weekly, and paid developers by international wire “once accounting closed.” Three predictable problems followed:
- Trust erosion. Authors couldn’t reconcile dashboard sales with payouts. Support tickets asked the same two questions: “When will I be paid?” and “Why is the amount different?”
- Refund pain. Reversals nuked month-end as ops tried to claw back proportional shares from authors; the platform either ate the loss or blew up relationships.
- FX fog. Buyers paid in USD, EUR, GBP; authors expected local currency; treasury converted ad hoc. Every exception became a spreadsheet.
The fix wasn’t a new gateway. It was a clear funds-flow contract turned into software.
Define the money contract in plain sentences
Before an API call, write the rules a CFO and a developer both understand:
- At checkout the platform fee is X%, the author share is Y%, tax handling is Z (e.g., tax inclusive with reverse charge where applicable).
- When an order closes the author sees a provisional credit; it turns settleable after the refund window or usage confirmation.
- Refunds reverse in the same proportions, from the unsettled pool first; if already settled, the author ledger debits the next payout.
- Chargebacks mirror refunds, but sit in a separate risk bucket; authors see pending exposure and eventual outcome.
- FX happens on pooled balances (daily netting), not per transaction, with achieved rates benchmarked and visible in reporting—never in buyer UI.
If you can’t state these rules in five bullets, you’re not ready to code.
The ledger that makes splits boring (in a good way)
Build a double-entry sub-ledger per author. Each order writes three legs:
- Buyer → Marketplace gross receipt in the storefront currency.
- Marketplace → Author provisional share in the author’s ledger currency (not necessarily the storefront currency).
- Marketplace fee recognized separately for revenue reporting.
When the refund window ends (or usage is confirmed), the provisional share graduates to settleable. If a refund occurs earlier, you unwind the provisional leg instead of asking finance to do math on Thursday night.
Settlement cycles that authors can plan around
Payouts run on a calendar, not on vibes:
- Weekly base cycle per region: EU/EEA via SEPA, UK via FPS, US via ACH; LatAm and India via local partners where available.
- Instant upgrade for a fee in corridors with instant rails and sane limits (SEPA Instant, FPS).
- Visible cut-offs in the author dashboard: “Approve payouts by 16:00 CET Tuesday for Thursday value date.”
A calendar replaces a thousand tickets. Authors adapt faster than you think once the clock is credible.
Refunds that don’t poison the relationship
Two decisions turned refunds from crisis to routine:
- Proportional reversal by rule. Refunds reverse platform fee and author share by contracted percentages, before settlement. Authors see the debit as an event tied to the order ID and refund memo.
- Post-settlement clawbacks with dignity. If the share is already paid, the ledger books a negative settleable that nets against the next payout. Extreme tails (e.g., no future sales) trigger a minimal, clearly stated recovery workflow.
No emails begging authors to “send back $47.13.” The ledger carries the truth; payouts do the arithmetic.

Taxes without turning into a ministry
You don’t need to adjudicate every tax code on earth. You need consistent data and evidence:
- Author profiles capture whether they sell as individuals or entities, their tax residency, and VAT/GST status where relevant.
- Storefront tax layer decides whether buyer prices include VAT/GST, reverse charge applies, or marketplace acts as deemed supplier (jurisdiction-dependent).
- Statements show gross, net-of-tax, platform fee, and author share in the author’s currency, with an export the author can send to their accountant.
If the law says you’re a deemed supplier in a region, treat tax as your liability in that region. Don’t shove it into the author’s column and hope.
FX: show the outcome, hide the plumbing
Authors should pick a payout currency from a small list (e.g., EUR, USD, GBP). Behind the scenes:
- Pooled netting. Aggregate storefront currencies into buckets and convert once per day on thresholds, not per checkout.
- Benchmarking. Record achieved FX rate vs a neutral benchmark so finance can quantify spread and vendor performance.
- No UI roulette. Buyers always see prices in storefront currency; authors always see their ledger in payout currency. No crossovers, no live-rate widgets.
When someone asks “Why did I get €1,247.06?”, your statement shows the FX rate and timestamp, not a shrug.
Risk controls that save real money
- Name/account lock for first payouts; bank detail changes require out-of-band verification and a cooling-off period.
- Velocity caps for new authors; limits warm with deliveries and low dispute rates.
- Anomaly detection on refund spikes, self-purchase loops, and multi-account funnels pointing to the same payout destination.
- Sanctions/PEP screening at onboarding and periodically. Quiet defenses beat loud apologies.
Developer statements that end email threads
The winning layout fits on one page:
- Period revenue by product and currency
- Platform fee and taxes called out explicitly
- FX section with conversion date and rate
- Refunds/chargebacks table with order IDs and statuses
- Net settleable and value date for the next payout
If your author still writes support, your statement is unclear—fix the statement, not the agent script.
KPIs that prove the ecosystem is healthy
- On-time payout rate by value (>98%)
- Auto-reconciled percentage of settlements (>95% without human touch)
- Refund-to-sales ratio and chargeback rate trending stable by cohort
- Average author response time to bank detail changes (should increase—because of cooling-off)
- FX realized spread vs benchmark (measured, not guessed)
When these stabilize, community sentiment turns. Developers care less about the brand promise and more about money shows up when the dashboard says it will.
Implementation path that fits in a quarter
Weeks 1–3: finalize the money contract, build the sub-ledger, wire provisional vs settleable logic, and map refund events.
Weeks 4–6: add payout rails (EU/UK/US first), author dashboard with cut-offs, and statement exports.
Weeks 7–9: turn on daily FX pooling and benchmarking, plus instant payout upgrade in select corridors.
Weeks 10–12: tighten tax evidence (invoice exports, deemed-supplier flows if applicable), ship chargeback handling with status mirroring to authors.
Ship corridors, not universes. Consistency beats breadth.