Stripe Connect Fund Flow Patterns for Marketplaces

Stripe Connect fund flow patterns determine more than where a marketplace sends money. The choice between direct charges, destination charges, and separate charges and transfers fixes transaction ownership, refund liability, and payout mechanics early. The right pattern follows the marketplace’s business model, and its webhook handler, reconciliation job, and payout schedules must be designed around that choice from the start.

Why the fund flow decision is an architectural commitment, not a configuration detail

Stripe Connect orchestrates payments, payouts, onboarding, tax, and compliance across buyers and sellers. The charge pattern defines responsibilities that extend into dispute handling, seller balances, and the platform’s financial records. Changing it after launch requires a Stripe Connect migration. The decision made in week one can therefore govern the platform for years, which makes it a prerequisite to integration code.

How the three charge patterns differ in who owns the transaction

The core distinction is who Stripe treats as the merchant of record. That ownership determines the dispute and refund relationship. With direct charges, the buyer pays the connected account, and the platform collects its fee through application_fee_amount. The seller is the merchant of record and owns disputes and refunds with the buyer. Stripe routes disputes to that connected account.

With destination charges, the buyer pays the platform account, and funds transfer to the connected account. The platform is the merchant of record. It owns disputes and refunds even though the seller receives the funds. Separate charges and transfers also put the platform in that role, but the charge and the transfer are distinct operations. The platform charges the buyer first and transfers the seller’s portion later, controlling when that movement occurs.

Standard, Express, and Custom shape how sellers use their accounts and what the platform’s engineers must build. They do not replace the transaction ownership decision. Their fit follows from the charge pattern, with the control and compliance trade-offs considered after the fund flow is clear.

What destination charges actually cost the platform in refund and payout risk

Destination charges look simple at checkout because the payment and the transfer happen together. That simplicity reverses when a refund becomes necessary. A successful charge credits the connected account’s balance, where the funds enter its payout cycle. For US accounts, the default is a daily rolling payout, with a two-business-day settlement delay, or T+2, before funds become available. The settlement delay and the payout interval are different controls.

By the time a vendor rejects an order or a quality dispute arises, the seller’s funds may already have reached their bank. The platform still owns the refund obligation. Getting those funds back can require negative balance recovery once the money is no longer held in Stripe. Partial fulfillment brings the same risk when the captured amount is more than the value of what the seller delivers.

A team choosing this pattern should set a connected-account payout schedule that matches its refund risk. Weekly or monthly payouts give the platform more time to make refunds against settled balances, while daily payouts get money to sellers sooner but leave the platform with more risk after payout. Manual payouts give marketplaces with many refunds or disputes the most control because funds stay in the connected account balance until the platform triggers payout. The seller agreement must document that schedule. Changing it after onboarding is a leading source of seller support load.

When separate charges and transfers are necessary and what they require from the platform

Separate charges and transfers fit workflows in which the seller’s portion cannot be determined when the buyer pays. Funds may need to wait for delivery confirmation, vendor acceptance, or milestone completion before they move. The platform charges the buyer without a destination parameter, leaving the full amount in its own balance. Once the required business event occurs, it transfers the seller’s portion and retains its commission. Charge and release become separate responsibilities for the platform.

That control introduces a specific payout trap. Stripe’s default payout schedule can sweep the platform balance into the platform’s bank account before the seller release job runs. Stripe cannot tell which funds in that balance belong to sellers and which are platform revenue. The seller is then owed a transfer, but the balance intended to fund it is empty. Reconciliation is needed to detect the mismatch after the sweep has occurred.

The platform needs to set its own payout schedule to manual on day one. This is distinct from controlling connected-account payouts under destination charges. Here, the platform must preserve the funds needed for future transfers and build the release trigger as an explicit workflow. The same pattern allows multi-party splits by making a transfer call to each connected account after a single buyer charge settles.

Why immediate capture breaks marketplace payment logic and how authorization solves it

Immediate capture breaks marketplace logic when order placement happens before the business can confirm what it will fulfill. Vendors may still need to review items. If a standard PaymentIntent captures at checkout, rejected items require refunds against captured funds, while platform fees may have been calculated on an order total that later changes. Those changes also make it hard to trust reconciliation against Stripe reports.

For decisions that resolve after checkout, the recommended approach is manual capture on the PaymentIntent. Authorization reserves funds on the buyer’s card without moving the money. The PaymentIntent enters requires_capture, and the platform resolves vendor decisions or partial fulfillment before calculating the final amount. It then calls capture exactly once with the confirmed figures. This separates the buyer’s commitment from the marketplace’s final payment calculation.

The authorization window imposes a real timing constraint. Stripe does not hold an authorization indefinitely, so the workflow must complete its decisions and capture before the hold expires. Workflows that take longer than the authorization window need separate charges and transfers with an explicit escrow hold.

How Stripe's account types map onto charge patterns and who controls the seller experience

Account selection determines how much of the seller experience the platform must build and maintain. Standard accounts place onboarding and the dashboard with Stripe. The seller already owns a Stripe account and grants the platform access, making this the lowest-engineering-load option and primarily compatible with direct charges. That arrangement fits a transaction model in which the seller is the merchant of record.

Express balances platform control with Stripe-hosted onboarding and compliance. It works with all three charge patterns. The platform can customize the experience while Stripe handles KYC and fraud, making Express the recommended starting point for most marketplaces. A team seeking greater branding control should start there and migrate to Custom later if needed.

Custom requires the platform to build onboarding, the seller dashboard, and dispute tooling from scratch. It also puts KYC, fraud, and compliance responsibility on the platform. Full white-label control justifies that burden only when the seller experience requires it and the team can maintain it.

Stripe launched Accounts v2 in December 2025 and recommends it with configurations for new marketplaces. Its merchant, customer, and recipient configurations add a capability axis rather than directly replacing Standard, Express, and Custom. The legacy account types remain supported. Teams must therefore still decide how much of the seller experience they will own.

Webhook architecture as the operational foundation the charge pattern depends on

Each charge pattern has work that happens asynchronously and must update application state. Authorization, destination charges that succeed, and transfers that complete all send webhook events. A checkout response cannot stand in for that lifecycle. The platform needs an event-processing foundation that handles those transitions without making receipt of an event depend on completing its business logic.

The recommended design separates receiving from processing. The webhook handler validates the Stripe signature, writes the raw payload to a stripe_events table, and returns HTTP 200 without doing further work. A background worker pulls from that table, processes one event at a time, and updates application state.

Deduplication on event.id needs a database UNIQUE constraint or a Redis lock because application-layer checks alone can race. Failed processing returns to the queue with exponential backoff and pages on-call after N retries. Event rows should remain available for a meaningful retention window so the platform can replay them when a processing bug is discovered later.

Why a nightly reconciliation job is mandatory, not optional, for any of these patterns

Webhooks can be dropped, duplicate events can escape deduplication, and application fees can be miscalculated on discounted items. Refund adjustments can also be recorded incorrectly. These failures can remain silent until a seller raises a support ticket or an audit exposes the discrepancy, so event processing alone cannot validate the platform’s records.

The required safety net is a daily ledger comparison. A nightly job should pull every Stripe charge from the trailing seven days, match it against platform orders, and flag mismatches. It should also check that payouts match what was expected for each connected account and flag amounts that differ by more than a set threshold. Refunds and disputes require corresponding adjustments in the platform’s records.

Stripe’s next-generation reporting APIs target enterprise-scale financial reconciliation workflows. Stripe described that focus in its September 18, 2026 engineering post. High-volume platforms should evaluate those APIs rather than defaulting to the core charges and payouts endpoints for this layer.

Testing the fund flow before it touches real money

Fund flow tests must keep state from one operation to the next. A PaymentIntent created in one call affects what the next call can retrieve, while a transfer changes the balance available for another transfer. Refunds against destination charges and separate charges leave balances in different states. A stateless mock cannot check how those operations affect each other, even if each response looks correct on its own.

Stripe sandboxes provide separate testing environments that mimic real-world situations without affecting live transactions. Connecting them to GitHub supports automated testing. This closes a gap left by mock-based CI, which does not verify actual Stripe fund flow behavior. Configuration errors such as a missing on_behalf_of parameter or a miscalculated application_fee_amount need testing against both that behavior and expected mock responses.

Failure handling needs deliberate testing as well. Fault injection lets teams exercise webhook processing, reconciliation, and retries when Stripe returns a 429 or a 503 at a critical point. These tests address resilience that is rarely exercised against a live sandbox. Together, stateful testing and injected failures verify both the intended flow and the operational layer that must recover when it is interrupted.

Choosing the pattern that fits the marketplace model

The decision starts with three questions, answered in order. Is the seller or the platform the merchant of record? Is the transfer amount known at checkout or only after a business event? Does the marketplace need explicit escrow or funds to be released when milestones are met? The answers establish transaction ownership first, then the timing constraints the integration must support.

If the seller is the merchant of record and the amount is known at checkout, direct charges with application_fee_amount fit the model. Standard or Express accounts keep the account choice aligned with seller ownership. If the platform owns the buyer experience and disputes, destination charges fit when the amount is already known. That choice calls for Express accounts, weekly or manual connected-account payouts from day one, and platform dispute tooling.

If the amount remains unresolved or release depends on escrow or milestones, separate charges and transfers provide the required separation. Express or Custom accounts fit that model. The platform payout schedule must be manual from day one, and the release trigger must be a first-class workflow. Where post-checkout decisions fit within an authorization window, manual capture should precede final payment across any of the three patterns.

The store-and-process webhook handler belongs before fund flow logic, and reconciliation must ship before the first seller is onboarded. Because changing the charge pattern later requires migration, its payout schedules and operational infrastructure must be part of the initial architecture.