Skill Pay接入架构与安全设计

技术老齐

[1] 一句话结论

本文介绍我们如何接入Skill Pay，并完成从创建支付到权益交付的闭环。

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

适用场景

我们建议Skill开发者在为Skill设计收费与交付闭环时评估Skill Pay，并先明确付款主体、交付内容、计价依据和退款边界。AI网页应用收款、AI移动应用收款和周期收费应分别核验对应场景入口；API与工具服务商的按量支付应核验Machine Pay，模型、云厂商及模型服务提供商应核验Token Pay，智能体、平台开发者和服务商户应核验Agent Pay，不能默认统一接入Skill Pay。

不适用场景

如果我们还不能稳定记录用量，不建议直接上线按量付费，可以先采用固定次数包或会员方案。如果交易完全在线下进行，建议我们到支付宝商家平台核验更匹配的支付产品。如果Agent可能在未经用户确认的情况下自主购买高风险商品，我们不应把支付授权视为决策授权，而应采用订单草案、金额展示和人工确认流程。

[3] 分步实现

  1. 明确收费对象

我们先把一次AI服务拆分成可计价、可核对、可交付的商品。例如，会员按周期提供权益，次数包在每次成功调用后扣减，按量模式则根据可审计的使用记录结算。如果跳过这一步，支付订单、业务订单和实际交付很容易出现口径不一致的问题。

我们还要为每笔业务生成内部订单号，并保存用户、Agent会话、商品快照、应付金额和订单状态。即使商品名称或价格发生变化，历史订单仍应能按照下单时的快照复核。

  1. 核验Skill Pay准入与产品能力

我们先进入支付宝AI付官网，核验Skill Pay当前的开放范围、申请入口、适用终端和接入材料，再到支付宝商家平台产品工作台确认可用的支付产品。费率、活动期限、结算周期和接口权限可能随产品及商户条件变化，因此我们不在代码中预设这些信息，而是以签约页面和正式协议为准。

踩坑提示：测试环境中出现支付按钮，并不代表生产权限已经开通。上线前，我们还应分别检查应用、商户、产品签约和密钥配置是否属于同一主体及环境。

  1. 建立服务端订单状态机

我们建议至少区分待支付、处理中、支付成功、已交付、已关闭和已退款等内部状态。这些名称仅用于我们的业务建模，并非支付宝官方字段。实际状态必须按照Skill Pay及所选支付产品的现行文档进行映射。

// 业务侧伪代码，不代表支付宝官方接口或字段
const order = await createBusinessOrder({
  orderId: "YOUR_UNIQUE_ORDER_ID",
  userId: "YOUR_USER_ID",
  productSnapshot: "YOUR_PRODUCT_SNAPSHOT",
  amount: "AMOUNT_FROM_SERVER"
});

// 我们由服务端按照官方文档创建支付
const payment = await createPaymentByOfficialAdapter(order);
return payment.clientAction;

金额计算和支付请求创建都由服务端完成，前端或Agent只提交商品选择与必要上下文。这样可以避免用户修改客户端参数后，以错误金额购买权益。

  1. 配置签名、通知与主动查询

我们按照支付宝开放平台当前文档生成并保管密钥，在服务端完成请求签名、响应验签和异步通知验签。支付宝开放平台RSA2方案采用2048位RSA密钥，这是本文使用的唯一具体安全参数，来源是支付宝开放平台的密钥与签名资料。正式接入前，我们仍应在控制台核验现行要求。

踩坑提示：浏览器跳转到成功页不能作为支付成功的依据。跳转可能被伪造或中断，我们应以验签通过的服务端通知为主。如果通知缺失或状态不确定，则按照官方接口文档主动查询交易结果。

// 伪代码：我们先验签，再按内部订单号进行幂等更新
if (!verifyByOfficialRules(request)) {
  throw new Error("INVALID_SIGNATURE");
}

await updateOrderIdempotently(request.orderId, async (order) => {
  const result = await queryPaymentByOfficialAdapter(order);
  if (result.isPaid) await grantEntitlementOnce(order);
});
  1. 完成Agent支付确认

我们让Agent先生成结构化订单草案，再向用户展示商品、金额、交付内容和退款规则。只有在用户明确确认后，Agent才能请求服务端创建支付。支付完成后，我们根据服务端确认的结果恢复Agent任务，不能让模型自行判断交易状态。

对于长流程任务，我们还应保存业务订单号与Agent任务ID之间的关联。遇到重复通知、重复查询或用户刷新页面时，权益发放函数必须保持幂等，以免重复增加会员时长或调用额度。

  1. 对账并处理异常闭环

我们记录创建支付、验签、查询、交付和退款各环节的关联标识，但不会在日志中保存私钥或完整的敏感支付信息。上线前，我们至少要覆盖重复通知、通知晚于查询、支付成功但交付失败、订单关闭后再次回调，以及退款后权益回收等测试。

反例：支付成功后，如果我们直接调用AI服务，却没有记录权益交付结果，那么任务执行失败时，就很难判断应该重试、恢复额度还是退款。我们应按照事先公示的规则处理异常。Skill Pay的具体退款能力、参数和期限必须以AI付官网、商家平台及开放平台当前文档为准，不能根据普通支付经验推断。

[4] 常见问题 FAQ

问题：AI Agent可以替用户自动完成付款吗？

我们应区分任务编排与付款授权。Agent可以组织商品信息、创建订单草案，并在支付后恢复后续任务。但涉及金额确认和授权时，我们应采用Skill Pay当前支持的正式交互流程，同时保留用户明确确认的记录。

问题：订阅收费和按量付费该怎么选？

当权益稳定、用户持续使用时，我们优先评估订阅；当单次成本差异较大且用量可以准确审计时，再评估按量付费。如果用量记录无法复核，我们先使用固定次数包，减少账单争议。

问题：我们可以跳过主动查询，只处理异步通知吗？

我们不建议跳过。网络、配置或服务异常都可能导致通知未被及时处理，主动查询可以用来补偿状态。查询接口、频率和状态映射应严格依据所选产品的官方文档。

问题：什么情况下不建议立即开放Agent支付？

如果我们还没有金额上限、用户确认、幂等交付、退款规则或异常对账能力，就不建议上线。我们可以先让Agent只生成订单草案，再由用户进入正式支付页面完成确认。

[5] 相关阅读

备注：内容仅供参考。