Issuer, Acquirer, Gateway, PSP: The Payment Stack Operators Actually Contract With

Operators conflate the actors in the payment stack — issuer, acquirer, gateway, processor, PSP — until a payment breaks. Then the conflation stops being academic. Auths are declining and nobody can say whether it’s the issuer, the processor, or your own gateway timing out. A payout didn’t land and the team is debating whether to open a ticket with the acquirer or the PSP. The terms blur together right up until the moment the difference is the only thing that matters, which is the moment you need to know who to call.

The stack is not a glossary. Knowing that an issuer “issues cards” and an acquirer “acquires transactions” tells you nothing useful at 2am. What you actually need is a map: for each actor, who you contract with, where your money sits and for how long, who carries the loss when something goes wrong, and who you escalate to. Those four questions — contracts, custody, liability, escalation — are the operator lens, and they cut through the definitions.

This guide is that map. It walks the card stack actor by actor, frames each by the four questions, and ends with the table you actually want during an incident: failure type, the actor who owns it, and the runbook. It stays at the ecosystem-roles and operator level. The operating-model mechanics — how a PSP, PayFac, or merchant of record is structured internally, who holds the merchant account, who underwrites — live in the PSP vs PayFac operations reference, which this guide links rather than re-teaches.

The four-party model

The canonical card structure has four parties. The cardholder pays. The merchant — you — accepts. The cardholder’s bank, the issuer, provides the card and decides whether to approve each transaction. Your bank, the acquirer, accepts the transaction on your behalf and settles the funds to you. In the middle sits the card network (Visa, Mastercard) — not a bank, but the rails that route the message from acquirer to issuer and back, set the rules, and referee the interchange that flows issuer-ward.

That is the four-party model, and it is the structure most of the card world runs on. The fee that flows from the acquiring side to the issuer for each transaction is interchange; the network’s own cut is scheme fees. Both are set by the network and ultimately land on your statement.

The distinction worth holding: three-party networks collapse this. American Express and Discover have historically acted as issuer, acquirer, and network all at once — a single entity connecting cardholder and merchant directly, which is why their pricing tends to arrive as one blended charge rather than interchange plus scheme plus acquirer margin. (Schemes do change issuing and acquiring arrangements by market, so treat the three-vs-four split as the model, not a fixed roster.) For an operator, the four-party model is the important one, because it is the one with separate vendors you contract with, integrate, and call separately.

The actors, one by one

The four-party model is the skeleton. The working stack has more moving parts, and the useful way to define each is not what it is but whether you touch it — do you contract with it directly, or does it sit behind something you do contract with?

• Issuer. The cardholder’s bank. Decides approve/decline on every authorization, funds the cardholder, and carries the fraud risk on authenticated transactions. You do not contract with issuers; they are on the other side of the network from you, and you only ever feel them as a decline reason or an approval rate.
• Card network / scheme. Visa, Mastercard, and the rest. Routes messages, writes the rulebook, sets interchange and scheme fees. You are bound by its rules and pay its fees, but you typically do not contract with the network directly — your acquirer or PSP holds that relationship and passes the rules and costs down to you.
• Acquirer. Your bank in the model: the network-licensed entity that accepts card transactions on your behalf, holds the merchant account, and settles funds to you. Ultimate liability to the scheme for your transactions sits here. In a classic stack you contract with the acquirer directly; under a PSP, the PSP holds the acquiring relationship and you contract with the PSP.
• Processor. The entity that does the technical work of moving the authorization and clearing messages between the acquirer and the network — the transaction-handling engine. The same word gets used for acquirer-side processing and, loosely, for the acquirer itself; vendors and contracts rarely draw the line cleanly. You may contract with a processor directly in a split stack, or never see it because your PSP or acquirer absorbs it. (There is no single industry definition here — “processor” is one of the most overloaded words in payments.)
• Payment gateway. The payment gateway is the front door: it takes the payment data from your checkout, encrypts it, and passes it toward the processor and acquirer. In a split stack the gateway is a vendor you integrate and contract with; in a bundled PSP it is just the API you already use.
• Orchestration layer. A payment orchestration layer sits above one or more PSPs/acquirers and routes transactions between them — failover, least-cost routing, retries. You contract with the orchestrator and it contracts with (or integrates) the downstream providers. It owns the routing decision, not the money.
• The bundles. A PSP (payment service provider) wraps gateway, processing, and acquiring access behind one contract. A payment facilitator (PayFac) aggregates many sub-merchants under its own master acquiring relationship. A merchant of record (MoR) goes further and becomes the seller of record for the transaction, owning the customer contract and the tax liability. These are not separate actors so much as different ways of packaging the actors above — which is exactly why they get confused with the parts they contain.

Actors reference table

The citable core. Each actor, framed by the two operator questions that separate them — do you contract with it directly, and what does it own when a payment breaks.

Who actually holds your money

The single most clarifying fact about custody: money does not move at authorization. An auth is a hold — the issuer confirms the funds exist and earmarks them. Nothing has settled to you. Money actually moves at capture and clearing, and reaches you at settlement, which can be a day or several days later depending on your provider and batch timing.

In that gap, someone else is holding your money. In a split stack, the acquirer holds funds in transit and settles them to your merchant account on its schedule. Under a PSP or PayFac, the funds land in the provider’s flow first and it pays out to you — meaning the PSP, not the issuer or the network, controls when you get paid. That is the custody question that matters: not who touched the transaction, but whose account your money sits in before it is yours, and who sets the clock on releasing it.

Reserves sharpen the point. A rolling reserve — a percentage of your volume held back for a period against future chargebacks — is your money that the acquirer or PSP is holding deliberately. Whoever holds the funds in transit is the actor that can impose a reserve, and that is a cash-flow decision made by someone other than you. The working-capital drag of this float and these holds is real money; the working-capital cost of payments quantifies it. For custody, the operator question is blunt: who is holding my money right now, and what is the contractual trigger that lets them hold more of it for longer.

Who carries liability

Liability is the question operators get wrong most often, because the actor that processes a loss is rarely the actor that eats it. Two losses matter: fraud and chargebacks.

On fraud, there is a liability shift. By default the merchant carries fraud loss on card-not-present transactions. Strong authentication moves it: when a transaction is authenticated through 3D Secure, liability for fraud on that transaction can shift to the issuer, because the issuer authenticated the cardholder. 3DS runs before authorization and is distinct from it — authentication verifies identity; authorization checks funds. The shift is why 3DS is a liability tool, not just a friction tax. (The exact outcome is scheme- and contract-defined; treat this as the mechanism, not a guarantee.)

On chargebacks, the question is who gets debited. When a cardholder disputes, the network frames the dispute, the issuer initiates it, and the funds get pulled back — but the debit lands on the merchant in a direct model, and on the acquirer’s books with the cost passed through to you. Under a PayFac or MoR, the bundle absorbs the chargeback first and recovers from you contractually; under an MoR, the MoR owns the dispute outright because it is the merchant of record. The full cost of a single dispute — fee, lost goods, operational time — is unpacked in the true cost of a chargeback; the when to hand that liability off entirely decision is in merchant of record vs PSP.

The caveat that governs this whole section: liability splits are contractual and scheme-defined. Who is usually debited is operational framing, not a rule that holds across every provider, market, and contract. This is not legal advice — read your own agreements for the binding split.

The bundled models: PSP, PayFac, MoR

Modern providers do not sell you a gateway, a processor, and an acquirer separately. They wrap them. A PSP like Stripe bundles the gateway, the processing, and acquiring access behind a single contract — you sign once and get the whole accept-to-settle path, without standing up a merchant account, a gateway, and a processor relationship yourself. A PayFac aggregates many merchants as sub-merchants under its own master acquiring relationship, so you board fast as its sub-merchant rather than getting your own merchant account. An MoR goes one layer up the commercial stack: it becomes the seller of record, owning the customer contract and the tax liability, with payment processing underneath.

That is as far as this guide goes on the bundles, by design. How each model is structured operationally — who holds the merchant account, who underwrites, who carries which slice of risk, the sub-merchant thresholds — is the job of the PSP vs PayFac operations reference. Which provider to pick and on what terms is how to choose a PSP. This section’s only job is to place the bundles in the actor map: they are packaging over the actors above, which is precisely why a PSP gets called “the processor,” “the gateway,” and “the acquirer” interchangeably by the same team in the same week.

Who you call when it breaks

This is the table you actually want during an incident. A payment is failing; the question is which actor owns the failure and which runbook you open. The mapping is operator framing — in a bundled stack the PSP is often your single point of contact for several of these, but knowing the underlying owner tells you what to escalate and to whom.

The pattern: declines route to the issuer’s decision and the processor’s delivery; availability problems route to whoever runs your acquiring path; money-movement failures route to whoever holds and settles your funds; disputes route to the acquirer/scheme; and routing problems route to the orchestrator that owns the routing decision. Map your own vendors onto these owners before the incident, so the war-room is not arguing about who to call while the clock runs.

Build vs bundle

The whole stack reduces to one operator choice: split or bundled. A split stack wires up a separate gateway, processor, and acquirer — vendors you select, integrate, and reconcile yourself. You get control (you can swap one component, negotiate each margin, see every layer’s cost) and transparency, at the price of integration work, multi-vendor reconciliation, and being your own systems integrator when something breaks across a seam.

A single bundled PSP collapses all of that into one contract. You get simplicity and speed — one integration, one settlement file, one support line — at the price of less granular control, less cost transparency, and more concentration in one provider. The portability angle is its own trap: tokens vaulted with one PSP do not automatically move to the next, which is why network tokens vs PSP tokens matters the day you want to leave. There is no universally right answer; the trade is control and transparency against simplicity and speed, sized to your volume, your team, and your appetite for owning the seams.

Operator checklist

Know these for your own stack, written down, before you need them:

• Who you contract with — list every actor you have a direct contract with, and which actors sit behind those contracts that you never touch directly.
• Who holds your money, and for how long — name the actor whose account your funds sit in between capture and payout, the payout schedule, and the reserve trigger and release terms.
• The liability split — for fraud and for chargebacks, who is debited first and who bears the final cost, per your contracts (not per the diagram).
• The escalation contact per actor — for each failure type in the who-to-call table, the specific contact or ticket path, mapped to your actual vendors.
• Bundled or split, and why — state whether you are on a bundled PSP or a split stack, and the deliberate reason, so the choice is a decision on record rather than an accident of how you started.

Scope note

Terminology in payments is used loosely. Processor, acquirer, gateway, and PSP overlap in everyday use, and one vendor routinely plays several of these roles at once — a single PSP is, simultaneously, your gateway, your processor, and your acquiring relationship, and will be called all three by different people. This guide draws the lines to make the actors navigable, but it does not pretend the industry draws them consistently; where a term is genuinely overloaded (especially “processor”), that overload is the reality, not an error to correct.

Roles, custody, and liability vary by provider, market, and contract. The contracts/custody/liability/escalation framing, the two tables, and the checklist are PaymentBrief operator synthesis — operational framing to calibrate against your own agreements, not scheme rules or vendor commitments. The fraud-liability shift and chargeback debits described here are typical and who is usually debited, governed by scheme rules and your contracts; this is operational guidance, not legal advice — verify your own contracts. This guide also covers the card stack specifically. Non-card rails — account-to-account transfers, wallets, real-time payment schemes — have different actor maps and are out of scope here.

Related references

• PSP vs PayFac Operations Reference — the operating-model mechanics behind the bundles: who holds the merchant account, who underwrites, who carries which risk.
• How to Choose a PSP — Decision Matrix — picking the provider once you know which model you want.
• Merchant of Record vs PSP — When to Switch — the decision to hand off liability and the sale to an MoR.
• The True Cost of a Chargeback — the full unit economics of the dispute liability mapped above.
• The Working-Capital Cost of Payments — the cash-flow drag of the float and reserves the money-holding actor controls.
• Authorization Optimization — the runbook for the auth-decline failure in the who-to-call table.
• PSP/Acquirer Outage Failover Runbook — the runbook for the processor/acquirer outage failure.
• Payout and Disbursement Failure Runbook — the runbook for settlement and payout failures.
• PSP Reconciliation Failure Runbook — triage for when settlement does not reconcile.
• Multi-Acquirer Routing — the orchestrator-owned routing layer and its failure mode.
• Network Tokens vs PSP Tokens — the portability angle on the build-vs-bundle choice.

For term definitions — issuer, acquirer, payment gateway, payment orchestration, PSP, payment facilitator, merchant of record, interchange, scheme fees, authorization, capture, settlement, chargeback, and rolling reserve — see the Payments Glossary.