application_fee_amount (Stripe)

application_fee_amount is the Stripe parameter a Stripe Connect platform uses to keep part of a payment made to one of its connected accounts. The kept part is the application fee. For a marketplace, booking platform or software product that takes payments for its users, it is usually the platform's revenue.

How application_fee_amount works

You pass application_fee_amount when you create a PaymentIntent. In Checkout, it goes in payment_intent_data[application_fee_amount]. The value is an integer in the smallest currency unit, so 123 on a USD payment means $1.23. Stripe computes it in the same currency as the charge.

The parameter takes a fixed amount. For a percentage, you calculate the amount yourself and pass the result. Subscriptions are the exception. They accept application_fee_percent, a number from 0 to 100 with up to two decimal places, which Stripe applies to each billing period's invoice total.

Stripe's rules for the fee:

• It must be positive and less than the charge amount.
• The fee collected is capped at the captured amount.
• Stripe adds no extra fee on the application fee itself.
• Platforms based outside Brazil can't collect application fees from Brazilian connected accounts through Stripe.

You can also set fee rules without code in the Dashboard's Platform Pricing Tool. A fee passed in the API overrides those rules, so leave the parameter out if you use the tool.

Where the money goes by charge type

Direct charges. The payment is created on the connected account. Stripe transfers the application fee to the platform and takes Stripe's processing fee from the connected account's balance.

Destination charges. The payment is created on the platform. The full amount goes to the connected account, then the application fee comes back to the platform, which pays the Stripe fee. In Stripe's example, a $10.00 charge with a $1.23 fee and $0.59 of Stripe fees leaves the platform $0.64. Instead of application_fee_amount, you can set transfer_data[amount] to the seller's share. Stripe recommends the application fee because it creates a fee record you can report on.

Separate charges and transfers. There is no application fee. You keep your cut by transferring less than the charge amount to each connected account.

The ApplicationFee object and its events

Each collected fee creates an ApplicationFee object and fires application_fee.created. On direct charges, Stripe creates these objects asynchronously by default, so listen for the event instead of expecting the fee in the charge response. Refunding a fee, in full or in part, fires application_fee.refunded. Stripe recommends the amount on each ApplicationFee for fee reporting.

Refunds and application fees

A refund doesn't return the application fee by default. On a direct charge, the connected account pays the refund while the platform keeps its cut. Pass refund_application_fee=true on the refund to return the fee. A full refund returns the whole fee. A partial refund returns a proportional share, so refunding $40 of a $100 payment with a $5 fee returns $2.

On destination charges, the connected account keeps the transferred funds by default and the platform covers the refund. Set reverse_transfer=true to pull the money back from the seller. If you refund the application fee on a destination charge, you must also reverse the transfer.

Disputes raise the same question. On destination charges, Stripe takes the dispute amount and fee from the platform's balance, and the platform can reverse the transfer to recover it from the seller.

What to check each month

• Reconcile platform revenue from application fee amounts, not from gross charge volume.
• Track your take rate, which is fees divided by volume. A sudden drop usually means a pricing rule or an API override changed.
• Set refund_application_fee on purpose in every refund call, and write the refund policy into your seller agreement.
• Listen for application_fee.refunded to keep your own ledger in sync.

Application fees and ChargeBell

ChargeBell has no alert for application fees. It covers the events on your connected Stripe account that put revenue at risk. The refund alert posts when money goes back to a customer, and the dispute alert posts when a payment is challenged. Destination charges live on the platform's own account, so refunds and disputes on those payments show up as events there. Send both alerts to a finance channel, and whoever owns platform revenue sees a refund or dispute the day it happens.