The four-party model: what each of the four roles does
Card payments work across banks and across borders precisely because of a fixed division of roles. Let's pin the roles down with a table first:
| Role | Who it is | What it does | What it doesn't do |
|---|---|---|---|
| Cardholder | You: the person using the card | Initiates payments, confirms identity | Takes no part in clearing |
| Merchant | The party receiving payment | Submits transactions, bears the fees | Doesn't decide whether a transaction is approved |
| Issuing bank | The institution that issued your card | Decides whether to approve the transaction | Doesn't settle directly with the merchant |
| Acquirer | The institution contracted with the merchant | Routes the transaction into the network and settles funds to the merchant | Doesn't decide whether the issuer approves |
| Card network | Visa / Mastercard, etc. | Sets the rules, handles interchange and clearing | Neither issues cards nor acquires |
The last row is the most easily overlooked: the card network provides the rules and the clearing: it is not a party to the transaction.
Once this table is firmly in mind, many phenomena find their owner. For example, “the charge failed” actually means the issuing bank returning a decline at the authorization stage; “the money hasn't arrived yet” is a timing matter in the acquiring and settlement stage: these are different stages that belong to different roles.
How the request moves, how the money moves
Each transaction involves two flows that run in opposite directions and are not synchronized in time. Looking at them separately explains why there's always a gap between “charge successful” and “money arrives”:
| Information flow (authorization) | Money flow (settlement) | |
|---|---|---|
| Direction | Merchant → acquirer → network → issuer → back along the same path | Issuer side → network clearing → acquirer → merchant account |
| When it happens | Within seconds | Usually T+1 or later, depending on the merchant's agreement with its acquirer |
| Outcome | Approved or declined | The merchant receives the net amount after various fees |
| Where problems show up | Declines, timeouts, 3DS verification required | Delays, fee deductions, reserve holds |
The information flow decides “can I pay”; the money flow decides “when will it arrive and how much will I actually get.”
There's also an intermediate state that's often overlooked: capture. Authorization only holds the funds (a hold); the merchant actually takes the money through a later capture action, and only then do clearing and settlement begin. This is exactly why a hotel's pre-authorization and its final charge can differ in amount: the full chain is covered on From preauthorization to refunds: capture, clearing and settlement.
How each role makes money
The four-party model works because every role has a revenue source. Once you see where the money flows, you understand why merchants treat different cards differently:
- Issuing bank: earns interchange fees, paid by the merchant side and cleared through the network, while also bearing bad-debt and fraud losses;
- Card network: charges network service and clearing fees, either as a percentage or per transaction;
- Acquirers and PSPs: charge merchants a rate that bundles in the interchange, the network fees, and their own markup: typically quoted as “a single blended rate”;
- Merchant: pays the fees in exchange for being able to accept card payments and the sales volume that comes with them.
Interchange is not a single rate; it's priced separately by card category, transaction type, region, and merchant category: that's the economic root of “merchants treat some cards differently”: accepting a high-interchange card costs the merchant more. Understanding this also explains why some merchants state outright in their official terms that they don't accept certain card types.
The three-party model: where networks close the loop themselves
Outside the four-party model there's the three-party model: networks like American Express and Discover act as both issuer and acquirer in some markets, taking on both sides of the transaction themselves, so no interchange between two separate institutions is needed.
The practical effect for users: three-party networks don't fully match four-party networks in acceptance coverage and dispute handling, and the institution you deal with when something goes wrong is different too. If your card works at merchant A but not at merchant B, beyond the merchant's own rules, it may also come down to which side they're connected to and which set of processes they use.
Three terms that are frequently used interchangeably
Three roles in the industry are often treated as the same thing, but their boundaries are clear:
| Term | Actual responsibility | Common misconception |
|---|---|---|
| Acquirer | Contracts with merchants and bears responsibility for onboarding and settlement | Treated as “the bank,” but it's a licensed role that isn't necessarily a bank |
| PSP (payment service provider) | Aggregates payment capabilities for merchants, often connecting multiple acquirers | Treated as an acquirer, but a PSP may route transactions to another acquirer |
| Payment gateway | The technical channel that transmits and encrypts transaction data | Treated as an entity that can collect funds, but it doesn't acquire or settle on its own |
These three merchant-side layers are expanded on the next page: Merchant payment services: PSPs, gateways and MCCs.
For card users, mixing up the three terms has little practical impact, but you must separate them when troubleshooting: a declined transaction usually means asking the issuer or the network; money that hasn't arrived means asking the acquirer or PSP; a page throwing an error is mostly a gateway or API issue.
Know the parties, and you'll know who to ask
In practice: when something goes wrong, use this lookup table to decide who to contact first and save yourself a lot of unproductive back-and-forth:
| Symptom you see | Which stage it belongs to | Who to ask |
|---|---|---|
| Charge declined with a decline code | Issuer-side authorization | Read the decline code first, then check the type and permissions with the issuer |
| Verification page won't open or throws an API error | Technical channel | The merchant's API or gateway |
| Charge succeeded but the merchant says it didn't receive it | Clearing and settlement | The merchant's acquirer or PSP |
| Second subscription cycle fails | Transaction type and balance | The issuer (type) and your funding (balance) |
| You want this money back | Refund | Initiated by the merchant, then flows back to the issuer side |
How to use this table: locate the stage first, then find the role: don't open with “why doesn't it work?”
This site operates on the issuing side: we're the party that issues the card to you, and we're responsible for the card itself: the card network, the BIN, transaction type permissions, and the balance. Who acquires on the merchant side, when settlement happens, and what fees are charged are outside our control and not something we promise. So the accurate answer to “can I use it at a certain merchant” comes in two parts: we guarantee the card's own elements are complete and usable, while whether the merchant accepts it is decided by the merchant and its acquirer.
Once the parties are clear, bring card-side issues to us: choose a card by use case when issuing, and the issuance entry is on the registration page.
FAQ
What's the difference between an issuing bank and an acquirer?
The issuing bank is the party that issues the card to the cardholder and decides whether the transaction is approved; the acquirer is the party contracted with the merchant that routes the transaction into the network and settles funds to the merchant. They sit on opposite sides of the transaction.
Are Visa and Mastercard banks?
No. They're card networks that set the rules and handle interchange and clearing. They neither issue cards nor acquire, and they don't charge cardholders directly.
Why does a successful charge still take days to reach the merchant?
Because information and money are two separate flows: authorization completes within seconds, while the funds only reach the merchant's account after clearing and settlement, and the gap depends on the agreement between the merchant and its acquirer.
Are authorization and capture the same thing?
No. Authorization only holds the funds; capture is what actually takes the money. A hotel's pre-authorization and its final charge can differ precisely because there's a capture step in between.
Who pays interchange to whom?
The merchant side pays the issuer side, cleared through the card network. It's priced by card category, transaction type, region, and merchant category: the economic reason merchants treat different card types differently.
What's the difference between the three-party and four-party models?
In the three-party model, the network acts as both issuer and acquirer (e.g., Amex and Discover in some markets), so no interchange between two institutions is needed; in the four-party model, issuing and acquiring are separate and the network handles interchange and clearing.
Is a PSP the same as an acquirer?
Not necessarily. A PSP aggregates payment capabilities for merchants and often routes transactions to other acquirers for processing. In terms of responsibility they're two layers, even though many companies do both.
When a transaction is declined, should I contact the merchant or the issuer?
Read the decline code to locate the stage first: the vast majority of declines happen at the issuer-side authorization stage and show the reason the issuer returned; only if it's an API error does it belong to the merchant's technical channel.
Which party is this site in the model?
The issuing side. We're responsible for the card itself: the card network, BIN, transaction type permissions, and balance. Whether a merchant accepts it, when settlement happens, and what fees are charged are decided by the merchant and its acquirer.
Got the idea in a few minutes? Go open a card
Cards start at $1, no monthly fee; account top-up is $0 with a $20 minimum per deposit. See the pricing page for full details.