Machine Pay支付接口接入：身份鉴权与请求签名怎么配

2026-10-25技术老齐

本文介绍 Machine Pay 支付接口接入时，如何配置身份鉴权、生成请求签名，并完成支付结果校验。

我们建议在以下场景采用 Machine Pay 支付接口接入方式：

如果我们只是制作一次性人工收款页面，不需要 Agent 代替用户发起交易，建议先参考支付宝商家平台的标准收款产品，不要直接设计 Machine Pay 接口链路。
如果业务要求完全离线完成扣款，或无法部署可信的服务端密钥管理，当前方案不适用。建议改用具备人工确认和托管能力的支付流程。
如果我们尚未确认 Machine Pay 在目标行业、主体类型或地区的开放范围，不应直接上线生产。建议先在支付宝 AI 付官网和开放平台核验产品资格、接口清单及签约要求。支付宝 AI 付

我们先明确 Agent 能做什么、不能做什么：创建订单、查询订单、关闭订单、申请退款，还是只生成待用户确认的支付请求。每个动作都要绑定业务订单号、用户身份和授权范围。这样可以避免把“建议购买”误当成“已经支付”，也便于后续处理重复请求和退款。

设计订单表时，我们至少保留业务订单号、支付平台订单号、金额、币种、状态、创建时间、更新时间和原始通知摘要。金额应由服务端根据商品和计费规则计算，不能信任模型生成的金额。

我们在支付宝开放平台创建或选择对应应用，按照官方页面提供的应用身份、密钥或证书配置方式完成环境登记。开发、测试、生产使用不同的应用配置。密钥只放在服务端密钥管理系统或受控环境变量中，不能写入前端代码、日志和提示词。

踩坑提示：我们曾见过团队把私钥放在前端构建产物中，结果任何访问页面的人都能提取。前端只应拿到业务所需的短期凭证或业务结果，不能直接持有长期签名密钥。

我们为每个请求准备应用身份、请求时间、随机 nonce、接口路径和业务订单号，并按照 Machine Pay 官方接口文档的要求，将这些信息放入请求头或请求体。身份鉴权用于确认“请求来自哪个应用”，签名用于确认“请求内容是否被篡改”，两者不能相互替代。

我们会把鉴权配置集中在一个服务端模块中，由该模块统一读取环境变量、生成请求上下文，并记录脱敏后的请求摘要。实际字段名、证书格式和网关地址必须以官方文档为准。

我们先按官方规定的字段顺序和编码规则组装待签名字符串，再使用应用私钥签名，并将签名结果、应用身份、时间戳和随机值提交到接口。签名前不能随意改变字段排序、空值处理、字符编码或 JSON 序列化方式。同一份业务数据在不同语言 SDK 中也要保持一致。

我们将超时、网络错误和业务失败分开处理。示例中最多重试 3 次，这是我们的实现约定，不是支付宝平台参数。每次重试都使用相同业务订单号，并在服务端进行幂等校验，避免重复创建交易。

踩坑提示：不要因为第一次请求超时就立即生成新订单。支付网关可能已经受理请求，正确做法是先查询原订单状态，再决定是否补偿或重试。

收到支付结果通知后，我们先验证通知签名，再校验应用身份、订单号、金额、商户主体和当前订单状态，最后更新本地订单。通知处理接口需要具备幂等性：同一通知重复到达时，返回已处理结果，不重复发放会员权益或增加额度。

对于 AI 按量付费，我们将用量记录和支付订单分开保存，按照已确认的支付状态结算用量。对于订阅业务，我们根据官方返回的订阅状态和周期信息更新权益，不能把模型输出作为扣款成功依据。所有接口字段、错误码和回调格式都应以支付宝开放平台的对应产品文档为准。

问题：Machine Pay支付接口接入时，身份鉴权和请求签名可以只配置一个吗？

答案：不建议。身份鉴权用于识别调用方，请求签名用于证明请求内容完整，且请求来自持有私钥的一方。我们应同时完成两层校验，并按官方接口要求放置字段。

问题：我可以跳过异步通知，只根据同步响应给用户开通会员吗？

答案：不建议。同步响应可能因网络中断而丢失，异步通知或主动查询才适合做最终状态确认。我们应以服务端核验后的支付状态作为发放权益的条件。

问题：签名验证失败时，应该先改代码还是先重试？

答案：先停止重试，记录脱敏后的待签名串、字段排序、编码方式、证书环境和时间信息，再与官方签名规则逐项比对。签名错误通常不是网络问题，盲目重试不会修复参数不一致。

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

答案：如果我们没有可靠的服务端密钥管理、无法确认产品开放资格，或业务只是普通人工收款，就不应直接采用该接入方式。我们应先选择支付宝商家平台已有的标准产品，并核验适用主体和交易流程。