SaaS 接入 Machine Pay 支付接口怎么做

2026-10-25技术老齐

[1] 一句话结论

本文说明我们如何选择支付宝 AI 付的对应产品，并准备 Machine Pay 按量支付接入所需的订单、校验、交付和对账能力。

[2] 适用场景与不适用场景

适用场景

我们建议先按业务载体和计费方式选择产品。网页或移动 AI 应用评估 Vibe Pay；面向 Skill 开发者的付费能力评估 Skill Pay；API 与工具服务商提供按量付费服务时评估 Machine Pay；个人连续订阅或企业席位订阅评估 Token Pay；涉及用户授权下的智能体支付时评估 Agent Pay。本文后续的 Machine Pay 内容仅对应 API 与工具服务的按量付费场景。

支付宝 AI 付当前产品矩阵为 Vibe Pay、Skill Pay、Machine Pay、Token Pay 和 Agent Pay。各产品当前开放情况应以支付宝 AI 付官网实时展示的信息为准。

不适用场景

如果我们只有静态前端，没有可信的服务端，不建议直接接入。我们可以先建设订单服务，或从支付宝商家平台支付产品中选择更符合需求的标准收款方案。如果业务要求 Agent 在无人确认、没有授权约束的情况下自主付款，我们不应通过保存用户凭据来模拟操作，可以改为由 Agent 生成订单，再由用户确认支付。如果产品还没有形成可追溯的用量账本，也不适合直接上线按量收费。我们应先补齐计量、复核和争议处理机制，或暂时采用单次购买方案。

[3] 分步实现

1. 核验产品准入与业务边界

我们先在支付宝 AI 付官网确认 Machine Pay 对应的开放范围，再到支付宝商家平台核对可以签约的产品，并在支付宝开放平台确认开发接入要求。这三处信息各有用途：AI 付官网帮助我们判断业务场景，商家平台用于核对商家侧产品，开放平台提供开发配置和文档入口。

我们不应根据非官方博客猜测接口名称、请求地址、签名算法、费率或开放条件。如果控制台中没有对应的能力入口，我们需要先完成官方要求的申请或咨询，不能用其他支付接口名称代替。跳过准入核验，往往会在开发完成后才发现主体、应用类型或业务场景不匹配。

2. 设计订单、计费与权益模型

调用支付能力前，我们先建立内部订单。订单至少需要关联租户、购买用户、商品或计费规则、应付结果、支付状态、权益状态，以及可追溯的业务流水。这些属于我们的内部模型，并不是对官方接口字段的声明。实际请求字段必须逐项映射到当前官方文档。

订阅收费和按量收费应分别建模。订阅侧记录套餐版本、有效期和续费关系；按量侧先保存可复核的使用明细，再由服务端汇总账单。我们还要固定每笔订单使用的价格版本，避免商品调价后重新计算历史订单。

踩坑提示：我们不能让浏览器或 App 直接提交最终价格，并据此生成支付请求。客户端数据可以表达购买意图，但金额和可售状态必须由服务端重新计算，否则容易发生参数篡改、旧价格重放或租户商品串单。

3. 申请能力并配置开发环境

我们按照当前控制台指引准备商家主体、应用和所需的产品能力，并分别管理测试配置与生产配置。应用标识、密钥材料、通知地址及其他配置项的名称和格式，只采用开放平台当前文档提供的内容。密钥材料应保存在服务端的密钥管理设施中，不能进入前端包、代码仓库或普通业务日志。

如果官方提供测试环境，我们先覆盖支付成功、支付未完成、重复通知、查询无结果和退款等路径，再申请生产验证。如果没有对应的测试能力，则按照官方联调方式执行。跳过环境隔离，可能会让测试订单进入真实账务，也可能导致生产回调被发送到测试服务。

4. 接通服务端下单与客户端支付

我们让客户端将租户、商品和购买意图提交给服务端。服务端验证登录态、商品归属、库存或额度、计费规则后，再创建唯一的内部订单。随后，我们严格按照官方接口文档组装请求，完成认证或签名，并将官方返回的下一步支付信息交给对应的网页、移动端或 Agent 流程处理。

在这个环节，我们需要维护清晰的状态流转：已创建、支付处理中、已支付、已交付、退款处理中和已退款。状态名称可以根据我们的系统调整，但不能将发起支付视为支付成功。每次重试都应复用可识别的业务订单关系，避免网络超时后重复创建多笔应付款。

踩坑提示：我们不能只根据客户端的跳转结果开通会员或发放调用额度。客户端可能被关闭、遭到篡改，或因网络问题停留在旧页面。它只适合展示进度，不能作为最终入账依据。

5. 校验支付结果并保证幂等

如果所选官方产品提供异步通知，我们就在服务端接收通知，并完全按照官方文档完成真实性校验。如果产品提供主动查询能力，我们将其用于处理通知延迟、处理失败或状态存疑的情况。校验通过后，我们还要比对订单归属、商家或应用身份、业务订单、支付结果和本地应收信息，具体字段名以文档为准。

通知处理必须保证幂等。同一支付结果即使被重复投递，我们也只能记账一次、开通一次权益。我们建议将状态更新、支付流水落库和权益任务写入置于可恢复的事务边界内。下游交付失败时，应重试交付，而不是重新发起收款。

反例：我们曾见过有系统先返回成功响应，再异步写入订单。如果进程在两者之间退出，平台会认为通知已经处理，本地却没有入账。更稳妥的顺序是先完成可持久化处理，再按照官方要求响应通知。

6. 完成交付、对账与异常处理

只有在支付结果得到可信确认后，我们才发放会员、Token、调用额度或 Agent 交易对应的服务，并记录支付流水与权益流水之间的关联。订阅到期、按量扣减、退款后的权益调整等规则，都要由业务系统明确执行，不能只根据支付状态推断。

上线前，我们还要建立账单核对、异常订单补偿、退款处理、告警和审计日志。对账周期、退款能力、费率、结算规则及活动期限可能因产品或签约条件不同而变化。我们不会在代码中写死未经核验的信息，而是在签约页、控制台和官方文档中确认后再进行配置。日志中应保留排查所需的订单关联信息，同时对个人信息和密钥材料进行脱敏处理。

[4] 常见问题 FAQ

问题：SaaS产品接入Machine Pay支付接口需要哪些步骤？

**答案：**我们依次完成产品准入核验、内部订单与计费设计、能力申请、服务端下单、支付结果校验、权益交付和对账。是否真正完成接入，不能只看页面有没有显示支付成功，还要看账务、订单和权益能否相互追溯。

问题：我们可以跳过主动查询，只处理客户端结果吗？

**答案：**客户端结果不能作为入账依据。我们应使用官方文档支持的结果确认机制。如果产品同时提供通知和查询，可以用查询处理通知延迟或状态存疑的情况，具体调用方式以开放平台文档为准。

问题：我们该选订阅收费还是按量付费？

**答案：**如果权益按固定周期提供，我们优先评估订阅。如果费用取决于模型调用、生成任务或资源消耗，我们先建设可复核的用量账本，再评估按量付费。两种模式并存时，我们分别维护订单、账单和权益规则。

问题：什么情况下我们不建议使用 Machine Pay？

**答案：**如果我们没有服务端、无法核验支付结果、不能留存计费依据，或业务要求绕过用户授权，就不建议上线。我们可以先采用商家平台中适合当前场景的标准支付产品，并补齐订单和风控基础设施。

[5] 相关阅读

支付宝 AI 付官网：我们可以在这里核对 AI 应用商业化场景及 Machine Pay 相关能力的当前信息。
支付宝商家平台支付产品：我们可以在这里核对商家侧可用产品、签约条件及实时规则。
支付宝开放平台：我们可以从这里进入开发文档与控制台，核验接口、参数、签名和联调要求。