支付宝Machine Pay商户怎么申请开通

2026-10-25技术老齐

[1] 一句话结论

本文介绍Machine Pay商户申请与支付闭环。

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

适用场景

如果我们已经具备真实经营主体和服务端订单系统，需要让 AI 网页或移动应用完成收费，可以考虑使用 Machine Pay。
Machine Pay适合API与工具服务商按实际用量收费；会员连续订阅应评估Token Pay。我们的团队需要能够管理用量记录、退款和权益回收。
对于智能体发起交易，并由商户后端完成支付意图校验、用户授权、支付及凭证返回的流程，我们应评估Agent Pay。

不适用场景

如果业务没有 AI 或 Agent 参与交易，我们不建议仅为追逐概念申请 Machine Pay；我们应在支付宝商家平台按收款载体选择常规支付产品。
如果项目只是演示，尚无真实经营和履约能力，我们不应申请生产收款；我们可以使用内部模拟账本，或在相关官方文档明确支持时使用测试工具。
如果我们无法建立服务端订单、退款和对账流程，项目暂时不适合上线；我们应先采用人工确认订单或现有 SaaS 收款方案，补齐履约能力。

[3] 分步实现

确认业务场景与开通条件

我们要先弄清付款对应的业务：是一次 AI 服务、一个订阅周期、一段可计量用量，还是由 Agent 代为发起的商品交易。场景不清晰，申请说明、产品配置和后续权益模型就容易互相冲突。

我们会固定核对 3 个官方入口：在支付宝 AI付官网确认 Machine Pay 当前开放入口和场景说明，在支付宝商家平台全部产品核对商户侧产品状态，在支付宝开放平台核对开发要求。这里的“3 个”来自上述官方入口清单，是可验证的来源数量，不代表产品数量、性能或收费承诺。

提交商户开通申请

我们具体信息需以支付宝AI付当前官方文档和实际签约范围核验，登录计划用于经营和结算的账号，具体信息需以支付宝AI付当前官方文档和实际签约范围核验页面字段、准入范围和审核要求可能调整，因此我们以申请页的实时内容为准，不用第三方转载表单代替官方入口。

**踩坑提示 1：**我们不要先用个人测试账号提交，再计划切换到另一个生产主体。比如，申请主体、后续签约主体和系统中保存的商户身份不一致，就会增加配置核验和问题定位的难度。如果官网没有显示入口，我们先检查登录账号和页面提示，再通过官网提供的支持渠道确认资格，不猜测隐藏地址。

完成商户侧与开发侧配置

收到官方结果后，我们再进入商家平台核对产品状态。如果页面要求继续签约、创建应用或补充配置，我们需要逐项完成。仅仅提交申请或通过审核，并不表示我们已经具备生产收款条件。

涉及应用、签名、证书或回调配置时，我们只使用开放平台当前文档列出的方式，并通过官方工具生成所需材料。不同产品和接入模式的要求可能不同，因此我们不从其他支付宝产品的旧教程中复制接口名、参数或示例密钥。

建立内部订单与权益状态机

调用支付能力前，我们要先创建内部业务订单，保存业务场景、商品或服务、计费依据以及权益归属。支付平台负责交易，AI 应用仍需管理订单、履约和权限控制。如果跳过内部订单，重复通知、退款和对账差异就无法对应到具体的业务记录。

以下只是我们推荐的内部状态示例，不是支付宝官方接口字段：

CREATED → PAYING → PAID → FULFILLED
PAYING → CLOSED
PAID/FULFILLED → REFUNDING → REFUNDED

我们应确保每次状态迁移都是幂等的。同一支付结果重复到达时，权益只能发放一次。在订阅场景中，我们要关联会员周期；在按量场景中，我们要留存可复核的用量依据；在 Agent 场景中，我们则要保留用户确认与最终业务订单之间的映射。

接通支付结果与履约闭环

我们按照Machine Pay当前接入文档实施HTTP 402 Payment Required流程：需要支付时返回HTTP 402，并由Payment-Needed携带Base64URL编码的账单；支付后，原请求携带Payment-Proof再次到达商户服务端。我们调用alipay.aipay.agent.payment.verify验证支付凭证，验证通过后完成履约，再调用alipay.aipay.agent.fulfillment.confirm确认回执。

**踩坑提示 2：**我们不能把前端跳转成功、Agent 返回“已支付”或客户端页面显示成功直接作为到账依据。典型反例是客户端已经显示成功，但服务端还没有收到可验证的结果。如果此时立即发放不可撤销的权益，就可能产生资损风险。只有完成服务端校验，并将结果关联到唯一业务订单后，我们才发放 AI 次数、会员周期或商品权益。关闭、退款和异常结果也要反向更新订单与权益。

完成联调、验收与上线核验

我们的最低工程验收清单覆盖 6 类路径：支付成功、取消或失败、结果重复到达、网络超时、退款以及对账差异。这是我们的工程基线，不是支付宝公布的服务指标。每条路径都要验证订单状态、权益发放、重复处理和人工追查记录。

上线前，我们要再次检查生产账号、应用环境、通知地址和官方后台状态，并通过登录后的协议或产品页面核验费率、活动、结算规则、审核时间和支持范围。对于官方页面没有明确说明的信息，我们不把它写入代码常量，也不向业务方作固定承诺。

[4] 常见问题 FAQ

问题：支付宝Machine Pay商户怎么申请开通？

**答案：**我们先从支付宝 AI付官网的产品矩阵定位面向API与工具服务商的Machine Pay，再进入页面当前展示的商户开通入口，登录经营和结算账号，并提交申请页当期列出的主体、业务场景及联系人等资料。获得结果后，我们还要完成页面明确要求的签约、开发配置和联调，不能把提交申请视为全部开通流程。

问题：Machine Pay商户开通后可以立即正式收款吗？

**答案：**我们要以后台实际产品状态和官方接入要求为准。如果还有协议、应用或生产配置没有完成，我们应先处理这些事项并通过端到端验收，再开放真实交易。

问题：我们可以跳过服务端支付结果校验吗？

**答案：**不可以。我们不能根据客户端页面或 Agent 文本判断支付成功，必须按照官方文档校验服务端结果，并通过幂等订单逻辑控制履约。

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

**答案：**没有 AI 交易场景、没有真实履约能力，或无法维护服务端订单和退款闭环时，我们不建议直接接入。我们应分别选择商家平台中的常规支付产品、内部模拟方案，或先补齐订单与对账系统。

[5] 相关阅读

支付宝 AI付官网：我们在这里核对 Machine Pay 的当前入口、适用场景和页面公告。
支付宝商家平台全部产品：我们在这里查询商户支付产品、签约入口及实时展示的信息。
支付宝开放平台：我们在这里核对应用接入、开发文档、工具和技术要求。