Everyone in payments has heard of the four-party model. It appears in every introductory explainer, every scheme certification training deck, every vendor pitch. Most people in the industry can recite the four parties — issuer, acquirer, cardholder, merchant — without thinking.
Far fewer can explain what changes when a fifth party enters the picture, which model applies to their actual product, or why the distinction matters for the decisions they make every day.
This piece is a working explainer — not academic, not theoretical. It's the framing I use when a product team needs to understand the structure they're operating inside before they can make good decisions about it.
The Four-Party Model
The four-party model — also called the open-loop model — is the structure that underlies Visa and Mastercard. Four parties, each with a distinct role, connected through a scheme that sets the rules:
| Party | Role | Example |
|---|---|---|
| Cardholder | Initiates the transaction by presenting a card or credential | A customer paying at a POS terminal |
| Issuer | Holds the cardholder's account. Approves or declines the transaction. Bears the credit/fraud risk | The bank that issued the Visa card |
| Acquirer | Holds the merchant's account. Accepts the transaction on behalf of the merchant. Settles funds | The bank or processor that onboarded the merchant |
| Merchant | Accepts the payment in exchange for goods or services | Any business with a POS terminal or payment page |
The scheme — Visa or Mastercard — sits in the middle. It doesn't hold the money. It sets the operating rules, routes the transaction, and manages the interchange framework that determines how value flows between the issuer and acquirer.
This is the model that most product people learn first. It's clean, it's logical, and it describes how the majority of card transactions in the world work.
"The scheme doesn't hold the money. It holds the rules. Understanding that distinction is the foundation of everything else."
The Five-Party Model
The five-party model — also called the closed-loop model — adds a fifth party: the scheme itself as an active participant rather than a rule-setter. American Express and Diners Club are the canonical examples. In this model, the scheme is also the issuer, or is vertically integrated with the issuer function.
But in modern payments, the more practically relevant version of the five-party model is the one that emerges when a payment facilitator (PayFac) or aggregator enters the four-party structure. The five parties then become: cardholder, issuer, scheme, acquirer, and merchant — with the PayFac sitting between the acquirer and the merchant, acting as a sub-acquirer.
Stripe, Square, and PayPal in their acquiring capacity are operating this model. The merchant has a contract with Stripe, not with an acquiring bank directly. Stripe has the acquiring relationship with the bank. The bank has the scheme relationship with Visa or Mastercard.
| Party | Role in the 5-Party Model |
|---|---|
| Cardholder | Same as four-party — initiates the transaction |
| Issuer | Same as four-party — approves/declines, bears risk |
| Scheme | Same routing and rules function — but now explicitly recognised as a distinct layer |
| Acquirer / PayFac | The acquiring bank plus the payment facilitator — two entities where four-party had one |
| Merchant | Now a sub-merchant, contracting with the PayFac rather than the acquirer directly |
Why the Distinction Matters for Product Decisions
The model you're operating inside determines three things that product teams make decisions about constantly: liability, compliance scope, and feature constraints.
Liability
In the four-party model, liability for a fraudulent transaction travels through a defined pathway determined by scheme rules — typically landing on whichever party failed to implement the required security controls (3DS, chip, etc.). In the five-party model, the PayFac takes on the acquiring bank's liability exposure for its sub-merchants. This affects how a PayFac products its risk and underwriting logic, and why PayFacs have hard limits on merchant category codes and transaction volumes that a direct acquirer relationship wouldn't impose.
Compliance Scope
PCI-DSS scope, scheme compliance obligations, and AML/KYC requirements all attach differently depending on which party you are in the model. An issuer's compliance obligations look nothing like an acquirer's. A PayFac operating as a sub-acquirer inherits a specific set of scheme registration requirements — Visa's PayFac programme, Mastercard's Payment Facilitator rules — that a direct acquirer doesn't face in the same way. Product decisions that seem purely UX-driven (how you collect merchant data, how you handle chargebacks, how you present transaction limits) are often compliance-constrained at the model level.
Feature Constraints
The features a product can ship are bounded by the commercial and technical agreements that define its position in the model. An issuer can't unilaterally change how interchange is calculated. A PayFac can't offer its sub-merchants a settlement timeline the acquiring bank hasn't agreed to. A product manager who doesn't understand which party they're building for — and what that party can and can't do within the model — will spend months designing features that can't be built, or miss features that are already possible within existing agreements.
"The model you're operating inside isn't just context — it's a constraint system. The sooner your product team internalises it, the fewer dead ends they build toward."
Common Misconceptions
"We're on Visa, so we're four-party"
Not necessarily. Visa is a scheme, not a model. You can run a five-party structure on Visa rails. The model is determined by who holds which contractual relationships, not which network the card is issued on.
"The scheme is just the pipe"
The scheme is the rules, the routing, and increasingly — with products like Visa Direct, Mastercard Send, and network tokenization — an active infrastructure layer that issuers and acquirers build products on top of. Treating it as passive plumbing is how you miss the features the scheme is already offering.
"This is a technical concern, not a product concern"
The most common and most expensive misconception. The four/five-party distinction drives product strategy — which markets you can enter, what your margin structure looks like, what compliance posture you need, and how fast you can move. It's not an infrastructure detail. It's the operating environment.
The Practical Test
If you want to quickly establish which model your product is operating in, ask three questions:
Who does the merchant contract with? If it's directly with a bank, you're likely in a four-party structure. If it's with an intermediary, there's a five-party structure in play.
Who bears the chargeback liability? Follow the liability and you'll find the model. The party that absorbs chargebacks is the party carrying the acquiring risk — and that tells you where the model's commercial weight sits.
Who has the scheme registration? Visa and Mastercard both publish their registered acquirers and payment facilitators. If your business appears on that list, you're a direct participant. If it doesn't, you're operating through one who does.
A note on 1Link and local payment schemes
In markets like Pakistan, the domestic interbank network (1Link) operates a distinct model from international four-party schemes. The switch function, settlement, and dispute management all sit with the scheme operator in a way that's closer to the original closed-loop model than to open Visa/Mastercard rails. Product teams building for both international and domestic acceptance need to hold both models simultaneously — and understand where the rules diverge.
Why This Matters More Now
The four/five-party distinction is becoming more relevant, not less, as embedded finance and BaaS proliferate. Every fintech that wants to issue cards is entering a relationship with an issuing bank, a card network, and potentially a processor — three separate commercial and technical relationships, each with its own obligations. Every platform that wants to accept payments on behalf of merchants is stepping into a PayFac-adjacent model, whether they've registered as one or not.
Understanding which model you're in — and which party you are within it — is not a payments fundamentals exercise. It's the prerequisite for making product decisions that will actually hold up when the scheme audit arrives, when a regulator asks who's responsible for merchant KYC, or when a processor relationship needs renegotiating.
Working on a card or payments product?
If you need payments architecture thinking applied to your specific programme, let's talk.
Book a call