如今打开 Chrome 网上应用店的开发者后台，你会发现少了一个东西：一个"支付"标签页。谷歌早在 2021 年就关闭了自家针对扩展的应用内支付系统，而且再也没有恢复。如果你想在 2026 年为一款 Chrome 扩展收费，那么计费、订阅、退款、税费征收——以及几乎没人会提前规划的那部分：核对你银行账户里实际到账的钱与你实际卖出的东西是否对得上——全都得靠你自己。
最后这一点，绊倒的独立开发者比定价问题还多。一家通过 Stripe、Paddle 或类似 ExtensionPay 这样的封装工具运营三四款扩展的单人公司，最终会发现打款存款根本无法清晰对应到某一款产品，退款会在 Chrome 网上应用店审核延迟之后毫无征兆地激增，而银行余额也总是和销售看板上显示的数字对不上。这些都不是你业务里的漏洞，而是拼凑一套本该由谷歌代管的支付体系之后，必然出现的结果。
下面介绍如何搭建一套能扛住这一切的记账体系。
谷歌为何退出支付业务
Chrome 网上应用店支付系统诞生于 2010 年代初，那时独立开发者想为浏览器扩展收费，可选的方案并不多。到了 2021 年，Stripe、Braintree 以及一批"记录商户"（merchant of record）服务已经足够成熟，谷歌因此认为自己不再需要运营专属的结账、许可证密钥和打款系统。它弃用了 Chrome 网上应用店支付系统，并把所有付费扩展逼到了两条路之间：要么免费，要么改用第三方支付处理商。
对开发者而言，实际后果是：扩展赚到的每一美元，如今都要流经一套你自己搭建的支付体系，这套体系产生的每一个对账难题，也都得你自己解决。现在已经没有一份统一的"Chrome 网上应用店打款报告"了——有的只是支付处理商给你的数据、Chrome 网上应用店自身的上架分析数据，再加上你的银行对账单，而这三样东西第一眼看上去几乎从来对不上。
支付处理商还是记录商户——每款扩展只能选一个
在开始对账之前，你首先需要弄清楚自己在交易中站在法律意义上的哪一方，因为这会决定什么样的内容会被计入你的账本。
支付处理商（直接用 Stripe，或者一个建立在其之上的封装工具，比如 ExtensionPay）会让你成为卖方。你负责收款，你是税务意义上的记录商户，你要负责搞清楚每一个客户所在司法辖区的销售税和增值税义务。手续费更低——Stripe 的基础费率是每笔 2.9% + $0.30，而像 ExtensionPay 这样的封装工具通常还会在此基础上再加收一层——但合规负担全都落在你身上。
记录商户（Paddle、Lemon Squeezy、Fungies 等）会在法律上代替你成为卖方。他们负责收取增值税或消费税，在如今要求对数字商品征税的 140 多个国家申报纳税，处理拒付，再把净收益打给你。你要让出 4%–8% 的营收，而不是约 3%，但整整一类记账和税务申报工作都会随之消失。关于这两种模式的取舍细节，以及如何计算切换是否划算，可参阅我们的记录商户指南。
对于大多数月收入在几千美元以下的独立扩展开发者来说，记录商户多收的那 3%–5%，换来的是不必亲自在十几个国家注册增值税的省心保障。一旦你在多款扩展上跑出了实实在在的经常性收入，就该重新算一遍这笔账——随着交易量增长，这个平衡点会发生变化。
不管你选哪一种，都要把它写下来。你的账本需要对"谁是这款扩展法律意义上的记录卖方"给出一个明确答案，因为它决定了销售税负债究竟会不会出现在你的资产负债表上。
对账难题是结构性的，不是你哪里做错了
有一点最容易让开发者措手不及：即便支付处理商配置完全正确，你收到的打款金额也几乎从不等于当期产生的营收。有三件事会打破这种一一对应关系：
- 批量打款。 Stripe 和大多数记录商户都按滚动周期打款（通常是收费后 2–7 天，有时是按周），所以某月 5 号到账的一笔打款，里面包含的其实是上个月最后几天的销售。如果你把打款到账的那一天直接记为营收，那你每个月都在把收入错误地归到错误的会计期间。
- 多款扩展共用一个支付账户。 如果你把好几款扩展都挂在同一个 Stripe 或 Paddle 账户下——对于那些同时上线一批小工具而非单一旗舰产品的开发者来说，这很常见——那么打款就是覆盖所有产品的一笔总额。如果没有按扩展打标（比如 Stripe 的 metadata 字段，或者给每款扩展设置独立的 Product/Price），你就没法分辨到底是哪款扩展带来了这笔收入，也就无法判断哪款扩展才真正值得你花时间维护。
- 手续费、退款和货币兑换在你看到数字之前就已经被扣掉了。 打款金额已经是扣除处理手续费、当期发生的退款，以及（如果你面向国际销售）货币兑换损耗之后的净额。如果把打款金额直接记为营收总额，会虚增你的营收，也会掩盖你真实的利润率。
解决办法是三方核对，至少每月做一次：
- 支付处理商的销售报告——如果账户支持，会按产品/扩展列出未扣除手续费和退款前的总交易额。
- 支付处理商的打款报告——真正打到你银行账户的净额，手续费和退款作为独立的明细项列出。
- 银行对账单——实际到账的存款记录。
三者要互相对上。销售报告告诉你赚了多少（营收，在客户为当期服务付款时确认）。打款报告告诉你该记为费用和营收抵减项的手续费损耗和退款活动。银行对账单确认现金确实到账了。当这三者中任意两个对不上时，那就是信号——说明有什么地方需要排查：一笔失败的打款、一笔有争议的拒付，或者一项你没预料到的处理手续费。
Chrome 特有的风险：审核延迟与下架
每套支付体系都会有正常的退款活动。而 Chrome 扩展还多了一种值得单独记录的失败模式：Chrome 网上应用店的审核延迟与政策下架。
当谷歌的审核团队认定一款已上架的扩展违反政策时，你要么立即被下架（中度到严重违规），要么获得大约 7 到 30 天的整改期来修正一个较轻微的问题。不管是哪种情况，用户都会失去对一款他们正在付费使用的扩展的访问权限，这会带来一波可预见的退款请求、拒付和支持工单激增——有开发者反映过，仅仅因为这种模式，一个月内就损失了两位数百分比的订阅营收，这还不算直接产生的退款。
有两个记账习惯，能让这种情况变得可控，而不是一次意外冲击：
- 按原因给退款和拒付打标签。 客户单纯不喜欢这款扩展而要求退款，是正常的经营成本。而因为扩展被下架一周而产生的退款，是一种独立的、可追踪的经营风险。把二者区分开来（哪怕只是一个备注字段或一个子账户），就能让你在一年的时间尺度上看清，营收的波动到底有多少来自平台风险，又有多少来自产品与市场匹配度本身的问题。
- 把一次待审核或一项尚未解除的政策警告，当作一件值得披露的事件，就像你会标记一个关键客户的流失风险一样。如果你正在算账，考虑要不要涨价、要不要招人、要不要贷款，那么一款正处于 30 天合规警告期内的扩展，就不能算作"稳定的经常性收入"——在它通过审核之前，都应该按有风险的收入来建模。
在赚到收入时确认，而不是在打款到账时确认
订阅制和一次性购买的扩展需要不同的处理方式，把两者混为一谈，是这个细分领域里最常见的会计错误：
- 按月或按年订阅：应在客户所购买服务的整个期间内均匀确认营收，而不是在扣款那一刻一次性全部确认。一份预付的年度套餐会形成一笔递延收入负债——你已经收到了钱，但十二个月的服务里还有十一个月没有交付，所以销售当月只有 1/12 计入营收，其余部分随着时间推移逐月从资产负债表上结转出来。
- 买断制终身方案（这在扩展这个细分品类里是很受欢迎的定价模式，因为用户对浏览器工具的持续订阅普遍抱有戒心）：这类方案仍然代表着你要无限期提供更新和支持的义务，所以在第一天就把全部现金确认为营收，会虚增你当月真实赚到的收入。更站得住脚的做法，是把终身方案的收入按一个合理估算的服务期限分摊确认（很多企业用 12 到 36 个月作为参照），而不是一次性全部确认。
- 不产生持续义务的一次性购买：在交付时全额确认——这是最简单的情形。
MRR（月度经常性收入）是一个有用的增长指标，但它和你账本里确认的营收并不是同一个数字。MRR 告诉你的是当前活跃订阅的运行速率；而你的账本应该反映你在扣除递延部分之后，当期实际赚到的收入。
一套能扛住多款扩展的账本结构
如果你用的是纯文本复式记账系统，"一笔打款、多款扩展"这个难题的解决办法，是从一开始就用一套按产品拆分收入的科目表，再为打款报告里已经净额结算掉的各项扣减单独设立科目：
2026-07-05 * "Stripe payout - batch #4471"
Assets:Bank:Checking 842.17 USD
Income:Extensions:FocusTimer -510.00 USD
Income:Extensions:TabArchiver -390.00 USD
Expenses:PaymentProcessing:StripeFees 41.83 USD
Expenses:Refunds:FocusTimer 16.00 USD每一笔打款都会变成一笔交易，把银行存款与按扩展划分的收入、手续费和退款作为独立的分录条目一一对应起来——而不是一行含糊不清的"Stripe 存款"，完全看不出哪款产品真正在盈利。因为文件是纯文本，你可以按扩展、按月份，或者按退款原因来 grep 或查询它，这正是一份笼统的打款报告给不了你的可见性。
每月清单
- 拉取当月支付处理商的销售报告（总额，如果可能按产品列出明细）。
- 拉取打款报告，把手续费、退款和拒付拆成各自独立的明细项。
- 用银行对账单核对打款到账情况。
- 按确认计划记录订阅和终身方案的营收，而不是在收到款项时一次性记录。
- 把因 Chrome 网上应用店审核延迟或下架而产生的退款，与正常流失单独打标签区分。
- 如果你通过纯支付处理商（而非记录商户）面向国际销售，检查你在任何一个国家的累计销售额是否已经跨过增值税/消费税的注册门槛。
让你的扩展业务账本和你的代码一样干净
你不会在没有版本控制的情况下发布一款扩展，你的财务也理应得到同样的严谨对待——尤其是当打款分散在多个产品和多个支付处理商之间的时候。Beancount.io 提供纯文本、带版本控制的记账方式，让你可以按扩展给收入打标签、追踪递延收入，并以你对待代码库同样的精度，核对打款与银行对账单。免费开始使用，看看为什么开发者们正在用管理其他一切自建项目的方式来管理自己的账本。