PSP reconciliation is the process of matching the settlement data your payment service providers report against your own records: your gateway, ERP, CRM or platform, and the money that actually arrived in your bank. It confirms that every deposit, withdrawal, refund and chargeback is accounted for, that payouts landed as expected, and that the fees you were charged match the fees you agreed. Where records don't align, you have a break to investigate.

Because there are more moving parts. Each provider reports in its own format, on its own settlement cycle, with its own fee structure and its own treatment of refunds, chargebacks and split payments. Add several providers, multiple currencies and high volume, and the number of comparisons grows faster than a team can keep pace with manually.

Ideally daily, or continuously as settlement files arrive. Payment data moves quickly and errors compound, so reconciling in step with the settlement cycle means a delayed payout or a fee discrepancy is caught within a day rather than at month end.

Common causes include timing differences between authorisation, capture and settlement; split payments and partial settlements; refunds and chargebacks processed in a different period from the original transaction; currency conversion differences; inconsistent transaction identifiers across systems; and fees deducted before payout rather than billed separately.

By recalculating what the fee should have been, transaction by transaction, against the rates in your contract, and comparing that to what was actually deducted. Providers rarely present fees in a way that makes this easy, and at scale even a small per-transaction discrepancy becomes material. This is the single most common source of recoverable value in PSP reconciliation.

Banks and PSPs coexist but operate differently. PSPs focus purely on facilitating electronic payments, while banks offer a wider range of services including loans, mortgages and insurance, alongside holding funds in accounts and handling deposits and cash withdrawals.

Both serve individuals and merchants, but by different methods. A PSP acts as an intermediary between consumers and financial institutions to facilitate electronic payments, which requires the consumer to authorise the use of their bank account for each transaction. A PISP has authorisation to initiate payments directly from a consumer's bank account to a specific merchant. As a form of open banking, and a subset of PSPs, PISPs produce a faster, smoother customer experience.

The FCA decides which companies can access open banking data, and approved organisations are known as third party providers, designated either AISP or PISP. AISPs offer account information services, gathering read-only financial information, typically so customers can view positions across several accounts without logging into each institution. PISPs provide payment initiation services, so they can both present financial information and move money from a user's account.

Payment service providers enable businesses to accept digital payments from sources such as credit and debit cards, e-wallets and online banking methods.

There are many, and some operate only in certain countries. Well-known examples include PayPal, Stripe and Worldpay.

Preparing a PSP reconciliation by hand is a lengthy task. Time disappears into retrieving data across providers, gateways, banks and internal systems, then cleansing it for comparison, all before reconciliation begins. Every manual step is also a chance for error, and there's no audit trail behind the result.

Many firms start with internal tools or scripts to manage PSP data. That can work early on, but maintaining integrations, adapting to changing PSP reporting formats, adding new providers and scaling matching logic alongside them becomes increasingly complex. A dedicated platform reduces long-term maintenance while providing configurable logic, structured workflows and audit visibility.