Refunding the buyer and recovering money from a seller are different transactions. Follow the charge, the transfer, and the ledger.
Verified: October 26, 2026 · Ecom Ratings · 2,708 words
Stripe Connect can make a marketplace’s payment flow look deceptively simple: a buyer pays, a seller receives a share, and the platform retains a fee. The complication arrives when that buyer receives a refund after money has already moved. Which balance loses the refund? Does Stripe retrieve the seller’s transfer automatically? What happens to the platform fee? The answers depend on the charge type, not merely on who clicked the refund button.
This guide separates the initial refund debit, the later recovery from a connected account, and the ultimate commercial responsibility for the loss. These are different events. We trace direct charges, destination charges, and separate charges and transfers, with worked examples, an operational ledger and the cases a payments dashboard often obscures. Figures below are hypothetical USD amounts intended to illustrate accounting mechanics, not a statement of current processing rates.
The quick answer: find the charge owner first
Stripe Connect has three principal charge patterns. In a direct charge, the payment is created on a connected account; the refund generally uses that account’s balance. In a destination charge, the platform creates the charge and an associated transfer sends funds to a connected account. Stripe debits refunds from the platform, and recovery from the seller may require a transfer reversal. With separate charges and transfers, the platform also owns the charge, but the transfers are independent: refunding the buyer does not alter them.
This is why looking at a single line called “refund” is insufficient. The buyer may have received the money while the seller still retains the transferred amount. An application fee may also remain with the platform unless separately refunded. The gross payment, payment-processing fees, application fees, transfer reversals and bank payouts occupy different ledger lines. For indirect-charge models Stripe’s documentation explicitly puts refunds and dispute costs on the platform balance, even where a connected account is the settlement merchant.
| Charge pattern | Charge lives on | Refund debited from | What happens to seller funds? |
|---|---|---|---|
| Direct charge | Connected account | Connected account balance | No platform-to-seller destination transfer to reverse |
| Destination charge | Platform | Platform balance | Reverse the destination transfer when appropriate |
| Separate charges and transfers | Platform | Platform balance | Refund does not automatically reverse independent transfers |
Four different meanings of “who pays”
First is payment execution: which Stripe account creates a Refund object and whose balance receives the debit. Second is cash recovery: whether money previously transferred to a connected account comes back to the platform. Third is commercial allocation: what the marketplace’s seller agreement says about defective items, cancellations, fraud and chargebacks. Fourth is residual liability: who must cover the deficit if recovery fails and balances go negative. One business may initiate a refund while another ultimately bears its economic cost under contract.
Consider a $100 booking cancelled after the platform sent $85 to a provider. A platform-side refund can return $100 to the buyer immediately. Unless the $85 is recovered, the platform is out the refund while the provider still holds the funds. A contractual clause saying “providers are responsible for cancellations” does not change the Stripe balance movement. The contract gives a basis for recovery; the integration must implement it and finance must reconcile it.
Distinguish the Stripe account responsible for a payment from the party described to the customer as the seller. Parameters such as on_behalf_of can change the settlement merchant and statement descriptor without moving the charge from the platform to the connected account. In Connect terminology, a direct charge and an indirect charge remain different even if the buyer sees the same trading name on a statement.
Direct charges: the connected account owns the payment
With a direct charge, the PaymentIntent and Charge objects exist on the connected account. The payment increases its balance, and an optional application fee is paid to the platform. The natural refund route is therefore to act on the connected account’s charge using the proper account context. A developer who searches only the platform’s Charges list may incorrectly conclude that no payment exists; Stripe documents this visibility limitation explicitly.
A basic accounting example begins with a $100 payment and a $10 application fee. The customer pays the connected merchant. The connected account receives the payment subject to payment fees and the application-fee deduction, while the platform receives its $10 fee. If the merchant later issues a $100 refund, the refund debit belongs to the connected account’s balance. The platform should decide separately whether its $10 application fee is also to be returned; a customer refund and an application-fee refund are different operations.
“Connected account pays” is still not a blanket promise that the platform has no risk. Connect responsibility for negative balances and losses varies with account configuration and the contractual model. In particular, a platform can have responsibilities when a connected account cannot cover liabilities. Do not assume that the UI label “Express” or “Custom” alone answers the loss-allocation question. Audit the actual account capabilities and Connect responsibility settings in the live integration.
For operations, a direct-charge refund should be recorded against the connected account, the original charge, the platform application fee and any commission repayment. A refund created without the right account context can fail because the platform is looking for a charge that does not exist on its own Stripe account. This is a data-model problem, not a reason to recreate the original payment.
Destination charges: refund debit and transfer reversal
A destination charge is created by the platform, typically with transfer_data[destination]. Its funds are automatically associated with a transfer to the connected account. When the platform refunds the payment, the platform balance takes the refund debit. Stripe provides reverse_transfer to reverse the relevant transfer proportionately, and refund_application_fee to refund the associated application fee when appropriate. These controls should be used deliberately rather than treated as universal defaults.
Take a $100 purchase where $90 is transferred to the connected merchant and the platform retains a $10 economic share before its payment costs. A full refund from the platform returns $100 to the customer. If the platform also reverses $90, the connected account gives back its transfer and the platform recovers most of its cash outlay; the platform’s own $10 revenue is effectively relinquished as part of making the customer whole. The actual ledger also includes Stripe processing fees, which are not recreated in this simplified example.
If the refund goes through without transfer reversal, the buyer receives $100 but the seller’s $90 stays where it was. The platform now needs a recovery action under its rules. That is a material financing exposure for marketplaces with low cash buffers. A destination-charge configuration is not the same as automatic settlement of every refund-related obligation.
Note that a destination charge may identify the connected account using on_behalf_of as the settlement merchant. Stripe nevertheless says refunds and disputes on such indirect charges debit the platform balance. Merchant-of-record analysis for taxes and customer-facing obligations is a separate issue from which balance pays the refund.
Separate charges and transfers: the decoupling trap
Separate charges and transfers let a platform collect one payment and later send amounts to one or several connected accounts. Stripe describes this architecture as useful when the eventual recipient is not known at purchase time or a payment must be divided among parties. Here the charge and the transfer are two different transactions: issuing a refund does not automatically rewind the distribution.
Imagine a $120 order in which the platform transfers $70 to a seller and $25 to a service provider, keeping the remainder before processing costs. The order is later completely cancelled. The platform issues a $120 customer refund. Nothing about that action, by itself, says how to recover $70 and $25. The platform must reverse one or both transfers to the appropriate amounts, or net the amounts against future settlements if its contracts and systems allow that. A transfer_group helps correlate entries but is not itself an automatic refund mechanism.
A partial refund is more complicated. Suppose only one $30 line item is cancelled and that line was provided by the seller. Reversing a fixed 25% from every recipient would incorrectly charge the service provider for the seller’s cancellation. The allocation policy should start from the refunded item’s beneficiary, associated platform-fee policy and contractual terms. Only then should it produce specific reversal amounts for each transfer.
Stripe also documents conditions for reversing transfers, including available balance or connected-reserve requirements in relevant cases. If a seller already withdrew the money, a reversal may not be immediately possible. A reliable system marks the refund completed but the recovery unresolved, rather than falsely presenting the order as financially closed.
Worked example: a partial refund and the platform fee
Use this hypothetical destination-charge transaction: customer pays $200, seller transfer is $170, platform gross fee is $30, and we ignore processing costs to focus on distribution. The customer receives a 40% refund, or $80. If the platform’s policy allocates returns proportionally, the corresponding seller-share recovery is $68 and platform-fee giveback is $12. The customer receives $80; the seller ultimately retains $102, and the platform retains $18 of its original economic share.
| Ledger item | Before refund | Change | After proportional refund |
|---|---|---|---|
| Customer total paid | $200 | −$80 | $120 |
| Seller’s transferred share | $170 | −$68 | $102 |
| Platform’s gross share | $30 | −$12 | $18 |
Those figures describe a chosen commercial allocation, not a mandatory Stripe fee split. An item-level refund could be allocated differently. If the platform collected an application fee via Connect, use the documented fee-refund mechanism and record it separately. If the funds were distributed with separate transfers, the platform needs explicit reversal operations or a clearly controlled netting process. Rounding in minor currency units also matters: a percentage model that produces fractions of a cent needs deterministic rounding so cumulative partial refunds do not exceed the original charge or reversal amounts.
Reconcile gross amounts before evaluating profitability. Whether the original payment-processing fee is returned depends on the applicable Stripe fee policy and payment method; do not automatically add back the original processing fee as if the charge never happened. The cost of a refunded order may include fees that remain unrecovered even after all seller transfers have been reversed.
Refund the buyer, reverse the transfer, refund the fee: three actions
The first action creates a refund against a Charge or PaymentIntent. The amount can be less than the original payment, and successive partial refunds cannot exceed the total. The second action, where applicable, reverses a transfer to a connected account, moving funds back toward the platform. The third, where applicable, refunds the platform’s application fee. They concern different Stripe objects and accounting effects.
Stripe’s Refund API supports parameters such as reverse_transfer and refund_application_fee for supported Connect charge flows. This convenience does not mean that every separate transfer tied to an order is reversed automatically. In the separate-charges architecture you must identify the transfers and execute the appropriate reconciliation. Also distinguish an application fee refund from returning an arbitrary marketplace markup to a buyer; the former is a Connect object operation, and the latter is an economic label in the business’s ledger.
Implement an idempotent workflow. Store the refund ID, original charge ID, refund amount, seller allocation, relevant transfer IDs and reversal IDs. When a webhook is retried, the handler should reconcile existing objects rather than issue a duplicate credit or second transfer reversal. Payment services may be eventually consistent: a successful customer refund can precede a completed seller recovery. Operational dashboards should expose those states independently.
Negative balances, paid-out sellers and cash timing
Marketplaces commonly focus on what a seller owes in principle. Liquidity risk is about when the platform can get it back. If the platform transfers funds immediately and refunds days later, its balance may need enough cash to cover the whole customer refund before any recovery. A seller’s available Stripe balance may be small after payout. Reversal failure is therefore a business workflow, not merely an exceptional API error.
Stripe’s marketplace guidance discusses reserves and negative balances for indirect charges. Certain connected-account settings may permit automatic debits from external accounts in specified regions, but their availability and result should not be assumed. A negative balance does not guarantee immediate collection. The platform should track unrecovered refunds by seller, aging bucket and expected recovery path, and set limits on new payouts or exposure where its agreement and applicable rules permit.
Separate a customer-service SLA from seller reimbursement. It may be appropriate to refund a buyer quickly while allowing days for merchant recovery; if so, finance should recognize a receivable rather than treating the recovery as cash. Reporting a refund as “complete” is fair for the customer-facing action but misleading for internal cash management if half the economic settlement remains outstanding.
A reconciliation checklist your finance team can run
For each refunded order, obtain the payment’s charge type, original gross charge, currency, processing fees, connected-account IDs, application fee, transfer IDs and any prior refunds. Confirm which account created the charge. Next, identify the customer refund amount and whether it has actually succeeded. Record the refund balance transaction rather than assuming an API acceptance means every downstream movement is final.
Then apply the merchant contract’s allocation rule to the line items being refunded. Compare expected seller recovery with actual transfer reversals, and mark unresolved amounts as receivables with dates and owners. Verify the platform fee treatment independently. For mixed-currency or cross-border transactions, record original and settlement currencies and any conversion differences; a transfer reversal is not guaranteed to restore the identical amount in every currency context.
Finally, reconcile against Stripe Balance Transactions rather than only the order dashboard. An audit trail should let an accountant answer four questions without opening source code: Did the customer get paid? Which Stripe account funded it? What value was recovered from each seller? What amount remains the platform’s actual economic loss? Those four answers should agree between the refund register, seller ledger and bank settlement summary.
Common mistakes in a Connect refund implementation
A common error is to reverse a transfer before establishing that the buyer refund is authorized. Another is reversing every transfer in a transfer group without confirming which seller caused a partial cancellation. A third is assuming that on_behalf_of moves refund liability away from the platform. For indirect charges Stripe explicitly says it does not. A fourth is refunding an application fee twice by combining automatic refund parameters with a separate manual fee refund.
Testing solely with a fully funded connected account hides the difficult cases. Create controlled test scenarios involving a partial refund, two recipients, a seller with little available balance and two customer refunds against one original payment. Verify retry behavior, ledger consistency and user-visible statuses. Never use live charge or transfer reversal operations as a casual diagnostic; run tests in Stripe test mode and apply the platform’s documented authorization controls.
A useful acceptance criterion is not “the refund endpoint returned 200.” It is that every authorized customer refund yields a balanced set of transaction records and a traceable recovery status. This catches the financially important defect: refunds appearing resolved in the product UI while the platform is silently financing sellers who already received their transfers.
FAQ: practical answers for marketplace operators
Does Stripe automatically debit the seller when I refund a destination charge?
Not merely because the customer refund was created. The platform balance is debited for a destination-charge refund. To recover the destination transfer, use the supported reversal mechanism and confirm its success; parameters can combine certain actions where the charge type supports them.
Does on_behalf_of make the seller pay the refund?
No. It changes settlement-merchant behavior in relevant Connect flows, but it is not equivalent to moving the charge to the connected account. For destination charges and separate charges/transfers, Stripe still describes the platform balance as responsible for refunds.
What if I refund a payment after the seller’s bank payout?
The refund can still debit the platform in an indirect-charge model. Recovery depends on available balances, reversal eligibility, reserves, possible future netting and contractual recovery tools. Never promise instantaneous seller clawback simply because the platform can initiate a refund.
Can I refund only part of an order?
Yes. Stripe supports partial refunds within the remaining refundable amount. Allocation among connected accounts is a separate decision, especially for separate charges and multiple transfers. Model line-item responsibility rather than reversing the same percentage from everyone by default.
Is a dispute the same as a merchant-authorized refund?
No. A dispute is initiated by the cardholder or bank and has its own evidence, timing and potential fees. The platform’s indirect-charge liability makes dispute operations a related treasury issue, but they require their own workflow and should not be reported as voluntary refunds.
The bottom line
The critical Stripe Connect question is where the original Charge object lives. Direct charges use connected-account payments. Destination charges and separate charges and transfers debit the platform for refunds, even where seller transfers happened earlier. Successful customer reimbursement, successful seller recovery and final financial liability must be tracked separately. A marketplace that models those three stages accurately can explain cash movement, test edge cases and avoid confusing contractual responsibility with an automatic Stripe transfer reversal.