Payment service provider (PSP)

Without a PSP, an online shop would have to set up a separate contractual and integration relationship for each payment method: a contract with a credit card acquirer, one with PayPal, one with a pay-by-invoice provider, plus a direct debit scheme via the house bank. The PSP bundles these relationships. It provides an API or a shop plugin, forwards transactions to the respective networks, takes care of authentication, fraud screening, status feedback and, in many constellations, also the payout to the retailer. For the shop operator, a bundle of contracts, certifications and interfaces thus shrinks to one manageable integration.

How it works: what actually happens during a payment

A card payment in e-commerce runs in several stages that the customer perceives as a single click. The process in simplified form:

• Initiation: the customer selects a payment method in the checkout. The shop passes the amount, currency, order reference and customer data to the PSP, either via a redirect to a hosted payment page or via embedded fields in which the card data flows directly to the PSP and never touches the shop server.
• Authentication: for card payments in Europe, 3-D Secure is usually triggered. The customer confirms the payment in their banking app or via a second factor.
• Authorisation: the request travels via the acquirer and the card network (Visa, Mastercard) to the card-issuing bank, the issuer. The issuer checks funds and risk and approves or declines the amount. The amount is thus reserved but has not yet been transferred.
• Capture: with the capture, often only when the goods are shipped, the authorisation is redeemed. Many retailers deliberately separate authorisation and capture in order to handle partial deliveries and cancellations cleanly.
• Settlement and payout: the amounts are settled in batches and paid out to the retailer's account with a delay of a few working days, minus the fees.
• Downstream processes: refunds, partial refunds, returned direct debits and chargebacks also run via the PSP and must arrive in the shop or ERP system as status changes.

Distinction: PSP, acquirer, issuer, payment method provider

The terms are often mixed up in everyday use, but they refer to different roles in the same process.

Historically, the separation was sharper: the PSP was a pure technology intermediary and the acquirer the licensed financial partner. Today the boundary is blurring. Providers such as Stripe or Adyen act as so-called full-stack providers and combine gateway and acquiring in one contract. Others, such as Computop, deliberately position themselves as acquirer-neutral platforms through which retailers can integrate their own acquiring contracts. For procurement, this is a central difference: anyone who wants to achieve negotiable card terms with their own acquirer needs a PSP that allows third-party acquiring.

Fee models

A PSP's cost structure is almost always made up of several components. Anyone who looks at a single percentage usually compares incorrectly.

• Merchant discount rate (MDR): a percentage of the transaction amount. At its core, it contains the issuer's interchange fee, the card network's scheme fee and the acquirer's margin. With interchange++ pricing models, these three components are shown separately; with blended pricing, they are merged into a mixed rate.
• Transaction fee: a fixed amount per payment, regardless of the value of the goods. With small baskets, this fixed portion weighs relatively heavily; with high B2B amounts, hardly at all.
• Basic fee and set-up: a monthly platform fee, sometimes tiered by payment method or transaction volume.
• Additional charges: chargeback fees, refund fees, currency conversion, fees for risk and fraud modules, payouts in foreign currency.

For card payments with consumer cards within the European Economic Area, the interchange portion is capped by regulation; Regulation (EU) 2015/751 sets upper limits for debit and credit card transactions in the consumer sector. Corporate cards and cards from third countries do not fall under it, which is why a B2B retailer with international customers typically sees a noticeably different cost structure from a pure B2C shop. The full text of the regulation is available on EUR-Lex.

Regulatory framework: PSD2 and strong customer authentication

Payment services in the EU are governed by the second Payment Services Directive, Directive (EU) 2015/2366, usually abbreviated to PSD2. Two aspects particularly shape everyday e-commerce.

First, strong customer authentication (SCA). Electronic payments must, in principle, be confirmed with at least two independent factors from the categories of knowledge, possession and inherence. The technical details are governed by a delegated regulation that also defines exemptions, for example for small amounts, recurring payments of the same amount or merchant-initiated transactions. A good PSP actively uses these exemptions, because every authentication step avoided reduces purchase abandonment. How a provider handles exemptions is therefore a tangible conversion topic and not a legal side note.

Second, the authorisation requirement. Anyone who accepts and forwards third-party funds needs authorisation as a payment institution or e-money institution and is subject to supervision, in Germany by BaFin. Purely technical service providers that only pass on data and never hold funds at any point may fall under an exemption. For retailers, the distinction is relevant because it determines who is liable in an emergency and whose insolvency would put their own money at risk.

A successor regime is in the works: the EU Commission has proposed a package consisting of a third Payment Services Directive (PSD3) and a directly applicable Payment Services Regulation. The proposals are in the European legislative process; binding implementation deadlines should only be treated as fixed once they have been published in the Official Journal. For ongoing selection processes, this means above all: assess the provider's adaptability and do not write assumptions about specific deadlines into your planning.

Selection criteria for B2B retail in the DACH region

In B2B business in German-speaking countries, what matters is less the number of wallets offered than the ability to map classic business processes. The most important checkpoints:

• Pay by invoice with payment terms: purchase on account is deeply rooted in German retail and is effectively standard in B2B. What matters is whether the PSP offers pay by invoice with payment terms and with protection against bad debt, whether credit checks are possible at company level and whether partial deliveries are handled cleanly.
• SEPA business-to-business direct debit: it differs from the core direct debit scheme mainly in that there is no eight-week right of objection and the payer's bank must confirm the mandate in advance. This considerably reduces the risk of returned debits but requires mandate management that many standard integrations do not provide.
• Acquirer contracts and pricing model: is your own acquiring possible? Is interchange++ shown transparently? Can terms be renegotiated above certain volumes?
• Payout rhythm and reserves: how quickly is money paid out, are security deposits withheld, and how does the provider behave with seasonal jumps in revenue?
• Accounting connection: a PSP whose payout reports cannot be reconciled cleanly with ERP and financial accounting simply shifts costs to accounting.
• Contract lock-in and data portability: can stored payment methods be migrated if you change provider? Without token migration, a switch for subscription or repeat purchase models is considerably more expensive than the pure integration effort would suggest.

Integration into shop systems

Technically, there are three common depths of integration. With a redirect integration, the customer leaves the shop and pays on a PSP page; this is the simplest and shifts the security requirements entirely to the provider. With an embedded integration, the payment fields remain visually in the checkout but technically run in an element of the PSP. With a full API integration, the retailer processes the payment data itself and accordingly bears the full PCI DSS burden, almost always the wrong decision for mid-sized companies.

In Shopware 6, payment methods are connected via payment plugins and the payment handler structure. Several PSPs maintain official extensions in the Shopware Store, so that the basic integration is usually configuration work rather than development work. Effort typically only arises at the edges: when linking payment status with order status, with partial refunds or when pay-by-invoice providers expect additional data fields.

With Shopify, there is a commercial peculiarity that is regularly overlooked in selection processes: anyone who does not use Shopify Payments but connects a third-party PSP pays a platform-side transaction fee to Shopify in addition to the PSP's fees. Its level is tiered by plan and documented in the Shopify Help Center. It is precisely this fee that can tip the calculation if a retailer depends on a particular PSP for regulatory or process reasons.

Real-world example: the provider landscape in the DACH region

A mid-sized B2B retailer that runs Shopware and serves both business customers on account and end customers by card typically faces this choice:

• Mollie: a Dutch provider with lean set-up, a transparent price list and good coverage of European payment methods. Popular with small and medium-sized shops that want to be ready to start quickly.
• Stripe: strongly developer-oriented, an extensive API, wide-ranging functions for recurring payments and platform models. An advantage when your own software docks onto the payment process.
• Computop: a German provider with a strong omnichannel and branch orientation; acquirer-neutral, which means existing acquiring contracts can continue.
• Unzer: grown out of the German payments landscape, with a clear focus on pay by invoice and instalment purchase including protection against default.

The decision is rarely made on the fee rate. It is made on the question of which provider maps pay by invoice with payment terms, business direct debit and accounting reconciliation in such a way that no manual rework arises in operation.

Common misconceptions

"The lowest percentage wins." A low blended rate can be more expensive than a seemingly higher interchange++ rate as soon as the real card mix contains many regulated debit cards. It only becomes comparable via a projection with your own transaction mix.

"One PSP is always enough." With high volumes or several country markets, a second provider as a fallback makes sense, both against outages and as a negotiating position.

"PSP and acquirer are the same thing." With full-stack providers, effectively yes; with acquirer-neutral platforms, no. The distinction determines with whom card terms are negotiated.

"SCA only affects consumers." B2B card payments are also covered; relief results from specific exemptions for secure corporate payment processes, not from the type of customer as such.

Outlook

Three developments are shaping the field. First, consolidation: at the large providers, gateway, acquiring, risk screening and payout are growing together into one package, which simplifies integration and increases dependency. Second, account-based payment methods: with the European expansion of instant transfers, alternatives to the card are emerging that are economically attractive for high B2B amounts. Third, the shift of competition away from price towards process integration: PSPs that bring together pay by invoice, credit checks, dunning and ERP reconciliation solve a problem that costs mid-sized companies more money than a few basis points of merchant discount.

FAQ

Do I need my own acquirer contract in addition to the PSP?

Not necessarily. Full-stack providers bundle both. Your own acquiring contract is worthwhile above all with high card volumes, because it makes terms negotiable, provided the PSP supports third-party acquiring.

What distinguishes SEPA business-to-business direct debit from the core direct debit scheme?

With the business-to-business scheme, the payer's eight-week right of objection does not apply, and the payer's bank must check the mandate in advance. This reduces the risk of returned debits but is only permitted between companies and requires careful mandate management.

How many payment methods should a B2B shop offer?

Fewer than B2C benchmarks suggest. What matters are pay by invoice with payment terms, direct debit and card. Every additional payment method creates reconciliation effort in accounting without bringing any significant conversion in B2B.

How much effort is a change of PSP?

The technical integration is usually the smaller part. What takes effort is migrating stored payment methods, converting recurring payments, adapting accounting reconciliation and the parallel phase in which refunds for old orders still run via the previous provider.

Is the PSP liable in cases of fraud?

That depends on the payment method and authentication. With correctly performed strong customer authentication, liability for card payments generally shifts to the issuer. For transactions without authentication, for example under an exemption, the risk often remains with the retailer or the provider that applied the exemption.