Application fee leaks: keeping a cut of a refunded sale

The default nobody reads

refund_application_fee defaults to false. Refund a charge without setting it and your platform keeps its full fee on revenue that no longer exists.

This cuts both ways, and which way matters depends on your terms of service.

Some platforms keep the fee deliberately — a stated policy agreed with sellers, compensating for payment processing already incurred. That is a legitimate business decision.

Others do it unknowingly, which is a trust and compliance problem: charging a percentage on transactions that were reversed, usually contradicting their own published terms.

And some over-correct, refunding the fee explicitly *and* using reverse_transfer — which already returns the funds that financed the fee. That combination can give the same money back twice.

The proportional calculation

The share of the fee to return equals the share of the charge refunded:

shouldRefund = round((amount_refunded / amount) × application_fee.amount)

Stripe rounds half-up on its own proportional calculations. Matching that rounding is what keeps your reconciliation agreeing with Stripe to the cent rather than drifting by one on every partial refund.

Why checking the fee alone gives a wrong answer

Both reverse_transfer and refund_application_fee touch the same dollars, so examining either in isolation produces a confidently incorrect result.

The measure that holds is the platform's net position across both:

Net Platform Margin = (Collected Fee − Refunded Fee) − (Original Transfer − Reversed Transfer)

A negative figure means you are genuinely out of pocket. A positive one means you are whole, regardless of which lever got you there. A tool that flags an unrefunded fee on a charge already made whole by a transfer reversal is double-counting — and if it acts on that automatically, it double-refunds the seller.

const netMargin =
  (applicationFee.amount - applicationFee.amount_refunded) -
  (transfer.amount - transfer.amount_reversed);

// netMargin < 0  →  you are carrying the loss

The zero-decimal currency trap

JPY, KRW, VND and a dozen others have no minor unit. An amount of 1000 means ¥1000, not ¥10.00.

Dividing by 100 for display is wrong by a factor of 100 for these currencies. A reconciliation script that gets this wrong reports losses two orders of magnitude off — which is either an alarming false positive or a silently ignored real one.

What FeeGuard does about it

FeeGuard computes the net position before attributing a shortfall to any cause. When reverse_transfer was used and the platform is already whole, the fee gap is not reported at all.

Zero-decimal and three-decimal currencies are handled explicitly, so a ¥ finding reads correctly rather than being off by 100×.