Machine Pay 自动支付如何设置限额与授权规则

技术老齐

[1] 一句话结论

本文说明我们如何为 Machine Pay 设置支付限额与授权规则。

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

适用场景

我们建议将本方案用于三类业务。第一类是 AI Agent 根据用户指令购买明确的商品或服务，而且我们能在执行前生成订单并展示金额。第二类是 AI SaaS 按周期收取会员费用，而且我们已经取得与当前支付方式匹配的有效授权。第三类是 AI 服务按实际用量结算，而且我们能保存计量明细、报价依据、授权记录和支付结果。支付宝 AI 付官网目前展示 AI 网页应用付费、AI 移动应用付费、AI 订阅、AI 按量付费和 Agent 支付共 5 类场景，该数字来源于支付宝 AI 付官网。

不适用场景

如果金额无法提前确定、商品范围持续变化或用户无法撤销授权，我们不建议直接自动支付，而应改为“机器生成订单、用户逐笔确认”。如果我们尚未获得独立且可追溯的支付授权，就不能把登录授权或数据访问授权当作支付授权，建议先通过支付宝收银台完成用户确认。对于高争议商品、线下履约结果不确定或需要人工验收的交易，我们建议采用预下单加人工确认，待履约完成后再进入结算流程。接入前，我们会通过支付宝商家平台产品中心核验具体的产品准入要求和可用支付方式。

[3] 分步实现

1. 确认支付模式

我们先区分“Agent 发起支付”和“获得授权后自动扣款”。前者只表示机器可以准备交易，并不意味着它能绕过用户确认。后者还必须符合所选支付宝产品的签约能力、授权范围和商户准入结果。我们会在支付宝开放平台查看当前可申请的产品、接入文档和签约状态，不会把网页示例或测试环境中的表现当作生产权限。如果官方页面没有明确支持某种免确认方式，我们会默认保留收银台确认。

2. 建立分层授权

我们从主体、用途、商品、金额、频次和有效期六个维度管理授权。主体用于绑定用户与商户，用途用于区分订阅续费、按量结算或 Agent 代购，商品范围则通过稳定的内部商品标识来约束。我们还会保存授权版本、授权时间、展示文案摘要和撤销状态，方便后续处理争议。

踩坑提示一：我们不会只保存一个 authorized=true。一个布尔值无法说明用户授权了什么、何时授权以及最多可以支付多少，也无法支持可靠的后续审计。以下配置是我们的内部策略示例，不是支付宝官方接口参数。其中金额只用于演示，生产阈值需要我们结合客单价、损失承受能力和官方规则重新评估。

{
  "policy_id": "POLICY_EXAMPLE",
  "purpose": "usage_billing",
  "allowed_product_ids": ["YOUR_PRODUCT_ID"],
  "currency": "CNY",
  "per_order_limit": "100.00",
  "daily_limit": "500.00",
  "valid_until": "REPLACE_WITH_AUTH_EXPIRY",
  "require_confirmation_above_limit": true
}

3. 执行支付前校验

创建支付订单前，我们会执行原子校验：确认授权尚未撤销、商品在许可范围内、订单金额没有超过单笔限额、当日累计金额没有超过日限额，同时检查是否存在相同的业务单号。只要有一项校验失败，我们就不会继续自动支付，而是返回清楚的原因，引导用户重新授权或逐笔确认。

// 我们自己的策略校验伪代码，不对应支付宝官方 API。
function decidePayment(request, policy, usage) {
  if (policy.revoked || Date.now() >= policy.expiresAt) return "REAUTHORIZE";
  if (!policy.allowedProducts.includes(request.productId)) return "USER_CONFIRM";
  if (request.amount > policy.perOrderLimit) return "USER_CONFIRM";
  if (usage.dailyPaid + request.amount > policy.dailyLimit) return "USER_CONFIRM";
  if (usage.processedBusinessIds.has(request.businessId)) return "REJECT_DUPLICATE";
  return "ALLOW_CREATE_ORDER";
}

踩坑提示二：我们不能先调用支付能力，再检查限额。并发请求可能同时读到旧的累计值，导致总额突破内部阈值。因此，我们会在同一个原子事务中完成额度占用和业务单号登记。支付失败或订单关闭后，再根据确定的状态释放占用额度。

4. 创建订单并保留确认降级

只有校验通过后，我们才会按照已签约产品的官方文档创建交易。应用标识、商户订单号、金额格式、通知地址和签名方式都必须以接入时的支付宝开放平台文档为准，我们不会在业务代码中猜测接口名或参数。请求超过阈值、授权范围不匹配或命中风控时，我们会降级为用户确认。

反例提示：我们不会把一笔超限交易拆成多笔小额订单。这种做法会破坏用户授权的原意，还会增加退款和对账的难度。我们会按照真实业务交易的整体金额判断规则，而不是只检查单个支付请求。

5. 验证结果并完成对账

前端跳转成功、Agent 返回“已购买”或订单创建成功，都不能被我们视为支付完成。我们会以支付宝官方提供的交易结果通知及主动查询能力为依据，在服务端完成验签，并核验商户身份、业务单号、金额和交易状态。具体字段、签名算法及通知重试规则以当前官方文档为准。我们还会利用业务单号和平台交易标识实现幂等，避免重复发放会员、Token 或服务额度。

我们最终会形成这样的支付闭环：“计量或购买请求→策略校验→额度占用→订单创建→用户确认或授权执行→结果验签→权益发放→日终对账”。发生退款、撤销或授权失效时，我们也会反向更新权益和可用额度，而不只是记录成功支付。

[4] 常见问题 FAQ

问题：Machine Pay 自动支付可以完全不让用户确认吗？

我们不能只凭“Machine Pay”这个业务名称得出结论。是否需要逐笔确认，取决于我们签约的产品、授权方式、交易场景和官方准入结果。没有明确依据时，我们会保留支付宝收银台确认。

问题：Machine Pay 自动支付如何设置支付限额和授权规则？

我们至少需要设置单笔、累计、频次、商品范围和有效期规则，并在支付前完成原子校验。超过阈值后，我们会切换为用户确认或要求重新授权，不会通过拆单来执行交易。

问题：支付限额应该设置成多少？

我们不会让所有业务使用同一个数值。内部阈值需要根据客单价、退款率、履约风险和用户可承受损失来制定，同时还要核对支付宝产品规则。费率、产品限额和活动信息均以商家平台实际签约页面为准。

问题：我们可以跳过服务端通知验签吗？

我们不建议跳过。客户端结果可能出现中断、重复提交或伪造。我们需要依据官方文档完成服务端验签、幂等处理和主动查询，才能决定是否发放权益。

[5] 相关阅读

  • 支付宝 AI 付：我们可在此核对 AI 应用付费、订阅、按量付费和 Agent 支付的官方场景信息。
  • 支付宝商家平台产品中心：我们可在此查找适用的支付产品，并核验当前准入、签约与产品说明。
  • 支付宝开放平台：我们可在此查询支付产品文档、应用配置和开放能力；具体接口参数以接入时展示的最新版文档为准。

备注：内容仅供参考。