The Industry Role Map: Who Makes Money in the Middle

Part V · Players and Risks (Chapters 20–25) Builds on: Chapter 5 (the four-party model), Chapter 6 (money follows risk), Chapter 7 (the authorization message), Chapter 8 (card-present and card-not-present), Chapter 9 (direct debit can't verify balances in advance) New concepts in this chapter: the acceptance front end (POS and gateway), processors (issuing side and acquiring side), BIN sponsor, PSP, PayFac, ISO, BaaS, payment orchestration, neobank, licensed vs. unlicensed

1. The Question the Previous Chapter Left Open¶

The previous chapter ended on this: before the new technology, you need to know which companies actually handle this money today, what they earn on it, and how they lose on it. Without that, you can't judge where a new technology should cut in.

This chapter lines the players up into one picture. The layout has a single basis: the line from interchange — "money follows risk."

2. The Three Questions for Judging Any Payments Company¶

Before the specific roles, build the method. When you see a payments company, ask three questions:

These three questions can place any payments company on the map below.

Before using them, draw the line around "license" in the first question. When this course says "licensed," it means one thing: a financial regulatory license issued by a government.

Whether a company needs such a license comes down to one line: does customer money become its liability — when it fails, are its customers creditors waiting in the liquidation queue? Taking deposits, holding and moving money on customers' behalf, issuing e-money: all of it lands on this line. (What these licenses are actually called, and why they are hard to get, the compliance skeleton unpacks across six jurisdictions.)

Easily confused with it are two other kinds of entry credential, just as scarce:

The distinction gets used almost immediately. When this chapter says Marqeta is "unlicensed," it means only that it lacks the first kind.

It still has to pass the card networks' processor registration and technical certification. It still needs a licensed bank willing to work with it — and to answer to regulators for that arrangement. US regulators can even show up and examine a bank's outsourced service providers directly, under the Bank Service Company Act.

"Unlicensed" does not mean "unregulated," and it certainly does not mean "anyone can do this." The bar just moves from "apply to the government" to "get the networks and the banks to accept you."

3. The Panorama First: One Chain, Five Positions¶

The four-party model gave this course its most important skeleton: cardholder — issuer — card network — acquirer — merchant. The first law of the industry map: of the hundreds of payment companies that have appeared over the decades, not one has invented a new position. Every one of them contracts for some stretch of work at these five. So memorizing the map takes no company names. Only positions.

How to read the figure:

• The colors are the answers to the three questions. Dark squares check all three — licensed, money crossing their books, eating losses. Gray squares check none, and can only charge per-transaction technology fees or sales commissions. Only the squares numbered ①–⑤ are the four-party model's five positions; the two unnumbered rows are front-end forms hung on top of them. The company names in each square come in the tables over the next few sections.

• Bottom to top is the direction the authorization message travels in the card transaction lifecycle: merchant → acquiring side → card network → issuing side.

• The entire difference between online and offline happens in one square: the acceptance front end (the step where the merchant takes in the card data). A store reads the card on a POS terminal; a web shop collects the number through a gateway. From the acquirer up, the two paths fully merge. So "e-commerce payments" and "offline acquiring" are not two industries. They are two entrances to the same chain.

• Two more kinds of company occupy no new square and instead sell several squares as a bundle — BaaS and payment orchestration, taken up separately later in this chapter.

Now walk every square in message order, from the merchant end to the issuing end.

4. The Acceptance Front End: The Only Fork Between Online and Offline¶

The first step of a card transaction is the merchant taking in the card data. This square comes in two forms.

Offline, it is the POS terminal (point of sale) — the card reader on the store counter. It does three things: reads the card data from the chip, the stripe, or the tap; encrypts it on the spot; assembles it into the authorization message from the card transaction lifecycle and sends it into the acquiring chain.

Online, it is the gateway. Behind a web shop's checkout page, the same job: take the card number you type, encrypt it, assemble the same authorization message, send it to the acquiring side, and pass the approval or decline back to the page.

Read those two paragraphs against each other: the gateway is the POS terminal of the online world. Two forms of the same square, matching function for function. This square is also the physical location of the dividing line from the card-not-present chapter — a terminal reading the card is card-present, a page taking the number is card-not-present, and the switch of fraud liability between the issuer and the merchant side happens exactly where this square switches form.

The standalone gateway is a disappearing species: carrying data won't sell on its own anymore, and most of it has been swallowed into a PSP feature.

5. The Acquiring Side: From Pulling In Merchants to Eating the Risk¶

The acquiring side split "holding the license" from "doing the work" long ago: the bank brings the license and the settlement account; the processor runs the systems. The issuing side did the same, as the next section shows.

The three biggest acquiring institutions in the US by processing volume are Global Payments, JPMorgan Chase, and Fiserv. Only Chase is a bank doing it in person; the other two are, at bottom, processors riding on sponsoring banks' network memberships.

This layering is not a textbook invention. The industry is reorganizing itself along it right now.

On January 9, 2026, two deals closed on the same day: Global Payments paid $24.3 billion for the acquiring giant Worldpay, and sold its own issuer processing business (the former TSYS) to FIS for $13.5 billion.

One purchase and one sale later, Global Payments is a pure acquiring company and FIS carries off issuer processing. Nearly $40 billion of M&A, and the knife came down precisely on the issuing-side / acquiring-side line.

Now put all these roles inside a single transaction. You pay $100 at an online store:

1. The store can accept cards at all because a year ago an ISO sales rep introduced it to an acquirer and took a commission — the transaction itself involves no ISO at all.
2. You click Pay. The gateway encrypts the card number you typed, assembles it into the authorization message from the card transaction lifecycle, sends it to the acquirer, and two seconds later passes "approved" back to the checkout page. Data is all it ever handles.
3. The acquirer puts the request onto the authorization chain through the card network to the issuer. At T+1 settlement, the money flows from the issuer into its account, and it takes out its fees and pays the store. Of all these roles, it is the only one that holds a license, has money cross its books, and eats the loss when the merchant runs off.
4. A PSP sells the effortless version of step 2: no hunting for a gateway, no wrangling message formats — wire up one Stripe API and it is all there.
5. And if the store had found hunting for an acquirer too much trouble and simply opened a Square account to start selling, then it went the PayFac route: steps 1 through 3 all bundled and handled by Square, with the store as one sub-merchant under Square's name.

Swap the web store for a convenience store and only step 2 changes hands: the gateway becomes the POS terminal on the counter. Not another word changes.

The division of labor in one line: the ISO pulls in merchants, the front end takes in data, the acquirer minds the money and the risk, the processor runs the systems, the PSP turns integration into a product, and the PayFac bundles the whole chain into "sign up, start collecting."

PayFac deserves a section of its own: the most important product innovation of the past decade

Under the traditional flow, a coffee shop that wants to accept cards applies to an acquirer itself: business registration, financial documents, a risk review, days to weeks of waiting. That bar keeps masses of small merchants out.

The PayFac's move: sign one big merchant account with an acquirer itself, then hang thousands of small merchants under its own name as "sub-merchants." A small merchant signs up and is collecting money within minutes.

The price is that the PayFac eats the full risk of those sub-merchants itself. A sub-merchant takes the money and never ships, the chargebacks pile in — the PayFac covers the loss.

By the rule from interchange, it carries the risk, so it gets to charge the higher rate. Square charges small merchants around 2.6% plus a fixed fee for in-person card payments — visibly above what a big merchant can negotiate. The difference is the price of that risk and that convenience.

Anyone who knows China's payment scene will ask the obvious next question: aren't Alipay and WeChat Pay PayFacs?

In experience, strikingly close — a corner shop tapes up a QR code and is collecting money the same day, with risk and disputes carried by the platform. In structure, no.

A PayFac is an unlicensed "super-merchant" hanging under someone else's acquirer. Alipay is itself a licensed payment institution — accounts, clearing, and acquiring in one body, running on its own network, nowhere on the card networks' four-party chain at all.

Functionally the two solve the same problem: small merchants collecting money in seconds. Structurally, the wallets are a different species, grown out of the "e-wallet balance" row of the table in the hierarchy of money — user balances are the wallet company's own liability, and how hard that money is depends on whether customer funds are held segregated.

6. The Issuing Side: The Four-Way Split Behind a Single Card¶

Cross the card network (the four-party model took it apart: touches no money, sets the rules, collects scheme fees from both sides) and you reach the issuing side.

Issuer processors come in two generations. The difference is not the age of the systems — it is whose hands the authorization decision sits in:

The authorization-decision row is where the knife falls between the generations.

In the traditional system, approve-or-decline is settled by risk parameters inside the processor, and the issuing side can only tune them. Marqeta turned that step into a real-time callback — it calls the capability JIT Funding (just-in-time funding): each time an authorization arrives, it first asks the client's system "approve or not, and which money does this draw on," and the client has the few hundred milliseconds before the authorization times out to answer.

That makes a new class of product possible. The order-pickup card DoorDash issues its Dashers approves only when the amount matches the order that Dasher is running right now. Everything else: declined.

For the first time, authorization logic became product logic. The card transaction lifecycle said authorization is the issuing side's call; this generation of processors opened the seat where the call is made to its clients.

The business Global Payments sold to FIS, mentioned above, is the traditional generation.

Here is a counterintuitive structure. A card issued by a fintech carries the fintech's name on the front, but:

• the BIN belongs to some small bank
• the authorization decisions run on a system from the likes of Marqeta
• the money sits at that small bank
• and the user knows only the fintech printed on the card

The 1.80% of interchange from interchange ends up divided among these four by contract. Whoever eats the bad debt takes the biggest share — usually the licensed bank, completely invisible to the user though it is.

One more thing to pin down: licensed or not is a structural choice, not a property of the company.

Marqeta again. In the US it chooses not to hold a license: contracts keep customer funds entirely in the partner bank's accounts, and not a cent touches its own balance sheet — that is how the "customer money becomes its liability" line gets deliberately stepped around.

But to enter the UK and European markets, in August 2025 it bought TransactPay, a licensed e-money institution. At a stroke it became the license holder and the BIN sponsor itself, and picked up full card network membership in the bargain — the membership tier that holds BIN ranges directly and takes part in clearing and settlement, open only to regulated financial institutions.

One company, two jurisdictions, two choices. Why the trade-off comes out so differently in the US and Europe, the compliance skeleton answers when it covers license regimes. So ask the three questions jurisdiction by jurisdiction — the same company can carry two sets of answers.

7. The User-Facing Square: The Neobank¶

The topmost square of the panorama is the product the user actually sees. The species in this square that most needs defining is the neobank: a company with an app and no branches, offering users the functions of a bank — accounts, cards, transfers — while mostly (especially in the US) holding no banking license of its own.

Drop it into this chapter's frame and the structure is not new at all: a neobank is the issuing side's program manager, with the product styled as "an entire bank." The accounts live at a partner bank, the card hangs on a BIN sponsor's number range, authorization runs on an issuer processor's system. The user thinks they opened a bank account. What they actually opened is an unlicensed company's "sublease" on an account inside a licensed bank.

The Revolut row points at the same conclusion as the previous section: unlicensed is a choice, not a fate — Europe's license regime makes holding your own the better deal (the compliance skeleton).

How do you split it from the e-wallets in the same square (the Alipays and Apple Pays)? The liability view from the hierarchy of money cuts it in one stroke:

• A wallet rides on top of the cards and accounts you already have. It spends your money for you.
• A neobank wants to replace the bank account itself. It holds your money for you.

Hold people's money, and you must answer the harder question — where the money actually is. This square only plants the definition; the anatomy waits for the next chapter.

8. Two Horizontal Bundlers: BaaS and Payment Orchestration¶

The last few sections kept repeating one move: an unlicensed company borrowing a licensed institution's powers. Turn that move into a standard product and you have BaaS (banking-as-a-service: a bank opens up its license-bound capabilities — account opening, deposits, card issuing, clearing — through APIs, for nonbank companies to use).

This structure lets a startup ship a product with accounts and a card in a few months. It is the technical foundation of the past decade's fintech explosion.

But the structure has a built-in hazard: the users' money is at the bank, while the ledger of which user has how much sits in the middleman's hands. The bank sees one big merged account — not the balances of the people inside it.

When the course reaches neobanks, you will see how that hazard became a real disaster in 2024.

BaaS is the horizontal bundle on the issuing side. The acquiring side has a mirror role: payment orchestration.

Orchestration wires together multiple PSPs and multiple local rails, shows the merchant one unified interface, and then picks the route for each transaction automatically, by cost and authorization rate.

The only difference between the two is what gets bundled: BaaS bundles license powers; orchestration bundles channels. Neither occupies a new square. Both earn the money of wiring several squares together for you.

9. Side by Side: Stripe and Adyen¶

These two get named in the same breath, but their structures differ.

The way to judge them is still the three questions.

Adyen holds a license, money crosses its books, and it carries the acquiring risk. So it can take more — and must manage more.

Early Stripe held no license: it won merchants on experience and breadth of product, and left the funds risk with its partner banks. The price is almost no room on rates — interchange did the arithmetic: what the acquiring side can negotiate is only that 0.37% band.

Note the "offline capability" row: both companies now cover online and offline in full. "Stripe only does e-commerce" is what it looked like in its early years, not where its boundary sits now — as this chapter said, online and offline differ by one square, the acceptance front end, and building out the other half costs less than you'd think.

10. A General Law: A Defect in an Infrastructure Grows a Layer of Business¶

Push and pull told one story of this: direct debit has no way to verify a balance in advance, so the account verification business grew on top of it.

The pattern is everywhere in payments:

The law hands you a way to hunt for opportunities: first find something a rail cannot do, then check whether anyone will pay to get around it. When the course sizes up the stablecoin opportunity, this is exactly the method it uses.

11. The Question This Chapter Leaves Open¶

The map is laid out, and the three questions are in hand. But a map is abstract — when you actually have to judge a specific company, how do the squares get used?

And this chapter leaves one follow-up unanswered: the neobank line "the money is in an account at the partner bank" does not survive close reading. In what account, exactly? Does the bank know which slice is yours? If the company in the middle fails, what do you hold that proves the money is yours?

Tools first, then the follow-up. The next chapter picks nine real companies and reads them in pairs — testing, along the way, whether the three questions earn their keep. After that, the anatomy of that line.

12. Self-check questions¶

1. Use the three questions from the top of this chapter — does it hold a license, does money cross its books, and what losses does it eat — to work out how Marqeta and Adyen differ in risk and in income.
2. Why can a PayFac charge small merchants a higher rate — and why isn't that fleecing them?
3. In a BaaS structure, what does the bank see, and what does the middleman see? What problem does that information gap create?
4. Marqeta says it "needs no license" in the US. Where does that "needs no" come from, and how is it different from "unregulated"?
5. A coffee chain has stores and an online shop. Between its in-store card payments and its online collections, at which square do the chains differ — and at which squares are they the same?

13. Answers¶

Answer for yourself before reading on.

1. In the US, Marqeta holds no license, money does not cross its books, and it eats no bad debt. It sells a technology system and authorization decision-making, and charges per-transaction technology fees — steady income, capped upside. Adyen holds a license, money crosses its books, and it carries the acquiring risk — so it can charge a markup on top of interchange and earn on the funds resting with it, but it also backstops merchants that run off, and the chargebacks they leave behind. By the rule from interchange, Adyen takes more because it carries more.

2. Because it genuinely carries the matching risk and cost: sub-merchants' chargebacks, fraud, and runaway losses land on the PayFac, and it compresses onboarding from weeks to minutes. The premium a small merchant pays buys "collecting money today" and "someone covers it when things blow up" — both worth a great deal to them. The "what the merchant gets" table from the origin of cards applies here unchanged: as long as what comes back is worth more than the rate gap, the deal stands.

3. The bank sees one merged account and its total balance — not how many users are inside it or how much each one has. The middleman holds the itemized ledger and knows whose every cent is. The information gap means that the moment the middleman's ledger is wrong, lost, or unreachable, the bank has no independent way to reconstruct what each user is owed. This is exactly the core mechanism of the Synapse case in neobank anatomy.

4. It is engineered by contract: customer funds sit at the partner issuing bank the whole way and never enter Marqeta's balance sheet, so the "customer money becomes its liability" line is never touched and no license requirement triggers.

   But it remains well inside the regulator's range — the partner bank answers to its regulator for the arrangement, and regulators can examine Marqeta directly under the Bank Service Company Act. "Needs no license" describes the mode of entry, not a regulatory vacuum.

5. They differ at exactly one square, the acceptance front end: the stores read cards on POS terminals; the shop takes card numbers through a gateway. From the acquirer through the card network to the issuing side, the two chains are identical. If both sides use the same PSP or PayFac (say, Square or Stripe for both), even the acquiring contract is one and the same. The other difference is where the risk lands (the card-not-present chapter): reading the card in-store is card-present, and fraud losses mostly fall on the issuer; typing the number online is card-not-present, and the losses fall on the merchant side.

Previous: Chapter 19 · The Wise Model: Cross-Border Remittances That Never Cross a Border Next: Chapter 21 · Case Studies: Nine Companies on the Grid