如何给 Vibe Coding 产品加入支付：从周末项目到赚钱的生意

Stripe 路线：你的控制权等于你的责任

Stripe 是 Payment Processor（支付处理商）——它只处理卡交易。你是法律上的卖方。德国用户买的是你的服务。这意味着：你需要先在欧盟注册 VAT OSS（增值税一站式申报——非欧盟企业可在单一成员国注册后统一申报全欧盟消费者的 VAT），追踪 45 个美国州的 economic nexus 阈值（年销售额 >$100K 或 >200 笔交易即触发该州税号注册义务），每季度自行申报和汇款。Stripe Tax（+0.5% add-on）可以帮你计算税率，但申报和汇款仍是你自己的责任。chargeback 争议也由你直接与银行沟通。

费率 2.9% + $0.30 是行业内最低的——但这不是你全部的成本。请一个懂跨境税务的会计师通常超过 MoR 的费率溢价。Stripe 适合什么场景？你主要卖给美国 B2B 客户（税务简单）、或者你已有税务团队、或者你的产品在单一大市场且不需要处理多国合规。

对独立开发者还有一个致命的隐性成本：Stripe 的风控极其严格。新注册公司、AI/SaaS 类产品、交易量突然增长——这些在社区里是反复被冻结账户甚至封号的触发条件。Stripe 的开户和验证流程复杂，需要大量企业资料。争议（chargeback/dispute）费率为 $15/笔——对于 $20/月以下的订阅产品，一次争议事件就可能吃掉几个月的利润。如果你的产品是小额订阅、新注册公司、或品类在 Stripe 的高风险名单边缘——在选 Stripe 之前先评估被冻结的概率和替代方案（Paddle MoR 风控更宽松、Clink 手续简单）。

对 AI 生成的代码有一个额外问题：Stripe 是 AI 工具默认生成的支付方案。因为 Stripe 的文档在 LLM 训练数据中占比最大，任何 AI 生成的"加支付"代码几乎一定是 Stripe。但 AI 不会告诉你——如果你面向 180 国消费者，用 MoR 比 Stripe 省去的是几个月税务工作。

MoR 路线：把税务外包给平台

Merchant of Record（记录商户）平台——Paddle、Polar、Lemon Squeezy、Creem、Dodo Payments、Fungies——作为法律上的卖方出现。德国用户购买的是"平台提供的服务"，平台负责计算、代收、申报、汇款该国 VAT。你收到的是一笔净额支付（net payout），不接触任何税务文件。chargeback 由平台处理。

费率 4–5% + $0.40–0.50，比 Stripe 高 1.5–2%。但这笔差价本质是"税务合规外包费"——对于面向全球的 Solo founder，这个溢价通常低于自己请会计师的月度成本。更重要的是，你花在税务上的时间可以被用于产品迭代。

MoR 的另一个好处是集成快。大部分 MoR 提供托管 checkout——Fungies 是 30 分钟的 copy-paste embed，Creem 是一键 checkout link。对 vibe coding 场景来说，这意味着从"我决定收钱"到"支付已上线"可以是一个下午的事。

Clink 路线：PCI L1 中间层——既不是 PSP 也不是完整 MoR

Clink 是第三条路。它不以 MoR 自居（是否作为法律卖方因法域而异），而是以 PCI DSS Level 1（支付卡行业最高合规级别）认证的支付基础设施身份出现。核心价值是：开发者用 API 接入信用卡（Visa/Mastercard/Amex）、Apple Pay、Google Pay 及 100+ 本地支付方式——PCI 合规、卡数据处理、风控全在 Clink 侧。你的服务器永不接触原始卡号，保持 SAQ A 级别（最轻 PCI 负担）。

Clink 的公开定位是"AI 时代的支付红利不应只属于有加密钱包的人"——与 crypto-native 路线（FluxA/x402）形成对照。据公开报道完成 BV 等领投种子轮。对于用 Lovable/Bolt/v0 生成的 Web 应用、需要快速接入法币支付而不想自建 PCI 合规体系的独立开发者，这是介于 Stripe（全责）和 MoR（全外包税务）之间的务实选项。

需要注意：Clink 的税务责任可能仍在开发者侧（需核实 Clink 在目标法域的 MoR 资质）。如果你的核心痛点是税务合规而非 PCI 合规，传统 MoR（Polar/Creem）可能更直接。

MoR 平台一览：费率、覆盖、适配场景

Lemon Squeezy（5% flat）：内建 affiliate、license key、UI 最漂亮。适合数字产品和简单 SaaS。⚠️ 2024 年被 Stripe 收购，产品路线图不透明——选它需要评估未来的迁移成本。

Paddle（5% + $0.50）：180+ 国覆盖，B2B 特性最全，dunning recovery（付款失败自动挽回）业内最强。适合规模化 B2B SaaS。

Polar（4% + $0.40）：GitHub/Discord 集成、开源友好、原生用量计费（token/API 调用/seat 组合定价）。YC W24 出身。2026 年 AI SaaS 技术创始人中口碑上升。

Creem（3.9% + $0.40）：50+ 国覆盖，设计优先，内建 affiliate 和 revenue split。欧洲背景。适合注重 checkout 体验的订阅 SaaS。

Dodo Payments（4% + $0.40 base，国际卡 +1.5%）：220+ 国覆盖，40+ 本地支付方式（印度 UPI、欧洲 SEPA、巴西 Boleto）。如果你的用户分布在非信用卡主力市场，Dodo 的本地支付覆盖是关键差异化。

Fungies（2% 起步）：费率最低，30 分钟 copy-paste embed，明确以"vibe coding 支付"为定位。180+ 国覆盖。适合极速变现、费率敏感的项目——但生态成熟度不及 Polar/Paddle。

Stripe Managed Payments（private preview）

2024 年 Stripe 收购 Lemon Squeezy 后，2025 年 Stripe Sessions 宣布 Stripe Managed Payments——Stripe 自己成为 MoR。但截至 2026 年中，它仍是 private preview，有明确限制：仅支持 Stripe Checkout（不支持 Elements 自定义 UI）、仅限订阅制数字产品（一次性购买不支持）、定价未公开（第三方估算国际订阅综合费率可能达 9–12%）。对于已在 Stripe Checkout 上跑订阅的独立开发者，这是未来最方便的 MoR 路径。但对新项目，独立的 MoR 更成熟可用。

Lovable：Lovable Payments（Stripe + Paddle）

Lovable 在 2025–2026 年推出了 Lovable Payments——一个完全内置于 Lovable 的支付层。你只需要在对话中说"add payments to my app"，Lovable 的 AI Agent 会：① 分析你的产品类型；② 推荐 Stripe 或 Paddle（数字产品 + 全球销售通常推荐 Paddle MoR，低费率 + 美国为主推荐 Stripe）；③ 替你创建和管理支付平台账号——你不需要提前注册 Stripe 或 Paddle；④ 自动创建产品与定价、生成 checkout UI、配置 webhook、设置数据库 schema 和行级安全策略。整个过程是对话驱动的，无需写任何代码。

限制：需要 Pro 计划以上；每个项目只能选一个支付提供商（Stripe 或 Paddle，不能混用）；Paddle 审核 AI 类产品可能需数天至数周；没有从 Stripe 切换到 Paddle（或反过来）的直接迁移路径。如果你之前用了手动 Stripe Connector，需要先移除再启用内置支付。

Lovable Payments 的费率与直接在 Stripe/Paddle 开户相同——Lovable 不额外加价。Paddle 作为 MoR 处理全球 VAT 和销售税；Stripe 作为 PSP，你可以选择开启 Stripe Managed Payments（可选 MoR 模式，但仅限少数国家）。

Bolt.new：Native Stripe 集成

Bolt.new 提供了原生的 Stripe 集成：Settings → Stripe → 输入 API key → 点击"Retrieve my products"同步你的 Stripe 产品目录 → 然后对 Bolt 说"Add payments"。Bolt 自动生成 Supabase edge functions 来处理 checkout session 创建、webhook 处理、订阅状态管理。需要 Supabase 或 Bolt Database 作为后端。注意：默认 scaffold 仍需手动修复 bodyParser 配置（确保 raw body 签名验证）和 webhook URL 指向生产域名——详见本文安全漏洞节。

Replit：/stripe Agent 命令

Replit 通过 `/stripe` Agent 命令提供内置 Stripe 集成：输入命令 → Agent 自动配置 sandbox 环境 → 生成 checkout 流程和 webhook 处理器 → 密钥存储在 Replit Secrets 中。上生产时安装"Replit Integrated Payments"Stripe Marketplace app——它会自动将生产密钥注入你的项目，无需手动复制粘贴。

Replit 的 `/stripe` 集成已包含 webhook 签名验证——这是唯一明确宣称内置安全校验的 Builder 集成。

v0（Vercel）：Stripe Marketplace 集成

v0 基于 Vercel 生态——通过 Vercel Marketplace 一键安装 Stripe，API keys 自动注入为环境变量。v0 生成 Next.js 应用时可直接使用这些变量。2026 年 3 月起 Stripe Marketplace 集成进入 GA 状态，支持 sandbox 测试 → 一键切换生产密钥。

Cursor / Claude Code / Firebase Studio / Base44：无内置支付——需要本文方案

Cursor 和 Claude Code 是 AI coding 工具，不是应用托管平台——它们生成代码但不包含平台级支付集成。用它们搭的应用需要手动接入支付（本文所有外部方案都适用）。Firebase Studio 可对接 Firebase Extensions（如 Stripe Payments Extension），但非对话内"添加支付"。Base44 以生成 Web 应用为主，无内置支付。

还没选好用什么工具搭建应用？先看 AI 应用构建器选型指南 了解各平台差异，再回到本文选支付方案——因为 Builder 选对了，支付可能已经内置了。

路线一：Stripe Checkout（2–3 天，控制力最大，责任也最大）

① 创建 Stripe 账号 → 获取 API keys → 安装 stripe npm 包；② 在 Stripe Dashboard 创建 Product + Price；③ 写一个 API Route 创建 Checkout Session（返回 URL）；④ 前端按钮调用 API 拿到 URL → router.push(url) → 用户跳转到 Stripe 托管支付页；⑤ 写 webhook 端点——接收 checkout.session.completed 事件 → 验证签名 → 幂等去重 → 更新数据库中的订阅状态 → 返回 200；⑥ 用 Stripe CLI 本地测试 webhook；⑦ 配置 Stripe Customer Portal（用户自行管理订阅）。关键风险：你很可能没做签名验证——AI 默认跳过。详见下文安全漏洞节。

适用场景：Cursor / Claude Code 生成的 Next.js 应用；需要深度定制 billing 逻辑；已有税务团队或主做美国 B2B。如果你的 Builder 已内置 Stripe（Bolt/Replit/Lovable），优先用内置版本——平台替你处理了安全配置的大部分。

路线零：Builder 内置支付——最快，零代码（Lovable/Bolt/Replit/v0）

如果你的 Builder 内置了支付，这是最快路径。以 Lovable 为例：打开项目 → 在对话中输入"add payments to my app, charge $29/month" → Lovable Agent 分析产品类型，推荐 Stripe 或 Paddle → Agent 创建账号、产品定价、checkout UI、webhook、数据库 schema → 在 Payments Tab 中查看 revenue dashboard → 完成 KYC/KYB 验证 → 切换至 live 模式上线。全程对话驱动，不需要写一行支付代码。Bolt 用户走 Settings → Stripe 路径；Replit 用户用 `/stripe` 命令。

路线二：Lovable + Clink（1–2 小时，也可选；本文真实案例）

这是本文作者自建产品 Oginify 实际使用的路径。注意：Oginify 在 Lovable Payments 正式发布前就已接入 Clink——如果你的 Lovable 项目今天才开始，优先尝试 Lovable Payments（路线零）。但 Clink 路径对以下场景仍有价值：你的 Builder 没有内置支付（Cursor/Claude Code）；Lovable Payments 的 Stripe/Paddle 选项不满足你的需求（如需 PCI L1 合规保障而非税务外包）；你已经用了 Clink 且不想迁移。

具体步骤：① 注册 Clink 账号 → 获取 API key；② 在 Clink Dashboard 创建产品与定价（一次性或订阅）；③ 在 Lovable 前端调用 Clink API 创建 checkout session → 跳转到 Clink 托管支付页；④ 后端（Vercel Serverless Function 或 Supabase Edge Function）接收 webhook → 更新用户权限；⑤ 本地测试 → 上线。Clink 的 PCI L1 意味着你不需要自建 PCI 合规——卡数据永不经过你的服务器。

路线三：Polar / Creem / Dodo（30 分钟–2 小时，完整 MoR）

Polar：注册 → 创建产品和定价模型（订阅/用量/seats/credits 组合）→ 安装 @polar-sh/nextjs 包 → 用 Polar 的 React 组件渲染 checkout。适合需要用量计费的 AI SaaS。Creem：注册 → 创建产品 → 获取 checkout link → 粘贴到页面中。Dodo：注册 → 创建产品 → 选择支付方式（40+ 本地方式）→ 嵌入 checkout。这三家的共同点是：不需处理税务文件、不需 PCI 合规、集成路径短。

路线四：Fungies（30 分钟，极速路线）

显式面向 vibe coding 受众——注册 → 创建产品 → 复制 <script> 标签和 <div> → 粘贴到你的页面 → 完成。30 分钟从零到收钱。2% 起步费率是 MoR 中最低的。适合"我就想先收钱看看有没有人买"的验证阶段。

漏洞一：Webhook 签名从未被验证

Stripe 发送 webhook 时附带 Stripe-Signature HTTP header——其中包含用你的 whsec_ 密钥对原始请求体（字节级）计算的 HMAC-SHA256 哈希。你的服务器必须用同一密钥重新计算并比对——匹配则来源可信。如果 AI 生成的代码跳过了这一步（它几乎一定会跳过），任何知道你的 webhook 端点 URL 的人都可以 POST 伪造的 checkout.session.completed 事件——不花一分钱解锁付费功能。

修复四步：① 路由使用 express.raw({ type: 'application/json' }) 而非全局 express.json()（签名验证需要原始字节，JSON 解析后再序列化字节序列不同，验证永远失败）；② 读取 req.headers['stripe-signature']；③ 调用 stripe.webhooks.constructEvent(rawBody, signature, process.env.STRIPE_WEBHOOK_SECRET)——失败直接抛异常；④ 验证失败返回 400。在 Next.js 中，需在 API Route 文件顶部加 export const config = { api: { bodyParser: false } }。

关键认知：修复只需 4 行代码——但你必须显式要求 AI 做这件事。默认 prompt 不会触发。

漏洞二：客户端价格可被篡改

AI 生成的 checkout 有时把 amount 或 price 放在前端请求体中传到服务端创建 Checkout Session。攻击者在浏览器 DevTools 或抓包工具中改数值即可付任意价格——把 $99 改成 $1。修复：服务端创建 Checkout Session 时只使用 Stripe Dashboard 中预定义的 Price ID（price_xxx）——金额在 Stripe 侧锁定，客户端最多传 priceId 标识符，绝不能传数值。

漏洞三：密钥泄露到前端 bundle

AI 可能把 sk_live_（Stripe 生产密钥）放在 Next.js 中 NEXT_PUBLIC_ 前缀的环境变量中。Next.js 构建时会将 NEXT_PUBLIC_* 变量内联到前端 JavaScript bundle——任何打开网站的人都能在浏览器 Sources 面板中看到你的生产密钥。拿到密钥的攻击者可以直接通过 Stripe API 退款、创建 payment、读取所有客户数据。规则：sk_live_ 和 whsec_ 永不进入前端 bundle；仅用 pk_live_（可发布密钥，设计为可公开）。

给 AI 的安全 prompt 模板

如果你用 AI 生成支付代码，把这个 prompt 加进去：

Add Stripe Checkout payments. Create a checkout session on the server using a Stripe Price ID (price_xxx) from an environment variable. On the webhook endpoint, verify the Stripe-Signature header using stripe.webhooks.constructEvent with the raw request body (disable body parsing). Deduplicate events by storing the Stripe event ID in the database. Return 200 immediately and process the event asynchronously. Never expose the Stripe secret key or webhook secret to the frontend.

测试 webhook 用 Stripe CLI：stripe listen --forward-to localhost:3000/api/webhooks/stripe——本地也能收到真实签名的 Stripe 事件。除了测试 checkout.session.completed（支付成功），还要测 invoice.payment_failed（付款失败——触发催款邮件）和 customer.subscription.deleted（取消订阅——收回权限）。

技术栈起点：Lovable SPA

Oginify 是一个通过 Lovable 构建的 Web 应用。Lovable 的默认产物是 React/Vite + Tailwind 单页应用（SPA）——没有 SSR，没有后端路由。产品功能在 Lovable 内通过对话迭代完成。当产品可以给早期用户试用时，下一个问题是：怎么收钱。

为什么当时选 Clink 而不是 Stripe（以及今天为什么首选 Lovable Payments）

当时选 Clink 的原因：第一，Lovable SPA 没有后端，Stripe 完整集成需要额外搭建 Serverless Function。Clink 的 checkout 流程更轻：前端调用 API → 跳转托管支付页 → 后端只处理 webhook。第二，PCI 合规——Clink 的 PCI L1 认证意味着卡数据处理和风控全在 Clink 侧。第三，想支持信用卡 + Apple Pay 但不想维护卡数据基础设施。

但最关键的决策因素是 Stripe 本身的风险：Stripe 风控极其严格——独立开发者、新注册公司、AI/SaaS 类产品在 Stripe 被冻结账户甚至封号是社区里反复出现的问题。Stripe 的开户和验证流程复杂，需要提交大量企业资料。此外，Stripe 的争议（chargeback/dispute）费率高达每笔 $15——对于小额订阅产品，一次争议事件就能吃掉几个月的利润。Clink 在这些维度上更友好：手续简单、风控逻辑更包容早期项目、争议处理成本更低。

今天（2026 年中）的答案：如果你用 Lovable 搭新项目，首选 Lovable Payments。它在对话中说"add payments"，AI Agent 替你创建 Stripe/Paddle 账号、产品定价、checkout UI、webhook、数据库 schema——零代码完成。Lovable Payments 的背后就是 Stripe 和 Paddle，但不需你自己处理复杂的集成配置。但 Lovable Payments 的 Stripe 路线仍继承 Stripe 的风控风险——如果你担心封号，Lovable Payments 的 Paddle 路线（MoR，风控更宽松）或外部 Clink（PCI L1，手续简单）是更安全的选择。唯一的考虑：Paddle 对 AI 类产品可能需要数天至数周审核；如果你要立即上线且担心 Stripe 风控，Clink 仍是一个有效的替代路径。

接入流程（约 1–2 小时）

① 注册 Clink 账号，获取 API key。② 在 Clink Dashboard 创建产品——Oginify 定价为 $1/月订阅起步。③ 在 Lovable 前端加 checkout 按钮——调用 Clink API 创建 checkout session → 用户跳转到 Clink 托管支付页（含信用卡输入、Apple Pay 等选项）。④ 设置 webhook 端点（Vercel Serverless Function）——接收 Clink 的支付成功通知 → 更新用户权限。⑤ 本地测试 → 上线。

支付界面见本文 Hero 截图：用户在 Clink 的托管支付页输入信用卡信息，Oginify 完全不接触卡数据。这保持了 SAQ A 级别的 PCI 负担——独立开发者可维护的最小合规面。

从中可以抄什么

第一，先确定 AI 构建器的产物形状再选支付——Lovable 出的是 SPA，后端需要额外搭建，选的支付方案必须适配这个架构。第二，PCI 合规不是"先不做等以后补"——第一天收钱就需要。选一个替你承担 PCI 的方案比以后被要求补审更经济。第三，支付方案选型不是"哪个最好"，而是你的 Builder 产物形状 + 目标市场 + 合规容忍度的交叉点。

第一步：先检查你的 Builder 是否已内置支付

这是最重要的一步，放在第一步。2026 年，主流 AI App Builder 都已内置支付：Lovable（Lovable Payments：Stripe + Paddle，零代码对话添加）、Bolt.new（Settings → Stripe，自动生成 Supabase edge functions）、Replit（/stripe 命令，自动配置 sandbox + webhook）、v0（Vercel Marketplace Stripe 集成，自动注入密钥）。如果你的 Builder 已内置支付且满足以下条件：① 覆盖你的目标市场（Paddle 处理全球税务 vs Stripe 适合美国为主）；② 支持你的计费模式（订阅/一次性）；③ 审核等待时间可接受（Paddle AI 产品可能需数天至数周）——用内置方案，不要选外部方案。

如果内置方案不满足（如需要用量计费、需要 PCI L1 合规而非 MoR 税务外包、或是用 Cursor/Claude Code 无内置支付），再往下看。

第二步：确定你的技术栈形状

如果你需要用外部方案，先确认 AI 构建器的产物形状。Lovable 和 Bolt 默认出 SPA（React/Vite，无 SSR）——支付集成的前端部分在平台内完成，后端部分需要额外搭建（Serverless Function）。v0 默认出 Next.js（SSR 可用）——支付集成可以走完整的 API Route + webhook 模式。Replit Agent 可出全栈应用——支付集成自由度最高。你的 Builder 的产物形状决定了支付集成的后端复杂度：SPA 产物优先考虑后端需求少的方案（Clink、Fungies embed），Next.js 产物可以走 Stripe 或 Polar 的完整集成。

第三步：你的用户在哪

如果你主要卖给美国用户——Stripe 足够，美国 B2B 税务简单。如果你卖全球消费者——MoR（Polar、Creem、Dodo、Fungies）的税务外包价值远远超过费率溢价。如果你的用户在印度、巴西、东南亚等非信用卡主力市场——Dodo Payments 的 UPI/Boleto 等本地支付方式是关键差异化，没有本地支付方式的 checkout 流失率可能高 30–50%。

第四步：你需要 MoR 的税务外包吗

如果你在一个国家注册且只卖该国——Stripe 足够。如果你卖多国但年销售额低于各州/国的 economic nexus 阈值——Stripe + Stripe Tax 可能够用。如果你卖多国且触发了阈值——MoR 的 1.5–2% 费率差通常低于自己请跨境会计师的月度成本。更重要的是，税务合规消耗的是注意力——独立开发者最稀缺的资源。

注意：Lovable Payments 的 Paddle 路线自带 MoR——如果 Lovable 推荐了 Paddle，你已经有了 MoR 税务外包。

第五步：你的 PCI 合规容忍度

PCI DSS 分 SAQ A（最轻——卡数据不经过你服务器）到 SAQ D（最重——自建支付页，数百项控制）。Stripe Checkout → SAQ A；Stripe Elements → SAQ A；Clink → SAQ A（PCI L1 在 Clink 侧）；MoR → SAQ A 或完全免除；Lovable Payments / Bolt Stripe / Replit /stripe → SAQ A（平台处理卡数据）。自己处理原始卡号 → SAQ D（季度扫描、渗透测试、大量文书——独立开发者几乎不应该选这条）。结论：无论选什么方案，保持 SAQ A 级别——永远不要让原始卡号经过你的服务器。

第六步：集成速度与计费复杂度

如果你要极速验证"有人愿意付钱吗"——Fungies（30 分钟 embed）或 Creem（checkout link）。但如果你用 Lovable，Lovable Payments 可能更快（对话中添加，无需跳出平台）——只是 Paddle 审核可能需要数天。如果你要做用量计费（token/API 调用按量收费）——Polar 或 Dodo 原生支持，Stripe 需额外 metering 层。如果你需要 deep customization——Stripe 是唯一选择但付出的是时间（2–3 天）和税务责任。记住：先收钱，再优化计费模型——不要因为"未来可能需要用量计费"推迟今天的支付上线。