FeeVerify for payment service providers
A PSP earns the difference between the prices it sets for merchants and the acquirer, scheme and provider costs underneath, usually across several acquirers and many markets. FeeVerify breaks that billing down and validates every transaction against your agreements and the published schedules. It recovers what you have overpaid, and checks each new month so cost changes reach merchant pricing before they eat into the margin.
What does a PSP pay, and where does the margin leak?
A PSP buys acquiring in each market it serves, pays the schemes for every transaction and for programmes it takes part in, and pays providers for services such as 3-D Secure, tokenisation and fraud screening. It then sells merchants a price, often blended for smaller merchants and interchange-plus or IC++ for larger ones. The margin sits between those two sets of numbers, and it leaks on both sides.
On the cost side, the bills are hard to test. Non-transactional scheme fees arrive monthly, one to two months in arrears, and are calculated on aggregates that do not map back to single transactions (Adyen). The Reserve Bank of Australia found some PSPs absorb fee inaccuracies instead of investigating them, because the fees are complex and change often (RBA, March 2026). On the revenue side, a scheme fee increase that never reaches a blended merchant's price is margin given away every month it goes unnoticed.
| What you pay or charge | Where it leaks | How FeeVerify checks it |
|---|---|---|
| Acquirer fees in each market | Markup, per-transaction fees and minimums that drift from the contract; volume tiers not applied as volume grows | Re-costs each transaction against the rate, tier and minimum in that market's acquirer contract |
| Transactional scheme fees | Wrong region, product or card type; pass-through marked up or billed twice | Recalculates each fee from the scheme fee schedule and your acquirer contract |
| Non-transactional and behavioural scheme fees | Aggregates nobody rebuilds; dispute and monitoring programme fees that go unchallenged | Rebuilds the aggregate or the triggering transactions and compares the result with the invoice line |
| Downgrades | Transactions clearing at a higher interchange tier because data is missing or settlement is late | Flags each downgraded transaction with the data, timing or configuration behind it |
| FX on cross-border settlement | Mark-ups above the contracted spread, or applied twice | Compares the applied rate with the contracted FX markup |
| Provider services: 3-D Secure, tokenisation, fraud screening | Per-call fees above the contracted tier, or billed for calls that never happened | Checks each provider invoice against its contract and your own transaction counts |
| Merchant pricing | Cost increases never passed on; merchants on the wrong plan; fees in the contract never billed | Checks that each merchant is billed what its contract says, and that upstream changes reached its price |
Sources: Adyen, non-transactional scheme fees; RBA conclusions paper, scheme fees, March 2026
Four ways FeeVerify protects a PSP's margin
FeeVerify sits as an independent control layer between what you pay acquirers, schemes and providers and what you charge merchants. Looking back, it recovers what has already leaked. Going forward, it keeps merchant pricing in step with cost and shows the true cost of each acquirer and route in every market.
Looking back: recover what has leaked
Recover overcharges
Every transaction is broken down and checked against the acquirer contract for its market, the scheme schedules and your provider contracts. Variances come back quantified, sourced and ready to claim.
Bill what merchants owe
Fees in merchant contracts that were never charged, and merchants priced on an old plan, are found and quantified, so you can correct the billing.
Going forward: keep the margin
Keep pricing in step with cost
Each new month of billing is validated as it lands, so scheme, FX and downgrade changes are caught in time to reprice merchants before the cost compounds.
Route and negotiate on clear economics
The true cost of each acquirer, market and route sits on one basis, clause-linked and sourced. That is what you need to decide where to route volume and what to ask for at the next acquirer renewal.
None of this needs new headcount. AI does the high-volume analysis, and experienced payments specialists sign off every material finding, so you do not need an interchange specialist in every market.
Proof in production
FeeVerify is proven on a tier-one cross-border payments business, anonymised here, that runs blended and IC++ acquiring across multiple markets and had no AI-led billing reconciliation before. The diagnostic ran on one month of its real production data and was delivered within 30 days of the data arriving.
That business runs the way many PSPs do: several acquirers, many markets, two pricing models and agreements in more than one language. Rules were built from its contract packages and the scheme schedules behind them, and every transaction was re-costed against them.
Figures are from an anonymised engagement; the client is not named. The proof page sets out the method and the disclosure.
Getting started
You start with a 30-day diagnostic on one month of your own data, and you see verified recoveries before any recurring fee. A good first scope is the market or acquirer with the most volume, or the one whose pricing nobody fully trusts. The first call agrees that scope and the data we need.
Share your data
Acquirer, scheme and provider contracts, side letters and incentive tiers, merchant pricing for your main segments, and one month of settlement and invoice files. No integration is needed to start.
30-day diagnostic
Every transaction is re-costed. Variances are quantified and linked to the clause behind them, and the findings are reviewed with your team.
Recover and continue
FeeVerify's fee is a success fee on the value you accept, with no ongoing commitment. Optional continuous assurance then checks each new month as it lands.
Pilot terms are agreed in the contract. The how it works page covers each step in more detail.
Questions PSPs ask
We already route across several acquirers. What would FeeVerify add?
Routing engines choose an acquirer from the rates someone loaded into them. FeeVerify checks what each acquirer actually charged against its contract, so the rates your routing depends on are tested every month. It also puts the true cost of each acquirer and market on one basis, including scheme fees, downgrades and FX, which is the comparison a routing decision needs. FeeVerify processes and routes nothing itself, so it has no stake in where the volume goes.
Can FeeVerify check our merchant billing as well as our costs?
Yes. With your merchant pricing and billing files, FeeVerify checks that each merchant was charged what its contract says, and that cost changes upstream reached the merchants they should have. That covers fees in the contract that were never billed, merchants left on an old plan, and pass-through that stopped short.
Do you need card numbers?
No. Files containing full card numbers are rejected at upload, so you send masked or tokenised data. FeeVerify needs the fields your fees depend on, such as card type, region, product, merchant category and amount. Your data stays in an environment only your organisation can see, and it is never used to train a model. The governance page has the detail.
How is FeeVerify paid?
You see verified recoveries before any recurring fee. After the 30-day diagnostic, FeeVerify's fee is a success fee on the value you accept, whether that is money back, cost savings or revenue gained, and there is no ongoing commitment. Specific pilot fees and percentages are set in the contract.
Related reading
Start with one month of your own data.
A pilot begins with the agreements that protect both sides, then your contracts and one month of settlement data, scoped with a payments specialist on the first call. The 30-day diagnostic re-costs every transaction against them and shows each variance with its clause, before any recurring fee.