收下第一笔钱：给你的 AI 应用接入真实收款，又不出岔子

有一个特定的时刻，一个 AI 应用不再是玩具、而变成一门生意：真实的钱第一次从它身上流过的时候。在那之前，犯错是廉价的。一个坏掉的按钮只是恼人。一个没人付钱的界面上算错的总额，不过是个笔误。但当一个真实客户的卡被扣款那一天，一个错误就要花掉真金白银——你的或他们的——而”是 AI 那么做的”这句话，你可不想对一个正在质疑某笔扣款的人说出口。

好消息是：给一个 AI 应用接收款项，比听起来要容易上手——前提是你搞清楚哪些部分交给你的 AI 构建器、哪些部分自己永远别碰。本文就是关于这条界线的指南。

那条保你平安的唯一铁律：永远别存储卡号

从这里开始，因为它是其余一切所依附的那条铁律。你的应用永远不该看到、存储或处理一个原始的信用卡号。 不在数据库里，不在你做的表单里，也不”就暂存一下”。直接处理卡数据，会把一堆法律和安全义务压在你身上——那是任何一个初次做应用的人都不该背的。

正确的做法是，你使用一个支付服务商——Stripe 是常见的那个，而且大多数 AI 应用构建器都对它很熟。服务商给你一个预先做好的、安全的支付表单。客户把卡号输进服务商的表单，由服务商来扣款，而你的应用只会收到一条”是的，这笔已付”的消息。你的应用知道支付发生了。它永远不知道卡号是什么。

当你让你的 AI 构建器接入支付时，把这一点明说出来：“用 Stripe Checkout（或 Stripe 托管的支付表单），这样我的应用就永远不经手原始卡数据。” 如果构建器开始生成一个带卡号字段的自定义表单，叫停它。那是你唯一不想让它做的东西。

“接入支付”实际包含什么

在动手之前先了解各个活动部件是有好处的，这样你才能看出什么时候缺了一块。一个能用的支付流程有四个部分：

一个价格。 你收多少钱，以及它是一次性的还是周期性的。这存在你的支付服务商里，而不是硬编码在你的应用里。
一个结账步骤。 客户点的那个按钮，它会把客户送到服务商那个安全的表单。
一条回传给你应用的确认。 支付之后，服务商告诉你的应用”这个人为这个东西付了钱”。这是新手最常跳过的部分——而跳过它，正是你最后会有一堆”付了钱却没拿到访问权”的用户的原因。
一份”谁为什么付了钱”的记录。 这样你的应用才能解锁正确的东西，你日后也才能回答”这个人付过钱吗？”。

如果你的 AI 构建器给了你一个能扣卡的付款按钮，但你的应用在那之后什么都没做不一样，那它就是做了第 2 部分，忘了第 3 和第 4 部分。这是最常见的半成品支付流程，而且它看起来好端端的——直到一个客户付了钱却什么都没得到。

如何把它描述给你的 AI 构建器

下面是一段覆盖了上述各个部分的提示词：

用 Stripe Checkout 给这个应用接入付费访问。只有一个方案：每月 19 美元。

当一个已登录的用户点击”升级”时，把他送到 Stripe 托管的结账页面。不要做一个自定义卡表单——我的应用永远不该经手卡号。

支付成功后，在数据库里把这个用户标记为”已付费”，并为他解锁报表页面。支付失败或被取消后，把他带回定价页面并附上一条提示。

用一个 Stripe webhook 在服务端确认支付，然后才解锁任何东西——不要仅凭用户落回到一个成功页面就解锁。

最后那一段，正是把一个真实的支付流程和一个脆弱的支付流程区分开来的关键。让成功页面来解锁访问权，意味着任何人只要知道了那个成功页面的网址，就能免费解锁它。而 webhook——一条从 Stripe 直接发到你应用后端的、经过验证的消息——才是那个值得信赖的信号。你的 AI 构建器知道怎么设置这个；你只需要点名要它。

在真钱之前，用假钱测试

Stripe（以及大多数服务商）会给你一个测试模式，里面有一些行为像真卡一样的假卡号——包括会成功的卡、会被拒付的卡，以及会触发错误的卡。用上它。在哪怕一张真卡碰到你的应用之前，把每一条路径都走一遍：

一次成功的支付。该解锁的东西解锁了吗？用户的状态变成”已付费”了吗？
一张被拒付的卡。应用是优雅地处理了它，还是把用户晾在一个坏掉的界面上动弹不得？
一次被取消的结账——用户点了”返回”而不是付款。他们最后落到了一个合理的地方、并且仍然没升级吗？
付款，然后登出再登入。他们还是”已付费”吗？（这能抓出那些只为当前会话解锁访问权、到第二天就忘了的应用。）

向你的 AI 构建器要那些测试卡号，或者去你服务商的文档里查。一个常见的”这笔支付会成功”的测试卡，你的构建器一问就能给你。把这四种情形全跑一遍。被拒付的卡和被取消的结账这两条路径，是 AI 构建器最常留着不修好的，因为他们优化的是那条顺顺利利的主路径。

那些会花掉真金白银的错误

有几种特定的失效模式，在初次做支付流程时一次又一次地出现：

在成功页面而非 webhook 上解锁。 上面讲过了，但值得再说一遍，因为它是代价高昂的那个。如果你的应用在用户一落到 /success 的瞬间就解锁付费功能，那你就是在指望用户的浏览器诚实地交代他们到底付没付钱。他们并不总是诚实的。在 webhook 上解锁。

没有记录他们为什么付了钱。 如果你的应用只是翻动一个全局的”已付费：是”开关，那么一旦你有了不止一个方案、或者有人取消、或者你需要发起退款，你就会很头疼。把具体的东西存下来：哪个方案、什么时候、以及服务商为那笔支付给出的 ID。日后处理客服问题时你会用到它。

忘了订阅是会到期的。 一笔一次性支付很简单：付了就是付了。一份周期性订阅却可能失效——卡过期了，下个月的扣款失败了。如果你的应用只监听”他们付了钱”、从不监听”他们的订阅结束了”，那你就会有一批人在停止付款之后还免费保留着访问权。告诉你的构建器，把”订阅已取消或扣款失败”那条消息也处理上，而不只是处理成功。

因为价格存在两个地方而收错了金额。 如果价格既写在你应用的界面里，又设在你的支付服务商里，它们终究会逐渐对不上，然后某个客户会看到 $19、却被扣了 $29。把价格放在一个地方——你的服务商——然后让你的应用显示服务商所说的任何价格。唯一的事实来源。

上线前的一份简短清单

在你从测试模式切换到真钱之前：

我的应用里没有任何一个让人输入原始卡号的字段。
支付是由服务商发来的一个 webhook 确认的，而不是由用户到达一个成功页面确认的。
我已经测试过一次成功的支付、一张被拒付的卡，以及一次被取消的结账——这三种情况都表现得合情合理。
付款之后，登出后以及第二天，访问权仍然保持解锁。
我的应用记录了每个人为什么付了钱，而不只是记录他们付了钱。
如果一份订阅失效了，访问权会被自动移除。
我已经把服务商的密钥从测试模式切换到了正式模式（这个容易忘——你的第一个真实客户撞上测试密钥，会收到一个莫名其妙的错误）。

如果每一个框都打了钩，你就可以接收真卡了。如果没有，那就是你和你 AI 构建器的下一次对话该谈的——在你把链接分享出去之前，而不是在第一次争议之后。

有帮助的那种心态

钱，是你应用里”看起来能用”和”真的能用”相距最远的那个部分。一个坏掉的布局，你立刻就能看见。一个不验证付款就解锁访问权的支付流程，看起来完美无缺——直到有人发现了，并告诉了他的朋友。

所以，把支付流程当作你 AI 应用里唯一要像个怀疑论者那样去测试的部分。试着不付款就混进去。试着把它搞坏。付款之后，再试着把你的访问权弄丢。你花在试图骗过自己应用上的那 30 分钟，是你能为它买到的最便宜的保险。

正打算给你做的东西加上支付？打开你下一次 AI 构建器会话时，把整个流程一口气描述清楚——价格、结账、webhook 确认，以及解锁什么——而不只是要一个付款按钮。付款按钮是容易的那 10%。另外 90%，才是让钱来得诚实的关键。