Stripe Direct Charge

One payment, two balances, and only the smaller one is yours

Stripe puts a number on the split rather than leaving it abstract. On a charge of 10 USD with a 1.23 USD application fee, "1.23 USD is transferred to your platform account. 8.18 USD (10 USD - 0.59 USD - 1.23 USD) is netted in the connected account (assuming standard US Stripe fees)."

So a single customer payment produces movement in two separate Stripe accounts. The seller nets the sale less Stripe’s cut and your cut. You receive the fee you set, and Stripe is clear that there "are no additional Stripe fees on the application fee itself".

The fee has limits worth knowing before you build pricing on it. The value "must be positive and less than the amount of the charge", and the fee collected is "capped at the captured amount of the charge", which matters if you capture less than you authorised.

One timing detail catches integrations. Application fees on direct charges "are created asynchronously by default", so the fee object can lag the charge that produced it. You can force it to exist immediately by expanding it in the charge request, which Stripe advises against because "it increases the latency of the request", or you can listen for the application_fee.created event and treat the fee as a second arrival rather than a property of the first.

There is also a choice here that neither indirect type offers: "You can choose whether to have Stripe debit fees directly from connected accounts or from your platform account." Destination charges and separate charges and transfers both assess Stripe’s fees on the platform with no such switch.

Your own API cannot see the sale

Stripe documents this under a heading called Platform visibility limitations, and it is the single most consequential thing about the charge type for anyone keeping books.

"Transaction objects such as PaymentIntents and Charges exist on the connected account, not on the platform." Querying your own Stripe account will not return them. To read them at all, "you must query the Stripe API using the connected account ID in the Stripe-Account header".

Stripe then names the tooling consequence directly instead of leaving you to find it: "This scoping behavior affects data synchronization services like Fivetran, as well as other third-party integrations that rely on platform-level API queries. To retrieve direct charge data, they must query the connected account, not the platform."

The Dashboard has a matching gap. Direct charges "don’t show in exports, but you can find them in reports, Sigma, or using the API".

Put those together and the accounting shape is clear. A platform on direct charges has no gross sales figure sitting in its own Stripe account, because the gross sale was never its transaction. What it has is a stream of commissions. For most software platforms that is the right answer rather than a gap, because the platform sold software and the seller sold the goods. It is still a surprise the first time someone asks for total marketplace volume and the platform’s own export comes back carrying only the fees.

The practical rule: if a figure you need describes the customer’s purchase, it lives on the connected account, and something has to be authorised to go and read it there.

Refunds and disputes land on the seller, and your fee does not come back on its own

Refunds run against the seller’s balance. "Stripe debits the refund amount from the connected account’s balance directly when you create a refund." If that account is short, "we set the refund status to pending", and "when the connected account’s balance has enough funds, Stripe automatically processes pending refunds in the order they were created and updates their status to successful".

That is a queue tied to somebody else’s cash flow, which is a support conversation no platform on destination charges ever has to hold.

The commission is a separate decision, and the default leaves it with you at the seller’s cost. Stripe says application fees "aren’t automatically refunded when issuing a refund", and that your platform "must explicitly refund the application fee" or the connected account, the one the charge was created on, "loses that amount". Passing refund_application_fee as true returns it. Partial refunds return it in proportion: "If the refund results in the entire charge being refunded, the entire application fee is refunded. Otherwise, a proportional amount of the application fee is refunded."

Disputes point the same way. Stripe "debits the disputed amount from the connected account’s balance, not your platform’s balance", and the dispute fee is configurable rather than fixed: Stripe "can bill the dispute fee to either the platform or the connected account, depending on the connected account’s configuration". If a dispute pushes the seller negative, Stripe "attempts to debit the external account on file for the connected account only if debit_negative_balances is set to true".

For a platform, the honest summary is that direct charges move both the money and the trouble to the seller, and leave you holding a commission that you have to decide, case by case, whether to give back.

The four gates that decide whether you can use it

Capability first. "Your connected accounts must have the card_payments capability active in order to use direct charges." Without it the charge cannot be created.

Account type second, and Stripe is blunt here. Direct charges "aren’t recommended for legacy v1 Express and Custom accounts", with the advice to "switch to v2 accounts, or use destination charges with these accounts instead". Stripe separately recommends direct charges "for connected accounts that have access to the full Stripe Dashboard", which is the same idea from the other end: the model assumes a seller who runs their own Stripe account and handles their own payments and disputes.

Payment methods third, and this one is a capability rather than a restriction. On direct charges "you create parent payment method configurations for your connected accounts, who can customize their own child configurations". Both indirect types use the platform’s configurations unless the charge sets on_behalf_of.

Geography fourth, for the commission specifically. "In line with Brazilian regulatory and compliance requirements, platforms based outside of Brazil with Brazilian connected accounts can’t collect application fees through Stripe."

Underneath all four sits the business-model question. Direct charges work best "for platforms that provide software as a service", and Stripe’s examples are Shopify, which "provides tools for building online storefronts", and Thinkific, which "enables educators to sell online courses". The common thread is that the seller owns the customer relationship. If your customers believe they are buying from you, this is the wrong charge type, and the visibility limitations above become a reporting problem rather than an accurate description of who sold what.