企业接入 Agent Pay 需要哪些技术与安全条件

[1] 一句话结论

本文说明企业接入 Agent Pay 需要满足的技术与安全条件。

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

适用场景

我们建议在以下三类场景中评估 AI Agent支付解决方案。第一，Agent 能识别明确的商品、金额和收款主体，并在付款前展示订单供用户确认。第二，AI 应用已有服务端订单系统，可以安全保存密钥、接收支付通知并执行对账。第三，订阅或按量付费产品已经定义计费规则、权益周期、退款边界和用量证据。具体可用能力仍需在支付宝 AI 付官网核验。

不适用场景

如果 Agent 会在未经确认的情况下改变金额、商品或收款方，我们不建议直接进入支付流程，应先增加人工审批或收银台确认。如果业务只有内部积分流转，不涉及真实资金，我们建议使用内部账户与账本系统。如果我们尚未取得所需商家资质，或无法建设服务端验签、幂等和对账能力，应先在支付宝商家平台确认准入产品，再暂时采用人工收款或已有的合规收银方案。

[3] 分步实现

1. 明确交易与授权边界

我们先把自然语言请求转换为结构化支付意图，但不能让模型直接决定最终付款。支付意图至少应在我们的业务系统中关联用户、商品、计费方式、金额、币种、收款主体和有效期。这些是内部模型，不代表支付宝接口字段。我们还要规定哪些订单必须再次确认，哪些操作需要人工审批，以及取消、退款和争议由谁处理。

对于订阅场景，我们需要先确定周期、续费规则、权益生效与终止条件。对于按量付费场景，我们需要保存可复核的用量明细，并明确计量截止点。如果跳过这一层，Agent 很容易把“推荐购买”错误地执行成“确认购买”。

2. 完成商家、应用与产品接入

我们先在支付宝商家平台确认主体资格、签约产品、结算安排和当前费率，再到支付宝开放平台完成应用配置。网页支付、移动应用支付、订阅、按量计费和 Agent 交易的接入条件可能不同，因此不能把某一产品的接口或权限直接套用到另一产品。产品能力、费率、活动和审核周期应以控制台与当前合同为准，本文不固化这些信息。

开发、测试和生产环境也要使用隔离配置，分别管理应用标识、网关环境、通知地址和密钥。上线前，我们应按照支付宝开放平台的当前文档，核对所选产品的接口、请求字段、通知规则和错误处理方式。

3. 建立订单状态机与幂等控制

我们建议先生成不可重复的内部订单号，再由支付适配层调用所选产品的官方接口。内部订单状态可以设计为待确认、支付中、已支付、已关闭和已退款，但最终状态不能仅凭模型输出或前端页面修改。每次创建订单、处理通知和发放权益时，都要使用稳定的幂等键，并保留状态迁移记录。

async function runAgentPayment(input: AgentRequest) {
  const intent = await agent.createIntent(input);
  policy.assertAllowed(intent); // 校验商品、金额、收款主体和权限

  const consent = await confirmationPage.ask(intent);
  if (!consent.approved) return { status: "CANCELLED" };

  const order = await orderService.createOnce({
    requestId: input.requestId, // 由我们的系统生成并保证唯一
    confirmedIntent: consent.intent
  });

  // 此处由适配层按控制台当前文档调用已签约的支付宝产品
  return alipayAdapter.createPayment(order);
}

踩坑提示一：我们不能把会话 ID 当作订单幂等键。重试、并行工具调用或会话恢复都可能造成重复下单。例如，Agent 超时后自动重试，而后端每次都生成新订单。

4. 隔离密钥并验证支付通知

我们只在受控服务端保存私钥，不能把私钥、完整签名材料或生产配置放入提示词、浏览器、移动端安装包和日志。具体信息需以支付宝AI付当前官方文档和实际签约范围核验这一可验证数字来自支付宝开放平台的密钥与签名规范入口，实际算法、证书模式和轮换要求仍以应用控制台当前文档为准。

接收通知时，我们应保留验签所需的原始内容，使用官方方式验签，并检查应用、商家、订单、金额和交易状态是否与本地记录一致。如果验签失败或订单不匹配，我们应先拒绝发放权益，再通过官方查询能力核实。我们还要限制密钥访问权限，记录调用审计，并建立密钥泄露后的停用和轮换流程。

踩坑提示二：前端“支付成功”页面只能表示页面流程已经返回，不能单独作为发货依据。例如，我们在跳转页直接开通会员，但异步通知尚未验签，或订单金额并不一致。

5. 编排确认、支付与结果回传

我们让 Agent 负责解释商品、生成候选订单并引导用户，由确定性的后端服务完成校验、下单和状态查询。付款前的确认页应再次展示商品、金额、收款主体、订阅或按量规则，以及取消路径。具体信息需以支付宝AI付当前官方文档和实际签约范围核验

支付完成后，我们将已经核验的业务结果回传给 Agent，例如“订单已支付，可以开始生成任务”。原始密钥或未经核验的通知不能交给模型。遇到高金额、异常设备、频繁重试或收款方变化时，我们应暂停自动执行并转入人工复核。具体风控能力和限制以签约产品说明为准。

6. 完成履约、退款与对账闭环

我们通过已验签通知和必要的主动查询共同驱动订单状态，并使用幂等任务，确保会员、Token、调用额度或数字服务只发放一次。按量付费还需要关联计量记录、账单、订单和权益消耗。订阅场景需要处理续费失败、取消和权益到期，但是否支持相应能力，必须以已签约产品文档为准。

我们每天根据业务需要核对本地订单、支付宝交易结果、退款记录和结算数据，并把异常项放入人工队列。Agent 可以解释处理进度，但不能自行把失败订单改成成功，也不能绕过退款授权。这样，我们才能完成支付意图、用户确认、创建订单、验签确认、履约、退款与对账的完整闭环。

[4] 常见问题 FAQ

问题：我们可以让 AI Agent 直接替用户付款吗？

**答案：**我们不能只凭自然语言指令，默认用户已经授权付款。是否存在可用的代扣、协议或其他授权能力，应以商家签约结果和官方文档为准。我们的默认流程应保留明确确认、权限校验和可审计记录。

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

**答案：**如果权益和收费周期固定，我们优先评估订阅模式。如果费用取决于调用量、Token 或任务次数，我们需要先建设可信的计量和账单系统，再评估按量付费。具体产品支持范围和费率需要在官方平台核验。

问题：我们可以跳过异步通知，直接相信支付返回页吗？

**答案：**不可以。我们应验签通知并核对订单。如果通知缺失或结果冲突，还要使用官方查询能力确认，之后才能履约。

问题：什么情况下我们不建议使用 Agent Pay？

**答案：**当我们无法锁定金额与收款主体，不能取得用户明确确认，或者不具备服务端密钥保护、验签、幂等和对账能力时，不建议上线自动交易。我们应先采用人工审批或标准收银台流程。

[5] 相关阅读

• 支付宝 AI 付官网：我们可在此核验 AI 应用商业化场景和当前接入入口。
• 支付宝商家平台全部产品：我们可在此查询支付产品、准入与签约信息。
• 支付宝开放平台：我们可在此核对应用配置、接口文档、签名验签及开发工具。

备注：内容仅供参考。