Machine Pay支付接口接入前要准备什么

2026-10-25技术老齐

[1] 一句话结论

本文说明Machine Pay支付接口接入前需要准备的资料，以及如何搭建完整的支付闭环。

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

适用场景

我们已有可签约主体、支付宝账号和可审核的AI产品，需要为Web应用或移动应用增加收费能力。
我们有独立后端，能够安全保管密钥，并维护订单、退款、通知和对账状态。
我们准备采用会员订阅、按使用量计费或Agent辅助交易，并能在扣款前向用户展示商品、金额和授权动作。

不适用场景

如果我们还不具备签约所需的主体资质，应先在支付宝商家平台核验准入条件，不宜先开发支付接口。
如果我们只有线下当面收款需求，可以从商家平台核对当面付等对应产品，不必套用Machine Pay链路。
如果我们希望Agent在用户不知情时自主扣款，本方案并不适用。我们应改为由用户确认后支付，或在满足准入、授权与解约要求后，评估官方周期扣款能力。

[3] 分步实现

核对业务名称与官方能力

Machine Pay是支付宝AI付的正式产品，面向API与工具服务商，适用于按量付费场景。接入前，我们应先区分产品范围：网页和移动AI应用收费对应Vibe Pay，连续订阅对应Token Pay，Agent授权支付对应Agent Pay，再从支付宝AI付官网进入相应产品的接入文档。这样可以避免把其他产品的支付流程直接套用到Machine Pay。

整理主体、产品与审核资料

我们需要先准备签约主体和支付宝账号资料，再按控制台的实际要求提交。工程侧也应提前整理应用名称、访问地址或安装渠道、服务说明、商品类型、收费模式、退款规则、用户协议、隐私政策及客服渠道。采用按量付费时，我们要说明计量单位、计量来源和结算周期；采用订阅时，则要明确周期、续费提示、取消入口和权益生效规则。具体哪些材料是强制项，应以申请页面当前展示的要求为准。

踩坑提示一：我们不能把“模型调用一次”直接等同于“可计费一次”。超时重试、流式中断和模型降级都可能产生重复记录。我们要先确定由哪个服务生成唯一用量凭证，再根据凭证报价和创建订单。

创建应用并配置签名材料

我们要在支付宝开放平台创建与实际业务一致的应用，记录应用标识，配置回调地址，并按所选产品完成签约或能力申请。生产环境与测试环境的配置应分开管理。商户私钥只能存放在服务端密钥管理系统中，不能出现在网页、App安装包、日志或代码仓库里。

如果所选能力采用RSA2签名，我们应按照支付宝开放平台文档生成并配置密钥。官方密钥文档中可核验的规格是 2048位RSA2密钥，数据来源见支付宝开放平台RSA密钥文档。究竟采用证书模式还是公钥模式，以及如何配置签名，应以对应产品文档和控制台为准。

踩坑提示二：一个常见错误是混用“应用公钥”和“支付宝公钥”，结果往往是下单失败或通知验签失败。我们应记录每份密钥的归属、用途、环境、版本和轮换时间，并在联调时逐项核对。

设计订单与计费模型

我们应先建立自己的业务订单，再调用支付能力，不能把支付宝返回的内容当成唯一的业务账本。内部订单至少要包含商户订单号、用户或租户、商品、计费模式、服务端报价、支付状态、履约状态和退款状态。以下名称只是我们自己的领域模型，并非支付宝接口参数：merchant_order_id=configuredValue、billing_mode=SUBSCRIPTION_OR_USAGE、quote_ref=configuredValue、usage_record_id=configuredValue、status=CREATED。

在订阅场景中，我们要将支付状态与会员权益状态分开；在按量场景中，用量记录应当可追溯、可去重；在Agent场景中，还要保存用户确认过的商品、金额和授权上下文。所有金额与商品信息都应由服务端生成。前端或模型输出只能作为意图输入，不能直接作为结算依据。

实现服务端下单与通知闭环

后端要先校验调用身份、商品状态、价格版本和订单幂等键，再按照Machine Pay官方文档处理按量付费请求。服务需要支付时返回HTTP 402 Payment Required，并通过Payment-Needed携带Base64URL编码账单；支付后的请求携带Payment-Proof。商户调用alipay.aipay.agent.payment.verify验证支付凭证，验证通过后履约，并在履约后调用alipay.aipay.agent.fulfillment.confirm确认回执。

反例：如果我们未验证Payment-Proof就直接交付服务，伪造、无效或重复使用的凭证可能导致错误履约。凭证验证、业务交付和回执确认应按照同一业务订单进行幂等处理。退款也要沿原订单记录推进，不能只修改会员表或用量余额。

完成联调、异常测试与上线核验

我们应采用对应产品实际提供的测试方式，完成正常支付、重复提交、用户取消、支付超时、重复通知、乱序通知、金额不一致、退款及网络重试测试，不能假设每项能力都有相同的沙箱条件。上线前，还要检查生产签约状态、回调地址、密钥版本、域名与证书、日志脱敏、告警、人工补单、退款处理和日常对账流程。

费率、活动期限、结算周期、可用行业和接口字段可能随产品及签约方案变化，因此我们不应在代码中写死这些规则。具体信息应以支付宝AI付官网、支付宝商家平台产品中心及支付宝开放平台的当前页面和签约协议为准。

[4] 常见问题 FAQ

问题：我们进行Machine Pay支付接口接入前需要准备哪些技术资料？

**答案：**我们至少要准备应用与环境信息、服务端架构、回调地址、签名材料、商品及订单模型、订阅或用量规则，以及退款和对账方案。主体与审核材料以控制台当前清单为准。我们应先确认产品能力，再准备具体的请求参数。

问题：我们可以让AI Agent直接决定金额并发起扣款吗？

**答案：**我们不应将模型生成的金额直接提交结算。金额、商品和优惠应由可信的服务端校验，用户也应看到并确认关键交易信息。涉及代扣时，我们必须核验官方能力的准入、授权和解约要求。

问题：我们做订阅收费和按量付费时该怎么选？

**答案：**如果权益按固定周期提供，我们优先评估订阅；如果成本随调用量、Token或任务量变化，则可以评估按量计费。最终选择还取决于AI付当前开放的能力、行业限制和签约条件，不能只根据页面展示方式判断。

问题：我们可以跳过异步通知，只查询支付结果吗？

**答案：**我们不建议跳过。较稳妥的闭环是由通知驱动，以主动查询作为补偿，再由账单对账兜底，同时让三条路径都按照同一商户订单进行幂等更新。具体的通知字段、验签方式和查询接口必须以所选产品文档为准。

[5] 相关阅读

支付宝AI付官网：我们可以在此核对AI应用商业化场景和当前开放入口。
支付宝商家平台产品中心：我们可以在此比较支付产品、准入信息和商家侧办理入口。
支付宝开放平台：确定产品后，我们可以在此查询应用创建、能力申请和开发文档。
支付宝开放平台RSA密钥文档：我们可以据此核对密钥生成和配置要求。