Running a multi-country marketplace. 7 chapters and a final quiz.

Chapter 1. The chart of accounts and the split engine.

A marketplace collects money that is not entirely its own. The first technical deliverable is neither the provider’s API nor the checkout flow. It is a ledger that knows, to the second, who owns every cent held. Everything else hangs off it. The reconciliation in chapter 2, the reserve in chapter 5, and the tax report in chapter 7 all read this same ledger. A badly designed ledger costs you for years.

Five accounts, and not one fewer

• Safeguarding account: the actual bank account that holds third-party funds. A single line, the one on the bank statement.
• Seller balances: one subledger per seller, moved by sales, refunds, and clawbacks. The total can always be computed.
• Earned commissions: the platform’s share, set aside at collection and withdrawn by an identifiable, dated outgoing transfer.
• Risk reserve: amounts held back for a seller or a category, owed to the seller but not yet available.
• Operating account: the platform’s own account, outside the safeguarding scope. No third-party funds ever enter it.

The split itself runs on versioned rules, never on code. Six parameters decide the result, and their order of application matters as much as their values. First the line price, then shipping fees, allocated to the seller or the platform, then the discount and who funds it. Next comes the commission base, with or without shipping, tax-inclusive or not, then the tax on the commission itself, and finally rounding.

CMD-2026-40118   3 lines   2 sellers   shipping 4.90 EUR paid by the buyer

  L1  seller V-8842   33.33 EUR   commission 12.5%
  L2  seller V-8842   33.33 EUR   commission 12.5%
  L3  seller V-1907   33.34 EUR   commission 18.0%   + shipping 4.90 EUR
      shipping goes to the seller and stays outside the commission base

1) commission line by line, rounded to the nearest cent
   L1   33.33 x 0.125 = 4.16625  ->  4.17
   L2   33.33 x 0.125 = 4.16625  ->  4.17
   L3   33.34 x 0.180 = 6.00120  ->  6.00

2) seller share = line price MINUS line commission
   never a second percentage: the classic source of the lost cent
   L1   33.33 - 4.17 = 29.16
   L2   33.33 - 4.17 = 29.16
   L3   33.34 - 6.00 = 27.34   + 4.90 shipping = 32.24

3) balance check, run before the entry is committed
   collected         33.33 + 33.33 + 33.34 + 4.90 = 104.90
   seller balances   29.16 + 29.16 + 32.24         =  90.56
   commissions        4.17 +  4.17 +  6.00         =  14.34
   90.56 + 14.34 = 104.90   ->  balance OK

Chapter 2. Safeguarding: the account, the deadline, the reconciliation.

Safeguarding is judged on three daily routines, not on a contract clause: where the funds arrive, when they reach the protected account, and how you prove every evening that the account holds exactly the sum of what sellers are owed. The regimes differ on the legal mechanism but converge on the burden of proof. A team either produces that proof or it doesn’t.

SAFEGUARDING ACCOUNT RECONCILIATION   —   2026-03-17   —   EUR

A   closing bank balance, safeguarding account statement      412,908.44
B   sum of seller balances, platform ledger                   387,214.10
C   earned commissions not yet withdrawn                       19,402.88
D   risk reserve held                                           8,000.00
E   payouts issued, not yet debited (in flight)                -1,708.54

check       A - (B + C + D + E) = 0
            412,908.44 - (387,214.10 + 19,402.88 + 8,000.00 - 1,708.54)
            412,908.44 -  412,908.44 = 0        ->  RECONCILED

alert threshold |gap| > 0.00 EUR on 2 consecutive days
                -> compliance incident, not an accounting anomaly

The five recurring breaks, and what causes them

• Payout returned by the seller’s bank: the amount comes back to the safeguarding account, and it must go back to the seller’s balance, not to the operating account.
• Posting date mismatch: the acquirer books a chargeback the day before the platform receives it. The break clears on its own, but it still gets documented.
• Bank fees debited from the safeguarding account: prohibited, yet common when a new account is set up wrong. Fix it with the bank; don’t offset it with an entry.
• Collection assigned to an unknown seller: the order was canceled between payment and allocation. The money sits in the bank with no identified owner.
• Currency conversion applied on credit: the account is held in one currency, the collection arrives in another, and an FX difference creeps in unnoticed.

Chapter 3. Licensed partner or your own license: running the numbers.

The decision comes down to two numbers and a date, not a conviction. The first number is the partner’s annual cost, which grows with volume. The second, the annual cost of an in-house function, barely moves. The date is when the license can actually take effect, and that third term is where teams most often go wrong.

The calculation, with parameters to replace with your own

VOLUME ASSUMPTIONS (replace with your actual figures)
  annual GMV collected                           40,000,000 EUR
  active sellers                                     12,000
  payouts per seller per year                            24
  new sellers verified during the year                3,000

PARTNER PRICING (replace with the offer you received)
  variable fee on GMV                                 0.25%
  fee per payout                                      0.25 EUR
  fee per seller verification                         2.50 EUR

ANNUAL PARTNER COST
  variable      40,000,000 x 0.0025            =  100,000.00
  payouts       12,000 x 24 x 0.25             =   72,000.00
  verifications  3,000 x 2.50                  =    7,500.00
  total                                        =  179,500.00 EUR

ANNUAL COST OF THE IN-HOUSE FUNCTION (to estimate, line by line)
  permanent compliance and risk team
  external audit, internal control, periodic reporting
  connection to and maintenance of the payout rails
  initial capital: TIED UP, not spent -> excluded from this total

BREAK-EVEN POINT
  variable fee x GMV = annual cost of the in-house function
  capital never enters this equation: it weighs on cash,
  not on the income statement

• The timeline sets the go-live date, not the budget. The authority informs the applicant within three months of receiving a complete application (Directive (EU) 2015/2366, Article 12). The clock only starts once the application is complete, and no law limits the preparation phase before it.
• A marketplace remains responsible for its seller base even when the partner holds the license: the marketplace designs the onboarding flow and explains any rejection.
• Hybrid setups exist: a licensed partner in launch markets, your own license in the home market. It doubles the reconciliation workload, and it should be a deliberate choice.

Scoring a tender for platform payment providers

Institutions that provide the setup for platformsStripe ConnectAdyen for PlatformsMangopayPayPal Commerce PlatformPAPayoneerDLdLocal

Chapter 4. KYB by country: one form, N registries.

A seller fills in one form, once. Behind it, three regimes consume that data and two separate gates open. Anti-money laundering rules govern the right to be paid; trader traceability governs the right to sell. Tax collection governs both, by blocking sellers who don’t respond. The engineering job is to model a single record, then plug the right national registry in behind each field.

type DossierVendeur = {
  // legal identity — collected once, read by all three regimes
  paysEtablissement: string        // ISO 3166-1 alpha-2
  identifiantEntreprise: string    // CNPJ, ABN, UEN, company number...
  registreSource: string           // where the number was verified
  verifieLe: string | null         // timestamp of the VERIFICATION, not of data entry

  // AML/CFT due diligence
  beneficiairesEffectifs: { nom: string; part: number }[]
  filtrageSanctionsLe: string | null

  // trader traceability — Regulation (EU) 2022/2065, Article 30
  contact: { adresse: string; telephone: string; courriel: string }
  autocertification: boolean

  // tax — DAC7, UK rules, 1099-K
  identifiantFiscal: string | null
  etatResidenceFiscale: string | null

  // payout account
  coordonnee: { type: "iban" | "chave-pix" | "vpa" | "aba" | "payid" | "uen"; valeur: string }
  appartenanceVerifiee: boolean
}

// TWO gates, never one: selling and getting paid don't open together
const peutVendre = (d: DossierVendeur) =>
  d.verifieLe !== null && d.autocertification && d.contact.adresse !== ""

const peutEtrePaye = (d: DossierVendeur) =>
  peutVendre(d) &&
  d.appartenanceVerifiee &&
  d.filtrageSanctionsLe !== null &&
  d.identifiantFiscal !== null

Re-verification triggers

• Change in beneficial owner: in the EU, the ownership stake that makes someone a beneficial owner is set at 25% (Regulation (EU) 2024/1624, Article 52). Crossing it triggers a new review of the record.
• Change in payout details: the highest-value signal in the whole chain, and the most common one when an account is compromised.
• Change in sales category: a clothing seller who switches to high-value electronics changes both its risk profile and its dispute profile.
• Reactivation after dormancy: a record verified three years ago says nothing about the business today.
• Crossing a volume threshold: the thresholds that trigger a change of status are local, and they apply to the seller as well as to the platform.

Chapter 5. Payouts: trigger, reserve, rail.

The payout schedule is a marketplace’s most sensitive parameter. Paying out fast attracts sellers and drains your collateral; paying out late protects cash and drives good sellers away. The setting isn’t decided for the whole platform but by sales category. Risk doesn’t expire on the same date for a book as for a vacation stay.

Sizing the reserve on the actual window

A reserve is sized on the dispute window, not on gut feeling. For merchandise not received, Visa rules allow 120 days from the expected delivery date, up to a limit of 540 days after the transaction. A rolling reserve of 5% of sales collected over 120 days therefore covers a net dispute rate of 5% over that same window. Redo the calculation by category, using the observed rate, never a marketplace-wide average.

Chapter 6. The three-party dispute.

A marketplace dispute pits a buyer against a seller, but it is settled between the issuer and the platform. That asymmetry explains almost every failure you see. The buyer files a dispute with their bank, the issuer claws the funds back from the acquirer, and the acquirer claws them back from the platform. The seller never sees the reason code, the network deadline, or the case file. The platform therefore plays two roles at once: party to the card dispute and arbiter of the commercial dispute.

Deflect before you defend

• A visible internal claims channel: a buyer who finds a button doesn’t call their bank. It is the cheapest lever, measured by the share of disputes opened outside the network.
• A recognizable statement descriptor: one dispute in two starts with a buyer who doesn’t recognize the line on their statement.
• Pre-dispute alerts: Verifi on the Visa side and Ethoca on the Mastercard side flag the dispute before it is formally filed and give you time to refund.
• A voluntary, documented refund: issued before the dispute is filed, it can be argued in your favor and doesn’t count toward the dispute ratio. It costs the amount, not the amount plus dispute fees.
• Automated evidence collection: asking a seller for a tracking number three months after the sale gets you nothing. Capture tracking at shipment, in the same call as the payout trigger.

Then comes allocation, where you find out what the marketplace agreement really says. The clawback debits the seller’s balance. If that balance doesn’t cover it, it goes negative and is netted against later sales; if the seller stops selling, the receivable is collected or provisioned. The contract must name who ultimately bears the loss before the incident, and the provider’s configuration must say the same thing. Any gap between the two surfaces on the day of the first large chargeback.

Chapter 7. DAC7 and 1099-K: building the extracts.

Two reporting regimes read the same ledger and don’t pull the same number from it. DAC7 asks for the consideration paid or credited to the seller, broken down by quarter, with the number of activities and the platform’s deductions. Form 1099-K reports the gross amount of the year’s payment transactions, with no deduction for commissions or refunds. Writing a single aggregation for both produces two wrong reports.

-- DAC7: consideration paid or credited, broken down by QUARTER,
-- with the number of activities and the platform's deductions.
SELECT vendeur_id,
       DATE_TRUNC('quarter', date_evenement)  AS trimestre,
       SUM(part_vendeur)                      AS contrepartie,
       COUNT(*)                               AS nb_activites,
       SUM(commission + frais + taxes)        AS retenues
FROM   grand_livre
WHERE  type_evenement IN ('vente', 'remboursement')
  AND  annee_civile = 2026
GROUP  BY vendeur_id, trimestre;

-- 1099-K: GROSS amount of the year's payment transactions,
-- with no deduction for commissions, fees, or refunds.
SELECT vendeur_id,
       SUM(montant_brut)  AS brut_annuel,
       COUNT(*)           AS nb_transactions
FROM   grand_livre
WHERE  type_evenement = 'vente'
  AND  annee_civile = 2026
GROUP  BY vendeur_id;

-- Corrections are assigned by the date of the ORIGINAL event:
-- a January 2027 refund on an October 2026 sale belongs
-- to Q4 2026 for DAC7.