GLOBAL PAYMENTS KNOWLEDGEISO 20022 / SWIFT / SEPA / MT / MX

Wallets & Alternative Rails / Learning brief

PSP, gateway, acquirer: who does what

Your notes

What this means in plain language

Merchants meet a crowd of intermediaries with overlapping names: gateway, payment service provider, acquirer, payment facilitator. Each does a distinct job. The gateway carries the transaction, the acquirer holds the scheme licence and the money, and a payment facilitator lets small merchants trade under its own umbrella. Untangling the roles tells you who is accountable when something breaks.

Taking cards is a job with several distinct trades, and one company often wears more than one hat, which is why the names blur. A payment gateway is the technical doorway: it captures the payment at checkout, forwards the authorisation request, and returns the answer — it holds no money. A payment service provider (PSP) is the broader contracting party that gives a merchant the ability to accept payments, often bundling the gateway with acquiring access, risk, and settlement reporting. The acquirer is the licensed bank that actually collects the card money and holds the scheme licence. A payment facilitator sits on top of an acquirer, onboarding many small sub-merchants under its own umbrella. The roles stay stable even when one provider combines them, and naming them is how you tell who is accountable when a payment or a refund goes wrong.

Three things to remember

  1. 01

    A gateway carries the transaction and holds no funds; the acquirer holds the scheme licence and the money.

  2. 02

    A PSP is the contracting party that may bundle gateway, acquiring access, and reporting into one relationship.

  3. 03

    A payment facilitator lets small sub-merchants accept cards under its master acquiring relationship, concentrating onboarding and monitoring duties on itself.

Where you would use this

USE CASE 01

A merchant reading a chargeback notice works out which party — gateway, PSP, or acquirer — actually owns the dispute.

USE CASE 02

A small seller decides between contracting its own acquirer and joining a payment facilitator's umbrella for faster onboarding.

USE CASE 03

An operations lead maps the accountability chain before a launch, so an outage or a refund failure has a clear owner.

Put the idea into a real situation

(SYNTHETIC / TRAINING ONLY) Demo Coffee Ltd signs one contract with Larkpay, a fictional payment institution, to take cards. In that single relationship Larkpay is the gateway (its checkout captures the card), the PSP (it arranges acceptance and reporting), and it routes to Meridian Bank as the acquirer that holds the licence and collects the money. When a customer later disputes a EUR 4.50 charge, Demo Coffee needs to know that the chargeback is owned by the acquirer through Larkpay, not by the gateway software — the same firm, but a different hat. Had Demo Coffee instead been a sub-merchant under a payment facilitator, that facilitator would have answered for onboarding and monitoring.

Evidence & review

REVIEWED 2026-07-18

Card acceptance for online and in-person merchants; role names vary by provider and market, but the accountability chain holds.

What this brief simplifies: One provider often bundles several roles, so the clean separation shown here is a teaching model. Payment-facilitator obligations are summarised, not enumerated. Merchant and provider are synthetic.

Sources for this brief2
  1. Market practiceMarch 2003 edition

    A glossary of terms used in payments and settlement systemsCPSS (now CPMI), Bank for International Settlements · Definitions: acquirer, payment service provider

    Standard definitions for payment, clearing, and settlement terminology used across BIS committee reports and referenced by glossary entries on this site. · Checked 2026-07-12

    Terminology has evolved since this edition; newer CPMI publications refine some definitions.

  2. Simplified educational illustration

    Payments Signal editorial teaching modelsPayments Signal · Role separation and synthetic merchant example

    This site's own simplified teaching models. · Checked 2026-07-12

    Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.

Learn this properly

Related briefs

Digital wallets, explained: pass-through versus staged

A digital wallet is a container for a way to pay, but not all wallets work alike. Pass-through wallets present a tokenised version of an existing card so the payment runs on the card rails; staged wallets take an in-wallet payment first, then pay the merchant separately. Knowing which kind you are looking at explains who the merchant is really paid by, where the funds pause, and what the device actually stores.

READ BRIEF

How network tokenisation protects a card

Network tokenisation replaces a card's real number with a device- or merchant-specific stand-in, the DPAN, that only the network can turn back into the real account. Because the token carries domain controls, a copied token is close to worthless outside the device and merchant it was minted for. This is how a stored card can be safer than the number printed on the plastic.

READ BRIEF

Payment orchestration and routing

An orchestration layer sits above a merchant's payment providers and decides, per transaction, which one to use, when to retry, and whether to cascade a declined attempt to a second provider. It is a router, not a rail: it moves no money itself. Used with care it lifts approval rates; used carelessly it retries a payment the customer already abandoned.

READ BRIEF
COMMUNITY SIGNAL

Discuss this learning page

Share an operational observation or ask a concrete payments question. Your name and message are public; your email remains private.

NEXT QUESTION REVIEWMonday, 27 Jul, 8:00 amMonday answer runs use source-supported educational material. Some questions may need owner review.
WHAT ARE YOU SHARING?

Public discussion

LOADING

Loading the discussion…