Stripe Destination Charge

Two ways to take your cut, and only one of them itemises itself

Stripe gives you two parameters for the platform’s share, and they produce different records. Choosing between them is a reporting decision more than a technical one.

With application_fee_amount, Stripe describes the sequence precisely: "The full charge amount is immediately transferred from the platform to the connected account that’s specified by transfer_data[destination] after the charge is captured. The application_fee_amount is then transferred back to the platform, and the Stripe fee is deducted from the platform’s amount." On a 10.00 charge with a 1.23 fee and 0.59 of Stripe fees, 8.77 settles with the connected account and 0.64 stays with you. Afterwards "an Application Fee object is created", which you can list in the Dashboard or in Sigma, and Stripe notes you can use its amount property "for itemized fee reporting".

With transfer_data[amount] you do the arithmetic yourself: "You subtract your platform’s fees from the charge amount, then pass the result of this calculation as the transfer_data[amount]." No application fee object exists, so there is nothing itemised to reconcile against. Stripe’s own suggested method is to "retrieve the PaymentIntent and subtract the transfer_data[amount] from the amount on the PaymentIntent", or to read the Destination Platform Fee column in the Balance history export.

Two further differences are easy to miss and hard to undo. Settlement currency: an application fee "settles in the same currency as the connected account’s settlement currency", while a transfer_data[amount] settles in your platform’s settlement currency, which matters the moment a payment crosses a border. And visibility: with transfer_data[amount], Stripe says your connected account "can’t view the total amount of the charge. They only see the amount transferred." With an application fee, the connected account can see both the total and the fee.

Stripe’s own recommendation is to "consider using the application fee amount to simplify reporting by creating explicit application fees which are linked to the charge". For anyone who has to explain a commission line to an accountant, that is the easier of the two to defend.

Whose business the customer thinks they paid

A destination charge sits on your platform, so by default your platform is the merchant the customer sees. Stripe states it plainly: "If on_behalf_of is omitted, the platform is the business of record for the payment."

Setting on_behalf_of to a connected account ID makes that account the settlement merchant, which Stripe defines as the party that "determines whose information is used to make the charge". The effects are concrete rather than cosmetic. Charges settle in the connected account’s country and settlement currency. The fee structure for that country applies. The connected account’s statement descriptor appears on the customer’s statement, and if that account is in a different country than the platform, so do its address and phone number. The pending balance is held according to the connected account’s own delay_days setting.

Stripe frames the choice around who the customer actually deals with. Some platforms prefer to be the settlement merchant "because the end customer interacts directly with their platform", as with on-demand services. Others have connected accounts that face customers directly, such as a storefront on a marketplace, where "it might make more sense for the connected account to be the settlement merchant".

One constraint decides it for you in some cases. Stripe notes that with certain exceptions, if your platform and a connected account are not in the same region, you must specify the connected account as the settlement merchant using on_behalf_of. And the parameter is "supported only for connected accounts with a payments capability such as card_payments".

Note what on_behalf_of does not change. It does not move the liability. Disputes on destination charges are debited from the platform "with or without on_behalf_of".

The refund that leaves your balance short

This is the behaviour that surprises platforms in their first month, and it is documented rather than accidental.

When you refund a charge carrying a transfer_data[destination], Stripe says that "by default the destination account keeps the funds that were transferred to it, leaving the platform account to cover the negative balance from the refund". You refunded the customer in full, the seller keeps their 8.77, and your balance absorbs the gap.

The remedy is a parameter. Setting reverse_transfer to true when creating the refund pulls the funds back from the connected account. Stripe adds that "if the refund results in the entire charge being refunded, the entire transfer is reversed. Otherwise, a proportional amount of the transfer is reversed."

The application fee is a separate decision again. By default "the platform account keeps the funds from the application fee" on a refund. Setting refund_application_fee to true pushes it back, and Stripe is explicit that "if you refund the application fee for a destination charge, you must also reverse the transfer".

Disputes work the same way but without the opt-out. For destination charges, "Stripe debits dispute amounts and fees from your platform account", and recovery is something you initiate by reversing the transfer. If the connected account has a negative balance, Stripe attempts to debit its external account only when debit_negative_balances is set to true. Stripe also warns that retransferring a previous reversal is subject to cross-border transfer restrictions, "meaning you might have no means to repay your connected account", and advises waiting to recover disputed cross-border transfers until after a dispute is lost.

For a bookkeeper the takeaway is that a refund on a destination charge is potentially three movements rather than one: the refund itself, an optional transfer reversal, and an optional application fee refund. A month-end that reconciles only the first will not balance.

Transfers that reverse themselves, and transfers that never happen

Two cases produce a charge with no matching transfer, and both look like missing money until you know the rule.

Asynchronous payments first. With methods such as ACH Debit or SEPA Debit there is a gap between initiation and confirmation, and Stripe notes that during that window "both the charge and the transfer to the connected account’s pending balance are in a pending state". If the payment then fails, "Stripe automatically reverses the transfer. No funds are permanently moved to the connected account." Nothing for you to do, and nothing to correct.

The second case does need attention. If the destination account loses its transfer capability or is closed during that same window, Stripe "can’t complete the transfer as originally requested", so it skips the transfer and "the funds remain in your platform’s balance". You are holding money intended for a seller, and the only signal is quiet: listen for the charge.updated event and check whether transfer_data on the Charge object is null. Stripe says a null value "indicates a skipped transfer", and that once the problem is resolved you can create the transfer yourself.

That second case is worth a control rather than good intentions. A skipped transfer inflates your platform balance and, if your books treat a destination charge as pass-through, quietly overstates what is yours.