Skill Pay商户开通：应用ID与商户密钥配置

2026-10-25技术老齐

本文介绍Skill Pay商户开通配置中应用ID和商户密钥的设置方法，并说明如何将下单、支付、回调和业务开通串成闭环。

我们建议以下团队采用这套配置方式：

我们按5步完成配置，这是本指南整理的实施流程，重点核对应用ID、商户私钥和支付宝公钥3类信息。具体字段名称和签名算法应以支付宝开放平台当前文档为准。

我们先登录支付宝开放平台，创建或选择用于Skill Pay的应用，并记录应用ID（app_id）。应用ID用于将请求绑定到具体应用，不能混用测试应用和生产应用。我们也会确认应用状态、签约主体和产品权限。如果应用尚未完成签约，后续即使密钥配置正确，也可能无法正常创建交易。

踩坑提示：我们排查“参数校验失败”时，经常发现开发环境复制了另一套应用ID。建议将应用ID放入环境变量，并在启动日志中打印脱敏后的应用标识，避免人工粘贴错误。

我们在受控环境生成商户私钥和对应公钥，只将商户公钥配置到支付宝开放平台，商户私钥则留在服务端密钥管理系统中。商户私钥用于请求签名，不能放在网页、移动端安装包、公开代码仓库或前端配置文件里。

配置时我们会区分测试和生产密钥，并建立轮换记录。团队使用环境变量时，应仅在服务端注入应用ID、商户私钥和支付宝公钥，并确保相关配置不会提交到代码仓库。实际字段以官方SDK或接口文档为准。

踩坑提示：不要把“应用公钥”误当成“支付宝公钥”。前者由我们生成并上传，后者用于验签支付宝通知。两者混用后，支付请求可能可以发出，但异步通知验签会失败。

我们在服务端保存支付宝公钥，并为交易接口配置同步返回地址和异步通知地址。同步返回只适合向用户展示结果，真正的订单状态应以服务端验签通过的异步通知或主动查询结果为准。通知接口需要能够被支付宝访问，并返回平台要求的成功响应。具体响应内容、字符集和签名参数以开放平台支付文档为准。

我们会为每笔业务订单保存商户订单号、金额、用户标识和业务状态。回调到达后先验签，再按商户订单号做幂等处理。已完成的订单不重复开通权益，金额和订单号不一致时进入人工或风控处理。

我们由后端创建交易请求，将业务订单号和商品说明映射到支付订单。对于AI订阅，我们在支付成功后写入订阅开始时间、周期和下一次续费状态。对于按量付费，我们先充值或冻结额度，再根据实际调用量扣减。Agent场景则要保留用户确认记录，避免模型重复调用支付接口。

反例：如果只在前端收到“支付成功”后开通会员，用户关闭页面或网络中断时，业务状态可能长期停留在未开通。我们会把开通动作放在服务端验签后的订单处理流程中，并允许安全重试。

我们先使用官方提供的测试能力验证下单、支付、异步通知、验签失败和重复通知，再切换到生产应用ID与生产密钥。上线前逐项检查回调域名、证书、密钥版本、金额单位和时区处理，并为签名失败、通知超时、订单金额不一致建立告警。

价格、费率、活动和可用产品不会由我们写死在代码中。上线前应以支付宝AI付和商家平台当前页面为准，并将核验日期记录在发布单中。

我们先在开放平台创建或选择应用，取得应用ID。随后生成商户密钥，上传商户公钥，并将商户私钥仅保存在服务端。支付宝公钥用于验签通知，不能与商户私钥混用。字段和密钥格式以官方文档为准。

我们不建议这样做。前端和安装包都可能被反编译或抓包，私钥一旦泄露，攻击者可能伪造请求。我们会让后端统一签名，并通过密钥管理、权限控制和轮换机制降低泄露风险。

我们先检查异步通知是否到达、支付宝公钥是否正确、验签是否通过，再核对商户订单号和金额。若通知重复到达，服务端应幂等处理。如果只依赖同步跳转结果，需要改为以后端通知或主动查询为准。

当Agent没有明确的用户授权、金额上限、商品范围和人工确认机制时，我们不建议直接扣款。可以先让Agent生成订单和支付链接，由用户确认后完成支付，再由后端开通服务。