作者：Yokiiiya，Stablehunter

Stripe宣布同意收购 OpenRouter 后，Stripe 在 AI 和 fintech 两个赛道都引发了很大的关注，Stripe 也是全球fintech领域少数估值超过千亿美元的独角兽之一。

我对 Stripe 的理解其实一直比较碎片化，我使用过他们的产品，关注过一些融资和收购信息，也写过他们在支付和AI Agent方面的变化，却从来没有按照时间线，系统了解过这家公司的商业模式、团队组织和资本路径。

最开始，Stripe 只是几行让开发者更容易接入支付的 API，16 年后，使用 Stripe 的企业一年已经能够处理 1.9 万亿美元的支付量，最新一次的估值也达到了 1,590 亿美元。

我想借着这篇文章，重新梳理 Stripe 的发展过程，理解它如何一步步扩展产品边界、重建团队，并利用资本为下一阶段争取时间。

（不过，这篇文章所能依赖的，仅限于 Stripe 、公司高管及外部机构已经公开的信息，公司内部真正发生过什么，管理层如何做出决策，又遇到过哪些没有对外披露的问题，我们并不知道。所以，这不可能是一份完整的公司历史，其中也难免存在信息缺失和视角局限。但把现有信息放回时间线上，至少能帮助我对 Stripe 如何从一家支付 API 公司成长到今天，形成一个更完整的认知。）

创办 Stripe 之前，两位创始人在做什么？

通常我们了解一家公司的时候，先看创始人的背景，Stripe 的两位创始人Patrick Collison和 John Collison 是一对兄弟，9196 他们的父亲 Denis 的背景是电子工程，母亲 Lily 是微生物学背景，父母都是各自家庭里的第一代大学生，父母辈有农场家庭背景。

WIRED 的早期报道里提到，他们小时候家里有过 9 台电脑，还每月花约 100 欧元买德国转发的卫星宽带。家里讨论的氛围也更多是技术和科学话题，还有公开资料提到，Patrick 8 岁上过大学的电脑课程，后来去了 MIT；John 后来在 Harvard 读书。这种从很早期开始的技术输入，解释了他们为什么能很快把「能运行起来」作为产品标准。

Stripe 不是他们的第一家公司，在做 Stripe 之前，兄弟俩在 2007 年做了电商卖家工具 Shuppa（后更名为 Auctomatic）。他们先没拿到爱尔兰当地投资，后来通过 Y Combinator 获得支持；2008 年 Auctomatic 以约 500 万美元出售。他们已经不是「第一次创业者」，而是有过一次真实退出和一轮更成熟的资本叙事。

Patrick 和 John 已经不是「第一次创业者」，他们知道如何把一个想法做成可以使用的产品，也经历过寻找客户、募集资金和出售公司的过程。出售 Auctomatic 获得的资金，还让他们在开始下一家公司时，不必完全依赖一笔融资才能生存。

因此，Stripe 的起点并不是两个毫无创业经验的大学生，突然决定进入支付行业。而是两名年轻的连续创业者，在第一次创业过程中遇到支付问题，又带着此前积累的经验、资金和人脉，开始解决一个他们认为仍然没有被解决好的问题。

这也构成了 Stripe 最早的起点：

技术家庭提供了早期环境，第一次创业把他们带进硅谷，而支付问题则成为第二次创业的入口。

Stripe 最早的银行合作是怎么建立的？

作为一家支付公司，最重要的基础之一其实是账户，代码可以由工程师自己写，但商户账户、资金通道和清算能力，最终都需要银行和支付机构提供。

两个没有银行和支付行业经验的年轻人，是如何做起一家支付公司的？坊间也有一些说法，认为两兄弟背后可能存在没有公开披露的金融资源或关键人物。但目前没有足够可靠的公开资料可以验证这些传闻，所以本文不对此作推测，也不把它纳入讨论。

我们只沿着现有公开信息，看看 Stripe 最早的银行合作究竟是怎样建立起来的。

早期的 Stripe，在这个问题上并不顺利，Patrick 后来在 Stanford 的一次课程中回忆，最开始，他们通过一个在聚会上认识的人，联系到美国中西部的一家支付公司，每当有用户注册 Stripe，Patrick 和 John 就会在这家公司的系统里，手工替用户再开一个账户，他们用这种方式操作了几十次。

从客户一侧看，Stripe 已经开始变得简单；但在 Stripe 内部，许多流程仍然需要两兄弟手工完成，这种方法可以用来验证产品，却无法支撑一家真正大规模运行的支付公司。

为了建立更稳定的合作关系，他们开始接触大型银行，其中就包括 Wells Fargo，但第一次见面并不顺利。按照 Patrick 后来的说法，Wells Fargo 当时非常明确地表示，没有兴趣与他们合作。Stripe 还没有获得大型金融机构的信任，也正是在这个阶段，Billy Alvarado 加入了公司。

Billy 出生在洪都拉斯首都 Tegucigalpa，父亲 18 岁时从银行的清洁工作做起，之后进入信贷审查岗位，后来又跟随上司加入 Citibank。父亲在银行里的职业发展，最终为 Billy 到美国读书提供了条件。

Billy 先在 Georgia Institute of Technology 学习工业工程，后来进入 Stanford GSB，并于 2000 年获得 MBA。加入 Stripe 之前，他曾在移动技术公司 SEVEN Networks 负责产品和工程，后来成为音乐服务 Lala 的联合创始人兼 COO。Lala 的业务需要与大型唱片公司谈版权和商业合作。这个过程同样涉及复杂的合同、利益分配和长期谈判，2009 年，Lala 被 Apple 收购，Billy 随后离开公司。

Stripe 的投资人 Geoff Ralston 是 Lala 的联合创始人之一，他知道 Billy 有处理大型机构合作的经验，也知道两兄弟在银行合作上陷入了僵局，于是建议他们把 Billy 招进来。但 Patrick 和 John 一开始并不理解，为什么一家技术公司需要招聘一个不写代码的人。

当时 Stripe 的前几名员工几乎全部是工程师。Patrick 后来回忆，Billy 是 Stripe 第 5 或第 6 名员工，也是第一位不以写代码为主要工作的人，两兄弟虽然认可 Billy 的能力，却仍然不清楚一个「非工程师」具体能为公司做什么。

Ralston 最后对他们说，先把人招进来，如果几个月后证明这个决定是错的，他愿意承担 Billy 的工资。Billy 加入 Stripe 大约两个月后，公司就与此前明确拒绝他们的 Wells Fargo 建立了合作关系。

Billy 真正补上的并不只是一个联系人，而是早期团队完全缺少的机构合作能力。

工程师习惯解释产品如何运行，银行关心的却是另一套问题：商户由谁审核，欺诈损失由谁承担，资金如何结算，出现争议后谁来处理，以及一家只有几个人的创业公司能否长期履行这些责任。

Billy 能够理解银行在担心什么，再把这些问题翻译成 Stripe 可以执行的流程和承诺。他也能把 Stripe 的技术产品，翻译成一家大型金融机构愿意签署的合作方案。他补上的不只是银行合作，还有公司运营。

Patrick 曾举过一个很有意思的例子，Billy 加入后问两兄弟，公司是如何发工资的，他们回答，把员工年薪除以 12，每个月直接把钱转过去，当时他们甚至没有正常处理工资代扣和税务等问题。这件小事很能说明早期 Stripe 的状态：它已经能够写出支付系统，却还没有完全学会如何经营一家真正的公司。

后来，Billy 成为 Stripe 的第一位业务负责人，并担任 Chief Business Officer 约十年，负责金融机构合作和国际扩张，也参与了 Stripe Atlas 等业务的建设。

Stripe 最早的银行合作不是来自两兄弟的支付家族背景，而是沿着另一条路径建立起来的：先做出产品，通过第一次创业和 Y Combinator 进入硅谷网络，再由投资人推荐关键人才，补上银行谈判、合规和公司运营能力。

这里面当然存在关系和资源，Geoff Ralston 愿意推荐 Billy，Billy 又有与大型机构谈判的经验，这些都不是代码能够替代的。但这些资源并不是两兄弟与生俱来的，而是在前一次创业、YC、投资人网络和关键招聘中逐渐积累起来的。

Stripe 的早期经历也说明，支付公司的门槛从来不只是写出一个好用的 API。代码可以让开发者愿意接入产品，但银行账户、风险承担和机构信用，才能让这些代码真正开始处理资金。

第一阶段：2010—2012，把支付的复杂性藏起来

银行合作解决了 Stripe 能不能做支付的问题。接下来，两兄弟还需要证明：开发者是否真的愿意把收款交给一家刚成立的公司。Stripe 最早解决的并不是一个新问题，而是一个长期存在、却一直没有被很好解决的问题。

当时，一名开发者如果想在网站里接受信用卡付款，通常需要先申请商户账户，再寻找支付网关，填写大量材料，等待审核，最后把不同机构提供的系统拼接起来。整个过程可能持续数周，技术文档和接口也很难使用。

Patrick 和 John 自己做 Auctomatic 时遇到过这些问题，身边的创业者也在反复抱怨同样的事情。他们发现，互联网创业的成本已经越来越低，开发者可以很快写出网站、部署服务器，却仍然很难让自己的产品开始收钱。这成为 Stripe 最初的切口。

2010 年，两兄弟开始编写后来成为 Stripe 的产品，Patrick 后来回忆，从第一行代码到产品正式公开发布，前后花了大约一年零十一个月，时间并不主要花在支付页面上，而是花在银行合作、风险控制以及支付系统背后的基础条件上。

Stripe 最早的产品承诺非常简单：开发者不需要分别寻找商户账户和支付网关，只要注册一个 Stripe 账户，接入几行 API，就可以在自己的产品里接受付款。

当时 Stripe 最有传播力的产品演示之一，就是用几行代码完成一次信用卡收款。后来「7 行代码接入支付」也成为 Stripe 早期最有代表性的产品叙事。

这几行代码并没有让支付本身变简单，银行连接、商户审核、欺诈判断、拒付处理和资金结算仍然存在，只是开发者不再需要分别面对它们。

Stripe 没有消灭支付的复杂性，而是把复杂性从客户一侧搬到了自己内部。

2011 年 9 月，Stripe 结束测试并正式对外发布，在美国市场，它采用了非常直接的定价方式：每笔成功交易收取 2.9% 加 0.30 美元，不收取开户费和月费。

这套定价看起来并没有创造新的收费模式，但它减少了开发者在使用产品之前需要理解和判断的事情。客户不需要先谈一份复杂合同，也不需要在业务还没有开始之前支付固定费用，只有真正收到钱以后，Stripe 才能获得收入。

从开发者进入公司

传统的企业软件通常从管理层、销售和采购部门进入公司，Stripe 走的是另一条路径：先让开发者愿意使用。

早期的 Stripe 没有成熟的销售团队，两兄弟会直接找到身边正在创业的人，帮助他们接入产品，再观察他们在哪个步骤停下来。John 后来提到，Stripe 最早的一批客户中有很多 Y Combinator 公司。一方面，这些公司本身就需要在线支付；另一方面，它们认识 Patrick 和 John，也更愿意相信 Stripe 不会在第二天突然消失。

这种信任很重要，开发者接入一个普通工具，最多承担迁移代码的成本；接入一家支付公司，却意味着把收入和资金流交给它处理。

因此，Stripe 早期的增长并不完全来自 API 足够简单，也来自两兄弟此前积累的创业者网络，产品降低了技术门槛，YC 网络则降低了第一批客户的信任门槛。

商业模式：客户增长，Stripe 才增长

Stripe 最初的收入模式很简单：客户每完成一笔交易，Stripe 就从中收取手续费。这种模式的好处是，Stripe 不需要在客户刚成立时就判断它有多大。即使是一家只有几个人的创业公司，也可以先接入 Stripe。客户没有交易，Stripe 几乎没有收入；客户的交易量增加，Stripe 的收入也随之增长。

这使 Stripe 与客户之间形成了一种比较特殊的关系。它可以很早进入一家公司的技术系统，却不需要在一开始收取很高的费用。作为交换，一旦客户成长起来，Stripe 就能够继续分享它的交易增长。

后来 Shopify、DoorDash 和 Instacart 等公司从创业公司成长为大型平台时，Stripe 也跟着它们一起扩大。这也是 Stripe 长期重视创业公司客户的原因：今天交易规模很小的客户，可能是未来最大的收入来源。

早期团队：所有人都在解决问题

这一时期的 Stripe 还没有清晰的部门边界，Patrick 主要负责产品和公司方向，John 同时参与产品、客户和商业事务。Greg Brockman 等早期工程师不仅要搭建支付系统，也要参与招聘、服务客户和建设内部工具。

Billy 加入之前，公司前几名成员几乎都是工程师；Billy 加入后，Stripe 才开始补上银行合作和公司运营能力。Stripe 的员工规模也扩张到约 17 人，在产品正式发布前后，团队才从最初的几个人逐渐发展到十几个人。

这种规模下，写代码、回答客户问题、与银行谈合作、招人和处理日常运营，往往由同一批人完成。

早期融资购买的不只是工程师

2011 年正式发布时，Stripe 已经获得约 200 万美元的早期投资，投资人包括 Sequoia、Peter Thiel、Elon Musk 和 Andreessen Horowitz 等。

这些投资人的价值不只是提供资金，对一家普通软件公司来说，融资主要可以用来开发产品和招聘员工；但对支付公司来说，资本还意味着它有时间建设银行合作、风控和合规系统，也能够向客户和金融机构证明，自己有机会长期存在。

Stripe 的产品越简单，它在内部承担的工作就越多。每增加一个客户，公司都要处理更多交易、欺诈、拒付和资金问题。这要求 Stripe 在收入规模还不大的时候，就提前投入大量基础设施。

因此，早期融资实际上为 Stripe 买了三样东西：建设产品的时间、金融机构的信任，以及承担支付风险的能力。

Connect：从一家公司的付款，进入整个平台的资金流

2012 年，Stripe 推出 Connect。最初的 Stripe 解决的是一家公司如何在线收款。Connect 解决的则是另一个更复杂的问题：如果一家公司本身就是平台，平台上还有大量卖家、司机、房东或者服务提供者，资金应该如何收取、拆分和支付？

Connect 让平台可以帮助自己的用户接受付款，并在平台、商家和服务提供者之间分配资金。这意味着 Stripe 服务的不再只是平台这一家公司，还开始进入平台背后成千上万个经营者的资金流。

从商业模式看，这一步非常关键。普通支付业务的增长主要来自单个客户自身的交易量；Connect 的增长则同时来自平台、平台上的商户，以及整个平台生态的扩张。如果一家平台增加一万名卖家，Stripe 就可能同时获得一万条新的支付关系。

Stripe 也由此获得了第一层平台杠杆。到 2012 年底，Stripe 已经完成了三个关键步骤：用 API 获得开发者，通过银行合作让支付真正成立，再利用 Connect 进入客户背后的商业网络。

它仍然是一家规模不大的创业公司，但已经不再只是帮助网站接受信用卡。Stripe 开始从一个支付工具，变成互联网公司可以直接调用的资金基础设施。

第二阶段：2013—2016，从支付工具变成创业基础设施

完成最初的产品验证后，Stripe 面临的下一个问题是：这套模式能否离开硅谷，进入更多国家，并服务更加复杂的公司？

对一家普通软件公司来说，进入新市场通常意味着翻译产品、建立销售团队和调整价格。支付公司进入一个新国家，却需要重新处理当地银行、支付方式、货币、监管、税务和风险规则。

Stripe 每进入一个市场，都要在内部重新连接一套金融系统，同时让开发者看到的 API 尽量保持一致。2013 年，Stripe 正式进入英国，开始把业务从美国扩展到欧洲。此后几年，它陆续进入更多国家，并增加对不同货币和支付方式的支持。

这一步改变了 Stripe 的价值。如果 Stripe 只服务美国市场，它提供的是一个更好用的支付接口；当它开始连接不同国家的银行和支付体系后，它提供的则是一种全球扩张能力。客户不需要每进入一个国家，就重新寻找当地支付机构、重新谈合作并重写一套系统。

Stripe 把这些差异吸收到自己的基础设施里，再通过相对统一的接口提供给客户。外部世界越复杂，Stripe 的价值就越高。

从收款工具进入更多业务环节

这一阶段，Stripe 开始不断扩大产品边界。最初，它只帮助企业接受付款；Connect 推出后，它开始处理平台和商户之间的资金分配。随着客户规模增加，Stripe 又逐渐进入移动支付、订阅、风控和企业全球化等环节。

2014 年 Apple Pay 发布后，Stripe 很快提供了接入支持。对开发者来说，他们不需要重新理解 Apple Pay 背后的支付流程，而是可以继续通过 Stripe 接入新的支付方式。

2015 年，Stripe 与 Visa 建立战略合作关系，Visa 同时成为 Stripe 的投资者。早期曾经需要努力获得银行信任的 Stripe，开始与全球最大的卡组织之一共同推动产品和市场扩张。

这不仅是一项商业合作，也说明 Stripe 在支付体系里的位置发生了变化。它不再只是连接银行和卡组织的创业公司，而开始成为传统金融网络进入互联网软件的一层接口。

2016 年，Stripe 又推出了两个对后续发展非常重要的产品：Atlas 和 Radar。

Atlas：在企业开始收钱之前进入

Stripe Atlas 帮助全球创业者注册美国公司、申请税号、开设银行账户，并完成创业初期需要处理的一系列基础工作。从短期收入看，Atlas 并不是 Stripe 最重要的产品。但它改变了 Stripe 接触客户的时间点。

过去，一家公司成立并准备开始收款之后，才会寻找支付工具；有了 Atlas，Stripe 可以在公司刚刚成立时就进入。创业者通过 Stripe 注册公司，接下来还可能需要银行账户、支付、订阅、税务、平台分账和资金管理。Stripe 不再等待一家企业成为客户，而是试图参与企业诞生的过程。

这种策略的回报不会立刻出现，大部分新成立的公司可能永远无法成长，能够带给 Stripe 的收入也很有限。但只要其中少数公司发展起来，Stripe 就可能从它们的第一笔交易开始，持续服务很多年。

这延续了 Stripe 早期服务创业公司的逻辑：先以较低成本进入，再与客户共同增长。

Radar：把交易数据变成新的产品

Radar 是 Stripe 推出的反欺诈产品，支付欺诈并不是新问题，但 Stripe 的优势在于，它可以同时观察大量企业和市场中的交易。当更多公司使用 Stripe 时，它就能看到更多正常付款、盗刷、拒付和欺诈模式；积累的数据越多，模型就越有可能识别新的风险。

识别能力提高后，Stripe 又可以把结果用于全部客户，减少欺诈损失，同时避免把正常交易错误拦截。这形成了一种数据循环：

更多客户带来更多交易，更多交易改善风险判断，更好的风险判断又让 Stripe 对新客户更有价值。

支付业务原本按照交易收费，Radar 则让 Stripe 开始把交易中积累的数据和风险能力单独做成产品。

到了这个阶段，Stripe 的商业模式已经出现了三个层次：

• 第一层是支付：帮助企业完成收款，并从交易中获得收入；
• 第二层是平台：通过 Connect 进入平台及其商户的资金流；
• 第三层是软件和数据：把风控、公司设立等能力变成可以重复提供的产品。

Stripe 仍然以支付为入口，但已经开始围绕一家互联网公司从成立到增长所需要的金融能力，搭建更大的产品体系。

组织开始跟不上产品增长

产品和市场扩大之后，早期几个人同时处理所有问题的方式开始失效。2014 年，Claire Hughes Johnson 加入 Stripe 担任 COO。当时 Stripe 大约有 160 名员工。Claire 此前在 Google 工作了十年，负责过在线销售、运营和自助广告业务。她加入 Stripe 后，逐渐管理业务运营、销售、市场、客户支持、风险、招聘、人力资源和办公空间等职能。Stripe 引入 Claire，并不是让两位创始人退出管理，而是为公司补上一套可以重复运行的组织系统。

Patrick 和 John 仍然负责使命、产品和长期方向，Claire 则开始把许多依靠创始人个人推动的事情，变成招聘流程、年度计划、销售机制、客户支持和管理制度。

这也是 Stripe 组织发展的第二个重要节点。Billy Alvarado 解决的是早期银行合作和商业运营问题；Claire 需要解决的，则是几百人乃至几千人的公司如何继续运行。

2015 年，Will Gaybrick 以 CFO 身份加入 Stripe。Will 此前在 Thrive Capital 工作，并参与过对 Stripe 的投资。他有数学、软件工程、法律和投资背景，并不是一名传统意义上只负责财务报表的 CFO。他的加入说明，Stripe 面临的问题已经不只是获得更多资金，而是如何在不断增加的产品、国家和业务机会之间分配资本。

Stripe 每进入一个市场、开发一种产品，都需要提前投入工程、合规、法务和运营资源。哪些项目值得长期建设，哪些产品应该暂缓，已经开始成为产品判断和资本配置共同决定的问题。

Will 后来从 CFO 转向产品和业务负责人，也可以从这一阶段找到原因：在 Stripe，财务、产品和基础设施投资从一开始就很难完全分开。

估值上升，资本开始为全球扩张买时间

2014 年，Stripe 完成约 8,000 万美元融资，估值达到约 17.5 亿美元，正式进入独角兽行列。同年晚些时候，它又完成约 7,000 万美元融资，估值升至约 35 亿美元。

2015 年，在与 Visa 建立战略合作的同时，Stripe 的估值达到约 50 亿美元。2016 年，公司再获得约 1.5 亿美元融资，投后估值约 92 亿美元。

三年时间里，Stripe 的估值从 17.5 亿美元增加到接近百亿美元。但资本市场购买的并不只是当时的支付收入。投资人实际上在押注三件事：第一，互联网交易规模会继续增长；第二，越来越多企业会把支付和金融能力交给软件平台；第三，Stripe 可以把不同国家和金融机构的复杂性，封装成一套开发者能够调用的基础设施。

这些融资也给了 Stripe 提前建设的能力，很多国家和产品在早期不会立刻产生足够收入，却需要公司先投入银行合作、牌照、合规、工程和本地团队。Stripe 用资本承担前期成本，再等待客户和交易规模逐渐增长。

这一阶段的人效，不适合只看收入

Stripe 没有公开足够完整的数据，让外界准确计算这一时期的收入、利润和人均产出。但从产品结构看，它已经开始形成另一种人效：同一套基础设施可以被大量客户重复使用。

一套 Connect 系统可以服务多个平台及其成千上万个商户；一套 Radar 模型可以从不同客户的交易中学习，再为所有客户提供风险判断；一项新的银行或支付方式接入，也可以同时服务进入这个市场的所有 Stripe 客户。

这是一种基础设施的复用效率。但它也有另一面。每进入一个国家、增加一种支付方式、服务一种新的商业模式，Stripe 内部都会增加合规、法务、运营和支持成本。

Stripe 对外提供的体验越简单，内部需要管理的复杂性往往越高。到 2016 年底，Stripe 已经不再只是一家提供支付 API 的公司。它开始覆盖企业设立、收款、平台分账、风险控制和全球扩张，并逐渐形成一个围绕互联网企业资金流展开的产品体系。

下一阶段的问题也随之出现：当产品越来越多、团队接近千人之后，Stripe 还能不能保持早期那种由工程师和创始人直接推动产品的速度？

第三阶段：2017—2019，从支付产品变成产品矩阵

到 2017 年，Stripe 面临的问题已经不再是「开发者愿不愿意使用」，而是客户长大之后，它能不能继续满足这些公司的需求。早期创业公司只需要解决收款问题，随着业务规模扩大，它们会开始面对订阅管理、发票、税务、财务报表、线下支付、跨境付款和资金周转等问题。

如果 Stripe 只提供支付，客户成长到一定阶段后，就需要寻找其他服务商，甚至重新建设自己的金融系统。Stripe 因此开始围绕客户的资金流，进入更多相邻环节。

Billing：从一次交易进入持续收入

2018 年，Stripe 推出新版 Billing，将原来的订阅功能扩展成更完整的经常性收入管理产品。一次性支付相对直接：客户购买商品，企业完成扣款。但订阅业务需要处理的问题更多，包括不同套餐、试用期、优惠券、按量计费、续费失败、升级降级和收入确认。其中很多问题并不是「能不能扣款」，而是「企业如何长期管理收入」。

Billing 把 Stripe 与客户的关系从一次交易延伸到整个订阅周期，企业不只是在发生付款时使用 Stripe，还会把产品定价、客户状态和收入规则放进 Stripe 的系统。

这也改变了 Stripe 的收费逻辑，支付收入取决于交易是否发生；Billing 等软件产品则可以围绕订阅规模、账单数量和功能使用收费。Stripe 开始从单纯的交易抽成，逐渐增加软件服务收入。

Terminal：从线上进入线下

同一年，Stripe 推出 Terminal，将业务从线上支付扩展到线下。传统支付行业通常把线上和线下看成两套系统，企业在线上使用一个支付服务商，在门店使用另一套收银和硬件系统，最后还需要自己整合订单、客户和财务数据。

Terminal 试图把这两部分连接起来，企业可以使用 Stripe 提供的读卡设备和软件接口处理线下付款，再把线上与线下交易放进同一套系统中管理。

这一步对 Stripe 很重要。它最初的优势来自互联网原生企业，但随着这些客户开设门店、进入现实世界，Stripe 也需要跟着它们走到线下。

Stripe 不是先去争夺传统商户，再要求它们更换整套系统，而是继续沿着现有客户的增长路径扩张产品。

Issuing、Capital 和 Sigma：进入资金管理

Stripe 在这一时期还陆续推出或扩大了 Sigma、Issuing 和 Capital 等产品。Sigma 帮助企业直接查询和分析 Stripe 中的交易数据；Issuing 让平台和企业发行实体卡或虚拟卡；Capital 则根据企业在 Stripe 上的经营和交易数据，为符合条件的客户提供融资。

这些产品看起来分别属于数据、发卡和贷款，但底层逻辑相似：Stripe 已经掌握客户的支付和经营数据，因此可以继续提供围绕资金管理的服务。

以 Capital 为例，传统贷款机构需要企业提交财务材料，再判断它是否有还款能力。Stripe 已经能够看到部分客户的收入规模、交易变化、退款和经营稳定性，可以利用这些数据完成风险判断，并通过未来交易收入回收资金。

支付由此成为进入更多金融服务的入口。Stripe 不需要一开始就向客户销售贷款或发卡产品。它先帮助企业处理交易，在积累足够的数据和信任后，再提供更多服务。

到了 2019 年，Stripe 的产品已经可以大致分成几个层次：

• Payments 和 Terminal 负责接受付款；
• Connect 负责平台内的账户、收款和资金分配；
• Billing 负责订阅和经常性收入；
• Radar 负责欺诈和风险；
• Sigma 负责数据分析；
• Issuing 和 Capital 开始进入发卡与融资。

Stripe 已经不再是一个单一支付产品，而是一组围绕企业资金流展开的金融工具。

商业模式：同一客户购买更多产品

产品矩阵形成后，Stripe 的增长方式也发生了变化。早期增长主要来自两个来源：更多客户接入，以及现有客户产生更多交易。现在又增加了第三个来源：同一个客户使用更多 Stripe 产品。

一家创业公司最初可能只使用 Payments，随着业务发展，它可能使用 Billing 管理订阅，通过 Radar 控制欺诈，使用 Connect 管理平台商户，再通过 Issuing 发卡或者使用 Capital 获得融资。

每增加一个产品，Stripe 与客户之间的关系都会更深，客户迁移到其他服务商的难度也会提高。这并不完全是传统意义上的产品捆绑，Stripe 的优势在于，这些产品共享相同的账户、交易数据、身份信息和资金系统。客户不需要为每一种金融能力重新搭建一套基础设施。

从客户角度看，它购买的是不同产品；从 Stripe 内部看，这些产品建立在同一套金融数据和资金网络上。

这也是 Stripe 从支付公司转向金融基础设施平台的关键一步。

客户结构开始变化

随着产品增多，Stripe 服务的客户也从早期创业公司扩展到更成熟的平台和大型企业。创业公司的决策通常很快，开发者试用产品，确认能够运行，就可能直接接入。大型企业的采购过程则完全不同，它们会关注系统稳定性、数据安全、全球覆盖、成本、合规和服务能力，还需要经过财务、法务、风控和采购等多个部门。

Stripe 早期依靠开发者口碑形成的自助增长模式，已经不足以完成所有大型客户的销售。这意味着 Stripe 不仅要继续服务工程师，还要学会与企业管理层、财务部门和采购团队沟通。它需要销售团队、解决方案工程师、客户成功和更成熟的支持体系。产品正在从开发者工具变成企业基础设施，组织也必须跟着改变。

David Singleton：工程组织需要新的管理方式

2017 年底，Stripe 已经接近 1,000 名员工，并从 Google 聘请 David Singleton 领导工程团队。David 此前负责 Android Wear，并参与管理大型工程组织。他加入 Stripe 时，公司已经拥有多个产品，工程团队也不再是所有人都能了解全部代码和客户问题的小团队。

早期 Stripe 可以依靠少数能力很强的工程师快速做出决定，团队接近千人后，同样的方式会开始产生问题。

不同产品可能重复建设相似的账户、权限和资金能力；一个底层系统的变化可能同时影响 Payments、Connect 和 Billing；工程师需要在产品速度、系统稳定性和金融风险之间做出平衡。

David 需要解决的，不只是如何招聘更多工程师，而是如何把 Stripe 的工程文化转化成可以在更大组织中运行的机制。

这也是 Stripe 组织史上的又一次能力补充：

• Billy 补上银行和机构合作；
• Claire 建立运营和管理系统；
• Will 把资本配置与产品选择连接起来；
• David 开始管理接近千人规模的工程组织。

创始人依然掌握公司方向，但越来越多专业负责人开始承担过去由创始人和早期员工直接处理的工作。

产品越多，协调成本越高

产品矩阵提高了单个客户的价值，也带来了新的组织问题。当 Stripe 只有支付产品时，公司可以围绕一个共同目标工作：让在线付款更容易。随着 Billing、Terminal、Issuing、Capital 和 Sigma 出现，不同团队开始拥有各自的客户、指标和产品路线。

这些产品又不能完全独立。Billing 需要调用 Payments 完成扣款；Connect 需要依赖账户和合规系统；Capital 需要使用交易数据判断风险；Radar 的判断又可能影响所有支付产品。

Stripe 不能简单地把每个产品拆成完全独立的公司，也不能让所有决定都回到创始人手里。它需要在两件事之间保持平衡：一方面让产品团队拥有足够自主权，另一方面保证底层资金、风险和数据系统仍然统一。

产品复用带来了更高的人效，产品之间的依赖则增加了协调成本。这两股力量在 Stripe 内部同时增长。

资本市场开始按照平台估值

2018 年，Stripe 完成约 2.45 亿美元融资，公司估值达到约 200 亿美元。2019 年初，Stripe 的估值进一步上升到约 225 亿美元。同年 9 月，公司又完成约 2.5 亿美元融资，估值达到约 350 亿美元。

两年时间里，Stripe 的估值接近翻倍。如果 Stripe 仍然只是一家在线支付处理公司，这样的估值很难仅用当时的收入解释。资本市场购买的，是它逐渐形成的产品矩阵以及在互联网企业资金流中的位置。

Payments 带来交易和客户，Connect 扩大账户网络，Billing 和 Radar 增加软件收入，Issuing 与 Capital 则让 Stripe 进入更多金融服务。

每一项产品既可能独立收费，又可以提高其他产品的使用价值。Stripe 开始拥有平台型公司的特征。但这条路线也意味着更高的成本，公司需要同时建设更多产品、进入更多国家，并招聘销售、风控、法务、合规和工程人员，融资仍然在为未来增长提前买单。

到 2019 年底，Stripe 已经从一家以开发者体验著称的支付公司，扩展为多产品金融基础设施平台。接下来发生的口罩，让互联网交易在很短时间内大幅增长，也把 Stripe 原本需要几年完成的扩张压缩到了两三年。客户、交易和员工数量一起快速增加，最终让公司进入成立以来最剧烈的一次组织扩张与纠偏。

第四阶段：2020—2023，😷超速、组织过冲与主动纠偏

2020 年，😷把大量商业活动突然推向线上，原本需要几年完成的数字化进程，被压缩到了几个月。餐厅开始接受线上订单，零售商搭建电商网站，线下服务转向订阅和远程交付，越来越多企业需要在互联网上完成支付。

对于 Stripe 来说，这既是一次巨大的市场机会，也是一次超出原有计划的压力测试。客户数量和交易量快速增加，原有客户也在短时间内获得了更多线上收入。Stripe 不仅要处理更大的支付规模，还要帮助企业进入新的国家、增加支付方式，并解决订阅、税务、风控和资金管理问题。

Stripe 判断，这种变化并不只是疫情期间的临时现象，而是互联网经济进入了一个新的增长阶段，公司因此开始加速扩张。

员工从 2,800 人增加到接近 8,000 人

2020 年 8 月，Stripe 在官方公告中披露，公司当时拥有约 2,800 名员工，分布在 16 个办公室。此后两年，Stripe 大量招聘工程、产品、销售、支持、风控、合规和运营人员。到 2022 年，员工数量一度接近 8,000 人，约为 2020 年的近三倍。

员工快速增加，与 Stripe 同期扩大的产品范围有关。2020 年前后，Stripe 推出或扩展了 Treasury、Climate 等产品；2021 年又密集推出 Tax、Identity、Payment Links 和 Revenue Recognition，并完成多笔收购；2022 年继续增加 Apps、Data Pipeline 和 Financial Connections。

Stripe 不再只是在支付业务上增加功能，而是在同时建设一套更完整的互联网商业基础设施。每增加一个产品，都需要工程、产品、合规、销售和支持团队；每进入一个国家，又需要处理当地银行、牌照、税务和支付方式。

😷期间快速上升的交易量，让这些投入看起来是合理的。如果互联网经济继续按照当时的速度增长，Stripe 就需要提前招人，为未来几年的客户和产品需求做好准备，问题是，增长并没有一直延续，这是很多创业公司遇到的通病。

产品扩张速度开始超过组织消化能力

人员增加并不一定立刻提高产出。早期团队规模较小时，一名工程师可以了解大量产品和底层系统，许多决定可以通过直接沟通完成。当公司接近 8,000 人、同时经营几十项产品之后，同样的管理方式会产生越来越高的协调成本。

一个新产品可能需要依赖账户、支付、风控、数据、身份和合规等多个底层系统。项目参与者越来越多，审批路径越来越长，团队之间的职责边界也开始变得模糊。

公司看起来拥有更多资源，但每增加一个团队，也可能增加新的会议、汇报和依赖关系。这正是基础设施公司的一个悖论：外部产品越统一，内部组织越容易变得复杂。

客户希望通过一套 Stripe 账户使用支付、订阅、税务和资金管理，但 Stripe 内部需要让多个团队共享相同的数据、风险和资金系统。任何底层改动，都可能同时影响多个产品和国家。

当员工数量快速增加时，新员工还需要被培训、理解系统和建立合作关系。招聘速度如果超过组织吸收新人的能力，人数增长反而可能降低整体效率。

2022 年，增长假设发生变化

2022 年，全球经济环境开始转变，😷期间迅速增长的线上消费逐渐回落，通货膨胀和利率上升影响企业融资与支出，科技行业的增长预期也开始下降。

Stripe 此前按照互联网经济会继续高速扩张的判断，提前增加了大量人员和成本。当外部增长放缓之后，公司原有的组织规模就显得过重。

2022 年 11 月，Patrick 和 John 向员工宣布裁员约 14%，在公开信中，两兄弟承认，他们对 2022 年和 2023 年互联网经济的增长过于乐观，也低估了经济放缓的可能性和影响。公司运营成本增长得太快，组织也变得没有以前高效。

裁员后，Stripe 的员工数量回到当年 2 月接近 7,000 人的水平，这封信值得注意的地方，是两位创始人没有把问题完全归因于宏观经济。他们明确承认，公司做出了错误判断，并且对这个结果负有责任。

对于一家创始人仍然掌权的公司来说，这也是创始人控制的另一面：创始人可以坚持长期投资，也必须承担扩张过快带来的组织后果。

裁员不是简单地把人数减回去

如果只看员工数量，Stripe 似乎只是把😷期间多招的人裁掉一部分，但组织很难通过一次裁员回到原来的状态。两年间，公司已经增加了大量产品和管理层级，即使人数减少，产品之间的依赖、跨团队协调和全球运营复杂度仍然存在。

Stripe 接下来需要解决的，不只是「少花多少钱」，而是重新判断哪些产品值得继续投入，哪些团队应该合并，哪些决策可以由更小的团队完成。

公司开始重新强调几件事：控制成本、减少协调、提高执行速度，并让团队更加接近客户和实际结果。

从这个角度看，2022 年的裁员不是一个单独事件，而是 Stripe 组织设计的一次主动纠偏。早期 Stripe 的效率来自人数少、目标单一；疫情后的 Stripe 必须寻找另一种效率：在产品和国家数量都无法退回原点的情况下，让一个复杂组织重新恢复行动速度。

管理层也在重新分工

Stripe 的管理层结构在这一阶段发生了变化，Claire Hughes Johnson 于 2021 年卸任 COO 的日常管理职务，转为 Corporate Officer 和顾问。在她任职期间，Stripe 从不到 200 人发展到数千人，并建立了销售、运营、支持、风险和人力资源等主要职能。

Claire 离开日常运营后，她原来承担的职责没有再集中交给一位新的 COO，而是逐渐拆分给不同的专业负责人。2020 年，Stripe 从通用汽车聘请 Dhivya Suryadevara 担任 CFO；同年又聘请前 AWS 全球商业销售负责人 Mike Clayville，建设面向大型企业的全球销售体系。

这说明 Stripe 的组织已经进入另一个阶段。公司不再需要一位 COO 从头搭建所有职能，而是需要财务、工程、销售、风险和国际业务负责人，分别管理已经具有相当规模的专业组织。

创始人仍然位于中心，但围绕创始人的管理结构变得更加专业化，也更加分散。

融资从增长资本变成员工流动性

😷期间，Stripe 的估值也经历了快速上升和明显回调。2020 年，Stripe 完成约 6 亿美元融资，估值约 360 亿美元。2021 年，公司再次融资约 6 亿美元，估值达到 950 亿美元，一度成为全球估值最高的未上市公司之一。

当时资本市场对互联网公司的估值普遍较高。Stripe 的交易增长、产品矩阵和全球扩张，使投资人相信它可能成为互联网经济的核心基础设施。

但到了 2023 年，Stripe 新一轮融资对应的估值下降到 500 亿美元，接近 2021 年的一半。表面上看，这是一次明显的估值下跌，但这轮融资的性质与早期融资已经不同。Stripe 表示，公司并不需要通过这笔资金维持日常经营，约 65 亿美元融资主要用于为员工提供股份流动性，并处理与员工股权相关的税务义务。

早期融资主要是让 Stripe 招人、开发产品和进入新市场；到了这一阶段，资本开始承担另一项功能：让持有多年股份的现任和离职员工获得退出机会。由于 Stripe 长期没有上市，员工手中的股份缺少公开交易市场。如果公司不能提供流动性，股权激励的实际价值会下降，也会影响招聘和员工留任。

因此，2023 年的融资不能简单理解成「Stripe 缺钱了」，它更像是 Stripe 在继续保持私有状态的同时，用融资安排解决一部分原本需要通过上市解决的问题。

怎么看这一阶段的人效？

2022 年，Stripe 处理的支付量约为 8,170 亿美元，如果按照裁员后接近 7,000 名员工粗略计算，相当于每名员工一年支撑约 1.17 亿美元的支付量。这个数字不能代表 Stripe 的人均收入或利润，支付量中的绝大部分属于商户，Stripe 只从中获得一部分费用，但它可以作为一个基础设施规模指标，观察每名员工背后支撑了多少资金流。

真正的问题是，2020 年至 2022 年期间，员工数量增长的速度一度快于支付规模和组织效率的提升。Stripe 在裁员信中承认，协调成本和运营低效已经开始进入公司。说明在接近 8,000 人的高点，增加员工不再自动带来同等比例的产出。

2023 年以后，Stripe 没有重新回到疫情时期的招聘速度，但支付规模继续增长。员工人数相对稳定，交易量和产品使用量却继续提高，人效才开始重新出现杠杆。

这一阶段给 Stripe 留下的教训并不是「大公司不应该招人」，而是：基础设施可以复用，组织复杂度却不会自动复用。

系统多处理一笔交易的边际成本可能很低，但组织每增加一个团队，都会带来新的沟通、管理和决策成本。到 2023 年底，Stripe 已经完成了一次从高速扩张到组织纠偏的转向，它没有放弃多产品和全球化路线，而是开始尝试用更克制的人员增长，支撑更大的交易规模。

这也为下一阶段埋下了伏笔：当内部增长受到约束之后，Stripe 开始更多通过收购获得已经成熟的团队和基础设施，把产品边界进一步扩展到稳定币、钱包、用量计费和 AI 模型路由。

第五阶段：2024—2026，从支付基础设施走向「可编程资金系统」

经历 2022 年的裁员和组织纠偏后，Stripe 没有停止扩展产品边界，不同的是，Stripe 不再主要依靠大规模招聘，从内部一点点建设所有新能力。它开始更频繁地通过收购，把已经成熟的团队、产品和基础设施直接并入自己的系统。

从 2024 年到 2026 年，Stripe 先后收购或宣布收购 Bridge、Privy、Metronome 和OpenRouter。这几家公司看起来分别属于稳定币、钱包、用量计费和 AI 模型路由，但放在一起看，它们并不是互不相关的投资。

它们共同指向一条新的产品路线：

Stripe 想管理的不只是一次支付，而是企业如何获得账户、持有资金、计算使用量、设定价格，并在传统货币、稳定币和 AI token 之间完成价值交换。

交易量继续增长，但人数没有回到😷时期的速度

2024 年，Stripe 上的企业处理了约 1.4 万亿美元支付量，比 2023 年增长约 38%。2025 年，这一数字进一步增加到 1.9 万亿美元，同比增长 34%，相当于全球 GDP 的约 1.6%。

与此同时，Stripe 官方招聘页面给出的员工规模仍然是 8,000 多人，与 2022 年裁员后的接近 7,000 人相比，人数重新开始增长，但增长速度明显低于支付量。

如果暂时按照 8,000 名员工粗略计算，2025 年每名员工支撑的支付量约为 2.38 亿美元。由于实际员工人数高于 8,000 人，真实数字会略低一些。作为对比，2022 年按照接近 7,000 名员工计算，每名员工支撑的支付量约为 1.17 亿美元，也就是说，在人数没有成倍增加的情况下，Stripe 每名员工背后支撑的交易规模，在三年左右接近翻倍。裁员后的 Stripe 重新获得了基础设施规模杠杆：交易量增长得比员工数量更快。

从自己建设，转向收购专业基础设施

早期 Stripe 倾向于自己开发产品，Payments、Connect、Billing、Radar、Atlas 和 Terminal，基本都是在公司内部逐步建设起来的。但当 Stripe 进入稳定币和 AI 基础设施后，完全从头建设所有能力的成本变得越来越高。

稳定币需要区块链、托管、合规和跨境结算能力；钱包需要管理身份、密钥和授权；用量计费需要实时处理海量事件；模型路由则需要连接不同 AI 模型，并持续比较价格、速度和质量。

这些领域各自都可能形成一家独立公司，Stripe 如果从零开始建设，不仅需要重新组建团队，还要等待产品、客户和行业经验逐渐成熟。收购则可以把这段时间压缩掉。

因此，Stripe 近几年的收购路线，不只是购买收入，也是在购买进入下一阶段所需要的时间。

Bridge：把稳定币变成资金通道

2024 年 10 月，Stripe 宣布收购稳定币基础设施公司 Bridge，公开交易金额约为 11 亿美元。交易于 2025 年 2 月完成。Bridge 帮助企业在传统银行系统与稳定币之间转移资金，也提供稳定币发行、储存和跨境支付能力。

对普通企业来说，稳定币真正困难的地方并不是在区块链上发送一笔 token，而是如何完成前后的连接：客户如何把法币换成稳定币，稳定币由谁托管，如何满足合规要求，最后又如何换回当地货币。

Bridge 处理的正是这些环节，收购完成后，Stripe 可以把稳定币能力放进自己已有的支付、账户和资金管理产品中。客户不需要理解底层使用哪条链、哪种稳定币或哪家托管机构，只需要选择用什么货币收款、持有和付款。

这与 Stripe 最早处理信用卡支付的逻辑非常相似，当年，Stripe 把商户账户、支付网关和银行连接隐藏在 API 后面；现在，它开始尝试把区块链、稳定币和跨境结算隐藏在同一套基础设施后面。

Privy：账户之外，还需要身份和钱包

2025 年，Stripe 宣布收购加密钱包基础设施公司 Privy，Privy 帮助应用为用户创建和管理钱包。用户可以使用邮箱、社交账户等方式登录，而不需要一开始就理解助记词、私钥和链上操作。如果 Bridge 解决的是资金如何在法币和稳定币之间移动，Privy 解决的则是：这些资金属于谁，由谁授权，又放在哪里，这对 Stripe 很重要。

传统互联网支付围绕银行卡和银行账户建立身份关系；在稳定币和 AI Agent 场景中，钱包可能成为新的账户载体，企业、个人和软件 Agent 都可能通过钱包持有资金并完成交易。

Stripe 如果只提供稳定币通道，却没有钱包和授权能力，就仍然缺少资金系统中的一个关键入口。Bridge 加上 Privy，使 Stripe 开始同时具备资金通道和账户载体，它不再只是在现有银行账户之间移动资金，也开始参与新的数字账户体系。

Metronome：AI 产品需要新的计费方式

2026 年 1 月，Stripe 完成对用量计费公司 Metronome 的收购，传统软件通常按月或按年收费。AI 产品的成本却更像云计算：每次模型调用都会消耗 token、GPU 和其他计算资源，不同模型和任务的成本也会变化。如果一家 AI 公司仍然只收取固定订阅费，就可能出现两个问题，使用较少的客户补贴使用较多的客户；模型成本发生变化时，产品价格又无法及时调整。企业因此需要按照 token、调用次数、处理时间或者实际结果进行计费。

Metronome 的核心能力，是记录这些复杂的产品使用数据，再将其转化成可以结算的账单。Stripe 原本已经拥有 Billing，但收购 Metronome 后，它获得了更成熟的实时用量计费能力，这样一来，Stripe 不只负责最后收钱，也开始参与「这笔钱应该如何计算」。这让 Stripe 在 AI 经济里的位置向前移动了一步：从完成付款，进入定义用量、计算价格和生成账单。

OpenRouter：从计算价格进入分配算力

2026 年 8 月 19 日，Stripe 宣布已同意收购 AI 模型路由平台 OpenRoute，这可能成为 Stripe 成立以来规模最大的一笔收购。

OpenRouter 为开发者提供一个统一接口，让他们可以使用来自 80 多家提供商的 400 多个 AI 模型，企业不需要分别接入不同模型，而是可以根据任务、价格、速度和稳定性，选择或自动路由到更合适的模型。

OpenRouter 与 Stripe 的产品逻辑有很强的相似性，Stripe 把不同国家、银行、卡组织和支付方式连接到一个相对统一的接口；OpenRouter 则把不同模型公司和推理服务连接到一个统一接口。

一个路由资金，一个路由算力。

更重要的是，OpenRouter 处理的不是一个纯技术问题，模型选择会直接影响 AI 产品的成本和利润。不同模型的价格频繁变化，同一个任务也可能在质量、速度和成本之间产生不同取舍。

收购 Metronome 之后，Stripe 可以帮助企业记录使用量并生成账单；如果 OpenRouter 交易完成，Stripe 还可以进一步参与模型选择和 token 消耗。

两笔收购连起来，形成了一条更完整的链路：选择模型 → 消耗 token → 记录用量 → 计算价格 → 向客户收费 → 完成资金结算。

Patrick 在收购公告中把 token 称为 AI 企业的「核心货币」，这里的「货币」并不是说 token 等同于美元，而是说，对于 AI 公司而言，token 已经成为一种需要被计量、分配和优化的核心生产资源。

Stripe 想做的，也不只是帮助企业购买 token，它希望同时管理 AI 企业的收入端与成本端：一边帮助企业定价和收款，一边帮助它们选择模型并控制计算成本。

四笔收购，拼出两条管道

把 Bridge、Privy、Metronome 和 OpenRouter 放在一起，可以看到 Stripe 正在建设两条相互连接的管道。

第一条是资金管道：账户或钱包 → 收款 → 持有资金 → 跨境转移 → 付款与结算。Bridge 和 Privy 补充了稳定币、钱包与身份能力，Stripe 原有的 Payments、Connect、Treasury 和 Issuing 则负责传统支付、账户、分账和发卡。

第二条是智能管道：选择模型 → 调用模型 → 计量 token → 计算成本 → 生成账单。OpenRouter 负责模型接入和路由，Metronome 与 Stripe Billing 负责使用量和计费，Stripe Payments 最后负责完成付款。

过去，Stripe 的主要产品边界是钱如何移动；现在，它开始同时处理智能如何被调用、计量和定价。

Token 不是美元，但正在成为新的计价单位

Stripe 和 OpenRouter 在收购公告中反复使用了一个说法：token 正在成为 AI 企业的「核心货币」。

模型 token 并不是法律意义上的货币，也不能像美元一样直接完成支付，它本质上仍然是衡量模型输入和输出使用量的一种计算单位。

但对于 AI 公司来说，token 已经具备了类似经营计价单位的作用，一家 AI 产品每服务一名客户，背后都可能消耗不同数量的 token，使用哪个模型、完成什么任务、响应多长、推理多少次，都会影响成本。

因此，AI 企业需要同时回答几个问题：

• 这次任务消耗了多少 token？
• 这些 token 对应多少模型成本？
• 应该向客户收取固定订阅费，还是按照实际使用量收费？
• 不同模型的价格发生变化后，产品应该怎样调整路由和定价？
• 客户付款后，资金如何在平台、模型提供商和其他服务商之间结算？

OpenRouter 负责模型选择和 token 路由，Metronome 负责记录使用量，Stripe Billing 负责生成账单，Payments 和稳定币基础设施则负责最后的资金结算。从这个角度看，Stripe 收购 OpenRouter 并不是把模型 token 当成一种新的美元，而是开始管理一种新的经济活动单位。

过去，Stripe 主要处理的是货币交易：一件商品卖多少钱，客户如何付款，商户如何收到资金。现在，Stripe 开始进一步处理交易发生之前的计算过程：一次 AI 服务消耗了多少资源，这些资源应该如何定价，又应该由谁承担成本。

与此同时，稳定币解决的是另一类问题，模型 token 是计算和使用量单位；稳定币则是真正用于付款和结算的数字货币。两者不能混为一谈，但可能会在 AI Agent 场景中连接起来。

未来，一个软件 Agent 可能自动选择模型、调用服务、消耗 token，再根据预先设定的权限使用稳定币或者传统支付方式完成付款。

整条链路可能变成：

Agent 发起任务 → OpenRouter 选择模型 → 模型产生 token 消耗 → Metronome 记录用量 → Stripe 计算账单 → 使用银行卡、银行账户或稳定币结算。

这才是 Stripe 同时布局 AI token 和稳定币的原因。它并不是简单押注两种热门技术，而是在判断：未来越来越多的经济活动会由软件自动发起，计算资源会被实时计量，付款也会从一次人工确认，变成由权限和规则控制的持续过程。Stripe 想把这套过程连接起来。

过去，它让一家互联网公司不用自己处理银行、卡组织和支付网关；未来，它希望让一家 AI 公司不用自己处理模型路由、token 计量、动态定价和全球结算。

如果这条路线成立，Stripe 的产品边界将再次发生变化：它管理的不再只是钱如何移动，还包括一次智能服务如何被生产、计量、定价和付款。

组织：从建设职能，变成整合专业团队

收购带来的不只是产品，也包括已经合作多年的专业团队。Bridge 的团队理解稳定币、合规和跨境资金流；Privy 的团队理解钱包、身份和授权；Metronome 的团队理解复杂用量计费；OpenRouter 的团队则长期处理模型接入、价格变化和路由选择。

这些能力很难通过短期招聘迅速复制，但收购也带来新的组织问题：这些团队应该保持多大独立性，底层系统如何与 Stripe 连接，原有产品和新产品之间由谁负责，以及如何避免大公司流程拖慢被收购团队。

Stripe 需要在整合与独立之间找到平衡，如果整合不足，收购来的产品只是几座彼此分离的孤岛；如果整合过度，又可能破坏团队原来的速度和产品判断。

这使 Stripe 当前的组织能力，与早期已经很不相同。早期团队的核心任务是自己把产品做出来；现在，管理层还需要判断应该自己建设什么、收购什么，以及如何把外部团队变成同一套基础设施的一部分。

AI 也在重写 Stripe 自己的组织

Stripe 对 AI 的判断，并不只体现在收购 OpenRouter 和 Metronome，AI 也开始改变 Stripe 自己开发产品和组织团队的方式。

2026 年 8 月，Will Gaybrick 在与 a16z 合伙人 David George 的访谈中，介绍了 Stripe 内部使用 AI 的一些情况。Stripe 内部开发了一套名为 Minions 的编程工具，工程师向它描述需要完成的任务后，Minions 可以独立编写代码、运行测试并提交 pull request，再由工程师进行检查。

根据 Gaybrick 在访谈中披露的数据，Minions 每周生成的 pull request 数量已经从年初约 1,200 个增加到约 7,000 个。在最近的一周里，AI 生成的代码变更约占 Stripe 全部 pull request 的 30%。

Stripe 还开发了内部知识工具 Kai，用来帮助员工查询公司内部的产品、政策和运营信息。Gaybrick 表示，这套工具已经被公司大部分员工使用，也提高了销售团队查找信息和处理客户问题的速度。这些数字来自 Stripe 管理层自己的公开表述，不能直接等同于整体生产力提高了 30%，AI 提交的代码仍然需要审核，不同 pull request 的复杂度也完全不同。

但它至少说明，AI 在 Stripe 内部已经不只是一个辅助聊天工具，而是开始进入代码开发、知识查询和产品交付流程。这也让 Stripe 面临一个新的组织问题：当一名工程师可以完成过去需要一个小团队才能完成的工作时，公司应该怎样重新设计团队？

Gaybrick 在访谈中提到，Stripe 正在尝试建立更小、更扁平的团队。过去，一名工程师可能只能同时推进一两个任务；有了编程 Agent 后，他可以把多个明确的工作分别交给不同 Agent，再把精力放在判断、设计和代码审核上。

过去的大型工程团队，通常通过增加人数提高并行开发能力；未来的团队则可能通过增加 Agent，提高每名工程师可以同时管理的工作数量。

这并不意味着 Stripe 已经得出了一套固定答案，如果工程师同时发起更多任务，但产品判断、代码审核和跨团队协调没有改善，公司也可能只是更快地产生更多需要处理的工作。代码生成速度提高，不代表正确的产品方向会自动出现。

AI 可以降低执行成本，却不能替代产品判断和责任归属。Stripe 因此没有把 AI 只当成减少人数的工具，Gaybrick 将公司的策略概括为「build more」：效率提升之后，不是只维持原来的产出并减少员工，而是利用相同的组织建设更多产品。

他举过销售团队的例子。Stripe 的内部 AI 工具让销售人员的生产率提高约 20% 后，公司并没有相应减少销售人员，反而继续招聘，希望把提高的效率转化成更多客户和收入。

这与 2022 年的裁员形成了一个有意思的对照，2022 年，Stripe 发现员工数量增加得太快，协调成本超过了新增产出；到了 2026 年，公司开始尝试用 AI 提高个人杠杆，在不过度扩大组织的情况下增加产品和商业产出。

因此，Stripe 当前的人效逻辑已经不只是「每名员工支撑多少交易量」，还增加了一个新的问题：一名员工可以同时调度多少软件 Agent，又能否对这些 Agent 产生的结果负责？

管理层继续专业化

截至 2026 年，Patrick Collison 仍然担任 CEO，John Collison 仍然担任 President，两位创始人继续掌握公司的长期方向。

Will Gaybrick 的职责已经从早期 CFO，扩展为 President of Technology and Business，统筹技术、产品和商业相关工作；David Singleton 担任 CTO；Dhivya Suryadevara 负责财务。

2026 年 6 月，长期负责收入和全球市场的 Eileen O『Mara 被任命为 Vice Chair，Tyler Bryson 出任 Chief Revenue Officer，这反映了 Stripe 组织结构的又一次变化。

早期公司需要的是能把职能搭建起来的人；现在需要的则是能够跨产品、技术、商业和区域配置资源的负责人，产品已经不再按照单一业务线运行，一次关于稳定币、AI 计费或模型路由的决策，可能同时涉及工程、资本配置、销售、监管和并购。因此，Stripe 把越来越多的技术和商业职责放在同一批管理者手中。

保持私有，开始成为一种资本策略

Stripe 在这一阶段仍然没有上市，但通过连续的员工股份交易，为现任和前员工提供流动性。2024 年的员工股份交易对应估值约 650 亿美元；2025 年上升到约 915 亿美元；2026 年 2 月，最新一次员工要约收购对应的估值达到 1,590 亿美元。这些数字来自员工股份交易，不是公开市场市值，也不完全等同于传统融资轮估值。但它们提供了一个外部投资者愿意以什么价格购买 Stripe 股份的参考。员工流动性交易让 Stripe 可以继续保持私有状态，同时缓解员工持股多年却无法变现的问题。

到了 2026 年，保持私有还带来了另一个优势：Stripe 可以使用现金和股份进行大型收购，而不需要每个季度向公开市场解释短期利润变化。

根据 Stripe 2026 年 8 月向投资人披露的数据，公司上半年收入同比增长 41%，自由现金流同比增长 43%。Stripe 还表示，即使进行了多笔大型收购，公司股份总数仍低于三年前。这些数据来自 Stripe 自己的投资人信，并不是公开审计财报。但它们说明，Stripe 正在尝试证明一件事：保持私有并不只是延迟上市，而是为了保留长期投资、股份回购和收购的灵活性。

过去融资主要为 Stripe 进入更多国家和建设产品争取时间；现在，资本开始被用于购买已经形成的专业能力，并把它们组合成下一代基础设施。

到 2026 年，Stripe 已经很难再被简单定义成一家支付处理公司。支付仍然是它最大的入口，但围绕这个入口，Stripe 已经逐渐形成账户、钱包、计费、税务、风控、稳定币、资金管理和模型路由等能力。

它正在从「帮助互联网公司收钱」，走向「帮助互联网公司管理收入、资金和计算成本」。

创始人没有离场，但核心团队一直在变化

Stripe 的一个特殊之处是，16 年过去，两位创始人仍然留在公司的核心位置。Patrick Collison 继续担任 CEO，John Collison 继续担任 President，很多独角兽发展到这个规模后，会引入新的 CEO，或者让创始人退到董事会，但 Stripe 没有走这条路线。

不过，「创始人一直在」并不意味着 Stripe 始终由两兄弟亲自管理一切，Stripe 最早只有十几个人时，Patrick 和 John 可以自己写代码、联系用户、设计产品，也可以直接参与银行合作、风险处理和招聘，当时公司的问题相对集中：如何让开发者更容易接入在线支付。

后来，Stripe 从一个支付 API 扩展到 Connect、Billing、Terminal、Issuing、Tax、Treasury 和 Identity，又进一步进入稳定币、钱包、用量计费和模型路由。两位创始人已经不可能理解和管理每一项业务的细节。

Stripe 的核心团队也由此不断变化，它不是一次性搭建出一套完整的管理班子，而是在每一个新的瓶颈出现时，寻找能够解决这一阶段问题的人。

Billy Alvarado：先让 Stripe 进入金融系统。Stripe 早期遇到的第一个现实问题，是仅仅把 API 写出来并不能完成支付。一家支付公司需要银行账户、支付通道、风险管理和金融机构的信任。对于没有传统银行履历的两位年轻创始人来说，这些问题并不能只靠技术解决。Billy Alvarado 的作用前面已经写过，他帮助 Stripe 建立银行和支付行业关系，处理支付运营，并让传统金融机构愿意与一家刚成立的技术公司合作，他的加入代表 Stripe 第一次从开发者工具跨入真正的金融基础设施。

Greg Brockman：把几个人的工程小组变成工程组织。解决银行合作之后，Stripe 面对的下一个问题是工程团队如何扩大。Greg Brockman 在公司很早期加入，并担任过 CTO。早期团队只有几个人时，很多问题可以依靠个人能力解决；但当团队扩展到几十人、上百人以后，公司需要建立统一的代码标准、审查机制、稳定性要求和招聘方式。这对支付公司尤其重要，普通软件出现故障，可能只是一个页面暂时打不开；支付系统出错，则可能带来重复扣款、账目错误、商户资金延迟甚至合规风险。Greg 后来离开 Stripe，并参与创办 OpenAI。但他在 Stripe 早期承担的关键任务，是帮助公司从依赖少数优秀工程师，过渡到能够持续招聘和管理工程人才的组织。

Claire Hughes Johnson：给高速增长的公司补上管理系统。2014 年，Claire Hughes Johnson 从 Google 加入 Stripe。当时 Stripe 已有一百多名员工，产品和客户增长很快，但还没有一套能够支持全球扩张的完整管理系统。她先后负责过销售、运营、客服、风险、人力和公司规划等工作。换句话说，她处理的是产品成功以后随之而来的问题：客户越来越多以后，谁来服务他们？团队越来越大以后，谁对结果负责？进入更多国家以后，如何管理风险和本地运营？不同产品同时争夺人员和预算时，如何确定优先级？她的价值不是推出某一个具体产品，而是帮助 Stripe 建立一套能够支撑持续扩张的组织基础。这个过程也并不完美。Claire 后来公开谈到，自己一度拥有过多直接汇报人员，反映出公司在高速增长中也出现过管理跨度过大、责任分配不清等问题。这恰好说明，Stripe 的组织能力不是天然存在的，而是在员工从一百多人增加到几千人的过程中，不断试错和重建出来的。

Will Gaybrick：把财务、产品和资本配置放到一起。Will Gaybrick 在 2015 年加入 Stripe，最初担任 CFO。后来，他的职责逐渐从财务扩大到产品、技术和业务，目前担任 Stripe 的 President of Technology and Business。这个角色变化很能说明 Stripe 后期的管理逻辑。当公司只有一个核心支付产品时，产品决策和财务决策可以相对分开。但当 Stripe 同时管理几十种产品，开始进行数十亿美元级别的收购时，产品选择本身就变成了资本配置。Stripe 必须不断决定：

• 哪些能力应该自己开发；
• 哪些能力更适合通过收购获得；
• 哪些项目暂时没有收入，但值得提前投入；
• 哪些产品应该停止或者缩减；
• 稳定币、AI Agent 和 token 经济应该投入多少资源。

Will Gaybrick 的职责横跨财务、产品和技术，这使 Stripe 可以把「产品是否值得做」和「公司应该在这里投入多少资本」放在一起判断。Stripe 近年的 AI 工程调整、稳定币投入和连续收购，也可以放在这个背景下理解。

David Singleton：让大型工程组织仍然能够交付。2017 年，David Singleton 从 Google 加入 Stripe。当时 Stripe 的员工已经接近一千人，工程管理面对的问题不再只是如何招聘优秀工程师，而是如何让大量团队同时工作，又不让决策和交付速度持续下降。公司扩大后，很容易出现一种情况：项目需要在多个部门之间协调，会议和审批越来越多，工程师越来越多，但产品推进反而越来越慢。David 参与建立的，是适用于更大规模的工程管理体系，包括底层基础设施、内部工具、工程责任划分和项目推进机制。后来，Stripe 同时维护支付、计费、税务、身份、发卡、资金管理、稳定币和开发者工具，需要的已经不是一个强大的工程团队，而是一套能够让多个工程组织并行运行的系统。Stripe 内部使用 Minions 等工程 Agent，也可以看作这条路线的延续：公司希望利用 AI 减少重复开发、维护工作和大型组织里的协调成本。不过，代码和 PR 数量增加并不自动意味着商业效率提高。最终还是要看这些工具能否缩短产品交付时间、减少维护成本，并转化为客户愿意付费的产品。

Mike Clayville、Eileen O'Mara 和 Tyler Bryson：从开发者自助走向企业销售

Stripe 最初的增长很大程度上来自开发者。

一名工程师看完文档、接入 API，公司就可能成为 Stripe 的客户。这种方式非常适合创业公司，但当 Stripe 开始服务大型零售商、平台和跨国企业时，仅靠文档和自助接入已经不够。

大型客户需要合同谈判、系统迁移、本地支持、风险安排、定制定价和长期账户管理。一次销售和迁移可能持续几个月，甚至更久。Mike Clayville 在 2020 年加入 Stripe，帮助公司建立面向大型企业的收入组织。Eileen O'Mara 随后参与扩大这套体系，并担任过 CRO。Stripe 表示，在她领导收入组织期间，公司年度支付总额接近翻倍，增长至 1.9 万亿美元。2026 年，Eileen 转任 Vice Chair，更多参与重要客户、合作伙伴和公共政策事务；Tyler Bryson 接任 CRO，继续负责全球商业增长。

这组管理层变化意味着，Stripe 最终形成了两套同时运行的获客方式。一套是开发者和创业公司自助接入。Stripe 在客户规模还很小时进入，等待其中一部分公司成长为未来的大客户。另一套是主动争取已经成熟的大型企业，为它们提供迁移、定价、风控和全球运营支持。

第一套模式帮助 Stripe 赢得未来的企业客户，第二套模式帮助它争取已经成长起来的企业。Will Gaybrick 将这套策略概括为：先赢得创业公司，然后再赢一次。

回头看，Stripe 的核心团队变化基本对应着公司的每一个阶段：

因此，Stripe 的组织演进并不是创始人逐渐退出，把公司交给职业经理人；也不是两位创始人一直亲自控制所有细节。

它更接近一条这样的路线：创始人亲自完成大部分工作 → 随着瓶颈变化引入不同负责人 → 建立专业管理层 → 创始人继续掌握方向和关键产品判断。

收购又给这套结构增加了一层新的变化。Bridge、Privy、Metronome 和 OpenRouter 不只是几项产品被装进 Stripe，也带来了新的创始人、工程团队、客户和行业知识。Stripe 接下来需要决定，哪些团队应该被完全整合，哪些产品应该继续独立运行，以及如何把它们接到账户、计费、支付和风控等底层系统。

所以，今天的 Stripe 已经不是一家依赖两位创始人处理所有问题的创业公司。它更像是一个由创始人控制方向、专业管理层负责规模化，同时不断吸收外部创业团队和专业能力的组织。

把 Stripe 的 16 年压缩成一张时间表

其中，Bridge 于 2025 年 2 月完成收购，Metronome 于 2026 年 1 月完成收购；OpenRouter 正在收购中。

它大致沿着一条连续路线向外延伸：收款 → 平台分账 → 订阅与线下支付 → 税务、风控和资金管理 → 稳定币与钱包 → AI Agent、用量计费和模型路由。

每一次扩张都在回答同一个问题：一家互联网企业要完成一笔交易、管理一段收入或者启动一种新的商业模式，还缺少哪一层基础设施？

早期 Stripe 解决的是「如何收钱」；后来解决的是「如何分配、管理和使用这笔钱」；进入 AI 阶段以后，它开始处理的则是「如何计量计算资源，以及软件如何代表人完成交易」。

如何理解 Stripe 的 1,590 亿美元估值？

2026 年 2 月，Stripe 组织了新一轮员工股份交易，对应估值达到 1,590 亿美元。这不是公开市场每天交易形成的市值，也不是一轮传统融资的投后估值。但它仍然提供了一个参考：参与交易的投资者，愿意用什么价格购买 Stripe 的股份。那么，这个估值建立在什么基础上？显然不只是 Stripe 每处理一笔银行卡支付所收取的手续费。

第一，Stripe 占据了企业建立互联网业务的早期入口

很多公司在规模还很小时就开始使用 Stripe。最初的接入决定可能只由一名工程师完成，但随着公司发展，客户数据、支付记录、订阅关系、退款流程、风控规则和财务系统，都会逐渐建立在 Stripe 上。这让 Stripe 获得了一种特殊的客户生命周期：它可以在客户很小时进入，然后跟随客户一起成长。

DoorDash、Shopify 和 Instacart 等公司早期都曾是创业公司，Stripe 不需要等到它们成为大型企业以后，再从其他支付公司手中争夺客户。

这也是 Stripe 所说的「先赢得创业公司，然后再赢一次」。

第一次，是通过简单的 API 和开发者体验进入一家创业公司；第二次，是当客户成长为大型企业后，再依靠全球支付、Billing、Tax、Radar 以及大客户服务能力留住它们。不过，第二次并不会自动发生。创业公司长大以后，会重新评估支付成本、稳定性、地区覆盖和服务水平，也会获得更强的议价能力。Stripe 仍然需要与 Adyen、PayPal、Checkout.com，以及大型企业自己建设的支付系统竞争。

第二，它的收入可以跟随客户的业务规模增长

Stripe 的支付、计费、税务、身份验证和资金管理收入，都与客户的实际业务活动相关。当客户交易额增长、订阅用户增加或者进入更多国家时，即使 Stripe 没有重新完成一次销售，它从同一个客户获得的收入也可能继续增加。普通 SaaS 公司通常需要增加席位或者提高订阅价格，Stripe 则可以直接参与客户业务规模的增长。

这也是基础设施生意的吸引力：一旦进入客户的核心业务流程，客户增长本身就可能成为 Stripe 的增长来源。

第三，越来越多产品可以复用同一套底层系统

Payments、Connect、Billing、Tax、Radar、Identity、Treasury 和 Issuing，并不是完全独立的产品。它们可以共享账户、账本、身份信息、风险模型、客户关系，以及银行和支付网络。

如果这种复用真正成立，Stripe 每增加一项产品，就可以在已有客户中获得新的收入，同时提高客户的迁移成本。一个同时使用支付、订阅、税务和风控产品的客户，显然比只接入支付接口的客户更难离开。

但这也是 Stripe 必须持续证明的地方。产品矩阵越来越大，不一定自然产生协同。如果产品之间不能真正共享数据、账户和操作流程，它们也可能变成一组相互割裂、持续增加组织成本的业务。

因此，Stripe 的价值不只是「拥有多少产品」，而是这些产品能否建立在同一套基础设施上，被同一个客户持续使用。

第四，银行关系、监管能力和客户信任很难复制

支付不是只靠代码就能完成的生意。一家新公司即使能够做出更简单的 API，也需要建立银行合作、卡组织关系、牌照、合规系统、风险团队和争议处理能力。

它还要让客户相信，资金可以长期、稳定地经过这套系统。Stripe 过去 16 年积累的不只是软件，还有金融机构关系、历史交易数据、风险判断能力和客户信任。这些资产不像一个前端功能，可以被另一个工程团队在几个月内复制。

早期 Stripe 用简单的开发者体验打开市场，但真正让它形成壁垒的，是隐藏在简单接口背后的金融和运营系统。

第五，市场也在为稳定币和 AI 时代的选择权定价

Bridge、Privy、Tempo、Metronome 和 OpenRouter 看起来属于不同领域，但把它们放在一起，就能看到一个相对连续的方向：

• Bridge 负责稳定币资金流动；
• Privy 提供钱包和身份入口；
• Tempo 探索面向支付场景的区块链；
• Metronome 处理复杂的用量计费；
• OpenRouter 连接模型、供应商和 token 消耗。

如果未来 AI Agent 可以自主购买软件、调用模型、管理预算和完成支付，它需要的就不只是一个支付按钮。

Agent 需要获得支付权限，需要知道自己能花多少钱；需要在不同模型和软件服务之间进行采购；需要处理不同国家、不同货币和稳定币之间的资金流动；还需要留下能够被企业审计、退款和追踪的交易记录。

Stripe 希望覆盖其中的多个关键环节：账户、钱包、支付、计费、风控、资金结算和模型调用。

因此，1,590 亿美元的估值大致包含了两部分价值：一部分是 Stripe 已经形成的全球支付基础设施；另一部分是它可能在稳定币和 AI 经济中占据的位置。

但第二部分目前仍然只是一种选择权。Stripe 需要证明，这些收购能够真正被整合，而不是一组价格昂贵、彼此关系有限的产品；也需要证明 AI Agent 和稳定币可以产生足够大的真实交易量，而不只是技术行业短期关注的概念。它还要证明，产品边界扩大以后，公司不会再次出现组织增长快于业务增长的问题。

所以，这个估值既是对 Stripe 现有支付规模的定价，也是在提前购买它可能进入的未来市场。

结语：Stripe 能否成为 Agent 时代的 AWS？

回看 Stripe 的 16 年，开始是两位年轻创始人用几行代码简化了支付接入，但真正决定 Stripe 能走多远的，并不是那几行代码本身。

早期的 Stripe，把申请商户账户、连接支付网关、保存支付信息和处理错误等复杂工作，收进一个简单的 API。后来，它又把平台分账、订阅计费、税务计算、欺诈识别、企业设立、资金管理和跨境支付收进同一个系统。到了稳定币和 AI Agent 阶段，它开始尝试处理钱包、资金流动、模型调用、token 计量和机器支付等新的复杂问题。

从表面上看，Stripe 的产品越来越多；但它想做的事情一直没有太大变化：把互联网企业不愿意自己处理、却又不得不处理的复杂性，变成基础设施。

Stripe 能否成为 Agent 时代的 AWS？过去，开发者不需要自己购买服务器、建设数据中心和管理底层计算资源。只需要调用 AWS 的服务，就可以创建和扩大一家互联网公司。AWS 把复杂的计算基础设施，变成了可以按需调用和按量付费的服务。

如果 AI Agent 真正进入商业活动，它们同样需要一套能够随时调用的经济基础设施。一个 Agent 不仅需要完成某个任务，还可能需要购买数据、调用模型、订阅软件、支付供应商或者把收入分配给不同参与者。这会带来一系列新的问题：

• Agent 如何获得支付权限？
• 它可以花多少钱，由谁设置预算？
• 调用不同模型产生的 token 成本如何计算？
• 一笔错误交易由谁退款、申诉并承担责任？
• 资金如何在法币、稳定币、银行账户和钱包之间流动？
• 企业又如何审计这些由软件自动发起的交易？

这时，Agent 需要的就不只是一个支付按钮，而是一整套账户、身份、钱包、计费、风控、税务和结算系统。

Stripe 近年的动作，可以沿着这个方向重新连接起来：

• Payments 和 Connect 负责接收、分配与结算资金；
• Billing 和 Metronome 处理订阅、用量与复杂定价；
• Radar 和 Identity 判断交易风险与参与者身份；
• Bridge、Privy 和 Tempo 处理稳定币、钱包与新的资金网络；
• OpenRouter 连接模型供应商，并提供模型调用和 token 消耗的入口；
• Agentic Commerce 相关产品，则尝试让 Agent 发现商品、获得授权并完成交易。

如果这些能力最终能够组合起来，Stripe 提供的可能就不再只是「人如何在互联网上支付」，而是：一个软件 Agent 如何获得预算、购买服务、调用模型、完成结算，并对自己的经济行为留下可以追踪的记录。

这是 Stripe 成为 Agent 时代基础设施的可能性，但它距离「Agent 时代的 AWS」仍然很远。

AWS 的核心价值之一，是提供相对标准化、可以被大量开发者自由组合的计算资源。Stripe 要获得类似的位置，也必须证明自己的支付、钱包、模型路由和计费系统能够被真正组合，而不是一组通过收购拼在一起的产品。

它还面临几个更难回答的问题：

• 首先，Agent 的法律身份和支付授权还不清晰。如果 Agent 自主做出错误采购，责任属于用户、Agent 开发者、模型提供商，还是支付平台？
• 其次，不同的模型公司、银行、钱包和支付网络是否愿意让 Stripe 成为中间层？如果 Stripe 同时参与支付、计费、模型路由和资金结算，客户也可能担心它控制过多环节。
• 再次，Agent 商业活动能否形成足够大的真实交易量？目前大量 Agent 仍然只是辅助人类完成任务，还没有真正获得独立预算，也没有持续采购服务。
• 最后，Stripe 自己能否管理不断扩大的产品和组织边界？它越接近一套完整的经济基础设施，内部需要协调的团队、监管关系和利益冲突也会越多。

所以，「Agent 时代的 AWS」目前更像一个需要验证的方向，Stripe 的优势在于，它已经拥有支付入口、企业客户、开发者关系、全球资金网络和风险基础设施。它不需要从零开始建立这些能力，也可以把新产品逐步推向现有商户。

它的风险同样来自这里：产品边界扩展得越远，组织越复杂，就越容易失去早期那种简单、清晰的产品体验。

因此，Stripe 未来最值得观察的问题，可能已经不只是支付总额还能增长多少，而是它能否把支付、稳定币、计费和模型调用组合成一套真正面向机器的经济基础设施。

如果答案是肯定的，Stripe 的上限就不再只是一家更大的支付公司，它可能成为 Agent 进入现实经济时默认调用的一层基础设施。如果答案是否定的，那么 Bridge、Privy、Metronome 和 OpenRouter 也可能只是一组昂贵、但彼此关联有限的收购。

最终，Stripe 能否成为 Agent 时代的 AWS，取决于它能否再次完成 16 年前做过的那件事：

把底层极其复杂的账户、资金、计费和责任问题留给自己，只给开发者和 Agent 留下一个足够简单、真正能够运行的接口。