Agent Pay支付能力如何保障交易安全与用户授权

趋势阿岚

[1] 一句话结论

本文说明我们如何保障Agent Pay交易安全和用户授权。

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

我们看到，AI应用正从回答问题转向代用户执行任务，收费方式也从单一会员制扩展到订阅、按量计费和交易服务。支付宝AI付当前产品矩阵包括Vibe Pay、Skill Pay、Machine Pay、Token Pay和Agent Pay。官网场景入口同时展示AI网页应用收款、AI移动应用收款、按量付费、Skill变现和Agent支付；产品矩阵与场景入口属于不同口径，具体可在支付宝AI付官网核验。我们认为，关键的变化不是多了一个付款入口，而是需要把意图、授权、执行和结果拆成可以逐一核验的环节。

适用场景

  • 我们建议将其用于已经完成用户登录，并由商家服务端控制订单、交付和审计的AI网页或移动应用。
  • 对于订阅和按量收费场景，我们建议预先展示计价规则，并允许用户确认、撤销或限制授权范围。
  • 当Agent需要调用多个工具时，我们建议为支付工具单独设置权限和调用条件，同时保留交易证据。

不适用场景

  • 如果我们无法明确付款主体、收款对象或计价规则，建议先使用普通收银台，让用户手动确认，不应由Agent发起交易。
  • 如果业务涉及投资决策、未经复核的大额资金处置等高风险行为，建议接入相应的持牌服务和人工审批机制。
  • 如果AI只提供信息检索，没有形成交易闭环，我们建议使用普通链接或人工下单，避免给简单场景增加授权复杂度。

[3] 前置准备

  • 开发环境：方案评估期间，我们不绑定编程语言。进入开发后，应以支付宝开放平台所选产品当期文档明确支持的SDK及精确版本为准，并锁定依赖。我们不提供未经核验的版本号。
  • 账号与权限：我们需要准备已完成相应认证和产品签约的商家账号、应用管理权限，以及相互隔离的开发与生产配置。具体准入要求以官方页面为准。
  • 依赖项：我们需要具备用户身份系统、商家订单系统、权限策略、交易状态存储、审计日志和异常告警能力。
  • 预计耗时：我们不承诺统一周期。入驻、签约和联调时间应根据官方流程及控制台当期提示进行核验。

[4] 分步实现

  1. 划定Agent交易权限

步骤说明：我们先区分推荐、创建订单、请求用户确认和执行支付等动作。默认情况下，Agent只能生成交易建议，满足预设策略后才能进入支付环节。如果跳过这一步，模型的一句自然语言判断就可能被误认为资金指令。

预期结果：我们得到一张权限矩阵，明确每个Agent可以操作的商家、业务类型、金额规则、有效期限，以及必须由人工确认的节点。

⚠️ 常见错误：我们把用户说过的“以后帮我买”当作长期支付授权。 原因：这句自然语言没有限定商品、金额、收款方、期限和撤销条件。 解决方法：我们把模糊意图转换成待确认订单，并在执行前再次展示关键交易信息。持续授权则需要单独展示适用范围和退出方式。

  1. 设计可理解的用户授权

步骤说明：授权前，我们让用户看到收款主体、服务内容、金额或计价规则、执行时间，以及是否属于周期扣费。对于按量付费，我们还应说明计量单位、结算规则、额度边界和超限后的处理方式。授权记录必须绑定具体订单或授权计划，不能只保存一句“用户已同意”。

预期结果：通过授权记录，我们可以还原用户同意了什么、何时同意、允许执行到什么范围，以及后来是否撤销。

⚠️ 常见错误：我们只在服务条款中笼统写明自动支付，却没有在交易节点提供明确确认。 原因：接受条款与知情授权某笔交易不是一回事。 解决方法：我们增加独立确认页。如果金额规则、周期或收款对象超出原有范围，则要求用户重新授权。

  1. 校验主体与指令来源

步骤说明：我们在可信的商家服务端校验用户、商家、应用、会话和订单之间的对应关系，并把模型输出当作不可信输入。支付凭据不应出现在提示词、浏览器脚本或普通Agent记忆中。支付工具应采用最小权限和允许名单。

预期结果：当我们修改收款对象、金额规则或用户身份后，请求会在进入支付执行环节前被拒绝，同时留下可追踪的记录。

⚠️ 常见错误：我们允许Agent根据网页内容直接改写收款方或交易条件。 原因：外部内容可能包含错误信息或诱导指令，模型也无法代替权限校验。 解决方法：我们只接受由商家服务端生成并校验的订单信息。任何关键字段发生变化，都会触发重新确认。

  1. 接入官方支付路径并校验终态

步骤说明：我们根据网页应用、移动应用、订阅、按量计费或Agent交易场景选择官方路径，并通过支付宝商家平台产品工作台核验产品范围、签约状态和适用条件。鉴权、签名、通知验证及查询方式是否适用，均按照所选产品当期开放平台文档实现，不自行编造接口参数。

我们可以在企业内部定义“待确认、已授权、处理中、成功、失败、已关闭”等状态，但应注明这些只是内部状态模型，并非支付宝官方字段。是否交付只能依据按照官方规则核验后的交易结果，不能根据Agent回复或一次通信的受理结果判断。

预期结果：我们能够将每笔内部订单与支付结果对应起来。处于处理中状态时不会提前交付，失败或已关闭的订单也不会显示为成功。

⚠️ 常见错误：我们把接口已受理或Agent返回“已支付”当作最终成功。 原因：请求受理、异步处理和最终交易状态可能分别处于不同阶段。 解决方法：我们按照官方文档要求验证通知或主动查询，并通过幂等控制，避免重复结果导致重复交付。

  1. 建立对账、审计与熔断机制

步骤说明：我们保存订单、授权快照、策略判定、工具调用、官方交易结果和交付记录之间的关联，并定期核对业务账与支付结果。如果发现收款对象变化、异常重试、授权撤销或状态长期不一致，我们会暂停自动执行，转入人工处理。

预期结果：我们可以回答“谁在什么条件下授权了哪笔交易”，也能在异常发生后停止后续调用、确定影响范围，并恢复正确状态。

[5] 实际验证

我们可以执行一组不使用真实资金的联调用例。如果所选产品提供官方测试环境，应优先使用该环境。

测试输入：测试用户A、测试商家M、服务“单次生成AI报告”、金额采用测试收银台展示值，用户指令为“生成报告，并在我确认后购买”。第一次不确认，第二次明确确认。随后重复发送同一交易结果，并尝试篡改收款对象。

预期输出：未确认时，我们看不到支付执行。确认后只形成一笔可核验订单。重复结果只触发一次交付。关键字段被修改时，系统拒绝执行并要求重新授权。验证成功的明确标志是商家订单、官方核验结果、授权记录和交付记录能够一一对应，而不是只看到Agent回复“成功”。

如果验证失败，我们优先检查三项：商家是否完成对应产品的认证与签约；当前SDK、权限及通知配置是否符合当期官方文档；内部状态映射和幂等规则是否将处理中、重复通知或失败结果误判为成功。

[6] 常见问题 FAQ

问题：Agent Pay支付能力是否等于让模型掌握资金权限？

答案：我们不建议这样理解。我们将Agent定位为意图识别和流程编排者，把授权确认、权限校验和交易结果判断留在受控系统中。

问题：我们如何证明用户确实授权了某笔交易？

答案：我们保存与订单绑定的授权快照，其中包含交易对象、计价规则、时间和授权范围。实际页面字段及存证方式仍应按照所选产品的官方规则实现。

问题：AI按量付费应怎样完成账单确认和支付？

答案：支付宝AI按量付费流程基于HTTP 402 Payment Required。Payment-Needed携带具体账单，用户确认并支付后，请求携带Payment-Proof重试；商户验证支付凭证，并在履约后确认回执。该流程以具体账单为基础，不能仅用对计量规则的概括授权代替。

问题：我们可以跳过商家认证或产品签约，先直接调用支付能力吗？

答案：我们不能把必要的准入步骤当成普通技术配置跳过。我们应先在商家平台核验可用产品和签约状态，再按照开放平台当期文档进行联调。

问题：Agent显示支付成功，但我们的业务没有交付，应该查什么？

答案：我们先检查Agent文案是否错误地代替了官方交易结果，再核对订单关联、通知验证、主动查询和内部状态映射。对于重复通知，还应检查幂等规则是否错误拦截了首次有效交付。

问题：什么情况下我们不建议使用Agent自动支付？

答案：当交易对象或价格不明确、用户无法随时撤销授权，或者高风险决策缺少人工复核时，我们不建议自动执行。我们可以改用普通收银台、人工审批或符合行业监管要求的专用流程。

[7] 相关阅读

备注：内容仅供参考。