A PSP contract is the pricing agreement between a fintech and a payment service provider, setting out the fees, rates, FX spreads, tiers, minimums, settlement terms, and timing rules that govern what the provider may charge. In fee verification, it is the source of truth: the authoritative statement of what every charge should be, against which actual charges are checked. The invoice tells you what the provider charged; the contract tells you what it should have charged. Verification is the comparison between them, and the contract is the side that defines correct.
In plain terms: the PSP contract is the agreement that decides what is right. Everything else, the invoice, the settlement, the FX rate, is a claim to be checked against it.
Key takeaways
- A PSP contract is the pricing agreement governing what a payment provider may charge a fintech: rates, tiers, FX spreads, minimums, settlement, and timing.
- It is the source of truth for fee verification because it, not the invoice, defines what each charge should be.
- The invoice is the provider's output and a claim; the contract is the agreement and the standard. When they disagree, the contract is the reference.
- A PSP contract is also distinct from the provider's public pricing page, which shows standard rates rather than your specific negotiated terms.
- To function as the source of truth at scale, the contract has to be turned into executable pricing logic, because prose in a folder cannot price a transaction.
- Everything downstream, expected charges, discrepancies, disputes, and recovery, anchors to the contract, which is why getting it right is foundational.
Short answer
A PSP contract is the agreement between a fintech and a payment service provider that defines the fees and terms the provider may charge: per-transaction rates, volume tiers, FX spreads, minimums, settlement terms, and timing rules. It is the source of truth in fee verification because correctness is defined by the contract, not by the invoice. The invoice is the provider's claim about what it charged; the contract is the agreement about what it should charge. To verify a charge, you reconstruct the expected cost from the contract and compare it to the actual charge, which means every expected figure, discrepancy, and dispute ultimately derives from the contract. For it to serve that role at scale, the contract must be converted from prose into executable pricing logic.
What a PSP contract is
A PSP contract is, at its core, a pricing schedule with conditions. It specifies what the provider may charge the fintech and under what circumstances, and a typical one covers several kinds of terms: per-transaction processing fees, expressed as fixed amounts, percentages, or both; volume tiers that change the rate as activity rises; FX spreads, usually defined as a margin over a reference rate; settlement terms, including how and when funds are settled and which fees are netted; minimums, such as a monthly floor with its true-up logic; timing rules, defining the windows in which charges are valid; and rebates or discounts owed back under certain conditions.
It is, in other words, dense conditional logic, signed and version-controlled. It is also the only document that states what the fintech actually agreed to pay, as opposed to what the provider's systems happen to bill.
Why the contract is the source of truth
The phrase source of truth has a precise meaning here: it is the authoritative reference that defines what is correct, the thing every other figure is checked against. For payment fees, that authority belongs to the contract, and the reason is straightforward.
Correctness is defined by agreement, and the contract is the agreement. A charge is correct if it matches what the two parties agreed, and what they agreed lives in the contract. Nothing else has standing to define correct. The invoice cannot, because the invoice is precisely the thing whose correctness is in question.
This is the distinction that makes verification possible. The invoice is the provider's output, generated by the provider's billing system, and it is a claim: this is what we charged you. The contract is the standard that claim is measured against. When the two agree, the charge is correct. When they disagree, the contract is right and the invoice is wrong, by definition, because the contract is what was agreed and the invoice is merely what was billed. Verification is the act of holding the claim up against the standard, and the standard is the contract.
What the contract is not
A few distinctions sharpen the definition.
It is not the invoice
The invoice is what was charged; the contract is what should have been charged. Treating the invoice as the source of truth, accepting it because it arrived and looks plausible, is exactly the error that lets fee leakage through.
It is not the public pricing page
A provider's published pricing shows its standard rates. Your PSP contract reflects your specific terms, including any negotiated rates, which may differ from the public page. The source of truth is your contract, not the provider's marketing pricing.
It is not the ledger or the events
The canonical record of events is what happened; the contract is what those events should have cost. One is the activity, the other is the pricing logic applied to it. Verification needs both, but they are different things.
The challenge: a contract has to be made executable
A PSP contract can only serve as the source of truth if it can actually price a transaction, and in its native form it cannot. It is a dense PDF of conditional prose, often amended across versions, written for humans to sign rather than for systems to apply. To anchor verification, every clause, every tier, every spread, every minimum, every timing rule, has to be turned into executable pricing logic: rules a system can apply to a specific transaction to compute what it should have cost.
This is the step that makes the difference between a contract that sits in a folder and a contract that governs your charges. Until the terms are reconstructed as logic, the source of truth is inert, and verification falls back to spot checks and memory. Once they are, the contract becomes what it should be: the live standard against which every transaction is measured.
Why everything anchors to the contract
The reason the PSP contract is foundational is that the entire chain of fee management derives from it. The expected charge is reconstructed from the contract. A discrepancy is the gap between that expected charge and the actual one. A dispute is the assertion that a charge breached a specific contract clause, supported by that clause as evidence. Recovery succeeds because the contract proves the claim. Even the discipline of provider economics is, at bottom, the management of charges against contracts. Remove the contract as the source of truth and none of it has a reference point: there is nothing to compute expected from, nothing to measure variance against, and nothing to cite in a dispute. This is why the contract, made executable, is the anchor that platforms such as Bluefyn build verification around, and it has a mirror on the billing side, where the client contract is the source of truth for what the fintech should charge its own customers.
The bottom line
A PSP contract is the pricing agreement that defines what a payment provider may charge a fintech, and it is the source of truth for fee verification because it, not the invoice, defines what every charge should be. The invoice is a claim; the contract is the standard. To play that role at scale it must be converted from prose into executable pricing logic, so it can price a transaction rather than merely describe pricing. Everything downstream, expected charges, discrepancies, disputes, and recovery, anchors to it, which is why treating the contract rather than the invoice as the source of truth is the foundation of controlling provider cost at all.
Frequently asked questions
What is a PSP contract?
It is the pricing agreement between a fintech and a payment service provider, defining the fees and terms the provider may charge: per-transaction rates, volume tiers, FX spreads, settlement terms, minimums, timing rules, and any rebates. It is dense conditional logic, signed and version-controlled, and it states what the fintech actually agreed to pay.
Why is the PSP contract the source of truth?
Because correctness is defined by what the two parties agreed, and the agreement lives in the contract. The invoice is the provider's claim about what it charged; the contract is the standard that claim is measured against. When they disagree, the contract is right by definition, because it is what was agreed.
What is the difference between a PSP contract and an invoice?
The contract states what the provider should charge; the invoice states what it did charge. The invoice is an output of the provider's billing system and a claim to be verified. Treating the invoice as authoritative, rather than the contract, is what allows fee leakage to pass unnoticed.
Is the PSP contract the same as the provider's public pricing page?
No. The public pricing page shows the provider's standard rates. Your PSP contract reflects your specific terms, including any negotiated rates, which may differ from the published page. The source of truth is your contract, not the provider's marketing pricing.
Why does a PSP contract need to be made executable?
Because in its native form it is prose in a PDF that cannot price a transaction. To serve as the source of truth at scale, its clauses, tiers, spreads, minimums, and timing rules must be converted into executable pricing logic that a system can apply to a specific transaction to compute what it should have cost.
What depends on the PSP contract in fee management?
Everything. The expected charge is reconstructed from it, a discrepancy is the gap from it, a dispute cites it as evidence, and recovery succeeds because it proves the claim. Without the contract as the source of truth, there is nothing to compute expected charges from, measure variance against, or cite in a dispute.
