Payment fees · Measured cost
What the processor charged,
not what the rate says.
Stripe, PayPal and Klarna each report what they kept, day by day. Turning that into one figure for a period sounds like addition and is not — because a processor connected on the tenth has reported twenty days of a thirty-day month.
Measured, not estimated · EU-hosted · Read-only by default
- Payment fees€135July
- Days reportedmeasuredas charged
- Days not reportedestimatedand labelled
- The mixturestatedon every screen
A day the processor reportedA day at the rate in Settings, marked as such
An illustration on the sample month, for a processor that actually keeps 1.92% where Settings says 1.70%. Every day it reports is added as reported; a day it does not report is filled at the Settings rate and marked as estimated, so the mixture is on the screen.
01 / The case for it
Your rate card is not what you were charged.
Without it
Currency conversion, cross-border cards and card types outside the headline price all move the real number, and the gap only shows up when somebody compares the statement to the assumption. Most reporting never does — it multiplies revenue by a percentage and moves on.
What Profflow does
What the processor actually reported, day by day.
Where Stripe, PayPal or Klarna reported a day, that day carries what was really taken. Where they did not — a processor connected mid-month covers only part of it — the rate from Settings fills in, and the screen says which days are which.
02 / Worth understanding
Why a typed percentage is always wrong
The rate on the pricing page is not the rate you pay
Card type, issuing country, currency conversion, chargebacks and refunded fees all move the number. Two months at identical revenue can carry different fees, and a typed percentage cannot see any of it.
A refunded sale does not refund the fee
On most rails the processor keeps its cut when an order is returned. That makes returns more expensive than the refund amount suggests, and it only shows up if fees are read per transaction.
Estimated days are marked, not blended
If a processor does not report a day, the gap is filled from the surrounding rate and labelled. The alternative — quietly averaging the month — produces a figure that looks measured and is not.
03 / What it lets you do
What follows from getting Payment fees right.
Per-day coverage
A fee total silently covering fifteen days of thirty is a smaller, more confident and more wrong number than the percentage it replaced.
Neither extreme
Refusing to use a partial month throws away twenty days of measurement to avoid admitting to ten days of estimate. Both halves are used and both are labelled.
Three processors, one line
Stripe, PayPal and Klarna add into the same cost in the P&L, each still traceable to its own statement.
The rate checked against reality
What you told Profflow you pay, against what was taken. Two legitimate measurements, with the difference named rather than averaged away.
Payout timing kept separate
What was charged and when the money arrives are different questions. The fee belongs to the P&L; the timing belongs to cash flow.
The same rule everywhere
This is how the products table treats partly-entered costs and how the daily P&L has treated fees since the processors were connected.
04 / What it is built from
Payment fees is assembled
from accounts you already run.
- 01Stripe balance transactions
- 02PayPal transactions
- 03Klarna settlements
- 04The rate in Settings
- 05Connection dates
- 06The period on screen
- Per-day coverage
- Neither extreme
- Three processors, one line
- The rate checked against reality
05 / How it is worked out
From the account
to the figure on the screen.
- 01ReadsWhat each processor wrote for each day it covered.
- 02FillsThe days it did not cover with the percentage from Settings.
- 03StatesThe mixture, so every screen can say what is measured.
- 04ComparesThe rate you entered against what was actually charged.
[ Asked of the figures ]
Why is this not just my rate times my revenue?
Because the rate in your settings and what the processor actually took are two different numbers, and the gap is worth seeing. Where the processor reported, that is used. Where it did not, the rate fills in and the screen says which days are which.
How Profflow reasons06 / How the figure is kept honest
The same four rules,
on every screen.
- Read-only, on every plan
Profflow observes the accounts it is connected to. It does not write an order, a price, a campaign or a payout back to any of them.
- Measured stays measured
A charge read from an account is labelled measured. Anything modelled — a forecast, a projection, a filled gap — is labelled as such on the screen it appears on.
- Every figure opens
Follow any number to the dated rows underneath it. A figure nobody can check is a figure nobody acts on.
- You approve
The product prepares a decision and shows the evidence. Nothing consequential happens until you say so.
About
Payment fees.
Can’t find the answer to your question?
Contact us by clicking here.
The percentage from Settings covers the whole period and every screen says the figure is an estimate. It is a defensible number and it is labelled as one.
Where the processor reports the reversal, yes — a refunded fee comes back out of the cost on the day it was posted.
Usually currency conversion, cross-border rates or a card type outside the headline price. That is exactly the gap this measures rather than assumes away.
The measured figure wherever it exists. Profit is worked out from what was actually charged, with the estimated portion identified.
See Payment fees on your own figures.
Stripe, PayPal and Klarna each report what they kept, day by day. Turning that into one figure for a period sounds like addition and is not — because a processor connected on the tenth has reported twenty days of a thirty-day month.