Draw the money flow before selecting the provider
A marketplace payment is more than a checkout success. Identify who sells to the customer, which account receives the charge, how each merchant and the platform earn their share, who funds a refund, and how money reaches the recipient’s bank. Record the commercial and operational responsibilities separately from API names.
Use five distinct events: customer payment, platform commission calculation, allocation or transfer to a recipient, payout to an external account, and reconciliation. A split shown on an order does not prove that a bank payout has completed.
Onboard the actual recipient, not a placeholder merchant
Confirm platform and recipient countries, business type, supported activity, payment methods, currency, required verification, and bank-account eligibility. Assign who requests missing information and communicates restrictions. Do not promise that registration alone enables charging or payouts, or that a previously verified account can never need another update.
Use the provider’s current requirements for the exact account configuration. Test an incomplete application, a restricted recipient, changed business details, and a failed or unavailable payout method. Collect sensitive onboarding information through the appropriate provider flow rather than adding unnecessary identity documents to ordinary order support.
Understand the charge pattern you are implementing
Stripe’s Connect charge documentation distinguishes direct charges on connected accounts from platform charges with destination transfers or separate transfers. Fee and reversal behavior depends on that choice; the patterns are not interchangeable labels for the same integration.
With separate charges and transfers, one platform payment can be associated with transfers to multiple recipients. Stripe distinguishes those transfers from bank payouts and documents balance and geographic restrictions. This is a provider architecture example, not a statement that every Ordering.co installation uses this pattern or that every territory can receive the same flow.
Keep an explainable allocation ledger
Illustrative accounting example, not provider pricing or an automatic product workflow: an order contains $60 for merchant A and $40 for merchant B. With an agreed 10% platform commission on those subtotals, the allocations are $54 to A, $36 to B, and $10 platform commission, before processing fees and other costs.
If $20 of A’s items are refunded and the agreement returns the corresponding commission, the adjustment is $18 against A’s allocation and $2 against platform commission. Remaining amounts are $36 for A, $36 for B and $8 for the platform: $80 after the $20 customer refund. That arithmetic does not decide who pays processing fees, covers insufficient balances, or handles tax; those need their own rules.
Store order and merchant references, currency, original amounts, commission basis, provider charge reference, allocation/transfer references, refund references, and bank-payout references. Reconcile gross amounts, fees and net movements without counting the same funds twice. A split payment across the customer’s cards is a different problem from distributing receipts among sellers.
Treat refunds, reversals and disputes as different operations
Stripe’s marketplace refund and dispute guide describes how indirect charges can debit the platform balance, with transfer reversal used to recover funds. A customer refund and recovery from the merchant are therefore separate actions to track.
Define who approves refunds, whether commission is returned, what happens after a bank payout, and who supplies dispute evidence before the provider deadline. Test partial refunds across merchants, insufficient balance, duplicate notifications, failed recovery, and a dispute that arrives after fulfillment. A ledger entry alone cannot recover money from another party.
Compare onboarding APIs and operating responsibilities
There is no universally best marketplace API without the operating model. Compare a candidate’s eligible countries and activities, hosted or embedded onboarding, requirement updates, test coverage, event delivery, retry/idempotency behavior, refund and dispute tools, reconciliation exports, support, and the responsibilities your team must retain. Test the same restricted-merchant and failed-payout examples rather than ranking providers from feature counts.
A retailer’s own branded card program is a separate issuing and commercial arrangement. Cardholder terms, funding, permitted use, incentives and any revenue share require their own provider agreement; receiving a commission through a marketplace split does not create a card program or guarantee interchange revenue.
Verify the actual Ordering.co configuration
The Ordering.co Stripe Connect integration documents automatic platform/business payment splits and available driver splits. Bank payouts follow the connected account’s settings and provider schedule. Do not infer a specific Connect charge pattern, cross-border approval, or every reversal automation from the existence of that feature.
Bring one normal order, a multi-merchant allocation, partial refund, restricted account and failed payout to the demos and implementation review. Use the two-sided marketplace guide to keep seller, customer and operator responsibilities aligned with the money flow.