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

Cards & Merchant Payments / Learning brief

Card payments: the four-party model

Your notes

What this means in plain language

Who does what in a card payment: the cardholder and merchant at the ends, the issuer and acquirer as their banks, and the card network in the middle routing messages and publishing the rules — plus how the three-party model collapses those roles into one operator.

A card payment connects four parties through one network. The cardholder holds a card from their bank, the issuer. The merchant accepts cards through its own bank, the acquirer. The card network sits between the two banks: it routes authorisation and clearing messages, calculates who owes whom, and publishes the scheme rules every member signed. Because both banks answer to the same rulebook, a card issued by one member bank works at any merchant signed by any other member bank — the two ends of the payment never need a contract with each other. The contrast is the three-party (closed-loop) model, where one operator issues the cards, signs the merchants, and runs the network itself, so no interchange fee passes between separate banks.

Three things to remember

  1. 01

    Issuer serves the cardholder; acquirer serves the merchant; the network connects the banks and sets the rules — it is not a party to the sale.

  2. 02

    The scheme rulebook substitutes for bilateral contracts, which is how any member issuer's card works at any member acquirer's merchant.

  3. 03

    Three-party schemes collapse issuer, acquirer, and network into one operator, so there is no interchange between separate banks.

Where you would use this

USE CASE 01

Mapping which contract governs a question: card terms point to the issuer, merchant fees and funding point to the acquirer, inter-bank obligations point to the scheme rules.

USE CASE 02

Placing vendors correctly in an architecture review: processors, gateways, and payment facilitators act for one of the four parties rather than adding a new one.

USE CASE 03

Explaining to a merchant why its own bank cannot see or fix anything on the cardholder's side of the loop.

Put the idea into a real situation

Illustrative example (SYNTHETIC / TRAINING ONLY): Maya Chen pays EUR 3.80 at Demo Coffee Ltd. Her card comes from Bank Alfa (issuer); Demo Coffee accepts cards through Meridian Bank (acquirer); Cardnet — a fictional card network standing in for Visa- or Mastercard-style networks — connects the two banks. The authorisation question travels merchant to Meridian to Cardnet to Bank Alfa, and the answer retraces the path. Later, clearing and settlement move the EUR 3.80 from Bank Alfa's side to Meridian, which pays Demo Coffee net of fees. Maya never deals with Meridian, and Demo Coffee never deals with Bank Alfa — the network and its rulebook stand where a direct relationship would otherwise have to exist.

Evidence & review

REVIEWED 2026-07-18

Card payments on four-party (open-loop) schemes generally; not specific to one network, country, or card product.

What this brief simplifies: Treats the four roles as cleanly separated. Real deployments add processors, gateways, and payment facilitators acting on behalf of a party, and some three-party schemes license external issuers or acquirers in some markets.

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

    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

    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

Card authorization under the hood

The real-time round trip behind an approved card payment: the ISO 8583 authorization request and response legs, what the issuer checks before answering, the authorisation hold that reserves money without moving it, and stand-in processing when the issuer cannot answer at all.

READ BRIEF

Card clearing and settlement, explained

How an approved card payment becomes money: end-of-day batches, clearing records presented through the network, interchange applied, multilateral net positions, one settlement movement between banks, and the final postings that debit the cardholder and pay the merchant net of fees.

READ BRIEF

Card tokenisation: from PAN to DPAN

Why a phone wallet never carries the real card number: how EMV payment tokenisation swaps the PAN for a device-bound network token (often called a DPAN), who the token requestor and token service provider are, what the token vault maps, and why a lost phone no longer means a reissued card.

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…