# 原始卡片 API 与 PCI 合规：SaaS 现实检查 > 原始卡片 API 让你完全控制支付表单，但也会大幅扩大 PCI 范围。了解这种取舍什么时候合理，以及什么时候绝对不值得。 - **Author**: Ayush Agarwal - **Published**: 2026-05-16 - **Modified**: 2026-10-06 - **Category**: Compliance, Checkout - **URL**: https://dodopayments.com/blogs/zh/raw-card-api-pci-compliance --- 大多数 SaaS 和 AI 产品永远不需要考虑原始卡片 API。支付服务商提供的托管式或内嵌式结账可以通过一次集成处理银行卡、电子钱包、本地支付方式、风控筛查和 PCI 合规。服务商的框架负责收集卡片数据，服务商负责结算支付，商户从始至终都看不到卡号。 但也有一些产品确实需要更多控制权。例如，需要自定义流程的支付表单、支付服务商 UI 无法支持的优化、与旧系统的集成，或只能提供原始卡片 API 的一次性支付处理商。对于这些产品来说，取舍是真实存在的。你获得了控制权，同时也会让自己承担更大的 PCI 合规范围，以及实际的工程和审计成本。 本文将介绍什么是原始卡片 API、PCI 合规在实际中意味着什么、什么时候这种取舍值得，以及 Dodo Payments 如何看待这一能力范围。 ## 什么是原始卡片 API 原始卡片 API 会直接在请求正文中接收卡号、有效期、安全码和持卡人姓名。你的应用代码或前端会将这些字段提交给服务商。服务商授权支付、返回结果，然后你的应用继续执行后续流程。 与之相对的是托管式或嵌入式表单：卡片数据会从买家的浏览器直接发送到服务商提供的框架中。你的应用永远不会看到卡号，只会看到代表已保存支付方式或已完成支付的令牌或标识符。 原始卡片 API 存在的原因，是某些集成需要让数据流经商户系统。例如，卡片已经通过其他渠道收集的旧版企业集成；商户希望完全控制输入体验的自定义移动应用；通过自身流程提交卡片的第三方系统；以及某些商户选择自行处理卡片数据并承担相应合规范围的合规项目。 对于这些场景，这项能力确实很有用。接下来，我们将详细说明使用它所需付出的成本。 ## PCI 合规在实际中意味着什么 PCI DSS，即支付卡行业数据安全标准（Payment Card Industry Data Security Standard），是规范卡片数据处理方式的安全标准。任何存储、处理或传输持卡人数据的组织都必须遵守它。该标准并不是只有一个版本的一套单一规则，而是一个分级框架：你的义务会随着卡片数据的处理方式和交易量而变化。 PCI 在实际中如何适用于你的业务，取决于所谓的合规范围。范围是指接触卡片数据的系统和流程。范围越小，需要覆盖的系统越少、审计点越少、需要实施的控制越少，合规问卷也会短得多。 最小的范围是 SAQ A。当你的环境完全不接触卡片数据，而是由完全外包的服务商通过托管页面或直接交付的嵌入式框架处理全部数据时，就属于这一范围。SAQ A 是一份简短文档，审计成本很低；大多数通过 MoR（名义商户）使用托管式或内嵌式结账的 SaaS 产品都会属于这一范围。 再上一级是 SAQ A EP。当你的环境不存储卡片数据，但负责提供收集卡片数据的页面时，即使数据会直接发送给服务商，也适用这一范围。此时问卷更长，需要对页面交付实施特定控制，合规范围也会扩大。 再往上是 SAQ D 和完整的 PCI DSS Level 审计。当你的环境实际接收卡片数据时，就属于这些范围。控制要求数量多且细致，包括传输加密、静态数据加密（如果你存储了任何数据）、访问控制、日志记录、漏洞管理、定期渗透测试、员工培训、网络分段，以及一长串其他义务。对于交易量较大的企业，还需要由合格安全评估师出具完整的合规报告（Report on Compliance），这是一项真正的年度项目，具体成本取决于公司规模，可能达到数万或数十万美元。 如果使用原始卡片 API，并由你的服务器接收卡片数据，你就会从 SAQ A 进入 SAQ D 或完整 DSS 范围。这就是核心取舍。 ## 什么时候使用原始卡片 API 才真正合理 尽管成本很高，但在少数场景中，原始卡片 API 确实是正确选择。 ### 你已经拥有 PCI 合规环境 如果你的公司出于其他原因已经按照 SAQ D 或完整 DSS 标准运营，那么新增原始卡片 API 集成的边际成本会很低。你已经具备所需的控制措施、审计流程和工具。与从零开始构建这一切相比，增加一个使用卡片数据的流程要简单得多。 ### 你的业务所在行业要求卡片数据经过你的系统 某些行业和集成要求商户位于数据流中。拥有全球分销系统的旅游平台、某些 B2B 采购集成，以及少数受监管行业都属于这种情况。如果你的业务确实处在这些领域中，你没有太多选择，原始卡片 API 就是可行路径。 ### 你需要托管式和内嵌式结账无法提供的支付体验 这是最需要保持怀疑的场景，因为要求非常高。现代托管式和内嵌式结账流程都极其灵活。如果你的团队确信必须完全控制表单中的每一个像素，务必在内部认真质疑这一判断。大多数时候，通过执行良好的内嵌式集成就能弥补差距，同时避免 PCI 成本。 ### 你对一次性支付流程有特定监管要求 某些受监管环境中的特殊要求，需要通过直接 API 提交支付。这种情况在 SaaS 和 AI 领域很少见，但确实存在。如果你属于这种情况，通常自己已经很清楚。 对于大多数 SaaS 和 AI 产品来说，上述情况都不适用。正确选择是使用托管式或内嵌式结账，让卡片数据完全不进入你的服务器。 ## 原始卡片集成的工作方式 如果你确实选择这条路径，实现流程通常包括以下几个清晰步骤。 调用创建支付 API，创建一条支付记录。响应中会包含一个密钥，用于授权下一次调用。 根据你的环境要求，通过前端或后端收集卡片数据。 使用卡片数据、密钥、账单信息和浏览器信息调用确认支付端点。浏览器信息很重要，因为 3-D Secure 身份验证会利用它对交易进行风险评分。 平台会尝试扣款。响应可能确认支付、拒绝支付，或返回表示需要客户进一步操作的状态，通常是进行 3-D Secure 身份验证。 如果需要 3-D Secure，你需要将客户重定向到响应中提供的 URL。客户通过银行完成身份验证，银行通知平台，原始支付随后进入最终状态。 在应用中处理最终状态，记录支付并交付客户购买的内容。 电子钱包支付的模式类似。Apple Pay 和 Google Pay 可以通过同一个确认支付端点处理，只需将电子钱包载荷替换原始卡片字段。这一点很重要，因为电子钱包支付可以通过原始卡片 API 能力范围运行，而不实际接触原始卡号；这样既能让 PCI 范围保持较小，又能提供你想要的 API 控制权。 调用方式和参数的完整参考，请参阅原始卡片 API 指南。本文关注的是取舍，而不是请求结构。 ## 使用原始卡片 API 时的常见错误 选择这条路径的团队经常会遇到类似问题。 在你的系统中的任何位置存储卡片数据。PCI 标准区分了卡片数据传输和存储：在适当控制措施下，传输是允许的；而存储受到严格限制。在应用数据库中存储卡号几乎从来都不是正确做法。如果你需要保存支付方式，请使用平台的令牌化能力，只存储令牌。 记录包含卡号的请求正文。这是最常见的审计失败原因之一。应用日志、错误追踪工具、请求镜像和分析管道都必须配置为在存储前对卡号进行脱敏。从第一天就这样做，比事后补救容易得多。 跳过浏览器信息收集。3-D Secure 身份验证依赖随确认请求发送的浏览器指纹。如果未能收集并传递这些信息，即使卡片本身有效，也会导致更高的拒付率和更差的风控筛查结果。 在运营层面把原始卡片流程当作托管式流程。原始卡片流程需要真正的 PCI 控制措施。年度审计、季度扫描、正式的变更管理和访问权限审查都属于合规义务。如果你的运营团队没有为此做好准备，审计结果不会理想。 低估持续维护成本。卡组织会更新规则，3-D Secure 协议版本会升级，合规要求也会变化。使用托管式或内嵌式集成时，这些工作由服务商承担；使用原始卡片集成时，则由你的团队承担。维护成本真实存在，而且会持续发生。 ## Dodo Payments 如何看待原始卡片 API Dodo Payments 支持这两种模式。对于 SaaS 和 AI 产品，默认且推荐的路径是托管式或内嵌式结账，这能让你保持在 SAQ A 范围内，并免去 PCI 负担。MoR（名义商户）模式意味着平台是名义销售方，由平台处理税务和合规。你的工程团队可以专注于产品本身。 对于确实需要原始卡片流程的场景，Dodo Payments 提供用于一次性支付的原始卡片 API，支持银行卡、Apple Pay 和 Google Pay。这不是大多数产品应该选择的路径，但在确实适用的特定场景中可以使用。 建议很简单：从托管式或内嵌式结账开始，确认用户体验和转化率达到目标。只有在存在托管式和内嵌式结账无法满足的具体要求时，才考虑原始卡片 API；并且在做出决定前，先与安全和财务团队确认 PCI 成本可以接受。 如需实现参考，[内嵌式结账指南](https://docs.dodopayments.com/developer-resources/inline-checkout)和[覆盖层结账指南](https://docs.dodopayments.com/developer-resources/overlay-checkout)介绍了推荐路径。原始卡片 API 文档则介绍了确实需要这项能力时的 API 结构。 ## 总结 原始卡片 API 是一种工具。和所有强大的工具一样，当更简单的方案已经足够时，人们也很容易选择它。合规成本是真实的，审计成本是真实的，维护成本也是真实的。对于大多数 SaaS 和 AI 产品来说，当托管式或内嵌式结账已经能够完成工作并将 PCI 范围保持在最低水平时，这些成本都不值得承担。 如果你有具体理由必须使用原始卡片 API，请谨慎实施。尽早建立控制措施。选择合适的日志和存储模式，尽可能让卡片数据远离你的系统。将合规视为工程责任，而不是财务上的事后考虑。在做出决定前，问问自己：你追求的目标是否真的需要这条路径，还是通过执行良好的内嵌式结账就能实现，而且成本只需其中一小部分。 ## 常见问题 ### 使用原始卡片 API 是否必然意味着要进行完整的 PCI DSS 审计？ 这取决于交易量和你的环境。交易量较小时，有时可以通过自我评估提交 SAQ D。交易量较大时，通常需要由合格安全评估师出具完整的合规报告，这是一项每年持续数月的合作项目。无论哪种情况，它都比 SAQ A 更复杂、负担更重。 ### 我可以将原始卡片 API 用于订阅吗？ 原始卡片 API 通常适用于一次性支付。对于订阅，标准模式是使用带有托管式或内嵌式表单的结账会话来保存支付方式，然后针对已保存的支付方式运行周期性计费。这样可以保持较小的 PCI 范围，同时获得完整的订阅能力。 ### 通过原始卡片 API 使用 Apple Pay 和 Google Pay，在 PCI 合规中是否算作原始卡片数据？ 电子钱包载荷通常与原始卡号区别对待，因为请求中并不包含实际卡片数据。大多数平台会将通过同一 API 能力范围处理的电子钱包支付视为较小的 PCI 范围。请向你的平台和审计师确认具体要求。 ### 团队后悔选择原始卡片 API 最常见的原因是什么？ 第二年和第三年的审计成本。第一年往往无法体现真实成本，因为团队还在摸索控制措施。到了第二年和第三年，持续审计、扫描、培训和整改工作都会完全显现，许多团队才意识到，选择托管式或内嵌式结账原本可以节省大量成本。 ### 我可以之后从原始卡片 API 切换到托管式结账吗？ 可以。许多团队最初为了灵活性选择原始卡片 API，之后随着转化数据和运营成本的变化，迁移到托管式或内嵌式结账。迁移并不简单，但范围是可控的。应将其作为一个项目来规划，而不是一次快速切换。 --- - [More Compliance articles](https://dodopayments.com/blogs/category/compliance) - [All articles](https://dodopayments.com/blogs)