A marketplace charge is not one payment, it is a split. This is how the split is constructed, and the invariants that keep it correct.
The model
Each seller holds their own connected account, in their own name, which they control and we cannot withdraw from. A buyer’s charge is created with the destination and the platform fee baked in, so the split executes at capture rather than being reconciled afterwards by a job that can fail.
charge
amount gross, integer cents
transfer destination the seller's connected account
application fee the platform's cut, integer cents
────────────────────
settles in one movement. no ledger sweep, no nightly jobThis is what DØLLs get paid first means mechanically. It is the order of operations inside the charge, not a sentiment.
Integer cents, everywhere
Conversion to a display string happens once, at the edge, on the way to the screen. Nothing is ever converted back.
The fee engine
One function, one rate, one place. It takes a gross amount and a seller, and returns the platform cut and the seller cut as integers that sum exactly to the input. The current live rate is a flat 6%.
- Rounding is resolved in one direction and stated. The two outputs must reconstruct the input, so one of them absorbs the remainder by rule rather than by accident.
- Legacy code paths exist for fundraiser and store rates that have no live product attached. They are flagged as legacy and are not reachable from any public surface.
- A refund reverses the fee. We do not keep a cut of money that went back.
Co-listed sales are a different shape
A co-listed product routes the buyer to the seller’s own checkout, so no money moves through us at all. Instead:
- The buyer completes the purchase on the seller’s store.
- An order webhook reports the paid order back to us.
- The order is recorded in the external-sale ledger as attributed volume.
- The fee is invoiced against that volume, rather than split at capture.
Two payment shapes for the same 6% is the cost of letting a brand keep its own checkout, and it is worth it. See List on Shopify.
Subscriptions
CLUB membership is a subscription product with a plan per tier and cadence. Prices in the application are display values; the real charge is the plan, and the two are kept in step by a sync script rather than by hand.
Webhooks
- Signature verified before anything is read. An unverified webhook body is untrusted input, not data.
- Handlers are idempotent. Providers retry, and a retry that double-credits an order is worse than one that does nothing.
- Fast acknowledgement, work afterwards. Slow handlers get retried, which is how duplicates start.
What we never hold
- Card numbers. Entered on a hosted field belonging to the processor. They never reach our servers or our logs.
- Seller balances. Money settles to their account, not into a pot we distribute from.
- Processing fees. A passthrough, taken before anything is counted.