Payments, Advanced: PSP Architecture and Ecosystem · Course Map
Learning path: 12 chapters in four parts
- Architecture (Chapters 1–5): what a PSP provides to its customers, divided into a balance core, pay-in endpoints and payout endpoints. Each must meet both licensing and engineering requirements.
- Extensions (Chapters 6–8): acquiring, local payment methods and card issuing, built on that architecture.
- Stablecoins (Chapters 9–10): three places stablecoins can fit — customer balances, on-chain endpoints and a treasury bridge — and who uses each.
- Agentic Pay (Chapters 11–12): the extra layer needed when an AI agent, a program that carries out tasks for someone, initiates payments, and the companies building it.
Builds on: the foundational material in Payment Systems. You should recognize clearing and settlement, push and pull, interchange, the hierarchy of money, correspondent banks, the Wise model and reconciliation. Each chapter lists its prerequisites so you can revisit anything you have forgotten.
1. What you should be able to explain¶
By the end, you should be able to answer six questions without looking them up:
| Question | Where it is answered |
|---|---|
| When a PSP advertises collections in 60 countries and payouts in 120, what does it actually have? | Chapter 1 |
| Whose liability is the balance in the customer's app, where is the money, and can the customer recover it if the PSP fails? | Chapter 2 |
| Why does obtaining a licence not, by itself, make collections and payouts work? | Chapters 2–5 |
| How does providing a collection account differ from acquiring for a merchant, and why does acquiring require merchant underwriting and chargeback monitoring? | Chapter 6 |
| Which parts of a PSP change when stablecoins are added, and which remain the same? | Chapters 9–10 |
| Where in the process does a PSP have an opportunity when an AI agent spends for a customer? | Chapters 11–12 |
These questions organize the course. The chapters give you the mechanisms needed to work out the answers yourself.
2. The basic PSP architecture¶
The foundational material in Payment Systems explains cross-border transfers through SWIFT and correspondent banks: a payment crosses borders in stages, with each bank recording its own ledger entries. This course focuses on another approach, the product offered by many payment service providers, or PSPs:
A PSP provides its customers with one balance core, connected to pay-in and payout endpoints across countries.
Each component has a different job:
| Component | Responsibility | Industry terminology |
|---|---|---|
| Balance core | Hold customer funds, record each customer's entitlement and display the balance | Balance, ledger |
| Pay-in endpoint | Collect money over a country's local rails and identify the customer it belongs to | Pay-in |
| Payout endpoint | Send money over a country's local rails and report the result to the core | Payout |
There is one core and potentially many endpoints. In this model, a cross-border payment becomes two local transfers connected by an increase and a decrease on one ledger. The pay-in endpoint collects in the payer's country and the core increases the customer's balance. The payout endpoint pays in the recipient's country and the core reduces that balance. The customer's individual payment does not cross the border. The PSP still moves its own funds across borders, but periodically, to rebalance net surpluses and shortfalls across its country accounts, rather than separately for every customer payment.
Each component must meet two sets of requirements:
| Licensing requirements: permission to operate | Engineering requirements: correct operation | |
|---|---|---|
| Balance core | Permission to hold customer balances; safeguarding of customer funds | An authoritative ledger with distinct balance states; daily reconciliation against safeguarded accounts |
| Pay-in endpoint | Local permission to collect; clearing access | Identify every receipt; distinguish receipt from availability; handle returns |
| Payout endpoint | Local permission to pay; clearing access; screen beneficiaries before payment | Prefund local currency; track each payment's state; reconcile |
A licensed partner can provide the permissions in the middle column. It cannot remove the responsibilities in the last column: when a balance is wrong, the customer turns to the PSP. That distinction recurs throughout the course.
The other three parts each add a layer to this architecture:
- Extensions (Chapters 6–8): acquiring is a pay-in endpoint with dispute liability; a local payment method is a pay-in endpoint with a checkout experience; issuing is a payout endpoint with real-time authorization. Each adds responsibilities to the same architecture. PSPs also sell software that does not handle funds, such as billing, tax, fraud tools and identity checks; financial products requiring other permissions or a bank partner, such as yield on balances, merchant financing, credit cards and FX forwards; and platforms that let other companies use the core and endpoints. The first two categories are outside this course. The third is the fourth PSP form discussed in the end-to-end walkthrough.
- Stablecoins (Chapters 9–10): they can be an asset in customer balances, a pair of on-chain endpoints or the PSP's treasury bridge. They replace the middle leg of a cross-border chain — transfers between two banking systems — while the ends still need connections to fiat money.
- Agentic Pay (Chapters 11–12): this adds a mandate-to-credential layer before execution and an evidence trail afterward. A scoped payment credential can be used once, within specified merchant, amount and time limits. The existing core and endpoints still execute the payment.
3. The recurring example¶
Our fictional company is StarMap, a design software business registered in Singapore. Each month it collects a €1,000 subscription payment from Müller Design in Germany and pays £800 to a freelance illustrator in the UK. Later it needs to accept consumer cards, offer local payment methods in the Netherlands and Brazil, issue employee cards, pay a developer in the Philippines on a Friday night, and let a procurement agent buy software. Each new requirement lets us walk through another capability in the same business.
4. Chapter overview¶
The chapters generally pick up an open question, establish the situation, walk StarMap through the mechanism, compare the alternatives and explain the differences, then lead into the next topic. Self-check questions and answers close each chapter. The overview below gives the question, the central explanation and the new concepts; the full chapters provide the detail.
Part I · Architecture (1–5)
| Chapter | Question | Central explanation | New concepts |
|---|---|---|---|
| 1 · The PSP model | With only one bank account, both collections and payouts become cross-border transfers | Replace two cross-border transfers with two local transfers and one connecting ledger; each of the three components has two sets of requirements | Balance core, pay-in endpoint, payout endpoint, one core with many endpoints |
| 2 · The balance core | Who owes the displayed balance, and where is the money? | Licensing determines who may owe customers money and how it is safeguarded; engineering separates four balance states and reconciles daily; a licensed partner holds the authoritative ledger in the partner model | Safeguarded account, authoritative and mirror ledgers, four balance states, own licence and licensed partner |
| 3 · Pay-in endpoints | Which customer owns each of 137 receipts, and when can they use it? | Virtual accounts move identification from the payment reference to the account number; clearing access may be direct or indirect; availability depends on rail finality and the PSP's risk policy | Virtual account, direct and indirect participation, receipt and availability, three-way reconciliation |
| 4 · Payout endpoints | Where does the UK sterling come from, and how do we know a payment arrived? | Funds must be in the pool before payment; a state machine covers failures and returns; customer FX changes the ledger, while treasury rebalancing changes the pools | Liquidity pool, prefunding, beneficiary validation, payout state machine, customer FX and treasury rebalancing |
| 5 · The end-to-end walkthrough | How do the three components process one payment together? | Endpoints change the funds track; the core changes the ledger track; four PSP forms explain Wise, Airwallex and Nium | Funds track and ledger track, four PSP forms |
Part II · Extensions (6–8)
| Chapter | Question | Central explanation | New concepts |
|---|---|---|---|
| 6 · Acquiring | A collection account cannot accept a consumer's card payment | Pull payments place liability on the recipient's side, requiring merchant underwriting, authorization and chargeback handling; sponsorship provides access through a principal scheme member | Acquiring and acquirer, principal membership and sponsorship, merchant underwriting, chargeback monitoring, local and cross-border acquiring |
| 7 · Local payment methods | Where do iDEAL, Pix and UPI fit beyond a plain transfer or a card checkout? | A local rail, a checkout confirmation step and method-specific refund and settlement rules; integration costs accumulate, creating demand for aggregation and orchestration | Four attributes, direct integration, aggregation, orchestration, asynchronous results, local settlement currency |
| 8 · The issuing ecosystem | A balance does not come with a card that can spend it | Move to the issuing side of the four-party model: six roles, the authorization decision and interchange economics; issuing is a payout endpoint with real-time authorization | Issuer and BIN, program manager, issuing processor, real-time authorization, just-in-time funding, spend management |
Part III · Stablecoins (9–10)
| Chapter | Question | Central explanation | New concepts |
|---|---|---|---|
| 9 · Three stablecoin positions | A Friday-night payout must wait until Monday | Stablecoins can sit in customer balances, on-chain endpoints or a treasury bridge; permissions follow the assets held and for whom; on-chain endpoints take on work previously performed by a rail operator | Three stablecoin positions, customer-facing stablecoin balance, on-chain endpoint, treasury bridge, issuer and service-provider permissions |
| 10 · Stablecoin use cases | Which position are companies actually using? | Six use cases, four supply-chain layers and two questions: how costly are the fiat rails at either end, and does the recipient want to hold stablecoins? | Six use cases, four supply-chain layers, two decision criteria |
Part IV · Agentic Pay (11–12)
| Chapter | Question | Central explanation | New concepts |
|---|---|---|---|
| 11 · What agentic pay solves | What can an agent pay with, why might a merchant block it, and who answers for a wrong purchase? | Existing payment systems authorize a specific payment; four parties' problems lead to a six-step delegated-spending loop, three credential forms and PSP opportunities in credential issuance and payment execution | Four parties' problems, delegated-spending loop, three scoped credential forms, machine-readable checkout |
| 12 · The agentic pay ecosystem | Who performs each of the six steps? | Four player layers and six protocols; three observations from mid-2026: merchants retain checkout control, machine-to-machine payments are numerous but small, and transport protocols have moved to a neutral foundation | Four player layers, six protocols and their responsibilities, three developments to track |
5. How this course connects to the others¶
- The foundational material in Payment Systems is a prerequisite. Clearing, settlement, interchange, correspondent banks and the hierarchy of money receive brief reminders where needed.
- Payment Licences and Players covers the powers and application requirements of licences across ten jurisdictions. This course explains the nature of licensing requirements; use that course for individual licences.
- Beyond Cards: Local Payment Rails and QR Codes explains how domestic rails operate. Here, the local payment methods chapter focuses on how PSPs connect to them.