Stripe Connect charge types determine where a payment is created and how funds reach connected accounts. They also affect whose balance is debited for fees, refunds and disputes. A platform should choose the funds flow together with its reconciliation and recovery process.
Start with the account that owns the charge
Stripe’s charge-types documentation describes direct charges and indirect charges. A direct charge is created on a connected account. An indirect charge is created on the platform, with funds then transferred to a connected account.
The indirect category contains destination charges and separate charges and transfers. Their difference concerns how the transfer is coupled to the payment.
Keep these product terms separate from the commercial description of a marketplace. “The seller receives the money” does not identify the account that owns the charge or the balance exposed to a refund.
The three patterns
| Pattern | Where the charge is created | How the connected account receives funds |
|---|---|---|
| Direct charge | Connected account | The payment belongs to that account, with applicable fees handled in the configured flow |
| Destination charge | Platform | A transfer to the specified destination is part of the charge flow |
| Separate charges and transfers | Platform | Transfers are created separately and can distribute funds to multiple connected accounts |
Source: Stripe Connect charge types, checked October 21, 2026.
The table describes the documented structure. It is not a recommendation that every platform in every region can use every pattern. Eligibility and configuration remain part of the provider’s current requirements.
Destination charges couple the payment and transfer
Stripe’s destination-charge documentation describes creating a charge on the platform, collecting fees and transferring the remaining amount to a connected account.
For a product team, the useful question is whether the recipient and allocation are known when the customer pays. If they are, that flow may fit the business process. The operational design still needs to handle a later refund or dispute.
A platform’s support interface should show both the customer payment and the connected-account transfer. Otherwise an operator may see a refunded payment and assume the corresponding funds have already been recovered from the recipient.
Use the provider’s documented reversal and refund behaviour rather than deriving it from a single status label.
Separate transfers need an allocation record
Stripe’s separate-charges-and-transfers documentation describes charging on the platform and transferring funds to multiple connected accounts.
A platform using this structure needs to explain how each transfer relates to the original payment. An internal allocation record can identify the intended recipients, amounts, transfer outcomes and any later recovery action.
Consider a hypothetical order involving two service providers. One payment is collected, then the platform allocates part to each provider. If only one provider cancels, a useful operations view can identify the affected allocation without treating the whole order as a single undifferentiated payout.
This is a design example, not a claim that Stripe supplies a complete order-allocation model for that business.
Refunds reveal the real operating model
Stripe’s overview identifies the account debited for refunds and chargebacks as a consequence of the charge type. Read that behaviour with the detailed refund and transfer rules for the selected integration.
A design review should walk through a customer refund after the recipient has already received funds. Identify who initiates the refund, which balance is debited, whether a transfer reversal is needed and what happens if recovery cannot complete.
Keep the customer obligation and the recipient recovery as separate tracked operations. A failed recovery should not disappear simply because the customer-facing refund completed.
The marketplace-chargeback guide covers the dispute workflow; marketplace payouts covers the later movement of funds to recipients.
Build reconciliation around identifiers
An order number is useful business context, but it should not replace the provider’s identifiers. Retain the relationship between the order, payment, transfer and any refund or reversal.
A reconciliation review can then ask concrete questions: did the payment succeed, were the intended transfers created, did each reach the expected state, and do later adjustments remain linked to the same allocation?
Define how the application handles an uncertain response before release. Repeating an operation blindly can create a second effect; assuming failure can leave an obligation unrecorded. Resolve the provider state and use the documented retry controls.
This sits alongside the ledger-balances guide, where pending, posted and available balances answer different operational questions.
Verify configuration with a failure scenario
Before adopting a flow, document the account configuration and use the provider’s supported testing process for a refund, a dispute and a failed transfer. Keep the results as evidence of that configuration, rather than claiming that one successful checkout validates the operating model.
The questions belong to engineering, operations and finance together. Each team needs to identify the same payment and understand which subsequent movement it is looking at.
