Stripe computes its own fee on every charge. Eventify computes its own estimate of that fee and stores it. This article explains where each number comes from, why they diverge, and how to reconcile the two ledgers.
The one-paragraph answer
Eventify never reads fee figures back from Stripe. When a payment succeeds, we only check the payment's status — we do not retrieve the actual fee breakdown Stripe recorded for that charge. Every fee amount shown in our reports is our own calculation, based on a flat per-currency rate we store internally.
So the “Stripe fee” you see in Eventify reports is a model of Stripe's fee, not a record of it. On a plain domestic card, the two usually agree to the cent. Across a real event — mixed card types, alternative payment methods, refunds, multi-installment orders — they will not, and that's expected behavior, not a data error.
The two ledgers
When a buyer pays by card, two independent systems record the charge:
- Gross amount (Stripe) vs. Buyer-paid gross (Eventify) — the only figure guaranteed to describe the same money on both sides.
- Processing fee, computed once by Stripe using the real pricing for that transaction (card brand, card country, payment method, currency conversion) vs. Estimated processing fee, computed by us as gross × a flat rate + a fixed fee.
- Application (platform) fee (Stripe) vs. Estimated platform fee (Eventify) — the same intended fee, calculated independently on each side.
- Net (Stripe: gross − Stripe's fee − platform fee) vs. Estimated net to host (Eventify: gross − our estimated processing fee − platform fee).
Where Eventify's numbers come from
- Rates come from an internal rate table: one entry per currency, holding a percentage rate, a fixed fee, and the platform fee (which can also be overridden per client).
- Pass-on gross-up. When a host passes fees on to the buyer, the buyer's price is reverse-calculated so the host still nets the intended face value: Buyer pays = (ticket price + platform fee + fixed fee) ÷ (1 − rate%); Charged amount = buyer's payment × rate% + platform fee + fixed fee.
- The buyer-paid gross, our estimated processing fee, and our estimated net to host are then derived from those numbers, rounding to the cent at each step.
- What actually goes to Stripe is only the gross amount and the platform fee. We never tell Stripe what we think its fee will be, and Stripe never tells us what it actually charged.
- When the payment settles, we recompute the same breakdown again and store it. At no point do we read anything back from Stripe except whether the payment succeeded.
Eight reasons the totals diverge
- Our fee is a flat model; Stripe's fee is transaction-specific. We apply one percentage plus a fixed fee per currency to every charge. Stripe prices each charge individually: international and premium cards typically cost more than domestic ones, currency conversion adds a margin, and alternative payment methods we may support each carry their own pricing. This is the largest and most systematic source of divergence.
- Refund accounting is structurally different. When we issue a refund through Stripe, Stripe generally keeps its original processing fee on that charge, and by default we don't ask Stripe to reverse the platform fee either. On our side, our recorded refund for pass-on-fee tickets re-derives and includes a processing-fee share, and staff can optionally refund the fixed fee once per order. The more refunds an event has, the wider the gap. Refund fee-retention behavior can vary by account settings and has changed over time — confirm current behavior in your own Stripe dashboard.
- Ordered amounts vs. charged amounts. An order can hold the full order value while Stripe was only charged for an approved subset, and pay-later orders accumulate across multiple settlement rounds. Only settled online charges have any counterpart in Stripe at all.
- Cash, free, face-value, and manually-recorded orders never touch Stripe. These appear in Eventify revenue reports and none of them appear in Stripe. Filter down to Stripe-settled charges before comparing.
- Date basis and time zones differ. Stripe reports by payment date (and payouts by the later date funds become available). Eventify's reporting is keyed off orders and their settlement rounds.
- Rounding happens at different points. We round to two decimals at every intermediate step. Stripe computes its fee once, on the exact minor-unit amount.
- Rates aren't locked to the moment of charge in every case. Refund calculations look up rates live, so an old order's refund can use a different rate than the one used to originally charge it.
- Currency presentation and zero-decimal currencies. Zero-decimal currencies (such as the Japanese yen or Korean won) follow a separate whole-unit path with slightly different rounding behavior.
A worked example
Illustrative rates (2.9% + $0.30 processing fee, $1.00 platform fee). A host sells a $100 ticket with fees passed on to the buyer: gross-up produces a $104.33 charge; our estimated processing fee is $3.33. On a domestic card, Stripe's actual fee matches at $3.33. On an international card (illustrative 3.5%), Stripe's actual fee might be $3.95 instead — same stored figures, different real-world outcome depending on the card used.
How to reconcile
- Match on the gross, per transaction — if the gross differs, escalate; if only the fee differs, that's the modeling gap described above.
- Narrow the window first: shrink to one or two days, find the first day that disagrees, then compare order-by-order.
- Compare like with like: use settled/collected figures only, exclude cash/free/manual orders, filter to one currency, align on settlement date.
- Treat refund fee deltas as expected; reconcile refunds on gross refunded amount only.
- For the true fee, Stripe's own payout and balance reports are the authority.
Possible future improvement
If exact fee parity ever becomes a requirement, the fix is architectural: after a successful payment, retrieve Stripe's actual recorded fee for that transaction and store it alongside our modeled figure. Today we don't do this, so parity isn't achievable just by tuning our rate table.
Known quirks worth knowing about
- Our two-sheet sales export intentionally disagrees with itself by design: order-level rows show the total modeled processing fee, while ticket-level rows show only the pass-on portion.
- When cumulative refunds on an order land within about 30 cents of the order total, the fixed fee is automatically folded into the recorded fee tracking for that order.
- A few older order types (e.g., some booth and session-based purchases) use separate, older fee calculations that don't perfectly match the current standard calculation.
