在你的应用里收钱：一份简明的支付接入指南
在你用 AI 构建的应用里接入支付，意味着连接像 Stripe 这样的服务商——由它处理银行卡表单、完成资金转移，你的应用只需记录订单，并在支付确认后做出相应反应。
有一个特定的时刻，你的应用会从一个项目变成一门生意：第一次有人通过它付钱给你。这也是一个 bug 从”有点尴尬”变成”你拿了我的钱，我却什么都没收到”的时刻。接受支付是大多数开发者会添加的风险最高的功能，好消息是，真正困难、令人生畏的部分其实不需要你自己去搭建。你只需要把它们正确接好线路，别跳过那些枯燥的边界情况。
这是一份关于如何在你用 AI 构建的应用中接入支付的简明指南——幕后到底发生了什么、最常出错的三件事，以及应该从哪种设置开始。
“接受支付”到底是什么意思？
接受支付，意味着把你的应用连接到一个支付服务商——大多数人会选 Stripe，这是个不错的默认选项——而不是自己搭建一套支付系统。分工是这样的，理解了它，你会安心很多：
支付服务商负责展示银行卡表单，负责获取卡号、校验并完成转账。然后它只告诉你的应用一件事：“这个人付了你 40 美元。” 你的应用从头到尾看不到卡号，不会存储它，也碰不到它。这不是一种限制——这正是重点所在。银行卡数据是一片法律和安全的雷区，把它完全留在支付服务商那一侧，意味着这片雷区是他们的责任，不是你的。如果你的开发工具提出要”把银行卡信息存进你的数据库”，答案永远是不行。
所以在一笔支付里，你的应用真正要做的事很小：把客户送到支付服务商的结账页面，然后在服务商告知款项到账时做出正确反应。
应该先支持一次性付款，还是订阅付款？
先从一次性付款开始。它和订阅用的是同一套核心线路，却不用面对那些反复出现的边界情况，而且大多数产品最初其实只需要”付一次钱，拿到东西”就够了。等你真正做出了值得每月付费的东西，再有意识地加上订阅功能。
两种支付形态几乎能覆盖所有场景：
- 一次性收费 —— 购买一张门票、一个模板、一次单独的辅导课、一份可下载的指南。钱转一次，事情就结束了。
- 订阅付款 —— 按月会员、周期性套餐。钱每个月自动转一次，这也意味着你同时要面对”卡过期了怎么办""对方取消订阅怎么办""这个月的钱到底有没有扣成功”这些问题。
AI 构建的应用里，最常见的支付错误是什么？
在 AI 构建的应用里，几乎所有支付问题都可以归结为三种错误：应用”忘记”了曾经发生过的支付、因为没有收据导致客户重复付款，以及只用真实资金测试了成功扣款这一条路径。针对每一种错误，下面都给出了一句可以直接粘给你的开发工具的明确指令。
1. 支付成功了，但应用”忘”了这回事。 客户付了钱，资金也进了你的服务商账户——可你的应用里却完全没有记录谁买了什么。一位工作坊组织者就这样卖出了 30 张门票，结果 Stripe 里有钱进账，自己的表格里却一个名字都没有。她完全不知道该放谁进门。
解决办法是：支付一确认，就立刻保存一条订单记录——谁付的钱、买了什么、金额多少、什么时候付的，以及一个清楚的”已付款：是”。可以这样告诉你的开发工具：“支付成功时，创建一条包含客户、商品、金额和付款状态的订单记录。依据的是支付服务商发来的支付确认，而不是客户是否回到了感谢页面。” 最后这句很关键——人们会关掉浏览器标签页、网络信号中断，或者不小心点了两次。真正可靠的”钱已经到账”的信号，是支付服务商直接发给你应用的消息（也就是 webhook），而不是客户的浏览器有没有跳转回成功页面。
2. 没有收据，于是他们付了两次钱。 有人点击付款，看到加载动画转了一圈，然后什么都没有——没有邮件，没有确认，什么都没有——于是他们以为支付失败了，又付了一次。现在你得退一笔款，而对方对你的信任也打了折扣。可以这样告诉你的开发工具：“支付一到账，立刻发送确认邮件，并展示一个清楚的页面，告诉用户已付款成功以及接下来会发生什么。” 支付之后的沉默，是你应用里代价最昂贵的沉默。
3. 用真实资金测试。 这是最容易悄悄带着 bug 上线的一种错误。开发者往往用自己的卡买一次自己的产品，看到成功了一次就宣布完工——却从没检查过银行卡被拒绝或者支付被退款时会发生什么。有一个应用就是这样，在卡被拒绝的情况下依然把订单标记为”已付款”，因为没有人测试过这条路径；客户白拿了产品，创始人是到月底才发现的。
测试这些其实完全不需要真实资金。每个支付服务商都提供测试模式，配有专门的假卡号——其中一些就是特意设计成会被拒绝的，好让你看到应用会怎么反应。可以这样告诉你的开发工具：“先在测试模式下构建并测试整个结账流程。处理好卡被拒绝和退款这两种情况，而不只是成功付款这一种。” 测试模式，大概是整个支付世界里最被低估、用得最少的功能。
没人明说的部分：现在你就是这门生意的经营者
有两件事人们总是会忘。第一，要真正收到钱，支付服务商需要你的真实资料——一个可以打款进去的对公账户或银行账户。这是一份你要亲自填一次的表格，不是应用能替你凭空生成的东西。第二，你赚到的钱要交的税，是你自己的事，不是应用的事。这两件事都不难，但如果没人提前说清楚，很容易让人措手不及。
添加支付功能时，应该先做什么？
第一步只做一件事：一个商品、一个价格、一次一次性付款，在测试模式下跑通。先别急着做购物车、优惠券、多档套餐或订阅，直到这一条路径干净利落地跑通为止——钱”转”了、订单被记录了、确认信息出现了。这一条能跑通的路径，比一个功能齐全、却从没扛住过一次卡被拒绝的结账流程更有价值。
接下来，做两次”陌生人测试”。第一次，用一个应该被拒绝的卡号在测试模式下结账——你的应用是如实相告（“这笔没有成功”），还是撒了谎，把订单标记成已付款？第二次，做一次成功的测试购买——你有没有得到一条订单记录和一封确认信息，而且如果你是那个客户，你会相信它吗？
接入支付听起来像是你要添加的最令人紧张的功能，但它其实就是一份接线活儿——有三种常见的出错方式，而测试模式能让你把这三种情况全都免费彩排一遍。选出那一件真正值得付费的东西，接通一条测试模式下的结账流程，把一笔假的交易从头到尾走一遍——包括卡被拒绝的情况——再让真正的银行卡碰到它。这就是你要做的第一件、也是全部的事。