Payouts run on Stripe Connect Express. BoostEcom never holds your bank details: Stripe does the onboarding, the identity verification and the transfer.
Set-up: /account/settings/payouts.
Onboarding
You are walked through Stripe's own Express flow. Your account moves through four states:
PENDING → RESTRICTED → ENABLED, or REJECTED.
Only ENABLED receives money. If Stripe still needs a document, the
account sits in RESTRICTED and the dashboard names what is
outstanding, because the requirements are mirrored from Stripe rather
than guessed at.
Status is kept in sync by the account.updated webhook. You can open
the Stripe Express dashboard at any time from the same page.
You are not paid at checkout
A buyer's payment sits in escrow for the whole 14-day dispute
window. The marketplace-payouts cron releases the net once that
window closes with no dispute open.
This is the deliberate trade: it is what makes a purchase safe enough to make, and it is why a buyer's dispute can still stop a payout after the sale.
The cron releases nothing to an account that is not ENABLED, which is
also why the seller is not KYC-gated inside the deal pipeline — Stripe
already checked.
Subscription listings pay monthly
A subscription listing bills the buyer every month, and every paid month produces its own order with its own escrow window from its own payment date.
Before this rule existed, only the first month ever reached the seller: renewal invoices resolved no local subscription and fell through untouched, so the platform collected 100% of months two onward with no order, no event, and nothing the dashboard could show.
What share is yours
The split is computed on the invoice total excluding tax, capped at the amount actually paid.
VAT collected on behalf of a state is not revenue and is never shared. Invoice-level discounts are respected rather than ignored. The platform fee is 3%.
Idempotency, and why it is in the database
A duplicate payout row would be a second real transfer of real money. Stripe replays a webhook delivery for up to three days, and the event-id table only deduplicates identical events, not the same invoice arriving by another path. So the guarantee is a unique constraint in Postgres on the invoice id, where it cannot be bypassed by application code.