嘿——我今天早上看到你发来的消息了，那张截图是你应用的支持收件箱里有人问“我该怎么给你付款”。真心恭喜你。这一刻，一个副业项目就不再只是个演示了。同时，这也是你之前一直能拖延的一百个小决定，全都集中在同一个周二冒出来的时刻。你让我直接告诉你该怎么做。我会的，但我想先带你了解一下原因，因为搞懂“为什么”才能让你三个月后不用再问我一遍——那时候可能换成了 Lemon Squeezy 而不是 Stripe，或者变成了订阅制而不是一次性付费。
你真正要做的决定
你把这个问题描述成“该用哪个支付服务商”，但实际上这是叠加在一起的两个决定。第一：你想成为“记录商户”，还是让别人来承担这个角色？第二：你的计费方式是什么——一次性购买、订阅，还是按用量计费？第一个选错了，六个月后你就得花一整个周末去一个你从没去过的国家注册增值税。第二个选错了，只是个麻烦的迁移问题，而不是法律问题，所以相对没那么可怕。
成为“记录商户”意味着在法律意义上，是你在出售这个产品。你负责收款，负责搞清楚客户所在的每个司法辖区的销售税和增值税规则，并负责申报。Stripe 很乐意帮你计算这些税款（Stripe Tax），但计算不等于缴纳——你仍然需要在每个达到起征点的地区进行注册和申报。像 Lemon Squeezy 或 Paddle 这样的“记录商户”服务，会把整个问题从你手中接过去：法律上他们才是卖家，他们在各地收取并缴纳税款，然后把净额付给你。你需要为此让出一部分利润。
| 方案 | 谁是卖家 | 典型抽成比例 | 税务处理 | 适合 |
|---|---|---|---|---|
| Stripe（直连） | 你 | 约 2.9% + 每笔交易 $0.30，Stripe Tax 另加 0.5% | 你负责注册和申报，Stripe 只负责计算 | 你预计每月交易量将超过几千笔，希望长期降低手续费 |
| Lemon Squeezy | Lemon Squeezy | 约5% + $0.50/笔 | 全权代管，他们是名义上的销售方 | 独立开发者，第一款产品，完全不想操心税务问题 |
| Paddle | Paddle | 约5% + 费用因地区而异 | 全权代管，更偏向企业级服务 | 带订阅功能且有一定发票需求的 SaaS |
| PayPal | 你 | 约3.5-4.5%，纠纷处理偏向买家 | 由你自己处理 | 特别信任 PayPal 的客户，而非默认选择 |
以你目前的情况来看——只有一个客户，产品也简单，还不确定这会不会发展成一门生意——我会建议你选 Lemon Squeezy 或 Paddle，而不是直接用 Stripe。多付那两个百分点的手续费，换来的是不用在一个你从未踏足过的州意外变成纳税申报人，这笔保险很划算。等业务量足够、你也做好了应对文书工作的心理准备后，随时可以迁移到 Stripe 直连。没人是为了好玩才迁移支付服务商的，但这是个星期二就能解决的问题，不是要耗上一年的难题。
我自己在早期一个项目上就犯过这个错——因为“大家都用 Stripe”而直接选了它，每月从几位欧洲客户那里收几百美元，结果十八个月后收到一封语气非常客气但让人一头雾水的邮件，问的是 VAT MOSS 注册的事。为此我搭进去了一个会计师的一下午时间，还有四十分钟纯粹的恐慌搜索“我是不是欠荷兰政府钱”。不算灾难性，但完全可以避免。
在动用正式密钥之前
不管你选哪家，都不要一上来就直接接入生产模式。这些服务商都提供测试/沙盒模式，配有能触发特定结果的假卡号——成功扣款、被拒、需要 3D 验证、余额不足。在动用真实密钥之前，把这些情况都过一遍。这些失败路径正是你第一周实际会遇到的，而且如果绑着某个真人的真实银行卡在线上调试，可就没那么好玩了。
在你的构建对话里，明确说明你希望分阶段进行：先要求把支付集成接到测试模式，并配上清晰可见的横幅或标记，以免任何人——包括未来的你自己——在测试时不小心刷了真实卡。然后再有意识地进行第二步，替换成正式密钥。要分成两次提示，而不是一次，尽管直接说“加上支付功能”让它自己猜该用哪种模式会更快。这道摩擦力正是关键所在。
你还需要决定：当 webhook 触发时你的服务器恰好宕机、响应缓慢，或事件被重复发送，该怎么办。这不是假设情况——它在第一周就会稳定地发生。你至少需要处理以下几类事件：
checkout.session.completed（或类似事件）——开通访问权限，这一刻客户才真正成为客户invoice.payment_failed——对于订阅服务，现在就决定这是立即锁定还是设一个宽限期，因为“立即锁定”对一张只是暂时出问题的卡来说，会给人留下非常糟糕的第一印象customer.subscription.deleted——有人取消了订阅，除非你的条款另有规定，否则应在计费周期结束时撤销访问权限，而不是立即撤销- 退款事件——请先自己书面明确一次退款政策到底是什么，别等第一个退款请求逼你临场决定
幂等性在这里比你应用里几乎任何地方都更重要。如果一个 webhook 被重复发送——而它确实会，因为服务商在收到非 200 响应时会重试——你绝不能重复开通权限，更糟的是重复扣款内部状态。存储事件 ID，在处理之前先检查是否已经处理过。
你一直在回避的定价问题
你在消息里提到不确定该收 $9/月，还是一次性收 $49。我不认为哪个是错的，但注意一下你实际在回避什么：与客户讨论持续价值到底是什么的那场对话。一次性定价更容易让人爽快答应，对你来说搭建起来也更简单（不用处理催缴、续订失败、取消流程）。订阅模式则是在赌你会持续改进产品，让人不流失——这是一个真实的承诺，不只是定价页上的一个勾选项。如果你不确定六个月后自己是否还会积极维护这个产品，一次性定价是更诚实的报价方式。以后一旦有持续的东西可以订阅了，随时可以再加订阅档位。
还有一件事，说完你就可以继续忙了：在收第一笔钱之前，在页面上放一份真实的退款和取消政策，哪怕只有三句话。不是因为有人会为了 $9 起诉你，而是写下来会逼你真正做出决定，而“等有人问了再说”往往意味着你最后是在一封愤怒的邮件中间仓促做出政策决定，而不是在一个平静的下午。
先去把沙盒接好。等你用一张假的被拒卡跑通之后再来找我——那才是真正说得上“能用了”的版本。
