Stripe’s 16-Year Chronicle: From 7 Lines of Code to a $100 Billion Valuation

Author:Yokiiiya,Stablehunter

After Stripe announced its agreement to acquire OpenRouter, it garnered significant attention in both the AI and fintech sectors. Stripe is also one of the few unicorns in the global fintech space with a valuation exceeding $100 billion.

My understanding of Stripe has always been somewhat fragmented. I’ve used their products, followed some funding and acquisition news, and written about their evolution in payments and AI Agents, but I have never systematically understood this company’s business model, team organization, and capital journey along a timeline.

Initially, Stripe was just a few lines of API that made it easier for developers to integrate payments. Sixteen years later, businesses using Stripe can now process $1.9 trillion in payment volume annually, and its latest valuation has reached $1,590 billion.

I want to use this article to re-examine Stripe’s development process, understand how it gradually expanded its product boundaries, rebuilt its team, and used capital to buy time for the next stage.

(However, this article can only rely on information that Stripe, its executives, and external institutions have already made public. We don’t know what truly happened inside the company, how management made decisions, or which undisclosed problems they encountered. Therefore, this cannot be a complete company history, and it inevitably contains information gaps and perspective limitations. But placing the available information back on a timeline can at least help me form a more complete understanding of how Stripe grew from a payment API company to what it is today.)

What were the two founders doing before founding Stripe?

Usually when we learn about a company, we look at the founders’ backgrounds first. Stripe’s two founders, Patrick Collison and John Collison, are brothers, 9196 Their father Denis has a background in electronic engineering, and their mother Lily has a background in microbiology. Both parents were the first in their families to attend university, with a farming family background on their parents’ side.

Early reports in WIRED mentioned that they had nine computers at home when they were young and spent about €100 per month on satellite broadband forwarded from Germany. The family discussion atmosphere also revolved more around technology and science topics. Public records also mention that Patrick attended a university computer course at age eight and later went to MIT; John later studied at Harvard. This early technical input explains why they could quickly adopt "it just works" as a product standard.

Stripe was not their first company. Before Stripe, the brothers created the e-commerce seller tool Shuppa (later renamed Auctomatic) in 2007. They initially failed to secure local investment in Ireland but later gained support through Y Combinator; in 2008, Auctomatic sold for approximately $5 million. They were no longer "first-time entrepreneurs" but had experienced a real exit and a more mature capital narrative.

Patrick and John were no longer "first-time entrepreneurs." They knew how to turn an idea into a usable product, and they had gone through the processes of finding customers, raising funds, and selling a company. The proceeds from selling Auctomatic also meant they didn't have to rely entirely on a funding round to survive when starting their next company.

Therefore, Stripe’s starting point was not two college students with no entrepreneurial experience suddenly deciding to enter the payments industry. It was two young serial entrepreneurs who encountered payment problems during their first venture, and then started solving a problem they believed was still not adequately addressed, armed with the experience, capital, and connections accumulated from before.

This also formed Stripe’s earliest starting point:

The technical family provided the early environment, the first venture brought them into Silicon Valley, and the payment problem became the entry point for the second venture.

How did Stripe establish its earliest banking partnerships?

As a payments company, one of the most important foundations is actually accounts. Code can be written by engineers themselves, but merchant accounts, funding channels, and clearing capabilities ultimately need to be provided by banks and payment institutions.

How did two young people with no experience in the banking or payments industry start a payments company? There are also some rumors suggesting that there might be undisclosed financial resources or key figures behind the two brothers. However, there is currently insufficient reliable public information to verify these claims, so this article will not speculate on them or include them in the discussion.

We will only follow the existing public information to see how Stripe’s earliest banking partnerships were actually established.

Early Stripe was not smooth sailing on this issue. Patrick later recalled in a course at Stanford that initially, they contacted a payments company in the Midwest of the US through someone they met at a party. Whenever a user registered for Stripe, Patrick and John would manually open another account for that user in that company’s system. They operated this way several dozen times.

From the client side, Stripe was already starting to look simple; but inside Stripe, many processes still required the two brothers to handle manually. This method could be used to validate the product, but it couldn’t support a truly large-scale payments company.

To establish more stable partnerships, they began approaching large banks, including Wells Fargo, but the first meeting did not go well. According to Patrick’s later account, Wells Fargo was very clear at the time that they had no interest in working with them. Stripe had not yet gained the trust of major financial institutions, and it was during this stage that Billy Alvarado joined the company.

Billy was born in Tegucigalpa, the capital of Honduras. His father started as a bank cleaner at age 18, later moved into credit review, and then followed his supervisor to Citibank. His father’s career progression in banking ultimately provided the conditions for Billy to study in the US.

Billy first studied industrial engineering at the Georgia Institute of Technology, later attended Stanford GSB, and earned an MBA in 2000. Before joining Stripe, he had led product and engineering at mobile technology company SEVEN Networks and later became a co-founder and COO of the music service Lala. Lala’s business required negotiating copyright and commercial deals with major record labels. This process also involved complex contracts, profit-sharing, and long-term negotiations. In 2009, Lala was acquired by Apple, and Billy subsequently left the company.

Stripe investor Geoff Ralston was a co-founder of Lala. He knew Billy had experience dealing with large institution partnerships and that the two brothers were stuck in negotiations with banks, so he suggested they hire Billy. But Patrick and John initially didn’t understand why a tech company needed to hire someone who didn’t write code.

At the time, the first few Stripe employees were almost all engineers. Patrick later recalled that Billy was Stripe’s 5th or 6th employee and the first person whose primary job wasn’t writing code. Although the brothers recognized Billy’s abilities, they still weren’t clear on what a "non-engineer" could specifically do for the company.

Ralston finally told them to hire him first, and if the decision proved wrong after a few months, he would cover Billy’s salary. About two months after Billy joined Stripe, the company established a partnership with Wells Fargo, which had previously explicitly rejected them.

What Billy truly filled was not just a contact, but a capability for institutional partnership that the early team completely lacked.

Engineers are used to explaining how a product works; banks care about a different set of questions: who approves merchants, who bears fraud losses, how funds are settled, who handles disputes, and whether a startup with only a few people can fulfill these responsibilities long-term.

Billy could understand what the banks were worried about and translate those concerns into processes and commitments Stripe could execute. He could also translate Stripe’s technical product into a cooperation plan a large financial institution was willing to sign. What he filled wasn’t just banking partnerships, but company operations.

Patrick once gave a very interesting example: after Billy joined, he asked the brothers how the company handled payroll. They replied that they divided the employee’s annual salary by 12 and transferred the money directly each month. At the time, they didn’t even properly handle tax withholding and other payroll issues. This small matter illustrates the state of early Stripe well: it could already write a payment system but hadn’t fully learned how to run a real company.

Later, Billy became Stripe’s first business leader, serving as Chief Business Officer for about a decade, responsible for financial institution partnerships and international expansion, and also involved in building businesses like Stripe Atlas.

Stripe’s earliest banking partnerships were not built from a payment family background of the two brothers, but along another path: first build the product, enter the Silicon Valley network through the first venture and Y Combinator, then have investors recommend key talent to fill the gaps in bank negotiations, compliance, and company operations.

Of course, relationships and resources existed here. Geoff Ralston was willing to recommend Billy, and Billy had experience negotiating with large institutions. These were things code couldn’t replace. But these resources weren’t innate to the two brothers; they were gradually accumulated through their previous venture, YC, investor networks, and key hires.

Stripe’s early experience also shows that the barriers for a payments company are never just about writing a good API. Code can make developers willing to integrate the product, but bank accounts, risk-taking, and institutional credit are what make that code actually start processing funds.

Phase One: 2010–2012, Hiding the Complexity of Payments

Banking partnerships solved the problem of whether Stripe could do payments. Next, the two brothers needed to prove: were developers really willing to hand over their receivables to a newly founded company? The earliest problem Stripe solved wasn’t a new one, but a long-existing one that hadn’t been solved well.

At the time, if a developer wanted to accept credit card payments on a website, they typically needed to first apply for a merchant account, then find a payment gateway, fill out a lot of materials, wait for approval, and finally stitch together systems provided by different institutions. The whole process could take weeks, and the technical documentation and interfaces were often difficult to use.

Patrick and John encountered these problems when building Auctomatic themselves, and entrepreneurs around them kept complaining about the same things. They found that the cost of starting an internet business was getting lower and lower—developers could quickly write websites and deploy servers—but it was still very difficult to make their products start collecting money. This became Stripe’s initial entry point.

In 2010, the two brothers started writing what would become Stripe’s product. Patrick later recalled that it took about one year and eleven months from the first line of code to the product’s official public launch. The time wasn’t mainly spent on the payment page, but on banking partnerships, risk control, and the foundational conditions behind the payment system.

Stripe’s earliest product promise was very simple: developers didn’t need to separately find merchant accounts and payment gateways. They just needed to register a Stripe account, integrate a few lines of API, and they could accept payments in their product.

One of Stripe’s most compelling product demos at the time was completing a credit card payment with just a few lines of code. Later, "7 lines of code to integrate payments" became one of Stripe’s most representative early product narratives.

These few lines of code didn’t make payment itself simpler. Bank connections, merchant verification, fraud detection, dispute handling, and fund settlement still existed; developers just no longer had to face them separately.

Stripe didn’t eliminate the complexity of payments; it moved that complexity from the client side into its own internal systems.

In September 2011, Stripe ended its beta and officially launched publicly. In the US market, it adopted a very straightforward pricing model: 2.9% + $0.30 per successful transaction, with no signup fee or monthly fee.

This pricing didn’t seem to create a new fee model, but it reduced the things developers needed to understand and judge before using the product. Clients didn’t need to negotiate a complex contract first or pay fixed fees before their business even started. Stripe only earned revenue when money was actually received.

Entering Companies through Developers

Traditional enterprise software typically enters a company through management, sales, and procurement departments. Stripe took another path: first make developers willing to use it.

Early Stripe didn’t have a mature sales team. The two brothers would directly approach people around them who were starting businesses, help them integrate the product, and observe where they got stuck. John later mentioned that many of Stripe’s earliest customers were Y Combinator companies. On one hand, these companies themselves needed online payments; on the other, they knew Patrick and John and were more willing to believe Stripe wouldn’t disappear the next day.

This trust was important. Integrating an ordinary tool at most incurs migration costs; integrating a payments company means handing over revenue and cash flow for it to handle.

Therefore, Stripe’s early growth didn’t come entirely from the API being simple enough; it also came from the entrepreneur network the two brothers had previously accumulated. The product lowered the technical barrier, and the YC network lowered the trust barrier for the first batch of clients.

Business Model: Customer Growth Equals Stripe Growth

Stripe’s initial revenue model was simple: for every transaction a customer completed, Stripe took a fee. The benefit of this model was that Stripe didn’t need to judge a customer’s potential size when they were just founded. Even a startup with just a few people could integrate Stripe first. If a customer had no transactions, Stripe earned almost no revenue; if a customer’s transaction volume increased, Stripe’s revenue grew accordingly.

This created a special relationship between Stripe and its customers. It could enter a company’s technical system very early without charging high fees upfront. In exchange, once the customer grew, Stripe could continue to share in its transaction growth.

Later, when companies like Shopify, DoorDash, and Instacart grew from startups into large platforms, Stripe expanded alongside them. This is also why Stripe has long valued startup customers: customers with small transaction volumes today could be the biggest revenue sources of the future.

Early Team: Everyone Solved Problems

During this period, Stripe didn’t have clear departmental boundaries. Patrick was primarily responsible for product and company direction. John participated in product, customer, and commercial matters simultaneously. Early engineers like Greg Brockman not only built the payment system but also participated in hiring, serving customers, and building internal tools.

Before Billy joined, the first few members were almost all engineers. After Billy joined, Stripe began filling in banking partnerships and company operations capabilities. Stripe’s employee count also expanded to around 17 people. Around the time of the official product launch, the team gradually grew from the initial few people to over a dozen.

At this scale, writing code, answering customer questions, negotiating with banks, hiring, and handling daily operations were often done by the same group of people.

Early Financing Bought More Than Just Engineers

At its official launch in 2011, Stripe had already secured about $2 million in early investment from investors including Sequoia, Peter Thiel, Elon Musk, and Andreessen Horowitz.

The value of these investors wasn’t just providing capital. For an ordinary software company, financing is primarily used to develop products and hire employees. But for a payments company, capital also meant it had time to build banking partnerships, risk control, and compliance systems, and could prove to customers and financial institutions that it had a chance to exist long-term.

The simpler Stripe’s product was, the more work it took on internally. Every new customer meant the company had to handle more transactions, fraud, disputes, and funding issues. This required Stripe to invest heavily in infrastructure upfront, even when revenue scale was still small.

Therefore, early financing essentially bought Stripe three things: time to build the product, trust from financial institutions, and the ability to bear payment risk.

Connect: Moving from a Company’s Payments into an Entire Platform’s Cash Flow

In 2012, Stripe launched Connect. The initial Stripe solved how a single company could receive payments online. Connect solved another, more complex problem: if a company itself was a platform, with many sellers, drivers, hosts, or service providers on it, how should funds be collected, split, and paid?

Connect allowed platforms to help their users accept payments and distribute funds between the platform, merchants, and service providers. This meant Stripe was no longer just serving that single platform company; it began entering the cash flows of the thousands of businesses behind the platform.

From a business model perspective, this step was crucial. Growth in ordinary payments mainly comes from a single client’s own transaction volume; Connect’s growth simultaneously comes from the platform, the merchants on it, and the expansion of the entire platform ecosystem. If a platform adds ten thousand sellers, Stripe could gain ten thousand new payment relationships at once.

Stripe thus gained its first layer of platform leverage. By the end of 2012, Stripe had completed three key steps: gaining developers with an API, making payments actually work through banking partnerships, and then using Connect to enter its clients’ commercial networks.

It was still a small startup, but no longer just helped websites accept credit cards. Stripe began transforming from a payment tool into financial infrastructure that internet companies could directly call upon.

Phase Two: 2013–2016, From Payment Tool to Startup Infrastructure

After initial product validation, Stripe’s next question was: could this model leave Silicon Valley, enter more countries, and serve more complex companies?

For an ordinary software company, entering a new market typically means translating the product, building a sales team, and adjusting pricing. For a payments company entering a new country, it needs to rehandle local banking, payment methods, currencies, regulations, taxes, and risk rules.

Every time Stripe entered a market, it had to internally reconnect a financial system while keeping the API developers saw as consistent as possible. In 2013, Stripe officially entered the UK, beginning to expand its business from the US to Europe. Over the following years, it entered more countries and added support for different currencies and payment methods.

This step changed Stripe’s value proposition. If Stripe only served the US market, it provided a better payment interface. When it started connecting banking and payment systems across different countries, it provided a global expansion capability. Customers no longer needed to find local payment providers, negotiate partnerships, and rewrite systems every time they entered a new country.

Stripe absorbed these differences into its own infrastructure and offered them to customers through relatively unified interfaces. The more complex the external world, the higher Stripe’s value became.

Moving from Payment Collection into More Business Areas

During this phase, Stripe began expanding its product boundaries. Initially, it only helped businesses accept payments. After launching Connect, it began handling fund distribution between platforms and merchants. As customer scale grew, Stripe gradually entered areas like mobile payments, subscriptions, risk control, and enterprise globalization.

When Apple Pay launched in 2014, Stripe quickly provided integration support. For developers, they didn’t need to re-understand the payment processes behind Apple Pay; they could continue to integrate new payment methods through Stripe.

In 2015, Stripe established a strategic partnership with Visa, with Visa also becoming an investor in Stripe. The Stripe that once struggled to gain banks’ trust early on began collaborating with one of the world’s largest card networks to drive product and market expansion.

This wasn’t just a commercial partnership; it showed Stripe’s changing position within the payment ecosystem. It was no longer just a startup connecting banks and card networks; it began becoming an interface layer for traditional financial networks to enter internet software.

In 2016, Stripe launched two more products crucial for its subsequent development: Atlas and Radar.

Atlas: Entering Before a Business Even Starts Making Money

Stripe Atlas helps global entrepreneurs register US companies, apply for tax IDs, open bank accounts, and complete a series of foundational tasks needed in the early stages of a startup. In terms of short-term revenue, Atlas wasn’t Stripe’s most important product. But it changed the point at which Stripe engaged with customers.

In the past, a company would seek payment tools after it was formed and ready to start collecting money. With Atlas, Stripe could engage when the company was just being formed. Entrepreneurs registered companies through Stripe, and later might also need bank accounts, payments, subscriptions, taxes, platform splits, and fund management. Stripe was no longer waiting for a business to become a customer; it attempted to participate in the process of a business being born.

The return on this strategy wouldn’t appear immediately. Most newly formed companies might never grow and would bring Stripe very limited revenue. But as long as a few of them developed, Stripe could potentially serve them from their first transaction for many years.

This continued Stripe’s early logic of serving startups: enter at low cost first, then grow with the customer.

Radar: Turning Transaction Data into New Products

Radar was Stripe’s anti-fraud product. Payment fraud wasn’t a new problem, but Stripe’s advantage was that it could simultaneously observe transactions across many businesses and markets. As more companies used Stripe, it saw more normal payments, stolen cards, disputes, and fraud patterns; the more data accumulated, the better its models could identify new risks.

After improving detection capabilities, Stripe could then apply the results to all customers, reducing fraud losses while avoiding incorrectly blocking legitimate transactions. This created a data loop:

More customers brought more transactions; more transactions improved risk assessment; better risk assessment made Stripe more valuable to new customers.

The payment business originally charged per transaction; Radar let Stripe start turning the data and risk capabilities accumulated from transactions into standalone products.

By this stage, Stripe’s business model had developed three layers:

• First layer: Payments – Helping businesses complete collections and earning revenue from transactions.
• Second layer: Platforms – Entering the cash flows of platforms and their merchants via Connect.
• Third layer: Software and Data – Turning risk control, company formation, and other capabilities into repeatable products.

Stripe still used payments as its entry point but had begun building a larger product system around the financial capabilities an internet company needed from inception to growth.

The Organization Started Lagging Behind Product Growth

As products and markets expanded, the early approach of a few people handling everything started to fail. In 2014, Claire Hughes Johnson joined Stripe as COO. At the time, Stripe had about 160 employees. Claire previously worked at Google for ten years, responsible for online sales, operations, and self-serve advertising. After joining Stripe, she gradually managed business operations, sales, marketing, customer support, risk, hiring, HR, and office spaces. Stripe bringing in Claire wasn’t about making the founders step back from management but about giving the company a repeatable organizational system.

Patrick and John were still responsible for mission, product, and long-term direction. Claire began turning many things previously driven by the founders personally into hiring processes, annual planning, sales mechanisms, customer support, and management systems.

This was the second important node in Stripe’s organizational development. Billy Alvarado solved early banking partnerships and business operations; Claire needed to solve how a company of hundreds or thousands could continue to operate.

In 2015, Will Gaybrick joined Stripe as CFO. Will previously worked at Thrive Capital and had participated in investing in Stripe. He had backgrounds in math, software engineering, law, and investing—not a traditional CFO focused only on financial reporting. His joining indicated that Stripe’s challenges were no longer just about getting more capital but how to allocate capital among an increasing number of products, countries, and business opportunities.

Every market Stripe entered, every product it developed, required upfront investment in engineering, compliance, legal, and operational resources. Which projects were worth long-term building, which products should be paused—these were becoming decisions based on both product judgment and capital allocation.

Will later transitioning from CFO to a product and business lead can also be traced back to this phase: at Stripe, finance, product, and infrastructure investment were hard to separate from the start.

Valuation Rises, Capital Begins Buying Time for Global Expansion

In 2014, Stripe completed an approximately $80 million funding round, reaching a valuation of about $1.75 billion, officially entering unicorn status. Later that year, it completed another approximately $70 million round, with the valuation rising to about $3.5 billion.

In 2015, while establishing its strategic partnership with Visa, Stripe’s valuation reached about $5 billion. In 2016, the company raised another approximately $150 million, with a post-money valuation of about $9.2 billion.

Over three years, Stripe’s valuation increased from $1.75 billion to nearly $10 billion. But the capital market wasn’t just buying the existing payment revenue. Investors were actually betting on three things: First, internet transaction volume would continue to grow. Second, more and more businesses would hand over payment and financial capabilities to software platforms. Third, Stripe could encapsulate the complexities of different countries and financial institutions into a set of infrastructure developers could call upon.

These funding rounds also gave Stripe the ability to build ahead. Many countries and products wouldn’t generate sufficient revenue early on but required the company to first invest in banking partnerships, licenses, compliance, engineering, and local teams. Stripe used capital to bear the upfront costs, then waited for customer and transaction volumes to gradually grow.

This Phase’s People Efficiency Isn’t Suitable for Revenue-Only View

Stripe hasn’t disclosed complete enough data for the outside world to accurately calculate revenue, profit, and per-employee output during this period. But from the product structure, it had begun forming another kind of people efficiency: the same set of infrastructure could be reused by a large number of customers.

One Connect system could serve multiple platforms and their thousands of merchants. One Radar model could learn from different customers’ transactions and provide risk assessment for all customers. Integrating a new bank or payment method could simultaneously serve all Stripe customers entering that market.

This was infrastructure reuse efficiency. But it had another side. Every country entered, every payment method added, every new business model served, added compliance, legal, operational, and support costs internally at Stripe.

The simpler the experience Stripe provided externally, the higher the complexity it often needed to manage internally. By the end of 2016, Stripe was no longer just a company offering a payment API. It began covering company formation, collection, platform splits, risk control, and global expansion, gradually forming a product system centered around internet companies’ cash flows.

The next phase’s question also emerged: when products multiplied and the team approached a thousand, could Stripe still maintain the early speed driven directly by engineers and founders?

Phase Three: 2017–2019, From Payment Products to a Product Matrix

By 2017, Stripe’s challenge was no longer "are developers willing to use it" but whether it could continue to meet these companies’ needs as they grew. Early-stage startups only needed to solve collection problems. As business scale expanded, they began facing issues like subscription management, invoicing, taxes, financial reporting, in-person payments, cross-border payments, and cash flow.

If Stripe only provided payments, customers reaching a certain stage would need to find other service providers or even rebuild their own financial systems. Stripe therefore began entering more adjacent areas around its customers’ cash flows.

Billing: Moving from a Single Transaction to Recurring Revenue

In 2018, Stripe launched a new version of Billing, expanding the original subscription functionality into a more complete recurring revenue management product. One-time payments are relatively straightforward: a customer buys a product, the business completes the charge. But subscription businesses need to handle many more issues: different plans, trial periods, coupons, usage-based billing, failed renewals, upgrades/downgrades, and revenue recognition. Many of these aren’t about "can we charge" but "how does the business manage revenue long-term."

Billing extended Stripe’s relationship with customers from a single transaction to the entire subscription lifecycle. Businesses weren’t just using Stripe when a payment occurred; they also put product pricing, customer status, and revenue rules into Stripe’s system.

This also changed Stripe’s fee logic. Payment revenue depended on whether a transaction occurred; software products like Billing could charge based on subscription scale, number of invoices, and feature usage. Stripe began gradually adding software service revenue on top of pure transaction fees.

Terminal: Moving from Online to Offline

The same year, Stripe launched Terminal, expanding its business from online payments to offline. The traditional payments industry typically treated online and offline as two separate systems. A business used one payment provider online, another set of POS and hardware systems in stores, and then needed to integrate order, customer, and financial data themselves.

Terminal attempted to connect these two parts. Businesses could use Stripe-provided card readers and software interfaces to handle in-person payments, then manage online and offline transactions within the same system.

This step was important for Stripe. Its initial advantage came from internet-native businesses. But as those customers opened physical stores and entered the real world, Stripe needed to follow them offline.

Stripe wasn’t going after traditional merchants first and asking them to replace entire systems; it continued expanding its products along its existing customers’ growth paths.

Issuing, Capital, and Sigma: Entering Fund Management

During this period, Stripe also launched or expanded products like Sigma, Issuing, and Capital. Sigma helped businesses directly query and analyze transaction data in Stripe. Issuing allowed platforms and businesses to issue physical or virtual cards. Capital provided financing to qualified customers based on their business and transaction data within Stripe.

These products seemed to belong to data, card issuance, and lending respectively, but the underlying logic was similar: Stripe already had customers’ payment and business data, so it could continue providing services around fund management.

Take Capital as an example. Traditional lenders require businesses to submit financial documents to assess repayment ability. Stripe could already see some customers’ revenue scale, transaction changes, refunds, and business stability, allowing it to use this data for risk assessment and recover funds through future transaction revenue.

Payments thus became an entry point to more financial services. Stripe didn’t need to start by selling loans or card products to customers. It first helped businesses handle transactions, then, after accumulating enough data and trust, offered more services.

By 2019, Stripe’s products could be roughly grouped into several layers:

• Payments and Terminal were responsible for accepting payments.
• Connect handled accounts, collection, and fund distribution within platforms.
• Billing handled subscriptions and recurring revenue.
• Radar handled fraud and risk.
• Sigma handled data analysis.
• Issuing and Capital began entering card issuance and financing.

Stripe was no longer a single payment product but a set of financial tools centered around business cash flows.

Business Model: The Same Customer Buys More Products

With the product matrix formed, Stripe’s growth model also changed. Early growth mainly came from two sources: more customers integrating and existing customers generating more transactions. Now a third source was added: the same customer using more Stripe products.

A startup might initially only use Payments. As the business developed, it might use Billing to manage subscriptions, Radar to control fraud, Connect to manage platform merchants, then Issuing for cards or Capital for financing.

Every additional product deepened Stripe’s relationship with the customer and increased the difficulty for the customer to migrate to another provider. This wasn’t entirely traditional product bundling. Stripe’s advantage was that these products shared the same accounts, transaction data, identity information, and funding systems. Customers didn’t need to rebuild infrastructure for each financial capability.

From the customer’s view, it was buying different products. From inside Stripe, these products were built on the same financial data and funding network.

This was also a key step in Stripe’s transition from a payments company to a financial infrastructure platform.

Customer Structure Began Changing

As products multiplied, the customers Stripe served expanded from early-stage startups to more mature platforms and large enterprises. Startup decisions were usually fast: a developer tried the product, confirmed it worked, and might integrate directly. Large enterprise procurement processes were completely different. They cared about system stability, data security, global coverage, cost, compliance, and service capabilities, and needed to go through finance, legal, risk, and procurement departments.

Stripe’s early self-serve growth model, reliant on developer word-of-mouth, was no longer sufficient to close all large customer deals. This meant Stripe not only needed to continue serving engineers but also learn to communicate with enterprise management, finance departments, and procurement teams. It needed sales teams, solutions engineers, customer success, and more mature support systems. The product was shifting from a developer tool to enterprise infrastructure, and the organization had to change accordingly.

David Singleton: The Engineering Organization Needed New Management

By late 2017, Stripe was approaching 1,000 employees and hired David Singleton from Google to lead the engineering team. David previously led Android Wear and had experience managing large engineering organizations. When he joined Stripe, the company already had multiple products, and the engineering team was no longer a small group where everyone understood all the code and customer issues.

Early Stripe could rely on a few highly capable engineers making decisions quickly. With a team approaching a thousand, the same approach started causing problems.

Different products might duplicate similar account, permission, and funding capabilities. A change to a core system could simultaneously affect Payments, Connect, and Billing. Engineers needed to balance product speed, system stability, and financial risk.

David needed to solve not just how to hire more engineers but how to turn Stripe’s engineering culture into mechanisms that could operate within a larger organization.

This was another capability addition in Stripe’s organizational history:

• Billy filled banking and institutional partnerships.
• Claire built operational and management systems.
• Will connected capital allocation with product choices.
• David began managing an engineering organization nearing a thousand people.

The founders still set company direction, but more and more specialized leaders began taking on work previously handled directly by founders and early employees.

More Products, Higher Coordination Costs

The product matrix increased per-customer value but also brought new organizational problems. When Stripe only had a payments product, the company could work around a common goal: make online payments easier. With Billing, Terminal, Issuing, Capital, and Sigma emerging, different teams began having their own customers, metrics, and product roadmaps.

Yet these products couldn’t be completely independent. Billing needed to call Payments to complete charges. Connect depended on account and compliance systems. Capital used transaction data for risk assessment. Radar’s assessments could affect all payment products.

Stripe couldn’t simply split each product into completely independent companies, nor could all decisions go back to the founders. It needed to balance two things: giving product teams enough autonomy while ensuring the underlying funding, risk, and data systems remained unified.

Product reuse brought higher people efficiency, but interdependencies between products increased coordination costs. These two forces grew simultaneously within Stripe.

The Capital Market Began Valuing It as a Platform

In 2018, Stripe completed an approximately $245 million funding round, valuing the company at about $20 billion. In early 2019, Stripe’s valuation further rose to about $22.5 billion. In September that year, the company raised another approximately $250 million, reaching a valuation of about $35 billion.

In two years, Stripe’s valuation nearly doubled. If Stripe were still just an online payment processor, such valuation would be hard to explain solely by revenue at the time. The capital market was buying into the product matrix it was forming and its position within internet companies’ cash flows.

Payments brought transactions and customers. Connect expanded the account network. Billing and Radar added software revenue. Issuing and Capital let Stripe enter more financial services.

Each product could potentially charge independently while also increasing the usage value of other products. Stripe began exhibiting platform company characteristics. But this path also meant higher costs. The company needed to simultaneously build more products, enter more countries, and hire sales, risk, legal, compliance, and engineering personnel. Financing was still buying future growth upfront.

By the end of 2019, Stripe had expanded from a payments company known for developer experience into a multi-product financial infrastructure platform. The pandemic that followed dramatically increased internet transactions in a very short time, compressing years of Stripe’s planned expansion into two to three years. Customer, transaction, and employee counts grew rapidly together, eventually pushing the company into its most intense period of organizational expansion and correction since founding.

Phase Four: 2020–2023, Pandemic Overdrive, Organizational Overshoot, and Proactive Correction

In 2020, the pandemic suddenly pushed vast amounts of commercial activity online. Digitalization processes that would have taken years were compressed into months. Restaurants started accepting online orders, retailers built e-commerce sites, offline services shifted to subscriptions and remote delivery, and more businesses needed to complete payments online.

For Stripe, this was both a huge market opportunity and a stress test beyond its original plans. Customer numbers and transaction volumes increased rapidly, and existing customers also gained more online revenue quickly. Stripe not only had to handle larger payment volumes but also help businesses enter new countries, add payment methods, and solve subscription, tax, risk, and fund management issues.

Stripe judged that this change wasn’t just a temporary pandemic phenomenon but that the internet economy had entered a new growth phase. The company therefore began accelerating expansion.

Employees Grow from 2,800 to Nearly 8,000

In August 2020, Stripe disclosed in an official announcement that it had about 2,800 employees across 16 offices. Over the next two years, Stripe hired heavily in engineering, product, sales, support, risk, compliance, and operations. By 2022, employee count once approached 8,000, nearly triple the 2020 figure.

The rapid employee growth was related to Stripe’s expanding product scope around the same period. Around 2020, Stripe launched or expanded products like Treasury and Climate. In 2021, it intensively launched Tax, Identity, Payment Links, and Revenue Recognition and completed multiple acquisitions. In 2022, it continued adding Apps, Data Pipeline, and Financial Connections.

Stripe was no longer just adding features to its payments business; it was simultaneously building a more complete internet commerce infrastructure. Each added product required engineering, product, compliance, sales, and support teams. Each country entered required handling local banks, licenses, taxes, and payment methods.

The rapid rise in transaction volume during the pandemic made these investments seem reasonable. If internet economic growth continued at that pace, Stripe needed to hire ahead for customer and product demand in the coming years. The problem was, growth didn’t continue indefinitely—a common pitfall for many startups.

Product Expansion Speed Began Outpacing Organizational Absorption Capacity

Adding people doesn’t necessarily immediately increase output. When team scale was small early on, an engineer could understand many products and underlying systems; many decisions could be made through direct communication. When the company approached 8,000 people and operated dozens of products simultaneously, the same management style generated increasingly high coordination costs.

A new product might depend on multiple underlying systems like accounts, payments, risk, data, identity, and compliance. Project participants multiplied, approval paths lengthened, and responsibility boundaries between teams started blurring.

The company seemed to have more resources, but each added team could also add new meetings, reporting, and dependencies. This is a paradox for infrastructure companies: the more unified the external product, the more complex the internal organization tends to become.

Customers wanted to use payments, subscriptions, taxes, and fund management through one Stripe account. But internally, Stripe needed multiple teams to share the same data, risk, and funding systems. Any underlying change could simultaneously affect multiple products and countries.

When employee numbers grew quickly, new hires also needed training, understanding systems, and building working relationships. If hiring speed outpaced the organization’s ability to absorb new people, headcount growth could actually reduce overall efficiency.

2022: Growth Assumptions Change

In 2022, the global economic environment began shifting. The rapid online consumption growth during the pandemic gradually eased. Inflation and rising interest rates impacted corporate financing and spending. Tech industry growth expectations also started declining.

Stripe, having previously assumed the internet economy would continue rapid expansion, had added significant personnel and costs ahead of time. When external growth slowed, the company’s existing organizational scale appeared too heavy.

In November 2022, Patrick and John announced to employees a layoff of about 14%. In a public letter, the brothers admitted they had been overly optimistic about internet economic growth in 2022 and 2023 and underestimated the possibility and impact of an economic slowdown. Company operating costs had grown too fast, and the organization had become less efficient than before.

After the layoffs, Stripe’s employee count returned to the near-7,000 level of February that year. What’s notable about this letter is that the founders didn’t attribute the problems entirely to macroeconomics. They explicitly admitted the company made misjudgments and bore responsibility for the outcome.

For a company where founders still held control, this was the other side of founder control: founders could insist on long-term investment but also had to bear the organizational consequences of over-expansion.

Layoffs Weren’t Simply Reducing Headcount Back

If looking only at employee numbers, Stripe seemed to just cut the extra people hired during the pandemic. But an organization can’t easily return to its previous state through one layoff. Over two years, the company had added many products and management layers. Even with reduced headcount, dependencies between products, cross-team coordination, and global operational complexity remained.

What Stripe needed to solve next wasn’t just "spend less money" but to reassess which products deserved continued investment, which teams should merge, and which decisions could be made by smaller teams.

The company began re-emphasizing several things: control costs, reduce coordination, increase execution speed, and bring teams closer to customers and actual results.

From this perspective, the 2022 layoffs weren’t an isolated event but an active correction in Stripe’s organizational design. Early Stripe’s efficiency came from small size and singular focus. Post-pandemic Stripe had to find another kind of efficiency: making a complex organization regain speed of action when product and country counts couldn’t revert to their starting points.

Management Also Reorganized

Stripe’s management structure changed during this phase. Claire Hughes Johnson stepped down from day-to-day COO duties in 2021, transitioning to Corporate Officer and advisor. During her tenure, Stripe grew from under 200 to thousands of employees and established major functions like sales, operations, support, risk, and HR.

After Claire left daily operations, her previous responsibilities weren’t centralized under a new COO but gradually distributed to different specialized leaders. In 2020, Stripe hired Dhivya Suryadevara from General Motors as CFO. The same year, it hired former AWS global commercial sales head Mike Clayville to build a global sales system targeting large enterprises.

This indicated Stripe’s organization had entered another phase. The company no longer needed one COO to build all functions from scratch but needed finance, engineering, sales, risk, and international business leaders to respectively manage already sizable professional organizations.

The founders remained at the center, but the management structure around them became more specialized and more distributed.

Financing Shifts from Growth Capital to Employee Liquidity

During the pandemic, Stripe’s valuation also experienced rapid rise and significant correction. In 2020, Stripe raised about $600 million at a valuation of around $36 billion. In 2021, the company raised another approximately $600 million, reaching a $95 billion valuation, once becoming one of the world’s highest-valued private companies.

At that time, capital markets generally placed high valuations on internet companies. Stripe’s transaction growth, product matrix, and global expansion made investors believe it could become core infrastructure for the internet economy.

But by 2023, Stripe’s new funding round corresponded to a valuation drop to $50 billion, nearly half of the 2021 figure. On the surface, this was a significant valuation drop, but the nature of this round differed from early financing. Stripe stated the company didn’t need this capital to sustain daily operations; the approximately $6.5 billion was primarily used to provide liquidity for employee stock and handle tax obligations related to employee equity.

Early financing primarily let Stripe hire, develop products, and enter new markets. By this stage, capital began serving another function: giving current and former employees holding stock for years an exit opportunity. Since Stripe remained private long-term, employees’ stock lacked a public trading market. If the company couldn’t provide liquidity, the practical value of equity incentives would decline, affecting hiring and retention.

Therefore, the 2023 financing can’t be simply understood as "Stripe needed money." It was more like Stripe, while remaining private, used a funding arrangement to solve problems typically addressed through an IPO.

How to View People Efficiency in This Phase?

In 2022, Stripe processed approximately $817 billion in payment volume. Roughly calculated using the post-layoff near-7,000 employees, that’s about $117 million in payment volume per employee per year. This number doesn’t represent Stripe’s per-employee revenue or profit—most of the payment volume belongs to merchants, with Stripe taking only a portion as fees. But it can serve as an infrastructure scale metric, observing how much cash flow each employee supports.

The real issue was that from 2020 to 2022, employee growth speed at one point outpaced increases in payment volume and organizational efficiency. Stripe’s layoff letter admitted coordination costs and operational inefficiency had entered the company. This indicated that at the peak near 8,000 employees, adding staff no longer automatically brought proportional output gains.

After 2023, Stripe didn’t return to pandemic-era hiring speed, but payment volume continued growing. Employee count remained relatively stable while transaction volume and product usage increased, allowing people efficiency leverage to reappear.

The lesson this phase left Stripe wasn’t "big companies shouldn’t hire" but: infrastructure can be reused, but organizational complexity doesn’t automatically reuse.

The marginal cost for a system to process one more transaction might be low, but each team added to an organization brings new communication, management, and decision-making costs. By the end of 2023, Stripe had completed a turn from high-speed expansion to organizational correction. It didn’t abandon its multi-product, global path but began trying to support larger transaction volumes with more restrained personnel growth.

This also set the stage for the next phase: as internal growth faced constraints, Stripe began acquiring already-mature teams and infrastructure more frequently, further expanding product boundaries into stablecoins, wallets, usage-based billing, and AI model routing.

Phase Five: 2024–2026, From Payment Infrastructure Toward a "Programmable Money System"

After the 2022 layoffs and organizational correction, Stripe didn’t stop expanding its product boundaries. The difference was that Stripe no longer primarily relied on massive hiring to slowly build all new capabilities internally. It began more frequently acquiring already-mature teams, products, and infrastructure directly into its system.

From 2024 to 2026, Stripe sequentially acquired or announced acquisitions of Bridge, Privy, Metronome, and OpenRouter. These companies seem to belong to stablecoins, wallets, usage-based billing, and AI model routing respectively, but viewed together, they aren’t unrelated investments.

They collectively point to a new product direction:

What Stripe wants to manage isn’t just a single payment but how businesses get accounts, hold funds, measure usage, set prices, and complete value exchange between traditional currency, stablecoins, and AI tokens.

Transaction Volume Continues Growing, but Headcount Doesn’t Return to Pandemic Pace

In 2024, businesses on Stripe processed about $1.4 trillion in payment volume, a roughly 38% increase from 2023. In 2025, this number further grew to $1.9 trillion, a 34% year-over-year increase, equivalent to about 1.6% of global GDP.

Meanwhile, Stripe’s official careers page still listed employee size as over 8,000 people. Compared to the near-7,000 post-layoff in 2022, headcount has resumed growth, but at a speed明显 slower than payment volume.

If roughly calculated with 8,000 employees, 2025 payment volume per employee was about $238 million. Since actual employee count is higher than 8,000, the real figure is slightly lower. For comparison, using near-7,000 employees in 2022, per-employee payment volume was about $117 million. In other words, without doubling headcount, the transaction volume each Stripe employee supported nearly doubled in about three years. Post-layoff Stripe regained infrastructure scale leverage: transaction volume grew faster than employee count.

From Building In-House to Acquiring Specialized Infrastructure

Early Stripe preferred developing products in-house. Payments, Connect, Billing, Radar, Atlas, and Terminal were basically built step-by-step within the company. But as Stripe entered stablecoin and AI infrastructure, the cost of building all capabilities from scratch grew higher and higher.

Stablecoins require blockchain, custody, compliance, and cross-border settlement capabilities. Wallets require managing identity, keys, and authorization. Usage-based billing requires real-time processing of massive event streams. Model routing requires connecting different AI models and continuously comparing price, speed, and quality.

Each of these areas could form an independent company. If Stripe started from zero, it would not only need to rebuild teams but also wait for products, customers, and industry experience to mature. Acquisitions could compress that time.

Therefore, Stripe’s recent acquisition strategy isn’t just buying revenue; it’s also buying time to enter the next phase.

Bridge: Turning Stablecoins into Funding Channels

In October 2024, Stripe announced the acquisition of stablecoin infrastructure company Bridge, with a disclosed transaction value of about $1.1 billion. The deal closed in February 2025. Bridge helps businesses move funds between traditional banking systems and stablecoins, also providing stablecoin issuance, storage, and cross-border payment capabilities.

For ordinary businesses, the real difficulty with stablecoins isn’t sending a token on a blockchain but completing the front and back connections: how customers convert fiat to stablecoins, who custodies the stablecoins, how to meet compliance requirements, and finally how to convert back to local currency.

Bridge handled precisely these steps. Post-acquisition, Stripe could embed stablecoin capabilities into its existing payment, account, and fund management products. Customers wouldn’t need to understand which chain, stablecoin, or custodian is used underneath; they’d just choose what currency to collect, hold, and pay in.

This closely resembles Stripe’s original logic for handling credit card payments. Back then, Stripe hid merchant accounts, payment gateways, and bank connections behind an API. Now, it’s attempting to hide blockchain, stablecoins, and cross-border settlement behind the same infrastructure.

Privy: Beyond Accounts, Identity and Wallets Are Needed

In 2025, Stripe announced the acquisition of crypto wallet infrastructure company Privy. Privy helps applications create and manage wallets for users. Users can log in with email, social accounts, etc., without initially understanding seed phrases, private keys, and on-chain operations. If Bridge solves how funds move between fiat and stablecoins, Privy solves: who do these funds belong to, who authorizes them, and where are they stored? This is important for Stripe.

Traditional internet payments build identity relationships around cards and bank accounts. In stablecoin and AI Agent scenarios, wallets could become new account carriers. Businesses, individuals, and software Agents may all hold funds and complete transactions through wallets.

If Stripe only provided stablecoin channels without wallet and authorization capabilities, it would still lack a key entry point in the funding system. Bridge plus Privy gives Stripe both funding channels and account carriers. It’s no longer just moving funds between existing bank accounts but also beginning to participate in new digital account systems.

Metronome: AI Products Need New Billing Methods

In January 2026, Stripe completed the acquisition of usage-based billing company Metronome. Traditional software typically charges monthly or annually. AI product costs resemble cloud computing: each model call consumes tokens, GPU, and other compute resources, with costs varying for different models and tasks. If an AI company still only charges a fixed subscription fee, two problems can arise: lighter-usage customers subsidize heavier users, and when model costs change, product pricing can’t adjust in time. Businesses therefore need to bill based on tokens, calls, processing time, or actual results.

Metronome’s core capability is recording these complex product usage data and turning it into billable invoices. Stripe already had Billing, but acquiring Metronome gave it more mature real-time usage billing capabilities. Thus, Stripe isn’t just responsible for final collection; it begins participating in "how should this charge be calculated." This moves Stripe’s position in the AI economy one step forward: from completing payment to defining usage, calculating prices, and generating invoices.

OpenRouter: From Calculating Price to Allocating Compute

On August 19, 2026, Stripe announced it had agreed to acquire AI model routing platform OpenRouter. This could become Stripe’s largest acquisition since founding.

OpenRouter provides developers a unified interface to use over 400 AI models from more than 80 providers. Businesses don’t need to integrate different models separately but can select or automatically route to more suitable models based on task, price, speed, and stability.

OpenRouter’s product logic strongly resembles Stripe’s. Stripe connects different countries, banks, card networks, and payment methods into a relatively unified interface. OpenRouter connects different model companies and inference services into a unified interface.

One routes money, the other routes compute.

More importantly, OpenRouter tackles not a purely technical problem. Model selection directly impacts AI product costs and profits. Different model prices change frequently, and the same task may involve different trade-offs between quality, speed, and cost.

After acquiring Metronome, Stripe can help businesses record usage and generate invoices. If the OpenRouter deal completes, Stripe can further participate in model selection and token consumption.

Linking the two acquisitions forms a more complete chain: select model → consume tokens → record usage → calculate price → charge customer → complete fund settlement.

In the acquisition announcement, Patrick referred to tokens as the "core currency" for AI businesses. Here "currency" doesn’t mean tokens equal dollars but that for AI companies, tokens have become a core production resource that needs to be measured, allocated, and optimized.

What Stripe wants to do isn’t just help businesses buy tokens; it hopes to simultaneously manage AI companies’ revenue and cost sides: helping them price and collect revenue while helping them choose models and control compute costs.

Four Acquisitions, Outlining Two Pipelines

Placing Bridge, Privy, Metronome, and OpenRouter together, we see Stripe building two interconnected pipelines.

First is the Money Pipeline: Account/Wallet → Collection → Fund Holding → Cross-border Transfer → Payment & Settlement. Bridge and Privy add stablecoin, wallet, and identity capabilities. Stripe’s existing Payments, Connect, Treasury, and Issuing handle traditional payments, accounts, splits, and card issuance.

Second is the Intelligence Pipeline: Select Model → Call Model → Measure Tokens → Calculate Cost → Generate Invoice. OpenRouter handles model integration and routing. Metronome and Stripe Billing handle usage and billing. Stripe Payments finally handles completing the payment.

In the past, Stripe’s main product boundary was how money moves. Now, it’s starting to simultaneously handle how intelligence is called, measured, and priced.

Tokens Aren’t Dollars, But Are Becoming a New Unit of Account

Stripe and OpenRouter repeatedly used a phrase in the acquisition announcement: tokens are becoming the "core currency" for AI businesses.

Model tokens aren’t legal tender and can’t directly make payments like dollars. They are essentially a unit of measurement for model input and output usage.

But for AI companies, tokens have taken on a role similar to an operational unit of account. Every time an AI product serves a customer, it may consume varying numbers of tokens behind the scenes. Which model is used, what task is performed, response length, inference steps—all affect cost.

Therefore, AI businesses need to answer several questions simultaneously:

• How many tokens did this task consume?
• How much model cost do these tokens correspond to?
• Should the customer be charged a fixed subscription fee or based on actual usage?
• When different model prices change, how should the product adjust routing and pricing?
• After the customer pays, how are funds settled between the platform, model providers, and other service providers?

OpenRouter handles model selection and token routing. Metronome handles recording usage. Stripe Billing handles generating invoices. Payments and stablecoin infrastructure handle final fund settlement. From this perspective, Stripe acquiring OpenRouter isn’t treating model tokens as a new dollar but beginning to manage a new unit of economic activity.

In the past, Stripe primarily handled monetary transactions: how much a product sold for, how the customer paid, how the merchant received funds. Now, Stripe is starting to further handle the computational process before a transaction occurs: how many resources an AI service consumed, how those resources should be priced, and who should bear the cost.

Meanwhile, stablecoins solve another type of problem. Model tokens are units of computation and usage; stablecoins are actual digital currencies used for payment and settlement. The two shouldn’t be confused but may connect in AI Agent scenarios.

In the future, a software Agent might automatically select models, call services, consume tokens, then use stablecoins or traditional payment methods based on pre-set permissions to complete payment.

The entire chain could become:

Agent initiates task → OpenRouter selects model → Model produces token consumption → Metronome records usage → Stripe calculates invoice → Settle using card, bank account, or stablecoin.

This is why Stripe is simultaneously investing in AI tokens and stablecoins. It’s not simply betting on two hot technologies but judging: in the future, more economic activity will be automatically initiated by software, compute resources will be measured in real-time, and payment will shift from a one-time human confirmation to a continuous process controlled by permissions and rules. Stripe wants to connect this process.

In the past, it let an internet company avoid handling banks, card networks, and payment gateways itself. In the future, it hopes to let an AI company avoid handling model routing, token measurement, dynamic pricing, and global settlement itself.

If this path holds, Stripe’s product boundaries will change again: it’s managing not just how money moves but also how an intelligent service is produced, measured, priced, and paid for.

Organization: From Building Functions to Integrating Specialized Teams

Acquisitions bring not just products but also specialized teams that have worked together for years. Bridge’s team understands stablecoins, compliance, and cross-border cash flows. Privy’s team understands wallets, identity, and authorization. Metronome’s team understands complex usage billing. OpenRouter’s team has long handled model integration, price changes, and routing selection.

These capabilities are hard to quickly replicate through short-term hiring. But acquisitions also bring new organizational questions: how much independence should these teams retain, how should underlying systems connect with Stripe, who is responsible between old and new products, and how to avoid big-company processes slowing down acquired teams.

Stripe needs to balance integration and independence. If integration is insufficient, acquired products remain isolated islands. If integration is excessive, it could destroy the teams’ original speed and product judgment.

This makes Stripe’s current organizational capabilities quite different from early days. The early team’s core task was building the product themselves. Now, management also needs to judge what to build in-house, what to acquire, and how to make external teams part of the same infrastructure.

AI Is Also Rewriting Stripe’s Own Organization

Stripe’s view of AI isn’t only reflected in acquiring OpenRouter and Metronome. AI is also changing how Stripe develops products and organizes teams.

In August 2026, Will Gaybrick, in an interview with a16z partner David George, discussed Stripe’s internal use of AI. Stripe internally developed a programming tool called Minions. After an engineer describes a task to it, Minions can independently write code, run tests, and submit pull requests for engineer review.

According to data Gaybrick disclosed in the interview, the number of pull requests Minions generates weekly has increased from about 1,200 at the start of the year to about 7,000. In the most recent week, AI-generated code changes accounted for about 30% of all Stripe pull requests.

Stripe also developed an internal knowledge tool called Kai to help employees query company-internal product, policy, and operational information. Gaybrick stated this tool is used by most employees and has improved sales teams’ speed in finding information and handling customer issues. These numbers come from Stripe management’s public statements and can’t be directly equated to a 30% overall productivity increase—AI-submitted code still needs review, and different pull requests vary in complexity.

But it at least indicates that AI within Stripe is no longer just an auxiliary chat tool but is entering code development, knowledge query, and product delivery processes. This also presents Stripe with a new organizational problem: when one engineer can accomplish work previously needing a small team, how should the company redesign teams?

Gaybrick mentioned in the interview that Stripe is experimenting with smaller, flatter teams. In the past, an engineer might only advance one or two tasks simultaneously. With programming Agents, they can distribute multiple well-defined tasks to different Agents and focus on judgment, design, and code review.

Past large engineering teams typically increased headcount to improve parallel development capability. Future teams might increase the number of Agents each engineer can manage simultaneously.

This doesn’t mean Stripe has a fixed answer. If engineers initiate more tasks simultaneously but product judgment, code review, and cross-team coordination don’t improve, the company might just generate more work to handle faster. Faster code generation doesn’t mean correct product direction automatically appears.

AI can lower execution costs but can’t replace product judgment and responsibility assignment. Therefore, Stripe hasn’t treated AI solely as a tool to reduce headcount. Gaybrick summarized the company’s strategy as "build more": after efficiency improves, don’t just maintain original output with fewer employees; use the same organization to build more products.

He gave the sales team example. After Stripe’s internal AI tools increased salesperson productivity by about 20%, the company didn’t reduce sales staff accordingly but continued hiring, hoping to convert the efficiency gain into more customers and revenue.

This forms an interesting contrast with the 2022 layoffs. In 2022, Stripe found employee count grew too fast, and coordination costs outweighed added output. By 2026, the company is trying to use AI to increase individual leverage, adding product and commercial output without excessively expanding the organization.

Thus, Stripe’s current people efficiency logic isn’t just "how much transaction volume per employee supports" but adds a new question: how many software Agents can one employee simultaneously direct, and can they take responsibility for the results these Agents produce?

Management Continues Specializing

As of 2026, Patrick Collison remains CEO, John Collison remains President, and the two founders continue to set the company’s long-term direction.

Will Gaybrick’s responsibilities have expanded from early CFO to President of Technology and Business, overseeing technology, product, and commercial work. David Singleton serves as CTO. Dhivya Suryadevara handles finance.

In June 2026, long-time revenue and global markets leader Eileen O'Mara was appointed Vice Chair, and Tyler Bryson became Chief Revenue Officer. This reflects another change in Stripe’s organizational structure.

Early on, the company needed people who could build functions. Now it needs leaders who can allocate resources across products, technology, business, and regions. Products no longer operate along single business lines. A decision about stablecoins, AI billing, or model routing may simultaneously involve engineering, capital allocation, sales, regulation, and M&A. Therefore, Stripe is placing more and more technology and commercial responsibilities in the same group of managers’ hands.

Remaining Private Becomes a Capital Strategy

Stripe remains private in this phase but provides liquidity to current and former employees through continuous employee stock transactions. The 2024 employee stock transaction corresponded to a valuation of about $65 billion. In 2025, it rose to about $91.5 billion. In February 2026, the latest employee tender offer corresponded to a valuation of $159 billion. These numbers come from employee stock transactions, not public market capitalization, and don’t fully equal traditional funding round valuations. But they provide a reference for what price external investors are willing to pay for Stripe shares. Employee liquidity transactions let Stripe remain private while alleviating the problem of employees holding stock for years without an exit.

By 2026, staying private brought another advantage: Stripe can use cash and stock for large acquisitions without having to explain short-term profit changes to public markets every quarter.

According to data Stripe disclosed to investors in August 2026, first-half revenue grew 41% year-over-year, and free cash flow grew 43%. Stripe also stated that even after multiple large acquisitions, total shares outstanding remain lower than three years ago. This data comes from Stripe’s own investor letters, not publicly audited financial reports. But they indicate Stripe is trying to prove something: staying private isn’t just delaying an IPO but preserving flexibility for long-term investment, share buybacks, and acquisitions.

In the past, financing primarily bought time for Stripe to enter more countries and build products. Now, capital is used to buy already-formed specialized capabilities and combine them into next-generation infrastructure.

By 2026, Stripe can hardly be simply defined as a payment processing company. Payments remain its biggest entry point, but around this entry, Stripe has gradually formed capabilities in accounts, wallets, billing, taxes, risk, stablecoins, fund management, and model routing.

It’s moving from "helping internet companies collect money" toward "helping internet companies manage revenue, funds, and compute costs."

The Founders Haven’t Left, but the Core Team Kept Changing

One unique aspect of Stripe is that after 16 years, the two founders remain in core positions. Patrick Collison continues as CEO, John Collison as President. Many unicorns at this scale bring in a new CEO or move founders to the board, but Stripe didn’t take that route.

However, "founders staying" doesn’t mean Stripe has always been personally managed by the two brothers in all details. When Stripe had only a dozen people, Patrick and John could write code, contact users, design products, and directly participate in bank partnerships, risk handling, and hiring. Company problems were relatively concentrated then: how to make online payments easier for developers to integrate.

Later, Stripe expanded from a payment API to Connect, Billing, Terminal, Issuing, Tax, Treasury, Identity, and further into stablecoins, wallets, usage billing, and model routing. The two founders can no longer understand and manage every business detail.

Stripe’s core team thus constantly changed. It didn’t build a complete management team all at once but found people who could solve problems at each new bottleneck stage.

Billy Alvarado: First Getting Stripe into the Financial System

Stripe’s first real-world problem was that merely writing an API couldn’t complete payments. A payments company needs bank accounts, payment channels, risk management, and trust from financial institutions. For two young founders without traditional banking experience, these problems couldn’t be solved by technology alone. Billy Alvarado’s role, written earlier, was helping Stripe establish bank and payments industry relationships, handle payment operations, and make traditional financial institutions willing to work with a newly founded tech company. His joining represented Stripe’s first step from a developer tool into real financial infrastructure.

Greg Brockman: Turning a Small Engineering Group into an Engineering Organization

After solving banking partnerships, Stripe’s next challenge was how to scale the engineering team. Greg Brockman joined very early and served as CTO. When the team had only a few people, many problems could be solved by individual capability. But when the team expanded to dozens or hundreds, the company needed unified code standards, review mechanisms, stability requirements, and hiring methods. This is especially important for a payments company. A bug in ordinary software might mean a page temporarily doesn’t load; a payment system error could cause duplicate charges, accounting mistakes, merchant fund delays, or compliance risks. Greg later left Stripe and co-founded OpenAI. But his key early task at Stripe was helping the company transition from relying on a few excellent engineers to an organization that could continuously hire and manage engineering talent.

Claire Hughes Johnson: Giving a High-Growth Company a Management System

In 2014, Claire Hughes Johnson joined Stripe from Google. At the time, Stripe had over a hundred employees. Product and customer growth were fast, but it lacked a complete management system to support global expansion. She oversaw sales, operations, customer service, risk, HR, and company planning. In other words, she handled problems that came with product success: when customers multiplied, who served them? When teams grew, who was accountable? When entering more countries, how to manage risk and local operations? When different products competed for people and budget, how to set priorities? Her value wasn’t launching a specific product but helping Stripe build an organizational foundation to support continued expansion. This process wasn’t perfect either. Claire later publicly said she once had too many direct reports, reflecting that the company also experienced issues like excessive management span and unclear responsibility allocation during hypergrowth. This恰恰 shows Stripe’s organizational capabilities weren’t innate but were constantly tested and rebuilt as employees grew from over a hundred to thousands.

Will Gaybrick: Putting Finance, Product, and Capital Allocation Together

Will Gaybrick joined Stripe in 2015, initially as CFO. Later, his responsibilities gradually expanded from finance to product, technology, and business. He currently serves as Stripe’s President of Technology and Business. This role change illustrates Stripe’s later management logic. When the company had one core payment product, product and financial decisions could be relatively separate. But when Stripe simultaneously manages dozens of products and begins billion-dollar acquisitions, product choice itself becomes capital allocation. Stripe must constantly decide:

• Which capabilities to develop in-house.
• Which are better acquired.
• Which projects have no revenue yet but are worth upfront investment.
• Which products should be stopped or scaled back.
• How much resource to allocate to stablecoins, AI Agents, and token economics.

Will Gaybrick’s responsibilities span finance, product, and technology, letting Stripe judge "is this product worth building" and "how much capital should the company invest here" together. Stripe’s recent AI engineering adjustments, stablecoin investments, and serial acquisitions can be understood in this context.

David Singleton: Letting a Large Engineering Organization Still Deliver

In 2017, David Singleton joined Stripe from Google. At the time, Stripe already had nearly a thousand employees. Engineering management’s challenge was no longer just hiring great engineers but making many teams work simultaneously without decision and delivery speed continuously declining. As companies grow, a common situation emerges: projects require coordination across many departments, meetings and approvals multiply, engineers increase, but product progress slows. David helped establish engineering management systems suitable for larger scale, including underlying infrastructure, internal tools, engineering responsibility division, and project advancement mechanisms. Later, Stripe simultaneously maintained payments, billing, taxes, identity, card issuance, fund management, stablecoins, and developer tools. What was needed wasn’t just a strong engineering team but a system allowing multiple engineering organizations to operate in parallel. Stripe’s internal use of engineering Agents like Minions can be seen as a continuation of this path: the company hopes to use AI to reduce duplicate development, maintenance work, and coordination costs in large organizations. However, increased code and PR counts don’t automatically mean improved business efficiency. Ultimately, it depends on whether these tools shorten product delivery time, reduce maintenance costs, and translate into products customers are willing to pay for.

Mike Clayville, Eileen O'Mara, and Tyler Bryson: Moving from Developer Self-Serve to Enterprise Sales

Stripe’s initial growth largely came from developers. An engineer read the docs, integrated the API, and the company could become a Stripe customer. This worked well for startups. But when Stripe began serving large retailers, platforms, and multinationals, docs and self-serve alone weren’t enough.

Large clients need contract negotiation, system migration, local support, risk arrangements, custom pricing, and long-term account management. One sale and migration could take months or longer. Mike Clayville joined Stripe in 2020, helping build a revenue organization targeting large enterprises. Eileen O'Mara later helped expand this system, serving as CRO. Stripe stated that under her revenue leadership, annual payment volume nearly doubled to $1.9 trillion. In 2026, Eileen moved to Vice Chair, engaging more with key clients, partners, and public policy; Tyler Bryson became CRO, continuing global commercial growth.

This management change means Stripe ultimately operates two customer acquisition models simultaneously. One is developer and startup self-serve integration. Stripe enters when customer scale is small, waiting for some to become future large clients. The other is proactively pursuing already-mature large enterprises, providing migration, pricing, risk, and global operational support.

The first model helps Stripe win tomorrow’s enterprise clients; the second helps it win today’s grown enterprises. Will Gaybrick summarized this strategy as: win the startup, then win it again.

Looking back, Stripe’s core team changes basically correspond to each company phase:

Therefore, Stripe’s organizational evolution isn’t founders gradually exiting and handing the company to professional managers, nor is it two founders personally controlling all details.

It’s closer to this path: Founders personally do most work → Bring in different leaders as bottlenecks change → Build professional management → Founders continue setting direction and key product judgments.

Acquisitions add another layer of change to this structure. Bridge, Privy, Metronome, and OpenRouter aren’t just products added to Stripe; they bring new founders, engineering teams, customers, and industry knowledge. Stripe next needs to decide which teams should be fully integrated, which products should continue operating independently, and how to connect them to underlying systems like accounts, billing, payments, and risk.

So, today’s Stripe is no longer a startup reliant on two founders handling all problems. It’s more like an organization where founders set direction, professional management handles scaling, while continuously absorbing external startup teams and specialized capabilities.

Compressing Stripe’s 16 Years into a Timeline

Among them, Bridge acquisition completed February 2025, Metronome completed January 2026; OpenRouter is pending acquisition.

It roughly extends outward along a continuous line: Collection → Platform Splits → Subscriptions & In-person Payments → Taxes, Risk, Fund Management → Stablecoins & Wallets → AI Agents, Usage Billing, Model Routing.

Each expansion answers the same question: what infrastructure layer does an internet business lack to complete a transaction, manage a revenue stream, or launch a new business model?

Early Stripe solved "how to collect money." Later it solved "how to distribute, manage, and use that money." Entering the AI phase, it’s starting to handle "how to measure compute resources and how software transacts on behalf of people."

How to Understand Stripe’s $159 Billion Valuation?

In February 2026, Stripe organized a new employee stock transaction corresponding to a $159 billion valuation. This isn’t a daily-traded public market cap nor a traditional funding round post-money valuation. But it provides a reference: what price are participating investors willing to pay for Stripe shares? So, what is this valuation based on? Clearly not just the fee Stripe charges per card payment processed.

First, Stripe Occupies the Early Entry Point for Businesses Building Internet Operations

Many companies start using Stripe when still small. The initial integration decision might be made by one engineer. But as the company grows, customer data, payment records, subscription relationships, refund flows, risk rules, and financial systems gradually build on Stripe. This gives Stripe a special customer lifecycle: it can enter when the customer is tiny, then grow with the customer.

Companies like DoorDash, Shopify, and Instacart were startups early on. Stripe didn’t need to wait until they became large enterprises to compete for them from other payment companies.

This is also what Stripe calls "win the startup, then win it again."

First time: enter a startup via simple API and developer experience. Second time: when the customer grows into a large enterprise, retain them with global payments, Billing, Tax, Radar, and large-account service capabilities. However, the second doesn’t happen automatically. Startups grown up reassess payment costs, stability, regional coverage, and service levels, and gain stronger bargaining power. Stripe still competes with Adyen, PayPal, Checkout.com, and large enterprises’ own payment systems.

Second, Its Revenue Can Grow with Customer Business Scale

Stripe’s payment, billing, tax, identity verification, and fund management revenues relate to customers’ actual business activities. When customer transaction volume grows, subscription users increase, or they enter more countries, even without Stripe redoing a sale, revenue from the same customer may continue increasing. Ordinary SaaS companies typically need to add seats or raise subscription prices. Stripe can directly participate in customer business scale growth.

This is the appeal of infrastructure businesses: once inside a customer’s core business process, customer growth itself can become Stripe’s growth source.

Third, More Products Can Reuse the Same Underlying System

Payments, Connect, Billing, Tax, Radar, Identity, Treasury, and Issuing aren’t completely independent products. They can share accounts, ledgers, identity info, risk models, customer relationships, and banking and payment networks.

If this reuse truly works, each new product Stripe adds can gain new revenue from existing customers while increasing their migration cost. A customer using payments, subscriptions, taxes, and risk is clearly harder to leave than one only using payment APIs.

But this is also where Stripe must continuously prove itself. A growing product matrix doesn’t automatically create synergy. If products don’t truly share data, accounts, and operational flows, they could become a set of siloed businesses continually adding organizational cost.

Therefore, Stripe’s value isn’t just "how many products it has" but whether these products can be built on the same infrastructure and continuously used by the same customer.

Fourth, Banking Relationships, Regulatory Capabilities, and Customer Trust Are Hard to Replicate

Payments isn’t a business built on code alone. A new company, even if creating a simpler API, needs banking partnerships, card network relationships, licenses, compliance systems, risk teams, and dispute handling capabilities.

It also needs customers to trust funds can flow through this system long-term and stably. What Stripe accumulated over 16 years isn’t just software but financial institution relationships, historical transaction data, risk assessment capabilities, and customer trust. These assets aren’t like a front-end feature another engineering team can replicate in months.

Early Stripe used simple developer experience to open the market, but what truly formed its moat was the financial and operational systems hidden behind the simple interface.

Fifth, the Market Is Also Pricing Optionality for the Stablecoin and AI Era

Bridge, Privy, Metronome, and OpenRouter seem to belong to different fields, but together, they show a relatively continuous direction:

• Bridge handles stablecoin fund flows.
• Privy provides wallet and identity entry.
• Metronome handles complex usage billing.
• OpenRouter connects models, providers, and token consumption.

If future AI Agents can autonomously purchase software, call models, manage budgets, and complete payments, they need more than a payment button.

An Agent needs payment authorization, needs to know its spending limit, needs to procure among different models and software services, needs to handle fund flows across countries, currencies, and stablecoins, and needs to leave transaction records auditable, refundable, and traceable by the business.

Stripe hopes to cover multiple key links: accounts, wallets, payments, billing, risk, fund settlement, and model calling.

Therefore, the $159 billion valuation roughly contains two parts of value: one is Stripe’s already-formed global payment infrastructure; the other is the position it might occupy in the stablecoin and AI economy.

But the second part remains optionality for now. Stripe needs to prove these acquisitions can be truly integrated, not just a set of expensive, loosely related products. It also needs to prove AI Agents and stablecoins can generate sufficiently large real transaction volume, not just short-term tech industry concepts. It must further prove that after product boundaries expand, the company won’t again face organizational growth outpacing business growth.

So, this valuation prices both Stripe’s existing payment scale and提前 buys into its potential future markets.

Conclusion: Can Stripe Become the AWS of the Agent Era?

Looking back at Stripe’s 16 years, it started with two young founders simplifying payment integration with a few lines of code. But what truly determined how far Stripe could go wasn’t those lines of code themselves.

Early Stripe hid complex work like applying for merchant accounts, connecting payment gateways, storing payment info, and handling errors behind a simple API. Later, it hid platform splits, subscription billing, tax calculation, fraud detection, company formation, fund management, and cross-border payments inside the same system. Entering the stablecoin and AI Agent phase, it’s attempting to handle new complexities like wallets, fund flows, model calls, token measurement, and machine payments.

Superficially, Stripe’s products multiply. But what it wants to do hasn’t changed much: turn complexities internet businesses don’t want to handle themselves but must into infrastructure.

Can Stripe become the AWS of the Agent Era? In the past, developers didn’t need to buy servers, build data centers, or manage underlying compute resources themselves. They could call AWS services to create and scale an internet company. AWS turned complex compute infrastructure into on-demand, pay-as-you-go services.

If AI Agents truly enter commerce, they’ll similarly need economic infrastructure they can call upon anytime. An Agent not only needs to complete a task but may also need to buy data, call models, subscribe to software, pay suppliers, or distribute revenue to different participants. This creates new problems:

• How does an Agent get payment authorization?
• How much can it spend, and who sets the budget?
• How to calculate token costs from calling different models?
• Who refunds, disputes, and takes responsibility for an erroneous transaction?
• How do funds flow between fiat, stablecoins, bank accounts, and wallets?
• How does the business audit transactions automatically initiated by software?

Then, an Agent needs not just a payment button but a complete system of accounts, identity, wallets, billing, risk, taxes, and settlement.

Stripe’s recent moves can be reconnected along this direction:

• Payments and Connect handle receiving, distributing, and settling funds.
• Billing and Metronome handle subscriptions, usage, and complex pricing.
• Radar and Identity judge transaction risk and participant identity.
• Bridge, Privy handle stablecoins, wallets, and new funding networks.
• OpenRouter connects model providers and provides entry for model calls and token consumption.
• Agentic Commerce-related products attempt to let Agents discover products, get authorization, and complete transactions.

If these capabilities ultimately combine, what Stripe provides might no longer be just "how people pay online" but: how a software Agent gets a budget, buys services, calls models, completes settlement, and leaves auditable records of its economic actions.

This is Stripe’s potential to become Agent-era infrastructure. But it’s still far from "the AWS of the Agent Era."

One of AWS’s core values is providing relatively standardized compute resources that vast numbers of developers can freely combine. For Stripe to achieve a similar position, it must prove its payment, wallet, model routing, and billing systems can be truly combined, not just a set of products拼凑 together through acquisitions.

It also faces harder questions:

• First, Agent legal identity and payment authorization remain unclear. If an Agent makes a wrong purchase autonomously, does liability lie with the user, Agent developer, model provider, or payment platform?
• Second, will different model companies, banks, wallets, and payment networks let Stripe be the middle layer? If Stripe simultaneously participates in payments, billing, model routing, and fund settlement, customers may also worry it controls too many steps.
• Third, can Agent commerce form sufficiently large real transaction volume? Currently, many Agents still just assist humans with tasks, not truly having independent budgets or continuously purchasing services.
• Finally, can Stripe itself manage ever-expanding product and organizational boundaries? The closer it gets to a complete economic infrastructure, the more teams, regulatory relationships, and conflicts of interest it needs to coordinate internally.

So, "the AWS of the Agent Era" is more a direction needing validation now. Stripe’s advantage is it already has a payment entry point, enterprise customers, developer relationships, global funding networks, and risk infrastructure. It doesn’t need to build these from scratch and can gradually push new products to existing merchants.

Its risk also comes from here: the further product boundaries expand, the more complex the organization, the easier to lose the simple, clear product experience of early days.

Therefore, the most interesting future question about Stripe may no longer be just how much payment volume can still grow, but whether it can combine payments, stablecoins, billing, and model calling into a true economic infrastructure for machines.

If the answer is yes, Stripe’s ceiling is no longer just being a bigger payments company; it could become the default infrastructure layer Agents call upon when entering the real economy. If the answer is no, then Bridge, Privy, Metronome, and OpenRouter may just be a set of expensive but loosely connected acquisitions.

Ultimately, whether Stripe becomes the AWS of the Agent Era depends on whether it can again accomplish what it did 16 years ago:

Keep the极其 complex underlying problems of accounts, funds, billing, and liability to itself, leaving developers and Agents only a sufficiently simple, truly working interface.