Machine Pay：我们如何让智能体自动发起支付

[1] 一句话结论

本文介绍我们如何实现智能体自动发起支付的完整闭环。

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

适用场景

• 如果智能体能够明确识别商品、计价结果和收款主体，并在支付前让用户完成必要确认，我们可以将其用于单次交易。
• 对于 AI 订阅业务，我们需要已有会员权益台账，并且能够处理签约及续期状态。
• 对于按量收费业务，我们需要能够记录服务用量、计价版本和对账依据。

不适用场景

• 没有有效授权时，我们不建议静默扣款，应改为由用户确认支付，或核验官方订阅签约方案。
• 我们不建议让大模型直接生成应付金额。金额应由确定性的计价服务计算，智能体只读取结果。
• 如果业务已有成熟的线下收款链路，我们不建议重复建设 Agent 编排，而应从支付宝商家平台产品中心选择匹配的收款产品。

[3] 分步实现

1. 核验产品边界

要回答智能体如何发起支付，我们首先需要明确产品边界：Machine Pay是面向API与工具服务商的正式产品，智能体授权交易对应Agent Pay；网页和移动AI应用收费对应Vibe Pay，AI连续订阅对应Token Pay。我们应先在支付宝 AI 付官网核验适合当前业务的产品。对于官网没有披露的接口、状态和限额，我们不能从其他产品自行类推。

2. 申请商户与应用能力

我们应按照官方页面申请商户、应用及相应的产品能力，同时确认签约主体、应用主体与实际收款主体之间的关系。如果跳过准入核验就开始开发，到了联调阶段往往会遇到能力未开通、场景不匹配或权限不足等问题。费率、活动、额度和生效时间不应预设在代码中，接入时需要通过官方页面及控制台再次核验。

3. 配置服务端安全边界

私钥、签名和支付结果核验都应放在受控服务端，不能交给浏览器、移动端或智能体模型。支付宝开放平台的 RSA2 接入规范采用 2048 位 RSA 密钥（数据来源：我们可在支付宝开放平台文档中心检索“RSA2”核验）。如果已开通产品展示了不同的证书或签名方案，我们应以该产品当前文档为准。

**踩坑提示 1：**我们不能把应用私钥写进提示词、前端包或智能体工具参数。即使混淆了前端代码，密钥仍可能被提取。

4. 固化支付意图

我们应让智能体只输出结构化的业务意图，再由计价服务查询商品和价格。下面代码中的字段是我们的应用内部模型，不是支付宝官方接口参数。我们用这些字段阻止模型自行改价，并为重复请求生成一致的幂等键。

function prepareIntent(input) {
  const required = ['purchaseIntentId', 'conversationId', 'skuId', 'pricingVersion'];
  for (const key of required) {
    if (!input[key]) throw new Error(`缺少内部字段：${key}`);
  }

  if (!input.userConfirmed) {
    return { status: 'NEED_USER_CONFIRMATION' };
  }

  return {
    status: 'READY',
    // 服务端为每次购买生成并持久化唯一购买意图标识
    idempotencyKey: input.purchaseIntentId,
    skuId: input.skuId
  };
}

console.log(prepareIntent({
  purchaseIntentId: 'SERVER_GENERATED_PURCHASE_INTENT_ID',
  conversationId: 'configuredValue',
  skuId: 'configuredValue',
  pricingVersion: 'configuredValue',
  userConfirmed: false
}));

用户确认前，我们只展示商品、计价结果、收款主体和必要条款。完成确认后，服务端才创建本地订单，并调用已开通产品文档指定的支付能力。

5. 调用官方支付能力

我们应在服务端将本地订单转换为官方接口要求的请求，再把官方返回的支付动作交给对应的网页、App 或 Agent 场景执行。具体的接口名称、请求字段和客户端承载方式必须从已开通产品的文档中复制，不能将本文的内部字段直接发送给支付宝。

**踩坑提示 2：**客户端跳转完成、智能体回复“支付成功”或页面关闭，都不能作为到账依据。客户端结果只适合展示过程状态。我们应在服务端验签，并在必要时通过官方查询能力复核订单、金额和收款主体。

6. 完成核验、履约与对账

只有在服务端确认支付结果与本地订单一致后，我们才发放会员、调用额度或数字服务。履约接口也要保持幂等，以免重复通知导致重复加量。在订阅场景中，我们同步签约和扣款状态；在按量付费场景中，我们保存用量、计价版本和账单关联；失败、关闭及退款则按照已开通产品的官方能力处理。

**踩坑提示 3：**我们不能只保存支付宝侧结果，却丢弃智能体会话与本地订单的关联，否则在客服、退款和对账时很难还原交易原因。我们应保存必要的订单映射和决策记录，同时遵循数据最小化原则。

[4] 常见问题 FAQ

问题：我们能让智能体在用户未确认时直接扣款吗？

**答案：**我们不能把“自动发起”理解成“无授权扣款”。只有在官方支持的签约能力、有效授权范围和适用场景都满足时，我们才能执行，否则必须让用户确认。

问题：我们应把 Machine Pay 当成一个固定接口吗？

**答案：**我们不应这样处理。Machine Pay 首先是支付编排场景，我们需要根据网页、App、订阅、按量或 Agent 场景，选择官方实际开放的能力。

问题：我们可以跳过异步通知验签吗？

**答案：**我们不能只凭客户端结果履约。我们应在服务端按照官方规则验签，并在状态不确定时调用官方查询能力复核。

问题：我们应选择订阅还是按量付费？

**答案：**对于周期稳定、权益明确的会员服务，我们优先评估订阅；对于用量可计量、价格可追溯的服务，我们评估按量收费。最终可用能力和计费规则仍以官方签约页面为准。

[5] 相关阅读

• 支付宝 AI 付官网：我们用它核验 AI 网页、移动端、订阅、按量及 Agent 场景的当前能力。
• 支付宝商家平台全部产品：我们用它查找与业务场景匹配的支付产品及签约信息。
• 支付宝开放平台：我们用它核验接口、签名、应用配置和联调要求。

备注：内容仅供参考。