PSPs, gateways, and orchestration
Untangling who does what to take a card: the gateway, the PSP, the acquirer, payment facilitators, and the orchestration layer that routes it all.
L0 Explain simply
An everyday analogy: taking cards is a job with several distinct trades, and one company often wears more than one hat. A payment-gateway is the doorway — the technical connection that carries a shop's payment from its checkout into the card networks and brings the answer back. A payment-service-provider is the broader contractor that arranges acceptance for the merchant: gateway, processing, sometimes the acquiring itself. Behind them sits the acquirer, the licensed bank that actually collects card money. When Demo Coffee Ltd signs up with a firm to take cards, that firm may be gateway, PSP and acquirer at once, or just one of the three subcontracting the rest. (SYNTHETIC / TRAINING ONLY — every firm named here is fictional.) The roles are stable even when the boxes are combined; naming them is how you tell who is responsible for what.
L1 Core concepts
A payment-gateway is the software path between a merchant's checkout and the acquiring bank: it captures card details securely, forwards the authorisation, and returns the result. A payment-service-provider (PSP) is the contracting party that gives a merchant the ability to accept payments — it may bundle the gateway, connect to one or many acquirers, and handle settlement reporting. Two models change who the merchant is to the card network. Under the payment-facilitator-model, the facilitator holds one master acquiring relationship and onboards many small sub-merchants underneath it, so they can accept cards quickly without their own acquirer contract. Under a merchant-of-record arrangement, a provider becomes the legal seller for the transaction, taking on tax, refunds and chargeback liability while the underlying business fulfils the order. These are commercial and liability choices, not new rails — the four-party model still runs underneath.
L2 Practitioner view
In production, the layer teams argue about most is payment-orchestration: a control plane above the gateways that routes each transaction to a chosen acquirer or alternative-payment-method, applies rules, and reacts to the result. Its everyday jobs are concrete. Routing sends traffic to the acquirer likely to approve it or to price it best. Cascading retries a declined authorisation down a fallback path — another acquirer, or a re-attempt after a soft decline — within limits, because blind retries annoy issuers and can breach scheme rules. Tokenisation at this layer lets a merchant store one orchestration token and swap providers without re-collecting cards. The honest tension: orchestration adds resilience and negotiating power, but it also concentrates a single point of failure and can blur PCI DSS scope and dispute responsibility, so the operational question is always which party answers when a payment or a refund goes wrong.
Sources for this topic2
- Market practiceMarch 2003 edition
A glossary of terms used in payments and settlement systems ↗ — CPSS (now CPMI), Bank for International Settlements
Terminology has evolved since this edition; newer CPMI publications refine some definitions.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
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.
Deepest material on this page: L2 — Practitioner view. Where a topic stops short of implementation depth, that is a deliberate coverage decision, not an oversight — see coverage.