Chapter 6 — Making Cards More Flexible: The Internet Layer

Why did universal card acceptance happen in postwar America — and not, say, in 1930s Europe or 1960s Japan? It wasn't the technology; the technology came last. Card networks didn't emerge in a vacuum. Three forces — none of them obvious from a modern vantage point — had to converge before universal card acceptance could exist. Miss any one of them, and the whole system would have collapsed before it started.

Reason 1: The Postwar Credit Boom

The first force was economic. After World War II, American household incomes surged, consumerism expanded, and a new kind of financial product found its moment: convenience now, settlement later. Installment buying had existed for decades, but the postwar era turned consumer credit from a niche offering into a mass-market expectation. Cards monetized that desire — they gave consumers the ability to spend today and pay tomorrow, and gave issuers a product they could profit from through interest, fees, and eventually interchange.

Without rising consumer confidence and a cultural shift toward credit-funded consumption, there would have been no demand for cards in the first place.

Reason 2: Regulatory Scaffolding

The second force was legal. A series of laws and court decisions — most of them reactions to early card industry disasters — built the trust framework that made the system work at scale.

After the BankAmericard mass-mailing fiasco (and similar stunts by other banks), the U.S. banned unsolicited card issuance in 1970 under 15 U.S.C. § 1642. No more cards showing up in mailboxes uninvited. This single regulation forced issuers to actually vet applicants, which dramatically reduced fraud and delinquency.

The Fair Credit Billing Act (1974) gave consumers formal dispute procedures. If you saw a charge you didn't recognize, you had a legal right to dispute it and have it investigated. This gave consumers the confidence to use cards — they knew they wouldn't be stuck paying for someone else's fraud.

Regulation Z capped cardholder liability for unauthorized transactions at generally $50. This was transformative. Consumers could tap their card knowing that even in the worst case, their exposure was minimal.

And in 1978, the Supreme Court's decision in Marquette National Bank v. First of Omaha Service Corp. allowed banks to export interest rates from their home state to customers in any state. This is why so many credit card issuers are headquartered in states like Delaware and South Dakota — they can set rates under favorable state laws and apply them nationally. Without Marquette, nationwide card programs would have been tangled in 50 different state usury laws.

Reason 3: Better Technology

The third force was technological. In the early days, card transactions were processed on paper — merchants took carbon-copy imprints of embossed cards and mailed paper slips to their banks. Authorization meant a phone call to the issuer. Settlement took weeks.

IBM's magnetic stripe standardization in 1969 gave cards a machine-readable identity. Visa's BASE I and BASE II systems (1973–74) brought electronic authorization and electronic clearing/settlement. And the expansion of telecommunications infrastructure — dedicated phone lines, then data networks — made real-time authorization possible at retail scale.

In other words, a payment network isn't just a product. It's a product, plus a legal framework, plus a technology standard, plus an economic incentive structure.

Remove any one, and the whole thing collapses. This is why building new payment rails is so hard — and why, as we'll see in later chapters, even the most disruptive challengers end up rebuilding some version of the same scaffolding.

The Internet Layer: How PayPal and Stripe Extended the Model

Card networks solved the coordination problem for physical commerce. But when the internet arrived, a new set of problems emerged: How do you accept payments on a website? How do you sign up merchants who don't have a physical storefront? How do you build trust between buyers and sellers who've never met?

Two companies — PayPal and Stripe — answered those questions in different ways. But both of them built on top of card rails, not as replacements.

PayPal: A User Network Layered Over Bank Rails

PayPal started as the merger of two startups: Confinity (1998) and X.com (1999), which joined forces in March 2000. Its original vision was ambitious — a new form of digital money. What it became was more pragmatic: a funding-source router that lets users pay through whichever rail is cheapest or most convenient.

When you pay with PayPal, your money might travel through ACH (at roughly $0.03 per transaction), or through a credit card (at roughly 1.9% plus $0.15), or from your PayPal balance. PayPal actively encouraged users to link bank accounts — cheaper funding — while still accepting card-funded payments for the network value they brought.

One of PayPal's cleverest innovations was the "random deposit technique" — micro-deposits of a few cents sent to your bank account, which you then confirmed by reporting the exact amounts back to PayPal. This served as a lightweight identity verification: proof that you controlled the bank account, without the friction of physical bank onboarding. It's a small detail, but it illustrates a pattern that defines internet-era payments: find a software-native workaround for a process that used to require paperwork and branch visits.

The most important design pattern PayPal introduced was instant UX over mixed-settlement backends. When you pay with PayPal using a linked credit card, the funds settle in seconds (through the card network). When you pay using a bank-funded eCheck, actual settlement takes three to four business days. But the user sees the same "Paid!" screen either way. The visible experience is uniform; the invisible settlement plumbing varies wildly. This same pattern — abstracting messy backend rails behind a clean user interface — would become the defining trait of every fintech that followed.

Stripe: Payments Infrastructure for Developers

If PayPal built a new consumer network on top of existing rails, Stripe did something different: it built a new way for merchants to connect to those same rails.

Before Stripe, accepting card payments online was painful. You needed a merchant account (weeks of paperwork), a payment gateway (more integration work), and PCI compliance expertise (more headaches). Stripe, founded in 2010, collapsed all of that into what became famous as "seven lines of code." Stripe.js collects card details in the browser, creates a token, and sends it to Stripe's servers — meaning the merchant's own server never touches raw card numbers, dramatically reducing their PCI compliance burden.

When WhiteBottle Coffee decided to sell gift cards online, they signed up for Stripe in about 15 minutes. No paper applications. No multi-week underwriting process. Just a software workflow that got them from zero to accepting payments the same day. What used to require a banking relationship and weeks of back-and-forth became a self-service developer tool.

Stripe is a PCI Level 1 Service Provider — independently certified to the highest security standard. But it's worth noting that PCI compliance remains a shared responsibility. Stripe handles the hard parts (storing and processing card data), but the merchant still has obligations around how they handle their integration.

Here's the critical thing to understand about Stripe, though: the underlying economics remain tethered to card rails.

Stripe's elegant seven-line integration doesn't eliminate interchange. It doesn't eliminate chargebacks. It doesn't change the four-party model. What Stripe did was make it dramatically easier and faster for merchants to plug into the existing system. The plumbing underneath is the same plumbing Visa and Mastercard built decades ago.

Table 3: Card Networks vs Internet Platforms — What Changed, What Didn't. PayPal and Stripe transformed the merchant and consumer experience, but the underlying settlement rails and economic model remain rooted in the card network architecture.

Gateway, Processor, PSP, Orchestrator: Untangling the Middle Layer

By now you've met a confusing cast of middlemen, and the industry doesn't help — the terms overlap, vendors wear multiple hats, and marketing blurs the lines on purpose. So let's pin them down, because knowing exactly who does what is the difference between reading your processing statement and being read by it.

A gateway is the front door: it captures card details at checkout, encrypts or tokenizes them, and forwards the transaction for authorization. It's the card terminal, rendered in software. A processor is the switch behind the door — the system that actually talks to the card network on the acquirer's behalf. A payment service provider (PSP) like Stripe, Adyen, or PayPal bundles gateway, processing, the merchant account, and payouts into a single contract: you onboard once, they handle the rest. And an orchestrator sits above multiple PSPs, routing each transaction to whichever provider is cheapest or most likely to succeed — a layer we'll dissect properly in Part VIII (Chapters 31 and 32).

Here's where each one sits in the flow of a single payment:

The middle layer, untangled. The gateway is the front door, the PSP bundles the plumbing, the network is the substrate — and the orchestrator, when present, picks which pipe each payment travels down.

Table 4: Network vs Gateway vs PSP vs Orchestrator. The higher up the table, the more foundational the player; the lower down, the more optional — until your volume makes it mandatory.

The lesson from PayPal and Stripe is that the internet layer of payments was an extension of card network goals, not a replacement. Card networks solved coordination among banks. Internet platforms solved onboarding, user experience, and developer ergonomics.

But the rails — the actual pipes through which money moves — remained the same.

The next question, naturally, is whether a completely different kind of rail could change that equation — one with no banks, no networks, and no interchange at all. That's where Web3 enters the story, and it's exactly where we go in Chapter 7.