--- title: "Marketplace Payments and Payouts" description: "Map account verification, customer charges, commissions, transfers, bank payouts, refunds, disputes and reconciliation before choosing a payment setup." canonical: https://www.ordering.co/blog/marketplace-payments-and-payouts/ --- # Marketplace payments and payouts: who owns each money movement Map account verification, customer charges, commissions, transfers, bank payouts, refunds, disputes and reconciliation before choosing a payment setup. 4 min read· Ordering.co· Guides ## 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](https://docs.stripe.com/connect/charges) 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](https://docs.stripe.com/connect/marketplace/tasks/accept-payment/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](https://docs.stripe.com/connect/marketplace/tasks/refunds-disputes) 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](https://www.ordering.co/integrations/stripe-connect/) 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](https://www.ordering.co/demo/) and implementation review. Use the [two-sided marketplace guide](https://www.ordering.co/blog/two-sided-marketplace-business-model/) to keep seller, customer and operator responsibilities aligned with the money flow. ## Keep reading. - ## [Rappi marketplace delivery versus Rappi Cargo: who owns the order?](https://www.ordering.co/blog/rappi-delivery-vs-rappi-cargo/) Separate orders placed in the Rappi marketplace from deliveries requested through Cargo, and compare checkout, customer data, dispatch, costs, and support. - ## [B2B marketplace examples: where to buy, sell, or build your own channel](https://www.ordering.co/blog/b2b-marketplace-examples/) Compare Faire, Amazon Business, JOOR and Ankorstore by buying model, category, geography, payment terms and the case for your own B2B channel. - ## [Dark store versus local delivery marketplace: choose who fulfills the basket](https://www.ordering.co/blog/dark-store-vs-local-delivery-marketplace/) Use DashMart's published model to compare a dedicated fulfillment location with merchant-store delivery, including inventory, picking, costs, and platform scope. ## See it running on your own menu. The shortest way to understand any of this is to watch an order go from a storefront to a store to a driver, on your locations. [Book a demo](https://www.ordering.co/contact/?meeting=demo#book)[See a live demo](https://www.ordering.co/demo/)