11 / FinTech / Payments
Stripe
A team presentation on why Stripe is a FinTech firm and what the Federal Reserve's instant-payment rail means for it, built around a seven-step model of how one Stripe payment moves from sign-up to payout. A separate group paper adds an organization design: how Stripe's teams should collaborate.
Set up, once per merchant
- 1 · OnboardKYC/AML through Stripe's license layer
- 2 · IntegrateAPIs and SDKs, bank account linked
Each payment, at checkout
- 3 · Initiatecard entered, encrypted at once
- 4 · Authorizecard network to issuer, Radar screens fraud
- 5 · Captureapproved payments batched for clearing
Money moves, days later
- 6 · Settleissuer pays Stripe over ACH or wire, 1–3 days
- 7 · Pay outStripe keeps its take rate, merchant gets the rest
01 / The question
Is Stripe a FinTech firm, and what does instant payment do to it?
Stripe does not lend from a balance sheet or take deposits at a branch. It sells payment acceptance as software: an API that connects a merchant to Visa, Mastercard and the bank rails, with fraud detection (Stripe Radar), subscriptions and recurring billing on top. The deck asks two questions of that business. First, does it qualify as FinTech, or is it just a payment processor with a good website? Second, the Federal Reserve now runs FedNow, a public rail that lets U.S. banks send money in real time, 24/7. Does that help Stripe or threaten it?
02 / The business model
Seven steps from sign-up to payout.
The model in the appendix follows one $100 card purchase through every party it touches: the merchant, the consumer, the consumer's bank (the issuer), the card network, Stripe Radar, the processor and the merchant's bank account. The original schema is shown below, and the table reads it step by step.
| Step | What the schema shows | Reading |
|---|---|---|
| 1 · Onboarding and global compliance | The merchant signs up and gives a legal or tax ID (EIN or SSN) and owner ID. Stripe's “license layer” runs KYC/AML checks before it accepts any payment. | Compliance is at the front door. The merchant borrows Stripe's regulatory standing instead of earning its own. |
| 2 · Technical integration and bank linking | The merchant links a professional bank account and adds Stripe APIs and SDKs, such as Checkout, to its site or app. | This is the developer-first entry point: a few lines of code replace what a merchant would otherwise build with banks and networks. |
| 3 · Transaction initiation and data encryption | The consumer enters card details at checkout. The data is encrypted immediately, and the merchant never touches raw card information. | PCI abstraction. The security burden moves from thousands of merchants to one provider. |
| 4 · Real-time authorization and fraud screening | The request goes through the card network to the issuing bank. Stripe Radar uses AI to screen for fraud in milliseconds. | The one step where the model names AI, and the one decision that can stop a bad payment before money moves. |
| 5 · Transaction capture and batching | An authorized transaction is captured, and Stripe groups successful payments into digital batches for clearing. | Batching is what makes Stripe an aggregator: one relationship with the rails serves many merchants. |
| 6 · Clearing and settlement (unnumbered) | The card network calculates interchange and scheme fees. The issuer settles the actual money over traditional rails, ACH or wire, into Stripe's acquiring accounts in 1–3 days. | The slow step. Information moved in milliseconds, but money takes days. |
| 7 · Payout and financial reconciliation | Stripe deducts its take rate and deposits the remaining funds into the merchant's linked account. Reporting and reconciliation run automatically on the dashboard. | The only step where Stripe is paid. |
03 / How the model works
Data moves fast, money moves slow, and Stripe sits between.
Read as a workflow, the seven steps fall into three phases. Steps 1 and 2 happen once and make the merchant ready: identity is verified and code is installed. Steps 3 to 5 happen on every payment, and most of that work is immediate: encryption when the card is typed, fraud screening in milliseconds, then capture. Steps 6 and 7 are the money phase, and they run at the pace of the old rails.
Three things follow from that shape. Stripe never owns a rail. It connects to the card networks and the banks and adds software on top, so the model reintermediates the system instead of replacing it. Risk sits at the start and in the middle: KYC at step 1 and Radar at step 4 are where Stripe decides who and what to let through. And revenue appears only at the end. The take rate at step 7 is the payoff for everything before it, and the schema does not put a number on it.
04 / Where FedNow enters
It attacks step 6, and that changes step 4.
FedNow settles in about 20 seconds against 1–3 days for ACH, and card networks authorize instantly but settle late. In the model, that is the slow step 6. The deck lays five opportunities on that gap, and four risks that come with it.
| Opportunity | What it means |
|---|---|
| Instant merchant payouts | Push true bank deposits 24/7 to gig workers, small businesses, creators and marketplaces, improving their cash flow. |
| Lower-cost payment alternatives | Offer a “Pay by Bank (Instant)” option to replace card fees of about 2–3% with bank-to-bank transfers, cutting dependence on card networks. |
| Competing with Zelle and RTP | Embed FedNow in Stripe Checkout, Treasury and Connect, using a public rail to reach smaller banks. |
| Embedded finance expansion | Instant supplier payments, refunds, insurance claims and loan disbursement, all built on instant settlement. |
| Risk and settlement advantages | Less float risk and chargeback complexity, and real-time fraud monitoring with AI risk models on instant rails. |
Here the model shows why the risks matter. Today the 1–3 days in step 6 is also a verification buffer: a payment flagged after the fact can still be caught before the money is gone for good. On an instant, irrevocable rail that window disappears, and step 4 becomes the only chance to stop a bad payment.
| Risk | Why it bites |
|---|---|
| Direct legal exposure | With no verification buffer, any split-second failure to catch a criminal means immediate federal fines and irreversible money laundering. |
| Reputation | The real-time false-positive dilemma: block honest merchants or let fast fraud through. Either way customers drift to competitors. |
| Financial solvency | Instant payments are irrevocable. If Regulation E is read to make Stripe reimburse “tricked” users, the losses come straight off the bottom line. |
| Licensing | ISO 20022 data-governance duties mean a failure to manage the data influx is a compliance violation, with regulators able to suspend licenses or block network access. |
05 / How Stripe differs
A software platform, not a merchant acquirer.
Stripe and the legacy players share a core: they process card payments, connect merchants to card networks and banks, charge transaction-based fees, provide fraud detection and handle settlement. The deck separates them on how they go to market and how they earn.
| Dimension | Stripe | Legacy players |
|---|---|---|
| Model | Developer-first: API-native, self-serve onboarding, built for startups and digital platforms. | Sales-driven, manual integration, relationship-based contracts. |
| Products | Beyond processing: Billing, Treasury, Issuing, Capital, payment orchestration and data tools. | Primarily acquiring and point of sale. |
| Revenue | Transaction fees, plus a SaaS layer and financial-services monetization. | Mostly transaction margin, hardware fees and long-term contracts. |
The deck tests the FinTech label against five concepts and finds Stripe fits each: delivery through software rather than branches, lower friction for merchants, abstraction of financial infrastructure, a trust layer that takes on risk and compliance, and reintermediation, since it does not remove banks and rails but becomes a new software layer between merchants and the payment system.
06 / The recommendation
The future is layered.
The deck does not treat FedNow as a replacement for Stripe or Stripe as a replacement for banks. FedNow provides speed and final settlement, banks hold deposits and move funds, and Stripe is the software layer above both. It ends on three recommendations: banks adopt real-time payments to stay competitive, Stripe uses FedNow to expand instant payouts and Treasury tools, and businesses choose platforms that combine speed, security, compliance and scale.
07 / How the teams work
Where collaboration breaks.
A separate group paper, written for a teamwork and collaboration course, looks at Stripe from the inside. It starts from how Stripe's teams are organized: around the stages of the payment lifecycle. The initiation stage, for example, belongs to the product design team, with engineering checking that proposals are technically feasible. Lining up specialized groups around core payment needs keeps silos small, and it lets Stripe build things a client has not asked for yet, such as an AI fraud-detection assistant in production systems that reduces fraud and raises authorization rates instead of only producing dashboards. The paper cites almost $1.4T of payments processed in 2024, growing roughly 25–40% a year since 2023.
It then finds three places where that structure fails.
| Pressure point | What went wrong | Why it happens |
|---|---|---|
| Speed against safety | In the Flipcause case, teams put swiftness ahead of compliance. Several violations were flagged after launch, only once Stripe's financial partners raised alarms, and Mastercard fined Stripe $137,500. | “Compliance debt”: controls and partner programs must be redone as regulation tightens, and “move fast and break things” does not work in financial infrastructure. |
| Global against local | Regional squads retrofit compliance, which restarts the product build. Brazil is the example: its instant payment system uses QR codes and works unlike US-centric money flows, so it needs bespoke engineering. | One structure no longer fits every office, from New York to Paris. Local market experts and a restructuring of personnel are needed. |
| Siloed incentives | Moving to PaymentIntents and PaymentMethods exposed inconsistent APIs. Payments and Billing had built incompatible software on separate roadmaps, conflicts surfaced as emergencies, and leadership had to mandate a top-down redesign. | Conflicting incentives, growth for one team and retention for the other. |
08 / The collaboration design
Shift coordination upstream.
The design answers each failure with a principle, and turns the principles into three mechanisms. It keeps them deliberately simple, because Stripe already has enough complexity in its core product and process should not add more. One rule sits underneath all of them: goals, results, progress and even missed targets should be visible across teams, apart from sensitive customer information, so that teams understand each other's difficulties and work on the most pressing problems together.
| Principle | What it means | Answers |
|---|---|---|
| Build the structure before the failure | Set up cross-functional teams that can experiment early and own their ideas while the platform keeps running. Legal, for example, catches reliability and compliance issues while product is still building the feature. | Speed against safety |
| A shared global core, adapted locally | Agree global APIs and shared design docs and reviews, then let regional squads in places like Hong Kong or Paris adapt them. Cash flows, compliance and engineering patterns are considered early, not when a market's requirements finally surface. | Global against local |
| Align incentives upfront | Hold joint decision forums tied to launches, where global and local teams share their view of risk and growth. Leaders reframe goals to weigh both, and document concerns and gaps, to prevent quiet resistance and local-win bonuses. | Siloed incentives |
| Mechanism | What it is |
|---|---|
| Shared Design Dossier | One document, updated whenever things change and published company-wide, that consolidates the technical architecture of core payment infrastructure. It becomes the go-to reference, a tool for training new hires and a guide for decisions. |
| Ownership Maps | A clear global owner for each critical component, who settles disagreements and questions. Local owners report to the global owner, handle everyday questions, and escalate what cannot be solved locally or what the whole company should learn from. |
| Risk Escalation Process | For critical categories such as regulatory and financial risk, a clear escalation line through a cross-functional chain of owners. It speeds decisions when timing matters and turns repeated ad-hoc calls into precedents. |
09 / Trade-offs and limits
What the design accepts.
The paper is explicit that no design removes friction in a company as fast-growing, distributed and technically complex as Stripe. Its mechanisms favor reliability, clarity of coordination and regulatory resilience, and each choice has a price.
| Choice | What it costs | Why the paper accepts it |
|---|---|---|
| Clear ownership and bounded decision rights | Some teams have less voice in upstream design when decisions are settled in defined cross-functional forums, not by open consensus. | In payments the cost of slow coordination often exceeds the cost of limited inclusion. |
| Local autonomy with shared interfaces | Collaboration quality can be uneven across teams, especially during rapid hiring or expansion. | Forcing uniform behavior would undermine Stripe's culture of ownership and technical creativity. |
| Transparency through shared documents and decision records | More information to process, so some teams may disengage or read selectively. | Central filtering would bring back gatekeeping and delay. The design assumes teams develop informal filtering norms. |
Some failures sit outside the design altogether. It cannot end strategic disagreement between teams with different incentives, stop external shocks such as a regulatory change or a reputational crisis from overwhelming coordination capacity, or guarantee alignment when the company's own priorities are unclear. The paper's conclusion is that collaboration at Stripe is limited less by a lack of authority than by the complexity of coordinating speed, regulation, global scale and interdependent product systems. It treats collaboration as an engineered system, not consensus or control, whose job is to make failures earlier, more visible and cheaper.