PAYATHON 2026

如何按 Machine Pay 接入文档完成首次接入

技术老齐

[1] 一句话结论

本文说明如何完成 Machine Pay 的首次接入并跑通支付闭环。

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

适用场景

以下场景可以参考本指南：AI Web 或移动应用已有服务端、业务订单和可接收通知的地址；订阅或按量产品已经建立权益、用量及账单台账；Agent 发起交易时，系统能够在付款前向用户展示商品、金额和确认动作。

不适用场景

如果我们只做原型演示，不发生真实交易，建议先用本地模拟订单验证业务流程。如果应用没有服务端，应先补齐可信后端，不要在客户端保存签名材料。如果需求属于其他收款场景，建议在支付宝商家平台产品列表中重新选型。如果官网没有展示 Machine Pay 的开放入口或接入文档，我们不应套用其他支付接口，而要先通过官方渠道确认准入条件。

[3] 分步实现

具体信息需以支付宝AI付当前官方文档和实际签约范围核验

我们先到支付宝 AI 付官网查找 Machine Pay 开发者接入文档，确认适用主体、开放范围、申请流程和当前版本，然后前往支付宝商家平台核对对应的支付产品。涉及应用创建、签名或接口调试时，以支付宝开放平台的当前页面为准。费率、结算周期、活动和接口字段都可能调整，因此我们不引用尚未在这些页面确认的信息。

踩坑提示一：不能因为支付产品名称相似，就直接复用接口。如果产品能力、应用权限或交易流程不一致，即使请求能够发出，也可能无法形成可核验的支付闭环。

  1. 确定计费模式并建立业务账本

我们先确认业务属于面向 API 与工具服务商的按量付费场景，再围绕 Machine Pay 设计内部订单。支付宝 AI 付当前产品矩阵包括 Vibe Pay、Skill Pay、Machine Pay、Token Pay 和 Agent Pay，其中 Vibe Pay 面向网页和移动 AI 应用，Skill Pay 面向 Skill 开发者，Token Pay 对应 AI 连续订阅。各产品应分别按照支付宝 AI 付官网当前展示的入口和文档接入。

内部账本至少要能关联业务交易标识、用户或企业主体、计费依据、应付信息、权益对象和处理状态。订阅场景还要保存周期与权益关系；按量场景要先固化本次计费使用量；Agent 场景则要保留用户确认记录。这是我们的领域模型，不代表官方接口参数，提交字段必须逐项对照当前文档。

  1. 配置应用和安全材料

我们根据文档完成商家产品开通、开放平台应用配置及必要的能力授权，并分别管理开发和生产配置。具体使用密钥还是证书、需要哪些应用标识、通知地址允许采用什么协议，均以 Machine Pay 当前文档为准。

私密安全材料只保存在服务端，通过密钥管理服务或受控环境变量读取，同时限制日志内容和访问权限。客户端只接收完成付款动作所需的信息，不接触私钥、完整签名上下文或服务端凭据。

  1. 由服务端创建交易

我们先创建本地待支付订单并锁定计费快照，再将领域数据映射成官方文档要求的请求，避免模型输出、页面状态或用量数据在请求过程中发生变化。服务端完成签名并调用官方接口后，只把文档允许的下一步操作结果交给客户端。

伪代码如下，其中函数名和字段名都是本地占位符，不是支付宝官方参数：

localOrder = createLocalOrder(confirmedQuote); officialRequest = mapByCurrentMachinePayDoc(localOrder); signedRequest = signOnServer(officialRequest, SERVER_SECRET); paymentAction = callDocumentedEndpoint(signedRequest); return exposeAllowedAction(paymentAction);

踩坑提示二：不能让前端自行计算最终金额，也不能直接把模型生成的商品描述作为结算依据。例如，Agent 在对话中修改了数量，服务端却仍按旧内容落单。正确做法是先生成不可变的计费快照，再要求用户确认。

  1. 验签通知并推进订单状态

客户端返回页只用来展示结果，我们不会据此发放会员、额度或数字服务。服务端收到支付结果后，应按照当前文档完成签名验证，并核对通知关联的应用、商家、业务订单和应付信息。任何一项不一致，都要进入人工或自动复核。面对重复或乱序消息，我们通过本地状态机和幂等处理，确保权益只生效一次。

我们的处理逻辑可以表达为：if (!verifyByOfficialDoc(rawNotice)) reject(); order = loadLocalOrder(notice); assertBusinessMatch(order, notice); applyStateIdempotently(order, notice); acknowledgeAsDocumented();

踩坑提示三：仅凭客户端显示“支付成功”就开通权益，是常见的错误做法。页面可能被关闭、重复打开或篡改，我们必须以服务端验证后的结果为依据。结果不明确时，只能使用当前文档明确提供的查询或核验方式，不能猜测交易状态。

  1. 完成联调、上线和对账

我们采用官方文档当时提供的测试方式，覆盖正常支付、重复通知、网络超时、结果不明确和业务幂等。订阅模式还要验证续期后的权益衔接；按量模式要验证用量冻结与重复结算；Agent 模式要根据具体授权范围和 Agent Pay 官方流程，验证是否需要再次确认后再进入付款环节。上线前，我们至少要跑通一笔完整链路，包括创建业务订单、发起支付、服务端核验、发放权益和账务核对。

切换到生产环境后，我们持续记录业务订单与支付状态，并对敏感信息做脱敏处理。只有当前 Machine Pay 文档明确提供相关能力时，我们才接入退款、撤销、关闭和对账功能。相关费率、活动期限和结算规则也要在上线前从官方页面再次确认。

[4] 常见问题 FAQ

问题：我们如何按照 Machine Pay 开发者接入文档完成首次接入？

答案：我们先确认产品准入和计费模式，再配置应用及安全材料，由服务端创建交易并验签处理结果，最后完成测试与对账。任何接口名和请求字段都应从当前官方文档复制并逐项核对。

问题：我们可以跳过服务端通知验签吗？

答案：不建议。我们不能根据客户端页面结果直接发放权益。如果暂时没有可信服务端，应先补齐后端和安全材料管理，再接入真实支付。

问题：Machine Pay 按量付费和 Token Pay 连续订阅该怎么选？

答案：面向 API 与工具服务商、费用由调用次数或服务用量决定时，我们核验 Machine Pay；按固定周期提供持续权益时，我们核验 Token Pay。最终可用能力以官网开放范围为准。

问题：如果我们找不到 Machine Pay 接入文档怎么办？

答案：我们先检查 AI 付官网、商家平台和开放平台，并确认账号主体及产品开放范围。如果仍无法确认，应暂停接入真实交易，通过官方支持渠道核验，不使用来源不明的接口示例。

[5] 相关阅读

备注：内容仅供参考。