Payment Service Provider (PSP)
A payment service provider (PSP) is a specialised provider that technically processes online payments between buyer, merchant and bank. It bundles several payment methods – such as credit card, PayPal, purchase on account or direct debit – through a single interface and handles authorisation, routing and securing of the transaction.
A payment service provider (PSP) is a specialised provider that handles the technical and organisational processing of payments between buyer, merchant and the banking system. Instead of needing a separate contract and its own connection for every payment method – credit card, PayPal, purchase on account, SEPA direct debit, Apple Pay, Klarna – the merchant gets a single integration through a PSP, behind which many payment methods and their associated networks are bundled. The PSP authorises the payment, routes it to the correct entity (bank, card network, wallet provider), handles settlement and provides security mechanisms such as encryption, tokenisation and fraud prevention.
This makes the PSP the control centre of the payment process in e-commerce: it connects the shop checkout with the underlying financial flows, without the merchant having to store sensitive card data itself or maintain a direct contractual relationship with every card network. To the customer the PSP usually stays invisible in the background or appears as an embedded payment window; for the merchant it is the central contract partner for all things digital payment – from the first authorisation through refunds to the payout of the money into the business account.
At a glance
- PSP = technical intermediary between buyer, merchant and bank/card network
- Bundles many payment methods through a single interface instead of many individual contracts
- Handles authorisation, settlement, tokenisation and fraud prevention
- To be distinguished from acquirer, payment gateway and the payment method itself
- In the ERP central to payment reconciliation, open items and accounting
How a payment service provider (PSP) works
The process begins at the checkout: once the customer selects a payment method and confirms the purchase, the shop passes the payment data to the PSP in encrypted form. The PSP checks the details and routes the authorisation request to the relevant entity – for card payments via the card network to the card-issuing bank (issuer), for wallets to the wallet provider, for purchase on account to the underlying risk carrier. If the payment is approved, the shop receives a positive response and can release the order. The actual flow of money (settlement) then happens in bundled form, usually collected across the day, and is paid out to the merchant’s account after deduction of fees.
A key part of the PSP’s service is security and compliance. The PSP ensures encrypted transmission, replaces real card numbers with tokens (tokenisation) so the merchant does not have to store sensitive data, and ensures compliance with the PCI DSS security standard. It also handles strong customer authentication (SCA / 3-D Secure), which is mandatory for many transactions in European payment traffic.
Components: gateway, authorisation and settlement
Technically, the PSP process consists of several building blocks. The payment gateway is the interface through which the shop securely transfers the payment data. Authorisation is the real-time check of whether funds, limit and security features permit a payment. Settlement (clearing) is the downstream actual clearing and payout of the money. Some providers bundle all steps including the merchant’s banking relationship (in which case they additionally act as an acquirer), while others specialise only in gateway and orchestration and connect external acquirers.
Why a payment service provider (PSP) matters
Without a PSP, an online merchant would have to contract individually with every card network, every wallet and every invoice provider, integrate each interface separately and handle the demanding PCI DSS certification itself. The PSP takes away this complexity and considerably shortens the time to a working checkout. At the same time, a broad range of payment methods demonstrably increases conversion: if the preferred payment method is missing, this frequently leads to cart abandonment. A PSP makes it possible to flexibly enable or disable common and regionally important payment methods.
Added to this are risk and fraud management, automated refunds, recurring payments for subscription models, and consolidated reporting across all payment flows. For merchants selling internationally, the PSP additionally handles currency conversion and the connection of country-specific payment procedures. The downside is transaction fees (usually a percentage plus a fixed amount per transaction) and a certain dependence on the provider – which is why larger merchants increasingly rely on payment orchestration in order to use several PSPs in parallel.
Payment service provider (PSP) in the ERP system
For inventory management the PSP is relevant at a critical point: it determines whether and when an order counts as paid. Via an interface or a connector, the PSP reports payment status, incoming amounts, fees, refunds and chargebacks back to the ERP system. Only this feedback makes it possible to keep open items correct, release orders for picking and automate payment reconciliation. Without the coupling, the incoming payment has to be reconciled manually against orders – error-prone and barely feasible at high order volumes.
Particularly important is the clean posting of PSP payouts. Since the PSP usually pays out in bulk and withholds its fees in the process, the amount in the bank account does not match the sum of the individual orders. The ERP has to break the bulk payout back down to the individual documents, post the PSP fees as an expense and document everything in a GoBD-compliant manner. Many e-commerce-oriented ERP systems come with ready-made connections to common payment service providers that automatically read in payment status, payouts and fees.
Payment reconciliation and open items
Automatic payment reconciliation is the core benefit of the PSP-ERP coupling. Every reported incoming payment is assigned to the matching debtor and the matching invoice, so that open items are cleared automatically and dunning is only triggered for genuinely unpaid receivables. For purchase on account or direct debit, where order release and actual incoming payment are separated in time, this status tracking is especially valuable – it prevents goods from being shipped without secured payment or a long-settled receivable from being dunned.
Distinction: PSP vs. acquirer, gateway and payment method
The terms around digital payment are often confused. The PSP is the technical intermediary and orchestrator that bundles many payment methods and services. The acquirer (acquiring bank), by contrast, is the licensed financial institution that processes card transactions for the merchant and credits the card money – some PSPs are also acquirers, but many work with external acquirers. The payment gateway is merely the technical interface for transmitting the payment data and thus only one building block within the PSP’s service, not an independent contract partner.
The PSP must also be separated from the payment method itself (credit card, PayPal, Klarna, SEPA direct debit): the payment method is the procedure the customer pays with; the PSP is the entity that makes this procedure technically available and processes it. Finally, the PSP is to be distinguished from the shipping service provider and from fulfilment: these concern the physical flow of goods, while the PSP controls exclusively the flow of money. Both streams come together in the ERP but are different domains.
DACH specifics for payment service providers
In the German-speaking region, purchase on account is traditionally the most popular payment method – a circumstance that shapes PSP selection, because not every provider covers the purchase on account (including risk assumption) common in Germany and Austria. Regional procedures such as Wero (the giropay successor in Germany), EPS and the debit card (Austria) as well as TWINT and the QR invoice in Switzerland are expected by customers depending on the market, which is why a PSP with a suitable local payment method mix noticeably influences conversion.
In regulatory terms, payment service providers in the EU are subject to the second Payment Services Directive (PSD2), which among other things makes strong customer authentication (SCA) mandatory. In Germany, payment services additionally require authorisation from BaFin. For accounting purposes, PSP payouts, withheld fees and chargebacks must be recorded in a GoBD-compliant manner and retained in an audit-proof way – the transaction and fee data drawn from the PSP interface form the basis for this and must be transferred cleanly into financial accounting and open-item management.
Example
Example: an online merchant connects a PSP to the ERP
A mid-sized fashion merchant sells through its own shop and wants to offer PayPal, purchase on account and SEPA direct debit alongside credit card. Instead of contracting with each provider individually, it integrates a payment service provider that makes all four payment methods available through a single interface. At the checkout the customer selects their method, the PSP authorises the payment in real time and, for purchase on account, additionally assumes the default risk.
The PSP is coupled to the ERP via a connector: payment status, incoming payments, fees and refunds flow back automatically. When payment is secured, the order is released for picking; for purchase on account, the open item is only cleared after the status report “paid”. The PSP’s bundled daily payout is broken back down in the ERP to the individual documents and the withheld fees are posted as an expense – so the accounting stays GoBD-compliant without manual reconciliation.
Frequently asked questions
Related services
Sources
Questions about Payment Service Provider (PSP) in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.