Most Magento merchants obsess over COGS and ad spend. Payment fees sit in the middle and get ignored — until the PSP settlement lands and “healthy” months suddenly look thin.
Stripe, PayPal, Adyen, Klarna and friends usually charge something like X% + €Y per successful charge. Magento records the order grand total. It does not automatically subtract the processor cut from your contribution margin.
If your dashboard never models that cut, every campaign, SKU and day looks better than cash.
The fee is small. The habit is not.
Take a €78 order on cards at 1.5% + €0.25:
- Fee ≈ €1.42
- On one order that is noise
- On 40 orders/day ≈ €57/day ≈ €1,700/month
PayPal-heavy stores at ~2.9% + fixed bleed faster. BNPL / Klarna often sits near ~3%. Bank transfer and COD may be ~0% on the PSP line but still have ops cost — the point is: method mix matters.
Merchants who “round fees to 2% in their head once a quarter” systematically overstate net profit on card-heavy weeks and understate how much a cheap bank-transfer promo actually saves.
What Magento shows vs what you keep
Magento is excellent at:
- Order grand total
- Payment method code (
stripe_payments,paypal_express, …) - Invoices and credit memos
Magento is not your acquirer P&L. The admin never says: *this day’s contribution after Stripe*.
So teams build habit:
- Export Magento revenue
- Subtract COGS (sometimes)
- Subtract ads (sometimes)
- Call the rest “margin”
- Wonder why the bank balance disagrees
Step 4 skipped payment fees and often merchant shipping cost. That is the same class of error as parent bundle cost = 0: the catalog looks fine; the cash does not.
A day that “works” until fees
Assume one Magento day (store timezone):
| Line | Amount |
|---|---|
| Revenue (after tax rules you use for P&L) | €10,000 |
| Refunds | €400 |
| COGS | €4,800 |
| Ads | €1,200 |
| Shipping you pay | €650 |
| Payment fees (mixed methods) | €290 |
Contribution after COGS: €10,000 − €400 − €4,800 = €4,800 After shipping: €4,150 After fees: €3,860 After ads: €2,660 net
If fees were left at €0 in the model, you would report €2,950 — about 11% too optimistic on net for that day. Scale that error across a quarter and your “safe” POAS targets are wrong.
Broader story: ROAS looks fine, cash does not.
Why ad dashboards never save you here
Meta and Google optimize to the conversion value you send them — usually revenue or purchase count. They do not know your Stripe schedule.
Even profit-based Google Ads conversions only help if the profit signal already subtracts fees (and COGS, and shipping cost). Otherwise Smart Bidding inherits the same lie: gross looks fat, PSP still takes its cut.
POAS vs ROAS only becomes honest when the “P” is contribution after real costs — fees included.
Percent + fixed: model both
A usable Magento fee rule is almost always:
fee ≈ max(0, order_total) × percent/100 + fixed_per_order
- Percent covers MDR / interchange-ish blended rates
- Fixed covers the per-transaction fee that hurts small AOVs hardest
A €29 add-on order at 1.5% + €0.25 pays ~€0.69 (~2.4% effective). A €190 order pays ~€3.10 (~1.6% effective).
If you only enter a flat “2% storewide” and your AOV is low, you understate fees. If AOV is high and you ignore fixed, you are closer — but still wrong on PayPal vs cards mix.
Per-method rules beat one global guess. Stripe ≠ PayPal ≠ Klarna ≠ bank transfer. Magento already stores payment_method on the order — use it.
Practical checklist (30 minutes)
- Pull last month’s PSP statements (Stripe / PayPal) — total fees ÷ successful charge volume = reality check
- List Magento payment method codes you actually use
- Set percent + fixed per method from the statement (or PSP pricing page), not from memory
- Re-run last 30 days of Magento net profit with fees on
- Compare to the version without fees — that delta is the silent margin tax
- If you upload profit conversions, confirm fee is inside the profit formula first
Also fix the usual companions: COGS mistakes, free shipping ≠ free, cash vs cohort refunds, and the broader Magento-vs-cash gap in green dashboard, red bank.
How Verid handles this
Verid applies payment fees inside daily Magento net profit:
- Store default: percent + fixed per order
- Optional per Magento payment method overrides (Stripe vs PayPal vs bank transfer, etc.)
- Fee uses order grand total in store base currency
- Same fee logic feeds Overview, day drill-down, and profit-valued conversion uploads when enabled
Setup: /docs/settings (payment fee rules) · formula context: /docs/how-it-works · sample store: /demo.
You do not need a perfect to-the-cent match with every Stripe dispute on day one. You need fees on the P&L at all. Zero is the expensive default.
Bottom line
Payment fees are not “finance’s problem later.” They are a per-order cost that changes which Magento days, methods and campaigns are actually worth scaling.
If your margin model skips them, you are not being conservative — you are running Magento on a flattering spreadsheet.