Chapter 1. Setting the scene: a transaction and its four parties.
“The acquirer rejected the capture, so we'll have to represent the chargeback.” To a newcomer, that sentence is opaque: payments have a jargon of their own, and a vocabulary mistake can be expensive. Confusing authorization with debit throws off a reconciliation; confusing acquirer with merchant makes a contract unreadable. The whole vocabulary is built around the card and its four-party model.
Two things travel between these four parties: messages (authorization requests, clearing) and money (settlement). A fifth player sets the rules: the scheme, or card network, such as Visa, Mastercard, or CB. In the real world, a swarm of technical providers sits in between. The next chapter covers them.
Chapter 2. The players: who does what in the chain.
Around the four parties orbits a whole ecosystem of providers, known generically as PSPs (payment service providers). In the EU regulatory sense, the term covers any institution authorized to provide payment services: banks, payment institutions, and e-money institutions. In everyday e-commerce usage, “PSP” means the provider that collects payments for the merchant (Stripe, Adyen, Worldline, etc.).
| End | Definition | Examples |
|---|---|---|
| PSP | Payment service provider: collects, routes, and secures the merchant's transactions | Stripe, Adyen, Worldline, Payplug |
| Gateway | Technical component that carries the transaction from the merchant's site to the acquirer | A CMS payment plug-in |
| Processor | Technical engine that processes messages (authorizations, clearing) on behalf of issuers or acquirers | Worldline Processing, equensWorldline |
| Scheme (network) | Sets the rules and standards, and arbitrates disputes between issuers and acquirers | Visa, Mastercard, CB |
| Wallet | Digital wallet that stores tokenized cards or a balance | Apple Pay, PayPal, Wero |
| Orchestrator | Layer that dynamically routes each payment to the best PSP or acquirer | Multi-PSP orchestration platforms |
| Payment facilitator (PayFac) | Aggregates sub-merchants under its own acquiring contract, with fast onboarding | Square, SumUp, Stripe |
| Marketplace | Platform that sells on behalf of third parties: it must safeguard the funds with a licensed PI or EMI | Amazon, B2B platforms |
| PI / EMI | Payment institution / e-money institution: licenses granted by the ACPR (France's banking supervisor), alternatives to a bank | Licensed fintechs |
| Regulators | License and supervise the players: the ACPR and the Banque de France in France, the EBA and the ECB in Europe | ACPR, EBA, ECB |
Since PSD2 (2018), two new regulated businesses have rounded out the picture. A payment initiation service provider (PISP) triggers a credit transfer from the customer's account, with their consent. An account information service provider (AISP) accesses accounts to display or analyze them. Together, these two businesses make up open banking.
One last player term: BNPL (buy now, pay later), the installment or deferred payment offered at checkout. The revised Consumer Credit Directive (CCD2, to be transposed by the end of 2025 and applicable from the end of 2026) is gradually bringing it into the scope of regulated credit.
Chapter 3. The flows: authorization, capture, clearing, settlement.
Flow vocabulary causes the most misunderstandings, so let's start with the timeline. A card transaction goes through four stages, each with its own precise term: authorization, capture, clearing, and settlement.
| End | What it is | What it isn't |
|---|---|---|
| Authorization | Issuer approval + hold on the amount | An account debit |
| Pre-authorization | Hold on an estimated amount (hotel, fuel), captured later for the actual amount | A final payment |
| Capture | The merchant's confirmation that the transaction should be collected (often at shipment) | The authorization itself |
| Batch | Grouped submission of captured transactions to the acquirer, before the cut-off time | Real-time processing |
| Clearing | Multilateral calculation of net positions between banks | Payout of the funds |
| Settlement | Actual transfer of funds that squares the positions | A mere provisional entry |
| Interchange | Fee paid by the acquirer to the issuer, capped in the EU at 0.2% (debit) and 0.3% (credit) | The total fee paid by the merchant |
| MDR (merchant discount rate) | Total price paid by the merchant: interchange + scheme fees + acquirer/PSP margin | A government tax |
In PSP dashboards, these stages show up as statuses: authorized, captured, settled, refunded. A typical webhook looks like this:
{
"event": "payment.captured",
"transactionId": "tr_20260711_8f2c",
"amount": { "value": 100.00, "currency": "EUR" },
"status": "captured",
"history": [
{ "status": "authorized", "at": "2026-07-11T09:14:02Z" },
{ "status": "captured", "at": "2026-07-11T18:00:11Z" }
],
"settlement": { "expected": "2026-07-13", "fees": { "mdr": 1.20 } }
}Outside cards, the vocabulary changes. A credit transfer (SCT) is pushed by the payer, while a direct debit (SDD) is pulled by the creditor under a mandate. An instant credit transfer (SCT Inst) settles in under 10 seconds, and these instruments, which move money from one account to another, are called A2A (account-to-account).
Chapter 4. Security and fraud: the vocabulary that protects you.
Security vocabulary revolves around one question: how do you prove that the payer really is the cardholder, and keep card data from being stolen? The first pillar is SCA (strong customer authentication), mandated by PSD2. It requires two factors from three categories: something I know (a code, a password), something I have (a phone, a card), and something I am (biometrics).
| End | Quick definition |
|---|---|
| SCA | Strong customer authentication: 2 factors out of knowledge / possession / inherence (PSD2) |
| 3-D Secure (3DS) | Protocol through which the merchant, scheme, and issuer exchange data to authenticate the cardholder online |
| Frictionless | 3DS flow with no customer action: the issuer relies on risk analysis |
| Challenge | 3DS flow with customer action: approval in the banking app, biometrics, a code |
| TRA exemption | SCA exemption based on the provider's risk analysis, up to €500 depending on its fraud rate |
| PAN | Primary account number: the card's 16-digit number |
| BIN | Bank identification number: the first digits of the PAN, identifying the issuer and the product |
| Security code (CVV/CVC) | The 3 digits on the back: prove physical possession of the card in card-not-present sales |
| Tokenization | Replaces the PAN with a token (DPAN) that is useless outside its context: this is what Apple Pay or a one-click checkout stores |
| PCI DSS | Mandatory security standard for anyone who stores, processes, or transmits card data (v4 in force since 2024) |
| EMV | Global standard for chip and contactless cards (Europay, Mastercard, Visa) |
| Liability shift | A 3DS-authenticated transaction shifts fraud liability to the issuer |
Chapter 5. After the payment: back office, disputes, and chargebacks.
Once the customer has left, the back office goes to work. It has to check that every sale was actually paid, process refunds, and fight chargebacks. The first term is reconciliation. It matches three sources that don't speak the same language: the site's orders, the PSP's transactions, and the transfers received at the bank.
| End | Who decides? | When? | Impact on the merchant |
|---|---|---|---|
| Void | The merchant | Before capture / batch | No funds move; the authorization is released |
| Refund | The merchant | After settlement | Returns the money voluntarily; possible fees, but no penalty |
| Chargeback | The cardholder, through their issuing bank | Up to 120 days later (depending on the reason code) | Funds pulled back automatically, handling fee, higher dispute ratio |
The chargeback follows a procedure codified in detail by the schemes. The cardholder disputes the transaction with their issuer, which pulls the funds back from the acquirer with a standardized reason code (fraud, item not received, duplicate transaction, etc.). The merchant can fight back by providing evidence, a process called representment. If the disagreement persists, the scheme decides in arbitration, and every transaction can be traced end to end by its ARN (acquirer reference number).
| End | Quick definition |
|---|---|
| Reconciliation | Matching orders ↔ PSP transactions ↔ bank transfers, discrepancy by discrepancy |
| Settlement report | PSP or acquirer file detailing transactions, fees, and net amount paid out |
| MID / TID | Identifiers for the merchant contract (merchant ID) and the terminal (terminal ID) |
| MCC | Merchant category code: 4-digit code classifying the merchant's business (5812 = restaurants, etc.) |
| KYC and AML/CFT | Merchant identity verification and anti-money laundering: onboarding obligations |
| Rolling reserve | Share of sales temporarily withheld by the acquirer as security against future chargebacks |
Chapter 6. Traps, false friends, and insider acronyms.
That leaves the vocabulary mix-ups that give a beginner away. The table below collects them one by one: reread it before every meeting.
| Often confused... | Whereas... |
|---|---|
| Acquirer and merchant | The merchant accepts the card; the acquirer is its financial provider |
| Authorization and debit | The authorization puts the amount on hold; the debit comes only after capture and settlement |
| Clearing and settlement | Clearing calculates net positions; settlement actually transfers the funds |
| Refund and chargeback | A refund is voluntary; a chargeback is imposed through the issuer's channel, with a fee |
| PSP and scheme | The PSP collects payments for the merchant; the scheme (Visa, CB) sets the network's rules |
| Debit card and credit card | Debit: the account is debited (immediately or deferred). Credit: backed by a revolving credit line; for the schemes, interchange also differs (0.2% vs. 0.3% in the EU) |
| Electronic money and commercial bank money | E-money is a prepaid balance issued by an EMI; commercial bank money is the balance of an ordinary bank account |
The final quiz and the flashcards will lock it all in. Payments vocabulary is learned like a living language: through repetition.