Application fee refund calculator and proportional math

The 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 keeps your reconciliation agreeing to the cent instead of drifting by one on every partial refund.

Why checking the fee alone gives a wrong answer

reverse_transfer and refund_application_fee touch the same dollars, so examining either in isolation is confidently incorrect.

The measure that holds is the net position across both:

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

Negative means you are genuinely out of pocket. Positive 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 reversal is double-counting — and if it acts on that automatically, it double-refunds your seller.

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

if (netMargin >= 0) return null;               // already whole
const recoverable = Math.min(feeShortfall, -netMargin);

Two traps that break naive implementations

Zero-decimal currencies. JPY, KRW, VND and around a dozen others have no minor unit — an amount of 1000 means ¥1000, not ¥10.00. Dividing by 100 for display is wrong by 100×. BHD, JOD, KWD, OMR and TND go the other way at three decimals.

Standalone fee refunds. A fee can be refunded with no charge refund at all — a promotional waiver or a fee correction. Reasoning from the fee inward will flag every one of those as a missing transfer reversal. Always reason from the charge outward.

Check your own numbers

The free scanner runs this exact calculation across pasted event data or a synthetic dataset, and returns the recoverable total broken down by cause. No account, no credentials.