# 托管式与自托管式支付网关：哪种适合你的 SaaS？ > 托管式与自托管式支付网关对比：PCI 合规范围、控制力、集成速度，以及哪种模式适合 SMB SaaS、企业级 SaaS 和全球化产品驱动型公司。 - **Author**: Ayush Agarwal - **Published**: 2026-06-08 - **Category**: Payments, Architecture, SaaS - **URL**: https://dodopayments.com/blogs/zh/hosted-vs-self-hosted-payment-gateway --- 托管式支付网关是指由服务商在其服务器上运行完整结账基础设施，并将客户重定向到其域名下输入支付信息的支付网关。自托管式（或"商户端托管"）支付网关则运行在你自己的基础设施上，由你掌控结账流程，并在应用中处理卡片数据。 这种区别听起来很技术化，但它会决定 PCI 合规范围、集成速度、品牌灵活性，以及在产品整个生命周期中你需要投入多少工程工作。本指南将解释这两种模式，并帮助 SaaS 创始人选择适合自己的方案。 ## "托管式"究竟是什么意思 支付网关采用托管模式时，服务商会托管收集卡片数据的页面。典型流程如下： 1. 客户在你的 SaaS 中点击"支付" 2. 你的后端向支付网关创建结账会话 3. 客户被重定向到支付网关域名下的 URL（或看到由支付网关提供的 iframe） 4. 客户在支付网关托管的页面上输入卡片信息 5. 支付网关扣款，并将客户返回你的网站，同时传回成功或失败状态 卡片数据完全不会接触你的服务器。从 PCI DSS 的角度看，这会大幅缩小你的合规范围（通常为 SAQ A，这是最简单的级别）。 托管式支付网关流程的示例包括：Stripe Checkout（重定向模式）、PayPal Checkout、Square 托管式结账，以及在 iframe 中渲染表单的[浮层结账](https://docs.dodopayments.com/developer-resources/overlay-checkout)产品。 ## "自托管式"究竟是什么意思 自托管式支付网关是指你的应用在自己提供的页面上收集卡片数据。卡号、有效期和 CVV 会在发送到支付网关 API 的过程中经过你的服务器（或至少经过应用的前端）。 典型流程如下： 1. 客户在你的结账页面输入卡片信息 2. 你的前端或后端将卡片数据发送到支付网关 API 3. 支付网关扣款并返回结果 4. 你的应用显示成功或失败状态 这种模式让你完全掌控 UI 和客户体验。代价是 PCI 合规范围大幅扩大。如果原始卡片数据曾接触你的服务器，你就会进入 SAQ D（要求最严格的级别）或更高等级，并承担大量合规工作。 如今，大多数"自托管式"实现实际上都会使用**客户端令牌化**，以避免原始卡片数据进入后端： - 你的前端使用支付网关的 JavaScript SDK - SDK 在客户端将卡片信息令牌化，并直接发送给支付网关 - 你的服务器始终只会看到令牌，而不是原始卡片数据 - 这样既能让 PCI 合规范围保持在可控水平（SAQ A-EP），又能让你掌控 UI 示例包括：Stripe Elements、[内嵌式结账](https://docs.dodopayments.com/developer-resources/inline-checkout)集成，以及 Braintree 的托管字段。 ## 快速对比 | 维度 | 托管式 | 自托管式（采用令牌化） | | -------------------------- | ---------------------- | ------------------------------ | | 你的服务器上是否有卡片数据 | 否 | 否（采用 SDK 令牌化） | | PCI 合规范围 | SAQ A（最轻量） | SAQ A-EP（较轻，但高于 SAQ A） | | UI 控制权 | 有限（采用服务商设计） | 完全控制 | | 集成时间 | 数小时到数天 | 数天到数周 | | 对转化率的影响 | 重定向会带来轻微摩擦 | 转化率最佳（无需重定向） | | 移动端体验 | 重定向时有时不够流畅 | 原生、无缝 | | 品牌展示 | 与服务商联合展示品牌 | 完全使用你的品牌 | | 维护负担 | 由服务商处理 | 由你处理 UI 变更 | 对于大多数早期 SaaS，托管式是更合适的选择，因为它上线最快，并且能将 PCI 合规范围降到最低。对于重视结账转化率的中端市场和企业级 SaaS，采用令牌化的自托管式通常值得额外的工程投入。 ## 什么时候选择托管式 在以下情况下，可以选择托管式支付网关： - 你处于早期阶段，需要在几天内而不是几周内上线 - 团队的支付专业知识有限 - PCI 合规让你感到棘手，希望尽量缩小合规范围 - 结账量较低，可以接受几个百分点的转化率损失 - 客户已经习惯基于重定向的结账流程（B2B SaaS、市场平台） 你需要接受的取舍是：品牌展示会有所妥协，重定向会带来一些摩擦，而且对用户体验细节的控制有限。 ## 什么时候选择自托管式（采用令牌化） 在以下情况下，可以选择自托管式： - 结账转化率会直接影响收入（面向消费者的 SaaS、高速增长的 SMB） - 需要在整个流程中保持一致的品牌体验（高端定位） - 希望持续对结账元素进行 A/B 测试 - 正在集成多种适合通过统一 UI 呈现的支付方式 - 有足够的工程资源维护定制结账流程 需要接受的取舍是：前期工程工作更多，PCI 合规范围略大，并且随着支付方式的发展需要持续维护。 ## 什么时候两者都不选：使用 MoR（名义商户） 还有第三种选择，可以绕开这两者之间的取舍。[MoR（名义商户）](https://dodopayments.com/blogs/what-is-a-merchant-of-record)（Merchant of Record）服务商，例如 Dodo Payments，可以为你处理完整的支付、税务和合规体系。你仍然可以在以下两种模式之间选择： - **采用托管式结账的 MoR（名义商户）**（[浮层结账](https://docs.dodopayments.com/developer-resources/overlay-checkout)）：集成速度最快，客户会短暂地由 MoR（名义商户）的结账页面处理 - **采用内嵌式结账的 MoR（名义商户）**（[内嵌式结账](https://docs.dodopayments.com/developer-resources/inline-checkout)）：控制力更强，客户始终留在你的 UI 中，同时 MoR（名义商户）仍然承担法律卖方角色 在这两种情况下，MoR（名义商户）都会承担销售税注册、增值税申报、拒付责任，以及覆盖 190 多个税务辖区和 220 多个国家和地区的全球合规工作。托管式还是自托管式的问题，就变成了用户体验选择，而不是合规选择。 > 过去，托管式与自托管式的决定主要取决于 PCI 合规范围。借助现代令牌化 SDK，两种模式都能满足 PCI 友好要求。如今真正的问题是转化率、品牌一致性，以及你是否希望自己掌控结账体验，还是将其交给他人处理。 > > \- Ayush Agarwal，Dodo Payments 联合创始人兼 CPTO ## 详细了解 PCI 合规范围 PCI DSS 标准会根据集成类型定义不同的自我评估问卷（SAQ）： | SAQ 级别 | 适用情况 | 审计负担 | | -------- | ----------------------------------------------- | ---------------- | | SAQ A | 卡片数据完全外包给重定向页面或 iframe（托管式） | 最低 | | SAQ A-EP | 通过支付网关 SDK 在你的域名下进行令牌化 | 较低 | | SAQ D | 卡片数据会接触你的服务器 | 高，通常需要 QSA | | 1 级审计 | 每年交易超过 600 万笔 | 每年进行外部审计 | 对于几乎所有 SaaS 使用场景，目标都是保持在 SAQ A 或 SAQ A-EP。主动达到 SAQ D 或更高等级会带来巨大的持续成本，几乎没有哪个 SaaS 创始人应该主动承担这种负担。 托管式支付网关会让你明确处于 SAQ A。采用令牌化的自托管式集成会让你处于 SAQ A-EP。对于小型团队来说，这两种范围都可控。 ## 实际案例 ### 一周内上线的早期 SaaS 使用 Stripe Checkout（托管式）或 Dodo Payments 浮层结账。跳过定制 UI 开发。先实现收入，了解客户真正关心什么，再在之后持续迭代。 ### 专注优化转化率的消费者 SaaS 使用 Stripe Elements 或 Dodo Payments 内嵌式结账。让客户在整个支付流程中都留在你的品牌 UI 内。持续对按钮颜色、布局和文案进行 A/B 测试。 ### 采用年度合同的 B2B SaaS 面向自助服务客户使用托管式结账。面向年度企业合同使用开票计费（可选 ACH/电汇）。这种组合是 B2B SaaS 的标准做法。 ### 全球化的产品驱动型 SaaS 使用 MoR（名义商户），并根据转化率目标选择适合的结账模式（浮层或内嵌式）。MoR（名义商户）会自动处理税务、合规和本地支付方式。 ## 托管式支付网关经常隐藏的细节 关于托管式支付网关产品，有一些事情并不总是显而易见： ### 1. 基于重定向的转化率损失 一些研究显示，当客户被重定向到第三方域名完成结账时，流失率会增加 5% 到 15%。这一比例会因受众和品牌而有很大差异。对于低客单价、高交易量的 SaaS，即使 5% 也很重要。对于买家意愿较高的 B2B SaaS，影响通常可以忽略不计。 ### 2. 定制能力有限 托管式结账页面通常可以配置颜色、Logo 和少量字段选项，但你无法重新排列布局或添加自定义字段。如果你的订阅服务需要收集特殊的注册信息，你可能最终要在结账前页面收集这些信息，从而割裂整个流程。 ### 3. 本地化差异 托管式结账通常能很好地支持主要语言和支付方式，但在长尾市场可能存在覆盖不足。自托管式则允许你自由组合所需的支付方式覆盖范围。 ## 自托管式通常需要付出什么代价 自托管式结账有一些隐藏的持续成本： - 初始工程开发（根据范围不同，需要 1 到 4 个工程师周） - 随着支付网关 SDK 版本更新而进行持续维护 - 在不同浏览器和设备上进行移动端测试 - 用于转化率优化的 A/B 测试基础设施 - 添加支付方式时进行合规审查 如果财务预测将自托管式视为一次性集成成本，那就是错误的。你需要规划每月持续投入 5% 到 10% 的工程时间来维护它。 ## 两种路径都仍然需要验证 托管式与自托管式的选择会改变卡片数据的存储位置，以及你需要承担的 PCI 合规范围。但它不会改变你是否需要接受验证。 无论采用哪种方式，受监管的服务商都必须确认你的法律实体，将所有权映射到自然人，并在向你结算资金前对这些人员进行筛查。账户模式改变的是责任范围：在直接商户账户模式下，收单机构会为你完成入驻并负责卡组织注册；而在 MoR（名义商户）模式下，MoR（名义商户）持有这层关系，并验证作为资金结算对象的你。 我们的 [KYB 验证指南](https://dodopayments.com/blogs/kyb-verification)介绍了两种路径分别需要哪些材料，[MoR（名义商户）与 PSP 的区别](https://dodopayments.com/blogs/merchant-of-record-vs-psp)则介绍了两者的结构性差异。 ## 常见问题 ### 托管式支付网关比自托管式更安全吗？ 两者都可以符合 PCI 要求。托管式是达到 SAQ A 的最简单路径。正确进行令牌化的自托管式属于 SAQ A-EP，同样是可控的。应避免让原始卡片数据进入服务器的实现方式（这会触发 SAQ D，合规负担很重）。 ### 托管式结账会降低转化率吗？ 有时会。基于重定向的托管式结账由于多了一个步骤，可能导致 5% 到 15% 的转化损失。使用 iframe 或浮层、让客户留在你域名下的托管式结账，通常对转化率影响很小。 ### 哪种托管式支付网关集成速度最快？ 现代托管式结账产品可以在数小时内完成集成。对于简单产品，Stripe Checkout、PayPal 和 Dodo Payments 浮层结账都可以在一天内完成集成。定制结账流程则需要数天到数周。 ### 我应该构建一个完全定制的自托管式支付页面吗？ 只有在你有明确理由时才应该这样做（例如交易量非常高、需要独特的用户体验，或有托管式方案无法满足的品牌要求）。对于大多数 SaaS，托管式或采用令牌化的内嵌式结账是更好的取舍。 ### MoR（名义商户）如何适用于托管式与自托管式？ MoR（名义商户）可以提供这两种模式。你仍然可以在托管式和内嵌式之间选择，但 MoR（名义商户）会为你的所有客户承担税务、合规和拒付处理。托管式与内嵌式之间的选择就完全变成了用户体验选择，而不是合规选择。 ## 结论 --- - [More Payments articles](https://dodopayments.com/blogs/category/payments) - [All articles](https://dodopayments.com/blogs)