# SaaS 平台嵌入式支付：2026 年实现指南 > 现代 SaaS 平台如何添加嵌入式支付，同时避免成为支付公司。涵盖架构、合规、收入分成和实现模式。 - **Author**: Ayush Agarwal - **Published**: 2026-04-29 - **Category**: Payments, SaaS, Integration - **URL**: https://dodopayments.com/blogs/zh/embedded-payments-saas-platforms --- 嵌入式支付意味着客户无需离开你的应用即可完成付款。实际上，SaaS 平台通常会从三种架构中选择一种来实现：基于 iframe 的内嵌式结账、模态弹窗覆盖层，或使用客户端令牌化的原始卡片 API。前两种方案可让你保持在 SAQ-A 范围内，大约一周即可上线。第三种方案提供完整的 UI 控制权，但会让你进入完整的 PCI-DSS 合规范围。 这个选择基本决定了大部分方案。虽然如此，剩余的实现工作并不简单：嵌入式支付涉及 PCI 合规、资金转移法律、结算风险、风控筛查和客户支持。大多数尝试自行构建嵌入式结账的创始人，最终都会得到一个每次发布都可能出问题的"弗兰肯斯坦式"集成。 本指南将介绍如何在 2026 年为 SaaS 产品添加嵌入式支付，同时避免承担成为支付公司的监管负担。内容涵盖架构选择、合规权衡，以及适用于不同 SaaS 垂直领域的实践模式。 ## 嵌入式支付究竟是什么 嵌入式支付意味着客户无需离开你的应用即可付款。卡片表单、成功状态、收据和订阅管理都存在于你的 UI 中。 这与托管式结账不同：在托管式结账中，客户点击按钮后会被重定向到第三方域名。托管式结账适合一次性购买，但不适合经常性 SaaS 收入，因为让客户留在应用内通常可以带来 15% 到 25% 的转化提升。你可以在 [内嵌式结账与托管式结账](https://dodopayments.com/blogs/inline-vs-hosted-checkout) 中并排比较这些权衡。 嵌入式支付也不同于"支付即平台"模式。在后者中，你让自己的客户（平台上的商户）接受付款。两者的模式有重叠，但当你为第三方促成支付时，需要面对的合规范围要大得多。 > 我最常看到的错误，是创始人把嵌入式支付和支付促成混为一谈。嵌入式支付意味着让客户的结账流程留在应用内；支付促成意味着让你的客户的客户完成付款。它们不是同一个问题，监管分量也完全不同。 > > - Ayush Agarwal，Dodo Payments 联合创始人兼 CPTO ## SaaS 平台为何嵌入支付 三个因素推动了这一决策： 1. **转化率。** 每次将客户重定向到第三方域名，都会损失一部分客户。嵌入式结账能够切实提升转化率，尤其是在移动设备上。 2. **品牌一致性。** 客户不应该在购买过程中感觉自己被转交给了别人。从你的应用无缝过渡到陌生域名上的支付表单，会破坏信任。 3. **订阅管理。** 当客户可以在你的应用内管理订阅、更换卡片或取消订阅时，留存率会提高。让客户前往第三方门户取消订阅，会让人感觉不够友好。 如需进一步了解转化影响，请参阅我们关于 [定价页面转化优化](https://dodopayments.com/blogs/pricing-page-conversion-optimization) 的深度文章，以及 [本地化支付方式为何能带来更高转化率](https://dodopayments.com/blogs/why-localized-payment-methods-are-important-for-higher-conversions) 的分析。 ## 嵌入式支付的三种架构 大多数 SaaS 平台会选择三种模式之一。每种模式都在控制力和复杂性之间做出不同权衡。 ```mermaid flowchart LR A[SaaS Application] --> B{Architecture Choice} B -->|Pattern 1| C[Inline Checkout] B -->|Pattern 2| D[Overlay Checkout] B -->|Pattern 3| E[Raw Card API] C --> F[iframe in your page] D --> G[Modal over your app] E --> H[Custom UI + tokenized card] F --> I[Lowest PCI scope] G --> I H --> J[Highest PCI scope] ``` ### 模式 1：内嵌式结账（基于 iframe） 支付服务商会将支付表单渲染为页面内的 iframe。你可以控制周围的布局，而卡片表单则处于沙箱环境中。 这种模式可以让你不进入 PCI 合规范围（只需遵守 SAQ-A）。对于 80% 的 SaaS 平台来说，这是正确的选择。具体实现请参阅 [内嵌式结账文档](https://docs.dodopayments.com/developer-resources/inline-checkout)。 ### 模式 2：覆盖层结账（基于模态弹窗） 支付服务商会在你的应用上方打开一个模态弹窗，用于完成支付步骤。客户在视觉上不会离开你的域名，但从技术上看，模态弹窗是由服务商加载的。 与内嵌式结账相比，可控性略低，但通常更容易集成。对于希望快速上线、又不想管理 iframe 在不同屏幕尺寸下的大小问题的 SaaS 平台来说，这是正确的选择。请参阅 [覆盖层结账文档](https://docs.dodopayments.com/developer-resources/overlay-checkout)。 ### 模式 3：原始卡片 API（完全控制） 你自行构建卡片表单，由支付服务商提供令牌化端点。你将令牌而不是原始卡片数据发送到支付 API。 这是最灵活、也最危险的选项。你需要承担 PCI-DSS 一级合规责任，以及卡片表单中任何客户端漏洞所带来的责任。只有在 iframe 结账无法满足特定 UI 要求，并且你拥有安全团队提供支持时，才应使用此方案。该方案触发的义务详见 [原始卡片 API 与 PCI 合规](https://dodopayments.com/blogs/raw-card-api-pci-compliance)。另请参阅 [原始卡片 API 文档](https://docs.dodopayments.com/developer-resources/raw-card-api)。 如需深入了解结账集成模式，请参阅 [结账会话文档](https://docs.dodopayments.com/developer-resources/checkout-session)。 ## 选择正确的模式 使用以下决策矩阵： | 场景 | 推荐模式 | 原因 | | ------------------------------------------------------ | ------------------- | ------------------------------------------------ | | 标准 SaaS 订阅结账 | 内嵌式（iframe） | PCI 范围最低，在 iframe 选项中拥有最高设计控制力 | | 移动端占比较高的产品 | 覆盖层（模态弹窗） | 模态弹窗比 iframe 更适合小屏幕 | | 采用自定义结账流程的市场或平台 | 内嵌式 + 自定义会话 | 在控制力和 PCI 最小化之间取得平衡 | | 具有非标准支付 UX 的产品（独特的表单布局、自定义验证） | 原始卡片 API | 唯一能够提供完整 UI 控制权的选项 | | 没有安全团队的公司 | 内嵌式（iframe） | 默认避免进入 PCI 合规范围 | ## 实现步骤：内嵌式结账 不同支付服务商的实现模式大致相同。以下是使用 Dodo Payments 时的示例。 ```javascript import DodoPayments from "dodopayments"; const client = new DodoPayments({ bearerToken: process.env["DODO_PAYMENTS_API_KEY"], }); // Server: create a checkout session const session = await client.checkoutSessions.create({ product_cart: [{ product_id: "pdt_pro_plan_monthly", quantity: 1 }], customer: { email: "customer@example.com", name: "Customer Name" }, return_url: "https://yourapp.com/success", }); // Client: render the iframe with session.checkout_url //