Stripe Connect: Destination Charges vs Separate Charges and Transfers for Marketplaces

Use destination charges when a customer pays your marketplace for an order fulfilled by one connected seller and you want the seller's share transferred automatically. Use separate charges and transfers when one payment must fund multiple sellers, the recipient is unknown at checkout, or transfers must happen later. Both models charge the customer on the platform account, and both generally leave the platform responsible for Stripe processing fees, refunds and disputes.

The difficult part is not getting a checkout page working. It is designing what happens when an order is partially fulfilled, a seller changes, a bank payment fails, a refund arrives after a transfer, or a dispute removes money from the platform balance. This guide compares the funds flows and provides a decision framework, ledger model and launch checklist for marketplace founders and engineering teams.

Destination charges vs separate charges and transfers: the short answer

Stripe Connect supports direct charges, destination charges, and separate charges and transfers. Stripe's official charge-type comparison distinguishes them by where the charge is created, how funds move, and which account absorbs fees and payment reversals.

These are payment routing models, not escrow products. A delayed transfer does not grant unlimited permission to hold customer money. Stripe's account balance guidance says holding periods and purposes are constrained, and recommends legal advice when uncertain.

When should a marketplace choose destination charges?

Choose destination charges for a single-seller transaction where the recipient is already known and you want Stripe to route the seller's share as the charge is captured. Examples include a booking marketplace paying one service provider or a platform selling one merchant's item per checkout.

A destination charge is created on the platform account. The seller's portion moves automatically into the connected account's Stripe balance, initially subject to Stripe's pending/available balance rules. That is not the same as an immediate bank payout. Stripe documents the mechanics in its destination charges integration guide.

For a hypothetical $100 order with a $15 platform application fee:

Customer pays $100
       |
Platform creates destination charge
       |
Connected account receives the charge allocation
       |
$15 application fee is transferred back to platform
       |
Stripe processing fees are charged to platform

The $15 is gross platform fee revenue, not profit. Actual net proceeds depend on Stripe fees, refunds, disputes, other operating costs and any taxes. This example is illustrative, not a Stripe pricing quote.

Stripe also supports specifying a smaller __INLINE_CODE_0__ rather than collecting an explicit application fee. Those approaches have different reporting and connected-account visibility implications; do not treat them as identical in accounting.

What if the customer pays for multiple sellers?

A destination charge is generally the wrong default for a single cart containing several independent sellers. One destination charge routes funds to one connected account. You could split the customer experience into separate charges, but that changes checkout, receipts, refunds and potentially payment costs. If a single customer payment needs to fund several recipients, Stripe recommends separate charges and transfers.

When should a marketplace choose separate charges and transfers?

Choose separate charges and transfers when payment collection and seller allocation must be independent operations. Stripe specifically identifies multi-party transactions, unknown recipients and deferred transfers as reasons to use this more complex model. See Stripe's Connect charge-type guide.

Imagine a hypothetical $100 order involving a restaurant, a courier and the marketplace:

Customer pays $100 to marketplace
            |
      Platform charge
            |
     Payment confirmed
            |
      Allocation ledger
       /           \
$70 restaurant   $20 courier
       \           /
  $10 retained by platform
  before Stripe fees and other costs

The platform creates separate transfers to each connected account. It must also handle retries, payout readiness, reconciliation, reversals and any mismatch between the internal order ledger and Stripe objects.

The platform's retained $10 is not automatically an __INLINE_CODE_0__ object. For separate charges and transfers, fee economics are normally expressed through how much is not transferred. This distinction matters for reporting.

What does __INLINE_CODE_0__ do?

A __INLINE_CODE_0__ is a useful correlation identifier that links payment and transfer objects to one business action. It does not, by itself, reserve money or delay a transfer until funds are available. Stripe documents that distinction in its separate charges and transfers guide.

What does __INLINE_CODE_0__ do?

When supported for the payment flow, __INLINE_CODE_0__ associates a transfer with a specific charge and can defer execution until the charge's funds become available. This helps avoid insufficient-available-balance failures, but it is not a substitute for checking whether an asynchronous payment ultimately succeeded. Stripe warns that delayed payment methods can fail after a transfer is requested. A production design should wait for confirmed payment success when appropriate and implement recovery for failures.

What happens when the customer requests a refund?

For both indirect charge types, Stripe debits the platform balance for the customer refund. The seller's money does not automatically return just because the customer was refunded. The recovery path differs by model.

Destination charge: By default, the connected seller keeps the transferred amount. Stripe supports __INLINE_CODE_0__ when refunding the charge, subject to the relevant constraints. If the platform also wants to return its application fee to the connected account, the __INLINE_CODE_1__ behaviour must be handled deliberately. For a partial refund, reversal amounts may be proportional.

Separate charges and transfers: Refunding the charge does not reverse its associated transfers. The platform must calculate and execute transfer reversals or reconcile the amount against later transfers. That calculation is a product decision: if only one seller's item was returned, reversing every seller's share would be wrong.

These behaviours are documented in Stripe's marketplace refunds and disputes guide.

Example: one item in a multi-seller order is refunded

Suppose a $100 order originally allocated $70 to seller A, $20 to seller B and $10 to the platform, before processing fees. If the customer receives a $30 refund for seller A's item, do not assume the correct recovery is simply 30% of every transfer. The platform needs a per-line-item allocation rule that answers:

1. Which seller's obligation changed?
2. How much of that seller's transfer has already occurred?
3. Does the platform return any portion of its fee?
4. Is the connected account balance sufficient for reversal?
5. What happens if recovery fails but the customer refund must proceed?

The exact figures depend on the marketplace contract and fee policy. Store the policy and resulting amounts as ledger entries rather than recalculating them from the current product catalogue.

Who pays when there is a dispute or chargeback?

For destination charges and separate charges and transfers, Stripe debits the disputed amount and dispute fee from the platform balance, with or without __INLINE_CODE_0__. The platform can attempt to recover funds from a connected account through transfer reversal, but recovery is not guaranteed. Stripe explicitly describes the platform's liability in its disputes documentation.

Build dispute handling as a financial workflow, not merely an email alert:

• Record the dispute against the original charge and affected order lines.
• Preserve delivery, booking, communication and fulfilment evidence.
• Track Stripe's evidence deadlines and dispute status.
• Record attempted transfer reversals and their outcomes.
• Reconcile funds reinstated after a won dispute before paying a seller again.
• Review cross-border restrictions before reversing or retransferring funds.

A refund, a dispute debit, a transfer reversal and a subsequent recovery are different financial events. Collapsing them into one __INLINE_CODE_0__ field creates reconciliation blind spots.

Does __INLINE_CODE_0__ change the charge type or remove platform liability?

No. __INLINE_CODE_0__ controls settlement-merchant details such as statement descriptor, settlement country and certain payment configurations. It does not convert an indirect charge into a direct charge or automatically shift Stripe's refund and dispute debits away from the platform.

Stripe explains the settlement effects in its charge-type documentation. The legal merchant-of-record question, customer contract and tax treatment also need separate review; do not infer legal status solely from one API parameter.

What if the platform and sellers are in different countries?

Check the exact platform country, connected-account country, charge type and __INLINE_CODE_0__ configuration before committing to a payment architecture. Stripe's cross-border payouts documentation lists supported regions and restrictions. It is not safe to assume every seller in every country can receive the same kind of Connect transfer.

Cross-border eligibility, currency conversion, settlement merchant details and account capabilities can change which design is available. Validate the actual account configuration in Stripe test mode and against current regional documentation before promising a marketplace launch date.

The missing architecture: an allocation ledger

For a marketplace with multiple recipients, your internal allocation ledger should explain every cent independently of Stripe's Dashboard. Stripe objects are the payment processor's record; your ledger connects them to orders, sellers, fees and fulfilment obligations.

A minimal design might use these records:

Store money in integer minor units and retain currency for every amount. Use database transactions and unique constraints to prevent duplicate allocations or transfers. A webhook can be delivered again, so processing must be idempotent. The separate Softotic guide on Stripe webhook duplicates and event ordering covers that reliability problem in more depth.

Payment and transfer state should be separate

A customer payment can be successful while the seller transfer is pending or failed. A seller transfer can be completed before a later customer dispute. Track at least:

payment:  pending -> succeeded | failed
transfer: planned -> requested -> completed | failed
refund:   requested -> pending -> succeeded | failed
recovery: not_required | planned -> attempted -> recovered | unrecovered

These are illustrative application states, not a claim that Stripe uses these exact enum values. Persist Stripe IDs and actual API statuses alongside your internal states.

A five-question decision framework

Before choosing the charge type, answer these in order:

1. Who is the customer buying from? If the seller transacts directly with the customer and owns the payment relationship, also evaluate direct charges. Stripe says they are often suited to SaaS platforms serving independent businesses.
2. Can one checkout include more than one seller or recipient? If yes, favour separate charges and transfers.
3. Is the seller known when payment is captured? If no, separate charges and transfers are usually the better fit.
4. Should the seller's allocation move automatically at capture? If yes and there is one seller, destination charges may reduce complexity. If not, investigate separate transfers and the applicable holding rules.
5. Can the platform operate refunds, disputes, reversals and reconciliation? If not, reconsider the business model or simplify the first release before accepting marketplace payments.

Do not choose separate charges and transfers merely because they sound more flexible. Stripe calls them a more complex integration and recommends using them when the business model requires it.

What should you test before launch?

Use Stripe test mode to verify the complete lifecycle, not just a successful card payment:

• One seller, one payment, expected platform fee and transfer.
• Multiple sellers, one payment, exact allocations and transfer IDs.
• Asynchronous payment still processing, then success or failure.
• Insufficient available balance and failed-transfer retry behaviour.
• Full refund and partial refund affecting only the appropriate seller.
• Transfer reversal failure because the seller has insufficient funds.
• Dispute after a seller transfer, including evidence and recovery tracking.
• Duplicate and out-of-order webhook delivery.
• Cross-border account eligibility, where relevant.
• Daily reconciliation of orders, payments, transfers, refunds, disputes and Stripe fees.

For teams commissioning a marketplace, the charge model and ledger should be decided during web application architecture, before checkout screens are treated as finished. If your platform has multiple sellers, complex commissions or delayed fulfilment, Softotic's custom software team can help define the payment flows and reconciliation requirements. To review a specific marketplace model, contact Softotic with an example order, seller allocation and refund scenario.

FAQs

Can Stripe Connect split one payment between two sellers?

Yes, with separate charges and transfers. The platform creates one customer charge and separate transfers to the connected accounts, subject to Stripe's supported-region and balance rules.

Are destination charges cheaper than separate charges and transfers?

Not necessarily. The best choice is driven by the funds flow and operational complexity. Actual processing and Connect fees depend on account configuration, region and pricing arrangement. Compare current Stripe Connect pricing rather than assuming one API pattern has a universal lower fee.

Does a destination charge pay the seller's bank immediately?

No. It transfers funds to the connected account's Stripe balance; the funds may be pending and bank payouts follow the applicable payout schedule.

Can I hold marketplace funds until a service is completed?

Sometimes, within Stripe's rules and the applicable legal framework. Separate charges and transfers provide more control over when the seller transfer occurs, but that is not unlimited escrow. Review Stripe's balance and holding guidance and obtain legal advice where needed.

Does refunding a separate charge reverse seller transfers?

No. Stripe says refunds on separate charges and transfers do not automatically affect associated transfers. Your platform must reconcile and reverse or recover the appropriate seller amounts.

Is __INLINE_CODE_0__ the same as a direct charge?

No. It influences the settlement merchant and customer-facing payment details on an indirect charge. The platform still bears refund and dispute debits for destination charges and separate charges and transfers.

Sources and references

• Stripe Docs: Understand how charges work in a Connect integration
• Stripe Docs: Create destination charges
• Stripe Docs: Create separate charges and transfers
• Stripe Docs: Handle refunds and disputes in a marketplace
• Stripe Docs: Understanding Connect account balances
• Stripe Docs: Cross-border payouts
• Stripe: Connect pricing