If you run a marketplace, your growth ceiling isn’t demand—it’s whether money movement keeps up without getting you in trouble. The moment you accept funds on behalf of others, you’re operating a sub-merchant model (directly as a PayFac/PSP or through one). Do it well and sellers get paid predictably, buyers stop opening disputes, and auditors nod. Do it badly and you’ll drown in returns, frozen balances, and regulator love letters. Here’s a field-tested blueprint that keeps speed, compliance, and economics in the same room.
First decision: which operating stack are you actually running?
Before a single line of code, pick the lane and write it down in plain English so product, finance, and legal agree.
- Aggregator/Marketplaces with a partner PSP (recommended to start). Your PSP holds the license and risk book; you own UX, seller policy, and data hygiene.
- Registered PayFac (advanced). You—or your captive PSP—underwrite and settle to sub-merchants directly under card-network rules. More control, more obligations.
- Mixed rails. Card acquiring via PSP + local A2A rails for pay-ins and pay-outs where adoption is strong (SEPA, FPS, ACH, PIX, SPEI, UPI).
Pick once, document the obligations, and align every feature to that choice.
Onboarding that’s fast for good sellers and hard for the wrong ones
Your KYB should feel like a funnel, not a wall. The trick is progressive disclosure and machine-checkable evidence.
- Tiered data capture (five-minute start): legal name, registration number, country, website/listings, beneficial owners, payout account.
- Automatic checks: registry lookup, sanctions/PEP screening, website scan for prohibited goods/MCC fit, bank account name match, email/domain reputation.
- Risk-rated extras: only when signals warrant—articles of incorporation, proof of address, VAT/GST certs, supplier invoices, fulfillment proofs.
- Staged go-live: small transaction caps and a rolling reserve until the seller completes first clean deliveries and shows low dispute rates.
Design the form as if an auditor will read it later—because they will.
Country and currency fences: write the map, enforce it in code
Every marketplace needs a permitted matrix:
- Where the seller is based (KYB country)
- Where buyers are (acquiring corridor)
- What currencies you accept/settle (storefront vs payout)
- Rail availability (local acquiring, A2A, wallet)
- Sanctions and local restrictions (no-go and enhanced-due-diligence lists)
Enforce the matrix at onboarding and at listing time. If a seller tries to add a SKU that triggers a restricted MCC/country combo, block it with a human explanation. Silent failures create support tickets; clear fences create trust.
Product and MCC hygiene: your quiet chargeback reducer
Map categories to MCCs and risk classes. Three outcomes:
- Clean: allowed; normal limits.
- Allowed with guardrails: higher chargeback propensity → stronger SCA/3DS policy, longer payout tails, higher reserve.
- Disallowed: block at listing; show policy excerpt.
Keep a review queue for newly invented categories and gray areas. Your chargeback rate is often decided at listing time, not at checkout.
Limits, reserves, and payout calendars (the part sellers actually feel)
Give each sub-merchant a risk tier that sets:
- Per-transaction caps and daily/weekly velocity
- Rolling reserve (e.g., 5–10% for 30–90 days) while they establish history
- Payout cadence (weekly base; instant upgrades where domestic instant rails exist)
- Tail holdback for categories with delivery/return risk (release at POD or after a short day-count)
Publish the rules in the seller dashboard with visible cut-offs and expected value dates. A calendar eliminates a hundred emails.
Split settlement and negative-balance management
Funds from a buyer payment should book into a virtual booking ledger that knows:
- Marketplace fee now; seller share provisional until refund/chargeback windows pass.
- Refunds reverse fee and seller share proportionally from the provisional pool first; if already settled, net from the next payout (and show the math).
- Chargebacks park in a risk bucket; if lost, the ledger debits future settleables.
- Negative balances trigger tiered actions: temporary increased reserve, instant-payout suspension, and—only if chronic—account pause.
Arithmetic beats negotiation. Codify it.
Payout safety: simple controls that save real money
- Name/account lock. First payout requires a bank-account name match; changes need out-of-band confirmation and a cooling-off period.
- Beneficiary whitelists. One seller, one (or few) payout accounts. “Please wire to a new account today” is how platforms lose money.
- Jurisdiction checks. Don’t pay to countries you wouldn’t onboard in. Exceptions go through compliance.
These controls are boring. That’s why they work.
3DS/SCA, risk routing, and descriptors buyers recognize
Treat SCA as a scalpel, not a hammer.
- Exempt low-risk traffic under TRA where available; insist on 3DS for high-risk MCCs, cross-border cards, and mismatched device signals.
- Use network tokens to survive reissues on subscriptions and to raise auth rates.
- Keep descriptors clear: marketplace name + seller slug when allowed; it’s the cheapest chargeback prevention tool you have.
Measure approval rates by BIN/country and rotate acquirers or rails accordingly.
Disputes: win fewer by starting fewer, and close the rest fast
A dispute you avoid is worth two you win.
- Upfront evidence: require delivery proof fields in order objects (carrier, tracking, timestamps, signatures).
- Proactive messaging: delays and partial shipments trigger buyer comms with one-click refund/replace.
- Representment packs: auto-assemble card network evidence from the ledger—descriptor, order, proof, conversation logs.
- RDR/Order Insight (where available): resolve many cases before they escalate.
Build it once; your support team will thank you every Thursday.
Reporting and tax: don’t bolt it on later
Two regimes bite platforms that ignore them:
- Platform reporting (e.g., DAC7, 1099-K equivalents). Store tax residence, TIN, gross amounts, fees, dates, and payout details per seller to emit annual statements without re-keying.
- Indirect tax (VAT/GST). If you are deemed supplier in a country, the liability sits with you, not the seller. Keep evidence (buyer location, IP, billing data) to defend rate and scheme choices.
If year-end needs a spreadsheet, you left it too late.
A2A rails for pay-ins and pay-outs: cheaper, faster, cleaner
Cards aren’t your only tool. Where adoption is strong, put account-to-account rails first:
- EU/EEA: SEPA Credit Transfer/Instant for buyer pay-ins and seller pay-outs.
- UK: Faster Payments for both directions.
- US: ACH (Same Day for exceptions).
- BR/MX/IN: PIX, SPEI, UPI.
Always mirror refunds to the original rail and attach virtual references so reconciliation is automatic.
FX policy: keep spreads out of the UX and in the CFO’s dashboard
- Let buyers pay in storefront currency; let sellers pick a payout currency from a short list.
- Convert pooled balances on time/threshold sweeps, not per order.
- Track achieved vs benchmark every day and renegotiate providers with numbers, not anecdotes.
If customers can “feel” your FX, you built it wrong.
KPIs that tell you the engine is healthy
- Auth approval rate by corridor and MCC
- Refund + chargeback ratio by seller tier
- On-time payout rate by value and corridor
- Auto-recon % on inflows/outflows (>95% is normal with virtual refs)
- Reserve coverage vs modeled exposure
- FX realized spread vs benchmark
Share these weekly; metrics decay quietly when nobody is watching.
A 90-day build you can actually deliver
Weeks 1–3: write the country/currency/MCC matrix; ship tiered KYB with sanctions and name-match; create seller risk tiers.
Weeks 4–6: stand up the booking ledger (provisional vs settleable), proportional refunds, rolling reserves; add SEPA/FPS/ACH pay-outs.
Weeks 7–9: enable local A2A pay-ins with virtual references; wire webhooks to auto-close orders and reconcile; add 3DS risk router and descriptor cleanup.
Weeks 10–12: ship seller dashboard with cut-offs/value dates; negative-balance handling; annual reporting fields (DAC7/1099-K data); FX sweep logic with benchmark reporting.
Ship corridors, not universes. Consistency beats feature bingo.