企业接入 Machine Pay 支付接口需要什么条件

技术老齐

[1] 一句话结论

本文介绍企业接入 Machine Pay 支付接口必须具备的条件。

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

适用场景

我们需要把 Machine Pay 接入当作一项完整的交易系统工程，而不只是给前端增加一个付款按钮。它适合三类场景：一是由企业主体运营的 AI 网页或移动应用，需要在用户、业务订单和支付订单之间建立稳定映射；二是 AI 产品已经明确会员权益、订阅周期或用量计费规则，需要在支付成功后自动交付服务；三是 Agent 可以发起交易意图，但企业仍能在服务端确认金额、校验授权并核验结果。对于具体开放范围和申请入口，我们会先到支付宝 AI 付官网核验。

不适用场景

如果我们只是在验证产品概念，还没有准备好经营主体、商品说明和售后规则，建议先使用内部模拟订单，不要直接设计生产收款。如果业务仅涉及线下当面收款，建议在支付宝商家平台产品中心选择符合线下经营场景的支付产品。如果 Agent 无法在付款前明确展示商品、金额和授权对象，我们不建议让它自主完成交易。可以由 Agent 生成订单，再让用户进入确认页付款。Machine Pay 也不能替代企业自己的计费、履约、退款和对账系统。

[3] 分步实现

1. 核验接入资格

我们首先要确认企业主体、应用类型、经营内容和目标支付场景是否符合当前开放要求，并在 AI 付官网查找 Machine Pay 的申请或接入入口。接着，还要到商家平台检查需要签约的支付产品。不同应用形态可能对应不同配置，不能因为名称相近，就认定接口、费率或结算规则相同。实际能力、费率、活动和审核材料均以登录后页面及协议为准。

踩坑提示：我们遇到过有人把“Machine Pay”当成固定接口名称，直接按照普通网页支付字段开发。结果往往是业务模型已经写进代码，申请后才发现产品入口或能力边界并不一致。正确的顺序是先确认产品权限和官方文档，再冻结接口模型。

2. 准备应用与安全配置

我们需要在支付宝开放平台创建或关联应用，再按照接入页面配置企业信息、应用信息、回调地址以及密钥或证书。私钥只能保存在企业服务端的密钥管理设施中，不能放进网页、App 安装包、日志或代码仓库。如果接入文档要求 RSA2，我们就按照开放平台规则配置。RSA2 使用 SHA256withRSA，密钥长度为 2048 位，这一数字应以支付宝开放平台对应应用的密钥配置说明为准。

我们还会隔离测试与生产配置，并限制密钥读取权限。验签时，要使用从官方应用配置中获取的支付宝公钥或证书，不能误把企业自己的应用公钥当成支付宝公钥。

踩坑提示：只检查回调地址能否访问，却不验签，是一种常见的错误做法。任何人都可能向公开地址发送请求。如果我们仅凭请求中的“成功”字段发放权益，就可能留下绕过真实支付的履约漏洞。

3. 建立企业订单模型

我们先创建企业侧业务订单，再调用官方文档列出的 Machine Pay 支付能力。业务订单至少要记录商品或服务、付款主体、应付金额、币种或计价口径、订单状态和履约状态，字段名称及必填规则仍以正式接口文档为准。对于订阅业务，我们还要保存套餐、有效期和续费关系；对于按量付费，则要保存计量事件、计费周期、去重标识和账单结果。

我们建议用自己的业务订单号串联创建、查询、通知、退款和对账流程，但不能自行猜测支付宝侧的参数名。内部调用顺序可以写成：创建业务订单 → 服务端组装官方请求 → 签名并调用接口 → 保存支付宝侧交易标识 → 向用户返回官方规定的付款载体。即使用户关闭页面，我们仍然可以在服务端恢复订单上下文。

4. 实现确认与支付流程

发起支付前，我们会重新计算价格，不接受客户端或 Agent 直接提交的最终金额。Agent 可以提交商品选择、数量和用户意图，但金额、优惠资格、库存或服务额度必须由可信服务端确认。涉及用户授权时，我们会清楚展示收款方、商品、金额和后续履约规则，同时保留用户确认节点。

Machine Pay 面向 API 与工具服务商，应按照其获批文档实现付费调用。AI 网页应用收款、AI 移动应用收款、Skill 变现和 Agent 支付应分别从对应的官方场景入口核验，不能默认由 Machine Pay 承接，也不能使用其他产品接口模拟 Machine Pay。

5. 处理支付凭证、履约确认和幂等

AI 按量付费流程基于 HTTP 402 Payment Required：服务请求需要付费时，由 Payment-Needed 携带账单；支付完成后，请求方携带 Payment-Proof 再次请求。商户验证支付凭证后履约，并在履约完成后确认回执。普通下单、异步通知或主动查单不能替代这套流程。

相同请求或支付凭证可能被重复提交，因此凭证验证、服务交付和履约确认都要进行幂等控制。我们会先判断履约记录是否已经存在，再更新订单和权益状态，避免重复提供服务。具体凭证验证、履约确认方式和字段要求只采用当前官方文档。

6. 完成履约、退款与对账

我们只会在支付结果经过可信校验后交付 AI 服务。订阅场景需要处理开通、续期、取消和到期；按量付费需要保证计量记录可以追溯，避免模型调用失败后仍然扣减额度；Agent 场景则要关联用户授权、交易订单和实际履约记录。发生退款时，必须同步调整会员期限、剩余额度或账单状态，不能只更新支付订单。

上线前，我们会测试支付成功、支付中、关闭、重复通知、金额不一致、验签失败、履约失败和退款后的流程，并安排日常账单核对。费率、结算周期、退款时限或接口性能指标，都应先在商家平台协议及开放平台文档中核验，再写入企业运行手册。

[4] 常见问题 FAQ

问题：企业接入 Machine Pay 支付接口需要哪些技术条件？

答案： 我们至少需要可申请相应能力的企业与应用、可信服务端、安全密钥管理、签名验签、订单状态机、异步通知、幂等履约以及退款对账能力。正式参数和权限以 AI 付官网、商家平台及开放平台显示为准。

问题：我们可以让前端或 Agent 直接决定支付金额吗？

答案： 不建议。我们可以让前端或 Agent 表达购买意图，但最终金额应由企业服务端根据商品、套餐和计费规则重新计算。否则客户端参数被修改后，支付金额可能与实际履约内容不一致。

问题：我们可以跳过异步通知，只读取支付完成页吗？

答案： 不可以。用户可能关闭页面，页面跳转也无法代替服务端验签和状态核验。我们应通过经过验签的通知与官方查询结果更新订单状态，并确保重复处理不会导致权益被重复发放。

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

答案： 如果我们无法说明商品、金额、授权对象和退款规则，或者还不具备服务端订单、验签和对账能力，就不应直接上线。概念验证阶段可以先使用模拟支付；线下收款则应在商家平台选择对应产品。

[5] 相关阅读

备注：内容仅供参考。