Start by identifying the charge architecture
Stripe destination charges are created on the platform account, with funds transferred to a connected account. Stripe fees, refunds and chargebacks debit the platform balance.[3] Editorial recommendation: before authorizing a marketplace refund, identify whether the original payment actually used this charge architecture. Record the charge, connected account, transfer and any application fee rather than relying only on an order number. This article does not describe direct charges or prescribe the same refund flags for separate charges and transfers. It concerns who bears a refund after a seller has received transferred funds, not the customer's eligibility under a refund policy. The source is Stripe's Web, Stripe-hosted destination-charge guide; it is not evidence that PayIn operates a marketplace or implements Connect.
The default leaves the transferred funds with the seller
For a refunded charge with transfer_data[destination], Stripe says the destination account keeps the transferred funds by default, leaving the platform to cover the refund's negative balance. Setting reverse_transfer=true when creating the refund pulls funds back from the connected account to cover the refund.[3] Editorial recommendation: the approval should name both the customer-facing amount and the intended funding party. A successful refund request is not enough evidence that the seller has borne the cost. If the platform deliberately funds a goodwill refund, retaining the transfer may be intentional; if the seller should return its share, the transfer decision must be explicit. Do not label either choice universally correct. Align the operation with the seller agreement and available account capabilities, and keep the approval alongside the actual returned objects.
Treat full and partial reversals as distinct review cases
Stripe refunds the entire charge by default, while a positive integer amount can request a partial refund. In the documented transfer-reversal flow, a refund of the entire charge reverses the entire transfer; otherwise a proportional amount of the transfer is reversed.[3] Editorial recommendation: review the resulting transfer reversal rather than assuming it equals an informal seller-share calculation. As an illustrative scenario, a customer receives only part of an order back while the seller agreement allocates costs differently from the platform's default split. No numerical outcome is asserted here. First determine whether the documented proportional behavior matches the agreed allocation. If it does not, stop for a design review instead of layering untracked manual movements on top. Keep partial refunds associated with the same original payment so the reviewer can explain the cumulative customer refund and cumulative recovery separately.
Application fees require their own decision
When a charge has an application fee, the platform keeps that fee by default. Setting refund_application_fee=true pushes the fee funds back to the connected account.[3] For a destination charge, refunding that application fee also requires reversing the transfer; the full charge refund includes the entire application fee, while a partial refund includes a proportional fee amount.[3] Editorial recommendation: approve the fee treatment independently of the customer-facing refund amount, but enforce the documented dependency between the two flags. Do not present all four boolean combinations as equally valid destination-charge operations. The source also permits keeping refund_application_fee false and refunding the application fee separately through the API.[3] If using a separate process, preserve its reference in the same case so another operator does not return the fee twice. An application fee is not interchangeable with Stripe's processing fee, and this guide makes no promise that processing fees are returned.
A failed refund can require another funds decision
If the refund fails or is canceled, Stripe says the failed refund amount returns to the platform's Stripe balance. Its guidance is to create a transfer to move funds to the connected account as needed.[3] Editorial recommendation: keep customer refund status and seller recovery status as separate review fields until the case is resolved. Do not automatically conclude that a failed refund restores the seller's earlier balance position. Determine whether a transfer reversal occurred, whether a fee was returned and whether another movement is appropriate before approving a new transfer. Do not reuse the same action merely because the customer still expects money: a new attempt and an internal reallocation answer different questions. The source provides the direction of the returned funds, not a guarantee that every later transfer is eligible in every region or account configuration.
Keep customer and seller explanations separate
Editorial recommendation: customer support should explain the customer refund state without exposing unnecessary seller-account information. Seller operations should separately explain the recovery and fee treatment approved under the relevant agreement. The same case identifier can connect those records, but a customer notification is not proof that the seller transfer was reversed. Require a second review when the requested funding allocation differs from the original approval. If an operator intentionally leaves funds with the seller, record that as platform-funded rather than presenting the missing reversal as a technical failure. A clear explanation of intent makes subsequent balance reconciliation possible without pretending that every difference between a refund and a transfer is an error.
Close the case with an explainable funds trail
Editorial recommendation: maintain an audit packet with the original charge architecture, customer refund amount and state, requested reversal flag, actual reversal reference, fee-refund decision and any follow-up transfer. Rehearse a full refund with both documented flags, a partial refund with transfer recovery, a platform-funded refund and a failed-refund review. For each case, verify who retained funds and who absorbed the cost instead of treating one green Dashboard status as the whole outcome. These are proposed acceptance scenarios, not live executions. This article and source verification are dated 2026-09-21; the source states no publication or update date. It does not certify legal compliance, settlement eligibility or a business's contractual right to recover funds. Account-supported regions and transfer restrictions require separate review; do not turn this vendor-specific workflow into a general cross-border payments rule.
Sources and dates
Verified on 2026-09-21. Source dates distinguish explicitly stated publication and update dates; an unspecified date does not mean the source was published today. This is public-document research, not a live payment test, security audit or accessibility certification. Vendor facts apply to the cited vendor; proposed workflows are editorial synthesis.
More new articles
Changing a plan while its invoice is unpaid: avoid crediting time never paid for →
Pausing collection is not pausing invoices: plan the backlog before resuming →
All field guides →