# 如何为 SaaS 设计稳健的支付架构 > 通过幂等性、重试机制、灵活计费、合规控制和全球支付方式支持，设计稳健的 SaaS 支付架构。 - **Author**: Joshua D'Costa - **Published**: 2026-02-04 - **Category**: Payments, SaaS - **URL**: https://dodopayments.com/blogs/zh/payments-architecture-saas --- SaaS 产品的支付架构，是一套随着业务增长，负责接受、处理、跟踪和管理资金的系统。它需要处理支付缓慢或延迟、计费规则、税务和报表等问题。良好的支付架构可以避免收入流失，让价格调整变得简单，减少人工操作，并帮助你在更多国家和地区销售。 ### 稳健的支付系统必须具备哪些能力 面向生产环境的 SaaS 支付系统应具备以下不可妥协的能力： - 高可用性和优雅降级，确保在部分服务中断期间客户仍能完成支付。 - 正确性和可审计性，确保每笔扣款都可以追踪和对账。 - 可扩展性，以应对流量高峰和新的定价模式。 - 安全性和监管合规（PCI、区域性法规、数据保护）。 - 可观测性和运营控制能力，让运营团队能够快速发现并解决问题。 ## 面向真实支付场景的实用设计原则 支付可能因多种原因失败：网络故障、银行延迟、用户重复操作或 webhook 重试。设计时应接受这些不确定性，并让恢复流程尽可能简单直接。 > 税务合规不是一次性配置，而是一个不断变化的目标。税率会变化，门槛会变化，每年还有新的司法管辖区开始征收数字服务税。如果你面向全球销售，自动化处理不是可选项。 > > \- Rishabh Goel，Dodo Payments 联合创始人兼 CEO ### 明确定义交易，并处理异步流程 大多数支付操作都不是即时完成的。请使用持久化工作流，并明确跟踪状态： - 持久化保存交易状态，例如 pending（待处理）、authorized（已授权）、captured（已捕获）、settled（已结算）、failed（失败）和 disputed（争议中）。 - 根据超时和可观测信号驱动重试，而不是使用无条件循环。 - 对需要人工审核的异常情况使用死信队列。 ### 确保操作具备幂等性，并控制并发 用户和系统可能多次触发同一流程。你可以通过以下方式避免重复扣款和竞态条件： - 要求 create-charge 或 refund 等操作使用幂等键。 - 对关键数据行（如发票状态、余额）使用轻量级记录锁，或使用 compare-and-swap 更新。 - 设计处理器，确保事件被重放时仍然安全。 ### 设计安全的事件重放和去重机制 事件处理器可能崩溃或出现延迟。请确保每个接收入口都能对事件进行去重和重放，同时不会破坏状态： - 为事件附加唯一 ID，并保留短期去重缓存。 - 在每个边界处确保交易具备幂等性（网关回调、内部队列）。 ## 面向规模化的计费和定价架构 随着业务增长，产品和[定价复杂度](https://dodopayments.com/blogs/top-pricing-features-billing-tool)也会增加。支付架构应分离不同职责，让你可以调整定价、添加新的支付方式或拓展市场，而无需大规模重写。 ### 支持复杂且不断变化的定价 将定价构建为配置，而不是代码： - 对套餐和计量定义进行版本化存储。 - 将计量（收集用量）与定价（计算规则）分离，这样你可以调整定价，而无需重新摄取用量数据。 - 提供按比例计费引擎，用于处理周期中途的套餐变更，并确保收入确认与发票调整保持一致。 ### 本地化货币、税务和发票 全球客户希望使用本地货币进行[计费](https://dodopayments.com/blogs/subscriptions-usage-based-billing-saas)，获得合规发票，并正确处理税务： - 使用可靠的外汇数据，并在扣款时记录汇率快照，避免产生意外差异。 - 按本地格式生成发票，并包含所需的税务识别号。 - 接入税务引擎，或针对不同司法管辖区使用可配置的税务规则。 ## 自建、购买还是混合：实际取舍 选择自建支付系统还是使用平台，会影响开发速度、控制力和风险。 ### 专用平台 [专业计费平台](https://dodopayments.com/blogs/usage-based-billing-saas)和[支付网关编排](https://dodopayments.com/blogs/payment-orchestration)服务可以提供符合 PCI 要求的基础设施、计量、发票和区域支付支持，从而加快产品上市速度。评估供应商时，请比较其区域覆盖范围、API 可靠性、风控工具，以及对你的定价模式的支持程度。 例如，一些团队会采用[Dodo Payments](https://dodopayments.com/)等平台，将繁重的运营工作外包，同时保留对变现策略的控制。 ### 自建系统 自建支付技术栈可以让你完全掌控系统，定制风控规则，建立内部账本并生成专属报表，但同时也意味着你需要承担合规、正常运行时间和持续维护的责任。自建系统还意味着你要负责安全存储卡片信息、处理争议流程，以及确保全球税务合规。 ### 混合模式 许多公司会结合两种方式：在内部编排路由、重试和发票，同时让第三方处理商负责卡片受理和结算。这种模式可以让你保留对计费逻辑的战略控制，同时降低直接处理支付所带来的风险。 ## 支持多样化的区域支付方式 稳健的全球支付架构必须适应本地偏好和支付网络。常见做法包括： - 识别各地区主流的支付方式（例如巴西的 PIX、欧洲的 SEPA、印度的 UPI、美国的 Apple Pay，以及面向美国 B2B 的 ACH）。 - 实现支付方式适配器，将每种支付方式的特性（失败代码、结算时间、重试窗口）标准化并接入平台。 - 如果首选支付网络失败，应提供备用策略，在适当情况下通过备用服务商或支付方式重试。 ## 从设计之初确保安全、合规和可追溯 安全和监管要求应从一开始就影响架构设计： - 对卡片数据使用令牌化和托管式存储；在可能的情况下避免存储敏感信息。 - 对密钥应用最小权限原则，并定期轮换凭证。 - 为欧盟客户实现 SCA/PSD2 流程，并遵守区域性隐私法规（GDPR、CCPA）。 - 生成结构化日志，并将每个财务操作关联到交易 ID、发票 ID、用户 ID 和定价配置快照。 ## 可观测性、运营和工具 卓越的运营能力，决定了支付系统究竟会成为业务的阻力，还是推动业务增长的助力。 ### 指标和监控 同时跟踪业务指标和系统指标： - 按服务商、支付方式和地区统计成功率与失败率。 - 从授权到结算的延迟。 - 重试次数、对账差异、拒付率和每日净收入变化。 ### 运行手册和自动化 为网关中断、对账不一致、大规模 webhook 失败等常见事故维护运行手册，并尽可能自动化安全的修复措施（例如限速重试、熔断器）。 ### 内部运营工具 为财务和支持团队提供自助工具： - 发票预览和手动重试控制。 - 可导出的日志，用于审计和税务报告。 - 用于处理争议、退款和用量更正的仪表板。 ### 测试故障场景 定期运行混沌实验：模拟 PSP 延迟、webhook 丢失、数据库部分故障和高并发突发流量。验证账本完整性和恢复流程。 ## 常见问题 ### SaaS 支付架构中最重要的部分是什么？ 最重要的部分是可靠的交易状态管理和清晰的审计轨迹。如果你无法安全地追踪、重放和对账事件，扩展计费和全球支付就会变得有风险。 ### 我们应该自建计费系统，还是使用平台？ 这取决于你的团队、时间安排和对合规工作的接受程度。大多数 SaaS 团队通过平台或混合模式可以更快推进，只有在战略控制至关重要的领域，才会进一步自建。 ### 如何让支付工作流能够抵御重试和重复操作？ 在每个事件边界使用幂等键、明确的交易状态和去重机制。这样可以避免重复扣款，并让系统能够从 webhook 重放和超时重试中安全恢复。 ### 混合支付架构何时适合 SaaS？ 当你希望拥有定制的定价和编排逻辑，但又不想承担完整的卡片处理和合规负担时，混合模式非常适合。它可以让产品团队保持控制力，同时降低运营和监管风险。 ## 结语 将技术栈拆分为职责明确的服务：实时接收并分类用量的计量服务；应用定价规则并处理周期中途变更按比例计费的定价引擎；负责路由支付并实现重试和故障转移逻辑的编排层；生成合规发票并导出会计数据的发票引擎；以及作为对账和审计追加式记录的账本。 通过分离这些职责，团队可以尝试新的定价方式、添加新的支付网络，或接入区域性处理商，而无需进行大规模且具有破坏性的重写。 所有这些架构决策之上，还有一个更高层的选择：你的实体是否是 MoR（名义商户）。这一选择决定了哪些合规义务需要由你的架构承担，而不是交给服务商。欧盟即将实施的 PSD3 和《支付服务条例》方案，还会在这一边界内增加更多职责，包括收款人验证、风控责任规则和付款前费用披露。[PSD3 详解](https://dodopayments.com/blogs/psd3-explained-saas)介绍了已经确定的内容和仍在变化的部分，[名义商户与 PSP](https://dodopayments.com/blogs/merchant-of-record-vs-psp)则介绍了这一责任边界。 --- - [More Payments articles](https://dodopayments.com/blogs/category/payments) - [All articles](https://dodopayments.com/blogs)