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
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 / What it looks like
What the processors actually charged
Where a day is not reported, the gap is filled from the rate observed on the surrounding days and labelled as estimated. The mixture is stated on the screen rather than averaged away.
Each processor reports what it kept, day by day. What you see is the sum of those reports — not a percentage applied to a total.
Adding up only the reported days would treat the first ten as free — a smaller, more confident and more wrong number than the percentage it replaced. 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.
03 / 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.
04 / What it is built from
Payment fees is assembled
from accounts you already run.
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 / 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.
07 / How the figure is kept honest
The same four rules,
on every screen.
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.
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.
Follow any number to the dated rows underneath it. A figure nobody can check is a figure nobody acts on.
The product prepares a decision and shows the evidence. Nothing consequential happens until you say so.
Questions
About Payment fees.
- What if I have not connected a processor?
- 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.
- Does it handle refunded fees?
- Where the processor reports the reversal, yes — a refunded fee comes back out of the cost on the day it was posted.
- Why do my fees differ from the rate I was quoted?
- 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.
- Which is used in profit?
- The measured figure wherever it exists. Profit is worked out from what was actually charged, with the estimated portion identified.
One operating system
The rest of the picture,
one view away.
Each part is useful on its own. Profflow holds them in one model, so a figure here carries the context from everywhere else.
See the whole productSee 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.