Payment processing systems: what a PSP needs from its accounts and payout rails

A payment processing system moves money from a customer's card or account to yours through a chain of players most businesses never see: gateway, processor, acquirer, and the accounts on each end. Here's what each part does and where your account and IBAN sit in it.

A payment processing system is the connected set of components that moves money from a customer's checkout to a merchant's payout: the gateway that captures the payment, the acquirer that authorises the card, the accounts that hold the funds, and the rails that settle and pay out. Most guides on payment processing stop at the card leg. For a payment service provider (PSP) or platform, the harder questions sit further down the stack, in the accounts and payout rails that decide whether you can hold client funds, settle in the right currency, and pay out across borders. This guide maps the full system, then focuses on the layer PSPs actually have to solve.

Key takeaways

A payment processing system spans four jobs: capture (gateway), authorisation (acquirer), holding (accounts), and settlement/payout (rails).
The card leg gets the attention, but the accounts-and-payout layer is where PSPs hit friction.
A card acquirer and an e-money institution (EMI) sit at different layers: one processes card transactions, the other provides the accounts and SEPA/SWIFT payout rails.
What a PSP needs from that layer: dedicated IBANs, SEPA and SWIFT payouts, multi-currency support, an API, and compliance that fits its sector.

What a payment processing system is

A payment processing system is the full chain that turns a customer's intent to pay into settled funds in a merchant's account. It's easiest to read as a sequence of jobs, each handled by a different component:

Capture, the gateway. The payment gateway is the customer-facing layer for online payment processing: it collects payment information, and the payment gateway encrypts it so sensitive payment data stays protected during online transactions. It may also use tokenisation, which replaces card details with unique tokens for security.
Authorisation, the acquirer and card networks. After the customer initiates payment with a credit or debit card, the acquiring bank and card schemes pass the request to the issuing bank, which approves or declines.
Holding, the accounts. Once money moves, it has to sit somewhere: client accounts, settlement accounts, and the balances a platform holds on behalf of its merchants.
Settlement and payout, the rails. The money is then paid out to the end merchant or beneficiary, over SEPA for euro payments, SWIFT for cross-border, or local rails in a given market.

For a single online shop taking card payments, most of this is invisible behind one processor. For a PSP or platform that collects on behalf of many merchants and pays them out, each of these jobs is a decision, and the last two are where the real work lives. Modern systems also need to support payment methods beyond cards, including digital wallets and bank transfers, while keeping financial transactions on secure channels with PCI DSS compliance and fraud detection controls.

Payment gateway and acquirer vs accounts and payout rails

Here's the distinction that trips people up, because two very different jobs both get called "payment processing."The gateway and acquirer handle the card transaction, including credit card payments and debit card payments. The gateway captures the payment; the acquirer, working with the card networks, authorises it and pulls the funds from the cardholder's bank account toward the merchant's bank for payment collection into the merchant account and onward payout to the merchant's bank account. This is the layer people picture when they think of a payment processor.The accounts and payout rails handle everything after authorisation: where the money is held, in what currency, and how it reaches the end beneficiary. Approved transactions are then settled and usually reach the merchant’s account within 1–3 business days, depending on the rails and provider. This is bank-and-EMI territory: IBANs, SEPA and SWIFT transfers, currency conversion, and the account structure that keeps client money identifiable.A PSP usually has the card leg covered. Where it gets stuck is the second layer: it needs accounts in its own name, the ability to receive and hold multiple currencies, and payout rails that reach every market its merchants operate in. Those aren't things a card acquirer provides. They come from an accounts-and-payments partner, and this layer matters for cash flow because settlement delays affect when merchants can access funds in their bank account.

What a PSP actually needs from a banking or EMI partner

Strip it back and a PSP or platform needs five things from the accounts-and-payout layer, and the right payment processing services also depend on sales channels, transaction volume, and required features. This is the checklist that decides whether a partner fits:

Dedicated IBANs in the PSP's own name. Named accounts, not a sub-reference inside a pooled omnibus account behind another provider. Named IBANs make client funds identifiable and reconciliation clean, which matters for both operations and audit.
SEPA and SWIFT payouts. SEPA (including SEPA Instant) for euro payouts across Europe, and SWIFT for cross-border. A PSP paying merchants in multiple countries needs both rails, not one.
Multi-currency support. The ability to receive and hold funds in several currencies and convert on payout, so a platform isn't forced through a single home currency on every transaction.
An API. Account creation, payments, and real-time transaction notifications available programmatically. A PSP is a technical operation: it needs to move money and reconcile it in code, not through a dashboard one payment at a time. APIs should also expose transaction data and transaction details for reporting, analytics, and integration with accounting software, including the detailed reports and analytics many teams need on customer transactions. Some businesses also need support for recurring payments or payment links through their broader online payment setup, and online payment gateways often extend this with subscription billing and website-builder integrations.
A compliance process and a real account manager. Onboarding that understands the PSP model and a named contact who knows the account, rather than a ticket queue. For regulated and higher-risk flows, this is often the difference between an account that opens and one that stalls.

A partner that delivers all five lets a PSP run its accounts-and-payout layer as infrastructure. Missing any one of them usually means a workaround that leaks time or margin. At this layer, efficient payment processing also helps manage cash flow, improves customer satisfaction and trust, and scales with business growth; businesses adopting online payment systems often see better cash flow management, and different setups can suit anything from mobile readers to omnichannel platforms.

Where an EMI fits vs a card acquirer

An EMI and a card acquirer are often mistaken for competitors. They sit at different layers of the same stack. Narvi is an EMI, not a card acquirer. It occupies the accounts-and-payout layer: it issues dedicated business IBANs in the account holder's name, provides SEPA and SWIFT payout rails, supports multi-currency receiving and conversion, and exposes it all through an API with real-time transaction notifications. A card acquirer or gateway handles cardholder data and ensures compliance with PCI DSS through controls tied to data security standards, while the EMI covers accounts and payouts. A PSP keeps its card processor for the card leg and plugs an EMI into the layer beneath for accounts and payouts. The two are complementary, not a swap.Narvi is a Finnish-licensed EMI, regulated by the Finnish Financial Supervisory Authority (FIN-FSA) and passported across the EEA. Holding funds with an EMI works under e-money safeguarding rules rather than a deposit guarantee scheme, which is a distinction worth being clear on when you choose where client money sits.

Onboarding a PSP with a perceived-high-risk profile

PSPs, and the sectors they serve, often carry a risk label that makes mainstream providers hesitate. Crypto flows, iGaming merchants, and cross-border volume can all trigger a decline at the compliance stage, not because anything is wrong, but because the provider isn't set up to assess that profile.An EMI whose onboarding is built for these sectors handles it differently. Rather than a blanket no, the process is a proper risk assessment: understanding the business model, the flows, and the merchant base, then structuring the account to fit. Narvi works with fintechs, PSPs, crypto businesses, and other regulated and higher-risk operators, and its onboarding is designed to assess exactly these profiles rather than reject them on sight. It's a compliance process, not a guarantee, and that's the honest framing: a partner willing and equipped to underwrite the risk, not one that waves it through.

Conclusion

A payment processing system is four jobs, not one, and for a PSP the load sits on the last two: holding client funds and paying them out, especially as online payment processing is expected to grow at a CAGR of 15.20% from 2023 to 2030 and the global digital payment market is projected to reach $24.31 trillion by 2030. The card leg has plenty of providers. Growth in online payment and contactless/mobile checkout, which can reduce cart abandonment, also raises the need for robust security measures and fraud prevention tools as fraud in online payments is forecast to reach $109 billion globally by 2029, and those tools help block suspicious payment activity and reduce fraudulent transactions. The accounts-and-payout layer, dedicated IBANs, SEPA and SWIFT rails, multi-currency, an API, and compliance that fits your sector, is the part that actually decides whether a PSP can operate across markets. An EMI is the piece that solves it, sitting beneath the card processor rather than competing with it.

Talk to our team about PSP accounts

Book a call with Narvi

Frequently Asked Questions

Payment processing is the secure handling of financial transactions when customers pay for goods or services, moving money from the payer through to settled funds in a merchant's account. It spans capturing the payment, authorising it, and settling and paying it out, so for businesses accepting payments the system may support various payment methods, including alternative payment methods, not only cards. Different components handle each step.

The customer initiates payment at checkout, where a gateway captures payment details securely. For cards, an acquirer and the card networks authorise the transaction and pull the funds, and the payment processor receives the issuing bank's decision and returns it to the merchant. The money is then held in accounts and finally paid out to the merchant or beneficiary over the appropriate rails: SEPA for euro payments, SWIFT for cross-border, or local schemes. In online payment processing, the processor forwards acquiring bank requests and confirmation before payout. For a PSP paying many merchants, the accounts-and-payout stage is the most involved. Providers also charge transaction fees under a fee structure that may use flat rate pricing, where a fixed processing fee or fixed percentage per transaction improves predictability, interchange-plus pricing, which includes actual interchange costs plus markup, or tiered pricing, which categorizes transactions by risk level; processor fees cover overhead and may be negotiable.

Global payment processing is handling payments across multiple countries and currencies, end to end, and global setups often rely on payment processing companies that support local payment options and international payments across regions. It adds requirements a domestic setup doesn't have: multi-currency accounts, cross-border payout rails like SWIFT alongside SEPA, currency conversion, compliance across jurisdictions, and support for multiple payment methods such as Apple Pay, mobile payments, direct debit, and local bank-based methods; flat-rate pricing charges a fixed percentage per transaction. For a platform operating internationally, the accounts-and-payout layer has to reach every market its merchants are in, and the best payment processing companies pair a secure payment processing system with local market fit because customers prefer familiar payment options in each region.

Last updated: 319 August 2026. Narvi Payments Oy Ab is an authorised Electronic Money Institution licensed by the Finnish Financial Supervisory Authority (FIN-FSA), registration number 3190214-6.DisclaimerThis publication is provided for general information purposes and does not constitute legal, tax, or other professional advice from Narvi Payments Oy Ab or its affiliates, and it is not intended as a substitute for obtaining advice from a financial advisor or any other professional.