Auditing PSP Fees
Your PSP contract says the merchant pays a defined markup plus applicable underlying or conditional charges. This month, the merchant's effective payment cost increases by 18 basis points. Was the merchant overcharged? There is not enough information to answer. The transaction mi
How to Audit PSP Fees: Compare Your Payment Contract With What You Were Actually Charged
Your PSP contract says the merchant pays a defined markup plus applicable underlying or conditional charges.
This month, the merchant's effective payment cost increases by 18 basis points.
Was the merchant overcharged?
There is not enough information to answer.
The transaction mix may have changed. A volume tier may have reset. More transactions may have crossed borders or used payment methods with different economics. Refunds or disputes may have produced additional charges. Currency conversion may have changed. A monthly minimum may have become payable. Taxes may apply to particular fees. The provider may use contractual rounding rules that differ from the merchant's model.
Or the provider may actually have billed something incorrectly.
Those possibilities cannot be separated by looking at the effective rate alone.
That is why a PSP fee audit should not begin as a search for “hidden fees.” It should begin as a financial control:
Take the commercial terms the merchant agreed to, translate them into testable pricing rules, calculate what the relevant payment activity should have cost, and compare that amount with what the PSP actually charged.
Only after that process should a variance be called an overcharge.
Negotiated pricing is not the same as charged pricing
Pricing negotiation establishes commercial terms.
Fee auditing tests their application.
These are different operating processes.
A merchant might negotiate:
a percentage markup;
a fixed transaction fee;
volume tiers;
payment-method-specific pricing;
cross-border charges;
currency-conversion charges;
refund or dispute fees;
monthly platform charges;
minimum commitments.
The commercial team can negotiate those terms correctly and still leave finance unable to verify them later.
The problem is usually that the agreement exists as prose rather than executable logic.
For example:
“0.X% for eligible domestic card transactions, subject to monthly processing volume, with separate cross-border and refund charges.”
That may be commercially understandable.
It is not yet an audit rule.
Finance still has to determine:
Which transactions qualify as domestic?
Which amount is the percentage applied to?
What currency is used?
When does the volume tier change?
Is the tier retroactive to all monthly volume or prospective after the threshold?
Which transaction date determines the month?
What happens to refunds?
Are taxes added?
How is the calculated amount rounded?
Until those questions have controlled answers, the merchant cannot independently calculate the expected fee.
Start with the contract—not the provider invoice
The provider invoice tells you what the PSP says you owe.
It should not define what you expected to owe.
The contractual source set may include:
Master services agreement
Fee schedule
Commercial proposal incorporated into the agreement
Payment-method addendum
Country or acquiring addendum
Subsequent pricing amendment
Written approved modification
Current effective dates.
The exact legal hierarchy is contract-specific and should be reviewed by the appropriate commercial/legal owner.
The fee audit's first task is to establish:
Which pricing terms were contractually applicable to this payment population during this audit period?
That means pricing needs to be effective-dated.
If a merchant negotiated a new rate effective July 15, a July audit may require two calculation regimes:
July 1–14 → pricing version A
July 15–31 → pricing version B.
A model that applies the newest rate to the entire month can manufacture a variance that never existed.
Step 1 — Convert the contract into pricing rules
The uploaded brief's PSP Fee Audit Model starts by converting contractual language into explicit rules.
For every fee, define at least:
Field
What it establishes
Fee name
Controlled merchant name
Fee owner/source
PSP, acquirer, method provider, other defined source
Calculation basis
Transaction count, payment amount, refund, monthly account, etc.
Rate
Percentage/basis-point component
Fixed amount
Per-event fixed charge if applicable
Currency
Currency in which fee is defined/calculated
Threshold/tier
Volume or other qualifying threshold
Geography
Relevant jurisdiction/corridor where contract specifies one
Payment method
Card/method/product scope
Transaction type
Payment, refund, dispute, payout, etc.
Effective date
When rule becomes applicable
Exclusions
Explicit contractual exclusions
Tax treatment
Only where supported by applicable contract/tax determination
Rounding rule
Where contract/provider documentation establishes one
The goal is to turn pricing prose into something another qualified reviewer can reproduce.
A pricing-rule record might look like this
Hypothetical example only:
Rule: CARD_MARKUP_DOMESTIC_V3
Applies from: 2026-07-01
Merchant entity: EU_ENTITY_1
Payment method: CARD
Condition: defined domestic transaction
Basis: captured amount
Rate: 0.XX%
Fixed fee: EUR 0.XX
Tier: monthly volume band B
Tax: according to validated contractual/tax treatment
Rounding: according to validated provider rule
Source: Fee Schedule Amendment 3
The percentages are intentionally omitted.
A useful fee audit should insert the merchant's real commercial terms rather than generic industry rates.
Contracted markup and pass-through cost are not the same thing
This distinction matters particularly where a provider contract separates—or conceptually references—provider markup from underlying payment costs.
The merchant might have:
Contracted provider markup
The PSP's agreed commercial charge.
Pass-through or underlying charges
Costs whose amount may be determined by another applicable pricing schedule, payment method, network, acquiring arrangement, or transaction characteristic.
Do not automatically judge the total fee by comparing it only with the provider markup.
If the contract says:
provider markup + applicable underlying charges,
then the audit must validate both pieces to the extent the necessary data and contractual definitions are available.
Likewise, do not claim an interchange, network, or acquiring component is present unless the provider's reports or authorized underlying records actually expose it.
The cluster explicitly requires fee decomposition to be evidence-led rather than guessed.
Blended pricing requires a different test
Some merchant agreements use blended charges rather than exposing underlying components separately.
That is useful for understanding why the audit must follow the merchant's actual pricing model.
If a merchant is contractually charged a blended rate, do not fabricate an interchange-plus decomposition just because that would make the analysis look more sophisticated.
Audit the economics the merchant actually agreed to.
Step 2 — Build the audit population
Before calculating fees, prove which transactions and financial events belong in the audit.
Possible source records include:
successful/captured payments
refunds
chargebacks/disputes
currency conversions
payout/remittance events
and:
monthly/platform charges.
Not every fee is necessarily transaction-level.
The brief explicitly distinguishes transaction-level charges from monthly invoices, so the audit needs at least two populations.
Transaction/event-level population
Potentially includes:
provider transaction ID
merchant entity
MID/account
transaction type
payment method
amount
currency
country/corridor variables required by the contract
processing/capture date
and:
actual provider fee where reported.
Period-level population
Potentially includes:
monthly platform charge
minimum commitment
aggregate tier adjustment
invoice-level tax
other contractually defined aggregate charge.
Do not force a monthly minimum onto individual transactions merely because the data model prefers transaction-level records.
A fee can be auditable while remaining period-level.
Step 3 — Calculate the expected fee
Now compute what the provider should have charged under the validated rules.
For a simple hypothetical transaction:
Captured amount: EUR 100.00
Applicable contracted rate: 0.40%
Applicable fixed fee: EUR 0.10
Then:
percentage component = EUR 100 × 0.40% = EUR 0.40
fixed component = EUR 0.10
expected fee before any other applicable component = EUR 0.50
This is deliberately simple.
Real pricing can depend on combinations of:
merchant entity
market
payment method
transaction type
card/product attributes where contractually relevant and observable
cross-border status
currency
monthly volume tier
refund/dispute status
effective date.
The audit rule should calculate only what the contract and source data support.
Calculate at the lowest reliable level
Transaction-level calculation is useful when the relevant fee is truly attributable to an individual transaction.
But the principle should be:
Calculate at the lowest level at which the commercial rule is both defined and supported by source data.
Examples:
Per-payment fixed fee
→ transaction level.
Percentage of captured amount
→ transaction level.
Monthly minimum
→ monthly aggregate.
Volume-tier pricing
→ transaction or period level depending on how the agreement applies the tier.
Monthly platform fee
→ invoice/period level.
Trying to allocate every fee down to one transaction can introduce fictional precision.
Step 4 — Determine the actual fee
The expected fee comes from the merchant's calculation.
The actual fee must come from provider financial evidence.
Depending on the PSP, relevant evidence might live in:
transaction reporting
settlement reporting
fee reports
invoice
statement
or:
payout deductions.
The reconciliation cluster explicitly warns that API access does not necessarily contain every financially authoritative settlement or fee field; some information can live in separate reports or invoices.
Do not calculate:
gross transaction amount − payout amount = PSP fee
unless the provider's settlement model establishes that the entire difference is fees.
The difference may include:
refunds
chargebacks
reserves
FX effects
prior balances
other adjustments.
A payout deduction is not automatically a processing fee.
Step 5 — Calculate variance
The core formula is intentionally simple:
Fee variance = Actual fee − Expected fee
If:
Expected fee = EUR 0.50
and:
Actual fee = EUR 0.51
then:
Variance = +EUR 0.01.
That is a variance.
It is not yet an overcharge.
The next step determines why it exists.
Step 6 — Classify the variance before escalating it
The editorial brief requires at least these categories:
Mix effect
Volume tier
Rounding
Tax
FX
Unknown fee
Contract interpretation
Suspected billing error.
A useful audit should make these categories operational.
Mix effect
The merchant's average/effective rate changed because the underlying transaction population changed.
Example:
Last month, more payments belonged to a lower-cost category.
This month, a greater share legitimately incurred a higher contractually defined payment-method or geographic charge.
Nothing about the rate card changed.
The mix changed.
This is why:
Effective-rate movement ≠ price change.
Volume tier
The expected fee used the wrong tier—or the provider used a tier the merchant did not expect.
Before classifying a billing discrepancy, verify:
tier metric
measurement period
eligible volume
currency
effective date
whether tiers are prospective or retroactive
and:
how reversals/refunds affect threshold calculations, if specified.
Do not infer these rules.
Extract them from the merchant's applicable agreement.
Rounding
A small variance can arise because:
merchant calculates aggregate percentage and rounds once
while:
provider calculates per transaction and rounds each fee.
Hypothetical example:
100 transactions each produce an unrounded fee of EUR 0.014.
Merchant method
EUR 0.014 × 100 = EUR 1.40
Provider method
If each transaction is rounded to EUR 0.01:
EUR 0.01 × 100 = EUR 1.00
or potentially another result depending on the validated rounding rule.
Neither calculation should be assumed.
The audit needs the actual applicable method.
Rounding differences can accumulate meaningfully at scale.
Tax
Taxes applied to PSP fees can create a difference between:
commercial fee before tax
and:
amount invoiced.
Do not label that difference an overcharge until applicable tax treatment has been validated by the appropriate finance/tax function.
This article should provide payment evidence, not tax advice.
FX
If the contractual charge or underlying transaction crosses currencies, verify:
source amount
source currency
conversion point
rate
rate timestamp/date
destination currency
and any:
explicit contractual conversion fee or spread that is actually observable.
The cluster's currency discipline explicitly prohibits comparing values across currencies without identifying the conversion point and rate context.
Unknown fee
The provider charged a fee line the merchant cannot map to a validated pricing rule.
That is a legitimate audit exception.
Do not automatically rename it:
overcharge.
Record it as:
unknown fee
and request the contractual/calculation basis.
Contract interpretation
The provider and merchant may disagree about how valid commercial language applies.
For example:
what qualifies for a volume threshold
or:
which geographical test defines the cross-border fee.
That is different from a mathematical billing error.
The escalation needs:
the applicable clause
the merchant calculation
the provider calculation
and:
the disputed interpretation.
Suspected billing error
Use this category after the merchant has ruled out the expected explanatory factors and can show that the actual charge does not reproduce the agreed pricing logic.
That is the point at which “possible overcharge” becomes justified language.
Why the effective payment rate can increase without any price change
This is the most important analytical trap to show explicitly.
Suppose the provider's contractual prices remain unchanged.
Month 1 consists mostly of one lower-cost transaction population.
Month 2 shifts toward a payment method, market, transaction type, or other category carrying a higher applicable contracted charge.
Then:
Total fees ÷ payment volume
can increase even though:
not one contractual rate changed.
That is a mix effect.
So audit two questions separately:
Pricing question
Did the applicable rates or fee logic change?
Portfolio question
Did the payment population subjected to those rates change?
Only the first is evidence of a pricing change.
The second can explain effective-rate movement under identical contract economics.
Volume tiers need their own calculation layer
Tiered payment pricing creates one of the easiest audit errors.
Suppose the agreement contains three monthly volume bands.
The audit must know:
What constitutes volume?
Gross processed payment amount?
Captured value?
Settled value?
Defined eligible transactions?
In which currency?
How are multiple merchant entities treated?
When is the threshold measured?
How are refunds treated?
Does a new tier apply only after the threshold, or to the complete period?
These are contractual questions.
Do not invent a universal tier methodology.
Build a tier ledger
For each pricing period, retain:
Field
Purpose
Contract/pricing version
Applicable terms
Period start/end
Tier window
Eligible volume
Tier basis
Currency/base
Prevent incorrect aggregation
Threshold reached
Evidence
Tier applied
Expected rule
Actual provider tier
Where observable
Variance
Difference
If several currencies must be converted to determine a contractual threshold, document the contractually appropriate conversion rule before calculating it.
Minimum commitments should be annualized carefully
Suppose an agreement has a monthly minimum.
A low-volume month might produce:
calculated transaction fees = $8,000
but:
minimum charge = $10,000.
The provider might therefore legitimately charge the minimum, depending on the exact agreement.
The effective fee rate rises.
No pricing term changed.
For annual budgeting, the merchant may want to model the potential annual minimum exposure.
But do not simply multiply a monthly shortfall by 12 unless the contract makes that a meaningful scenario.
A better view separates:
minimum commitment
actual qualifying fees
minimum top-up
and:
remaining contractual period.
The fee audit verifies what was billed.
Commercial finance can then use the same evidence for planning.
Refund and dispute fees need separate rules
A refund can have several financial effects:
refund principal
refund-processing charge
original processing fee retained or returned
and potentially:
currency/timing effects.
Do not assume the original payment fee is refunded.
The cluster explicitly requires provider- and payment-method-specific verification.
Likewise, dispute activity can include:
disputed amount
chargeback debit
chargeback fee
later reversal or recovery
and other applicable financial movements.
For a fee audit, focus on:
Was the fee component charged according to the applicable commercial schedule?
The broader financial-event linkage belongs in Reconciling Fees, Refunds and Chargebacks.
Cross-border fees require an explicit definition
“Cross-border” is not a sufficiently precise audit rule by itself.
The contract may define applicability based on a particular relationship involving:
merchant location
issuer/card country
acquiring location
payment method
or another defined factor.
Do not let analysts independently create a geography rule based on whichever country fields happen to exist in the warehouse.
Store:
raw provider geography variables
merchant canonical geography fields
and:
the exact commercial rule used to determine fee eligibility.
Then a cross-border-fee variance can be reproduced.
Audit the invoice as well as the transaction fees
A merchant can perfectly recalculate transaction-level charges and still fail to reconcile the provider invoice.
Why?
Because the invoice can contain:
monthly charges
minimums
taxes
credits
prior-period adjustments
or other validated commercial lines.
So perform a second bridge:
Expected transaction/event charges
+ expected monthly/platform charges
+ minimum adjustments
+/- valid credits/adjustments
+ applicable tax according to validated treatment
= Expected invoice amount
Then compare:
expected invoice
with:
actual invoice.
This keeps two controls separate:
Transaction fee validation
Did individual or attributable charges follow the pricing rules?
Invoice reconciliation
Does the provider's billed aggregate reconcile to the validated underlying fees and period-level charges?
Both matter.
Do not confuse the invoice with settlement deductions
Some PSP arrangements deduct fees directly from settlement.
Others may invoice some charges separately.
Others may combine mechanisms.
The fee audit therefore needs an explicit charge-location field:
Transaction record
Settlement
Payout
Invoice
Separate provider statement
or another verified location.
This prevents a merchant from counting the same fee twice because it appears in both a detailed transaction report and a summarized invoice.
For every fee category, document:
Where is the authoritative actual charge recorded?
The PSP Fee Audit Model
The complete operating model is:
Contract → Pricing rules
Extract:
fee
owner
basis
rate
fixed amount
currency
tier
geography
method
transaction type
effective date
exclusions
tax/rounding where applicable.
Pricing rules → Expected charges
Calculate at:
transaction
event
or:
appropriate aggregate period
depending on the commercial term.
Provider evidence → Actual charges
Use authoritative:
transaction fee
settlement
invoice
or other provider records.
Expected vs actual → Variance
Actual fee − Expected fee
Variance → Explanation
Classify:
Mix
Tier
Rounding
Tax
FX
Unknown fee
Contract interpretation
or:
Suspected billing error.
Expected charges → Invoice/settlement reconciliation
Prove that fee-level calculations reconcile to the aggregate amount actually deducted or invoiced.
Unexplained material variance → Escalation
Preserve enough evidence that the PSP can reproduce the merchant's finding.
What evidence supports a genuine billing discrepancy?
A message saying:
“Our fees look too high this month.”
is not strong audit evidence.
A better escalation package contains:
Contract evidence
agreement/schedule
applicable clause
pricing version
effective date.
Transaction evidence
provider transaction IDs
relevant merchant entity/MID
amounts
currencies
payment method
pricing-relevant characteristics.
Expected calculation
Show:
rule
inputs
formula
rounding
and:
expected charge.
Actual provider evidence
Show:
actual fee
source report/invoice
fee code/category where provided.
Variance
For example:
Expected: EUR X
Actual: EUR Y
Variance: EUR Z.
Investigation completed
Document which explanations were already tested:
mix
tier
tax
FX
rounding
effective date
contract interpretation.
Material scope
Show whether the issue affects:
one transaction
one merchant account
one payment method
one country
one billing period
or:
a repeatable population.
That turns a commercial complaint into a reproducible control finding.
Preserve the audit trail
For every material fee-audit result, retain:
source contract
pricing rule/version
source transaction/provider record
expected calculation
actual charge
variance
classification
reviewer
manual adjustment/override if any
provider correspondence/evidence
resolution
and:
subsequent correction.
The broader cluster requires this type of source-to-decision auditability for financially consequential controls.
If the provider issues a credit later, do not simply delete the original discrepancy.
Record:
original variance
→ dispute
→ provider resolution
→ credit/correction
→ closed finding.
That preserves control history.
Measure the audit as a control, not a savings campaign
A mature PSP fee audit should track:
Total expected fees
Fees calculated under validated contractual rules.
Total actual fees
Charges recorded in the authoritative provider evidence.
Fee variance
Actual fees − Expected fees
Variance as percentage of payment volume
Fee variance ÷ defined eligible payment volume
Always state the payment-volume denominator.
Unknown fee value
Total actual charges the merchant has not yet mapped to an agreed/validated fee rule.
Percentage of fees validated
One useful value-based definition is:
Actual fee value successfully mapped and tested against validated pricing logic ÷ total fee value eligible for audit
Define what “validated” means.
Variance by PSP
Useful in multi-provider environments, provided audit scope and fee definitions are comparable.
Variance by fee category
Helps distinguish:
transaction pricing
from:
dispute
cross-border
FX
or:
monthly charges.
Repeated discrepancies
Track recurrence by:
same rule
same PSP
same account
same category
and:
time period.
A recurring small error may matter more operationally than one isolated manual correction.
Time to resolve disputes
Measure from:
formal fee discrepancy opened
to:
commercially/financially resolved
using a defined start and end state.
These are the measurements assigned to the editorial brief.
How often should PSP fees be audited?
There is no universal cadence.
The uploaded operating model suggests payment fee analysis may fit into monthly and quarterly control rhythms, but cadence should vary with merchant volume, materiality, pricing complexity, close requirements, and provider relationship.
A useful design can include:
Monthly
Reconcile billed/deducted fees and investigate material exceptions.
Particularly useful where:
pricing is complex
volumes are high
or:
finance needs validated costs for close.
Quarterly
Perform broader controls such as:
re-test pricing mappings
review tier implementation
look for repeated discrepancies
confirm contract amendments were incorporated
review unknown fee categories.
After a commercial change
Run a targeted audit after:
new pricing
new PSP/product
new acquiring relationship
new payment method
new market
material volume-tier change.
The principle is:
Audit often enough that a systematic billing problem cannot compound for an unacceptable period before detection.
The merchant's finance/control owners should determine what that means in practice.
What if transaction-level fee data is unavailable?
Do not abandon the audit.
Change the level of testing.
Suppose the provider exposes only:
aggregate invoice fee by category.
The merchant may still be able to calculate:
expected aggregate fee
from:
eligible transaction population × contractual pricing logic
and compare that with the invoice.
The result has less diagnostic precision than direct transaction-level fee data.
It can still identify a material unexplained difference.
Label evidence quality clearly:
Transaction-level validated
Actual fee exists per underlying financial event.
Aggregate validated
Expected aggregate reproduces provider aggregate charge.
Partially validated
Some fee components are independently testable, others are not.
Unvalidated
Merchant cannot currently reproduce the charge.
Do not turn missing granularity into false certainty.
Can blended pricing be audited?
Yes—if the merchant has enough contractual and transaction evidence to reproduce the blended logic.
The merchant does not need an interchange-level decomposition if the agreement itself does not price that way.
For example, if the contract states a defined blended charge for an eligible transaction population, the audit can ask:
Did every eligible transaction receive the agreed blended charge?
Then separately validate conditional additions such as:
cross-border
FX
refund
dispute
or:
monthly charges
only where the contract contains them.
The mistake would be forcing a blended agreement into an interchange-plus model that the provider never contracted to deliver.
Its public payout support identifies payouts, local settlement, and payment reconciliation as Merchant Account support areas.
Those sources support a bounded recommendation:
Public documentation reviewed for this article does not establish:
transaction-level visibility for every fee component;
automatic contract-to-fee auditing;
automatic identification of overcharges;
one universal rounding/tier methodology;
identical pricing across products, methods, regions, or merchant agreements.
Turn fee-audit findings into commercial action
A fee audit can produce more than one type of finding.
Correctly billed
Provider charge reproduces the agreed commercial logic.
No escalation.
Correct, but economics changed because transaction mix changed
No billing defect.
The result may still matter commercially.
The right next action could be:
pricing analysis
routing analysis
payment-method strategy
or:
renegotiation.
That is not the same as billing remediation.
Contract interpretation issue
Resolve the commercial meaning.
Then update the pricing rule so future audits apply one governed interpretation.
Data-quality issue
The merchant cannot establish expected pricing because a required field is missing or inconsistent.
Fix the reporting/data layer.
Provider-reporting issue
A charge exists but cannot be traced adequately to provider evidence.
Escalate the reporting requirement separately from whether the amount itself is correct.
Confirmed billing discrepancy
Seek:
explanation
correction/credit where appropriate
and:
root-cause remediation.
Then verify that the correction itself appears in later financial records.
The final recommendation
The easiest PSP fee to challenge is the one that looks surprising.
The strongest PSP fee to challenge is the one the merchant can prove is inconsistent with its agreement.
That requires more than checking whether the effective rate moved.
A controlled fee audit starts with the contract, translates the commercial terms into reproducible pricing rules, applies those rules to the correct transaction and aggregate populations, compares expected charges with provider evidence, and explains legitimate differences before escalating the remainder.
The result should let the merchant say:
This was the rate in effect.
These transactions qualified for it.
This is how the volume tier was determined.
These were the applicable fixed, conditional, tax, FX, refund, dispute, or monthly charges supported by the agreement and evidence.
This is what we expected to pay.
This is what the provider charged.
This is the remaining variance.
And this is why we believe it is—or is not—a billing error.
That is the difference between fee monitoring and a real financial control.
This article provides general information and does not constitute accounting, audit, legal, tax, regulatory, or financial advice. PSP pricing, taxation, fees, settlement, currencies, and contractual rights vary by merchant, provider, product, jurisdiction, and agreement. Merchants should determine appropriate interpretations, controls, and escalation procedures with qualified advisers and their finance, procurement, legal, tax, and payments teams.
🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂
END OF ARTICLE
A. Brief interpretation
This is Reconciliation & Reporting — Article 14: Auditing PSP Fees. The article owns contract-to-actual fee validation: converting negotiated commercial terms into testable pricing rules, calculating what the merchant should have been charged, comparing that expectation with provider records, and investigating the variance. It should not become a pricing-negotiation guide or a general explanation of payment fees.
Merchant operational problem: A merchant has negotiated markups, transaction charges, tiers, cross-border fees, payment-method rates, monthly charges, and minimums, but cannot systematically reproduce what its PSP should have charged.
Unique evidence anchor: Negotiating a payment rate and receiving the agreed rate are two different processes.
Editorial position: A variance is not automatically an overcharge. First reproduce the applicable contractual logic—including effective dates, transaction mix, tiers, currencies, taxes, rounding, and conditional fees—then determine whether a true billing discrepancy remains.
Common assumption challenged: “If our effective payment rate increased, the PSP must have raised our pricing.”
Primary audit object: Contracted pricing logic compared with actual transaction-, settlement-, or invoice-level charges.
Source systems: Executed PSP contract and fee schedules, amendments, merchant payment data, PSP transaction/fee reports, settlement reports, provider invoices/statements, payout data where deductions occur there, and approved finance calculations.
Key identifiers: PSP, merchant entity, MID/account, provider transaction ID, fee line/reference, payment method, transaction type, settlement/invoice period, currency, and contract/pricing-schedule version.
Primary audience: Finance, procurement, controllers, payment leaders, pricing teams, commercial finance, and internal audit.
Merchant decision: Can the merchant independently reproduce the provider's applicable fee logic and explain every material difference between expected and actual charges?
Selected format: Contract-to-charge fee audit using the PSP Fee Audit Model prescribed in the brief.
Everything below is SEO, editorial, sourcing, verification, visual, and production guidance and is not publication copy.
PSP Fee Audit Model — production asset
Use the brief's framework as a downloadable worksheet or embedded calculator design:
Stage
Required control
Output
Contract
Extract valid commercial terms
Versioned pricing rules
Expected charge
Apply rules to eligible transactions/events/periods
Expected fee
Actual charge
Retrieve authoritative PSP fee evidence
Actual fee
Variance
Actual − expected
Fee variance
Diagnose
Mix, tier, rounding, tax, FX, unknown, interpretation, suspected error
Variance category
Reconcile
Tie validated charges to settlement/invoice
Audit completion
Resolve
Escalate material genuine discrepancies
Correction/explanation
Add four fields to every finding:
Contract evidence
Provider evidence
Owner
Resolution status
Visual
CONTRACT
Fee schedule · amendments · effective dates
↓
PRICING ENGINE
Eligibility · rate · fixed fee · tier · currency · conditional charge · rounding
↓
EXPECTED CHARGE
↓
ACTUAL PSP CHARGE
↓
VARIANCE
↙︎ ↓ ↓ ↓ ↓ ↘︎
Mix · Tier · Rounding · Tax/FX · Interpretation · Possible billing error
↓
INVOICE / SETTLEMENT RECONCILIATION
↓
RESOLUTION
Suggested alt text:
PSP fee audit workflow showing merchant contract terms converted into pricing rules, expected fees compared with actual PSP charges, fee variances classified, and validated charges reconciled to provider invoices or settlement records.
SEO package
How to Audit PSP Fees and Find Payment Billing Errors
H1:
How to Audit PSP Fees: Compare Your Payment Contract With What You Were Actually Charged
Meta description:
Learn how to audit PSP fees by turning payment contracts into pricing rules, calculating expected fees, comparing actual charges, validating volume tiers, and identifying genuine billing discrepancies.
Suggested URL:
/solve/payment-operations-dont-scale/reconciliation-reporting/auditing-psp-fees/
audit PSP fees
Secondary terms:
PSP fee audit; payment processing fee audit; payment provider fee audit; merchant fee audit; audit payment processing fees; PSP invoice audit; payment fee reconciliation; verify PSP fees; payment processing overcharges; payment pricing audit. These are the targets assigned in the editorial brief.
Article excerpt:
A higher effective payment rate does not by itself prove that a PSP changed its pricing. A defensible PSP fee audit reconstructs the merchant's contractual pricing logic, calculates expected charges for the applicable transaction and billing populations, compares them with actual PSP fees, and explains tiers, mix, rounding, tax, FX and conditional charges before classifying any remaining variance as a possible billing error.
Featured-answer candidate:
To audit PSP fees, convert the merchant's current fee schedule into calculation rules, apply those rules to the eligible transaction and aggregate billing populations, compare the expected fee with the actual provider charge, and investigate the variance. Do not call a variance an overcharge until volume tiers, transaction mix, rounding, taxes, FX and other applicable contractual conditions have been checked.
Internal links
The highest-priority links should follow the brief.
Anchor
Destination
Boundary
transaction-level fee reporting
Transaction-Level Fee Reporting
Owns cost-data availability and allocation
how to read a PSP pricing proposal
How to Read a PSP Pricing Proposal
Owns evaluating pricing before signing
PSP markup explained
PSP Markup Explained
Owns pricing-model education
payment reporting for finance teams
Payment Reporting for Finance Teams
Owns finance reporting pack
reconciling fees, refunds and chargebacks
Reconciling Fees, Refunds and Chargebacks
Owns financial-event reconciliation
The fee-audit article should remain the only page whose core question is:
Were the charges applied according to the merchant's agreed economics?
Measurement plan
Track the metrics specifically assigned in the brief.
Metric
Definition
Total expected fees
Sum of fees calculated under validated pricing rules
Total actual fees
Sum of authoritative provider charges in audit scope
Fee variance
Actual fees − expected fees
Variance / payment volume
Fee variance ÷ defined eligible payment volume
Unknown fee value
Actual charges with no validated mapping to agreed pricing logic
Fees validated
Validated actual-fee value ÷ total eligible actual-fee value
Variance by PSP
Fee variance segmented by PSP, on comparable audit scope
Variance by category
Fee variance segmented by governed fee category
Repeated discrepancies
Recurring validated issue by pricing rule/category/provider
Resolution time
Time from formal discrepancy opening to defined resolution
Every metric should identify the applicable period, currency logic, merchant entity/account scope, and data freshness.
Authoritative-source recommendations
Use the merchant's executed contract, Fee Schedule, amendments, and approved transaction/settlement/invoice evidence as the primary sources for any actual fee audit. Public pricing should not substitute for a merchant-specific agreement; the brief explicitly requires the distinction between public pricing and merchant contract.
Proposed author and reviewers
Recommended author: Payments pricing specialist or commercial payments lead with direct experience translating PSP contracts into payment-cost models.
Finance/procurement reviewer: Senior finance or payment-procurement lead.
Control reviewer: Controller or internal-audit specialist.
Additional reviewer where needed: Tax or legal specialist when the article contains anything beyond high-level treatment of tax or contractual interpretation.
These roles match the editorial brief's human-contribution recommendation.
The strongest first-hand evidence would be an approved anonymized audit where a change in effective rate was decomposed into:
mix effect
tier effect
legitimate conditional charges
and:
actual unexplained variance.
Do not invent savings or overcharges.
Fee fact-check checklist
Before publishing or operating a fee rule, verify:
Exact executed agreement.
Applicable fee schedule.
Amendments.
Effective dates.
Merchant entity.
MID/provider account.
Payment/product scope.
Calculation basis.
Percentage rate.
Fixed charge.
Currency.
Volume threshold.
Tier measurement period.
Tier population.
Prospective versus retroactive tier application.
Payment-method conditions.
Geography/cross-border definition.
Transaction-type conditions.
Refund fee.
Original-fee treatment on refund.
Dispute/chargeback fee.
Monthly/platform fees.
Minimum commitments.
FX charge where observable.
Rounding method.
Tax treatment.
Exclusions.
Provider actual-fee source.
Aggregate invoice source.
Settlement deduction source.
Duplicate representation across reports/invoice.
Adjustment/credit treatment.
Pricing-change notice/effective date.
Contract interpretation owner.
Payment-state and settlement fact checks
A fee audit can become wrong simply because the wrong transaction population was priced.
Verify whether the applicable fee is based on:
attempt
authorization
successful payment
capture
refund
dispute
settlement
or another defined event.
Do not assume:
authorized = captured
or:
captured = settled.
For settlement-deducted charges, separately verify:
gross proceeds
fees
refunds
chargebacks
reserves
FX
other adjustments
before treating the gross-to-net difference as payment-processing cost.
Provider-report verification
For each fee source, document:
report/API/invoice name
current schema
account eligibility
delivery mechanism
provider transaction/reference IDs
fee code
fee amount
fee currency
transaction type
date semantics
corrections
schema-change process
and:
whether the line is transaction-level or aggregate.
The brief explicitly warns that provider reporting interfaces and fee visibility are time-sensitive claims requiring current verification.
Accounting and tax boundary
The article should provide:
contract evidence
fee calculations
actual provider charges
variance evidence
and:
reconciliation support.
It should not prescribe universal:
tax treatment
expense classification
revenue presentation
accrual method
FX accounting
or other accounting policy.
The cluster requires complete, accurate, traceable payment evidence to feed accounting while leaving accounting treatment to the appropriate qualified owners.
Amber-flag claims
Do not publish these without evidence tied to the merchant's actual agreement and period:
“The PSP overcharged the merchant.”
“The provider changed our pricing.”
“Our effective rate should always be X%.”
“All transactions should cost X.”
“This fee is hidden.”
“This is interchange.”
“This is a scheme/network fee.”
“Cross-border means issuer country differs from merchant country.”
“Our volume tier applies retroactively.”
“Refunds return the original processing fee.”
“This FX difference is a PSP markup.”
“The provider used the wrong tax rate.”
“Every fee appears at transaction level.”
“Invoice total should equal transaction-level fees.”
“A payout deduction is a fee.”
Fee calculations are specifically identified as an amber-flag area requiring source, merchant/provider context, period, currency, and limitations to be stated.
Current approved terminology for merchant Fee Schedule.
Where merchant-specific pricing schedules are stored/accessed.
Products using other pricing structures.
Current transaction-level fee fields.
Current Reporting API fee visibility.
Settlement-report fee fields.
Payout-report fee fields.
Invoice/statement availability.
Fee codes/categories.
Processing-fee decomposition.
Fixed-fee visibility.
Percentage-fee visibility.
Cross-border fee reporting.
FX fee/spread reporting.
Refund fees.
Original-fee treatment after refunds.
Chargeback fees.
Remittance/payout fees.
Monthly account/platform charges.
Minimum commitments where applicable.
Volume-tier support.
How tier calculations are represented.
Pricing effective-date handling.
Rounding methodology.
Tax/VAT presentation on fees.
Credits/adjustments.
Fee correction workflow.
Merchant dispute/escalation workflow.
Current contractual dispute window applicable to the relevant merchant agreement.
Historical fee-report retention.
Current downloadable formats.
Fee-report/API schema versioning.
Multi-entity/MID fee reporting.
Multi-currency fee reporting.
Merchant-accessible transaction-to-fee linkage.
Ability to reconcile fees to settlement.
Ability to reconcile fees to invoice.
Whether any automated fee-validation functionality exists.
Approved fee-audit case study.
Approved fee-discrepancy outcome data.
Approved savings evidence, if any.
Which current public Terms apply to which legal entities/products.
Which older public support material remains operationally current.
Cluster sameness audit
Field
Auditing PSP Fees
Cluster article
Article 14
Primary intellectual format
Contract-to-charge financial control
Opening device
Effective rate rises 18 bps; refuse to call it an overcharge yet
Merchant problem
Negotiated pricing cannot be independently reproduced
Primary audience
Finance, procurement, controllers, payment pricing
Primary object
Expected fee versus actual fee
Primary source
Contract/Fee Schedule + provider charge evidence
Evidence anchor
Negotiated rate and charged rate are separate processes
Editorial position
Reproduce applicable pricing logic before alleging billing error
Assumption challenged
Rising effective rate means provider changed pricing
Core distinction
Variance ≠ confirmed overcharge
Supporting distinctions
expected ≠ actual; markup ≠ pass-through; mix ≠ price change; transaction fee ≠ invoice; public pricing ≠ merchant contract
Merchant decision
Can we reproduce every material PSP charge under our agreed economics?
Original framework
PSP Fee Audit Model
Primary metric
Fee variance
Coverage metric
Percentage of fee value validated
Risk metric
Unknown fee value
Operational metric
Time to resolve fee disputes
Primary failure mode
Effective-rate analysis mistaken for contract validation
Reconciliation boundary
Reconciles validated charges to invoice/settlement
Pricing boundary
Does not negotiate rates or teach pricing fundamentals
Reporting boundary
Uses fee data; Transaction-Level Fee Reporting owns cost-data model
Adjustment boundary
Tests fee charge only; refund/chargeback article owns broader financial-event reconciliation
Conclusion
A credible overcharge claim begins where the validated commercial logic stops reconciling
Does not own
PSP proposal negotiation, generic fee education, detailed fee-data architecture, general reconciliation workflow
That keeps the article within its assigned territory: validating whether a merchant was actually charged according to agreed PSP economics.
Need help narrowing down payment options?
Answer a few questions about your business and compare the capabilities that matter to you.
Explore matching options ↗