结论

处理这类跨主体场景时，需要先分清“负责下单的应用”和“用户实际进入的小程序”：

• op_buyer_open_id：填写用户在主体 A 小程序 APPID 下的 open_id。
• buyer_id / buyer_open_id：按当前下单接口文档的要求填写，二者只能选一个。
  • 如果能取得用户的支付宝 user_id，填写 buyer_id。
  • 如果使用开放账号体系，填写用户相对于调用下单接口应用的 open_id，也就是 buyer_open_id。
• 主体 A 小程序取得的 open_id，不能同时作为主体 B 基础应用的 buyer_open_id。open_id 与 APPID 绑定，通常不能跨应用直接复用。

如果主体 B 的基础应用拿不到该用户对应的 buyer_open_id，建议先由主体 A 小程序完成用户授权，取得可用于交易的 user_id，再将其作为 buyer_id 传入。同时，继续保留 A 小程序维度的 op_buyer_open_id。

另外，在常见的支付宝支付结果码中，6001 通常表示用户取消支付。仅凭这个代码，不能判断问题是没有传用户 ID。排查时还要结合下单接口响应、支付调用返回的 errorMessage、服务端网关日志，以及线上 APPID 是否命中了正确的绑定关系。

参数之间的区别

假设当前结构是：

• 用户运行的小程序：主体 A，APPID 为 APPID_A
• 发起服务端下单的基础应用：主体 B，APPID 为 APPID_B
• 收款商户：主体 B

各参数应按照所属的身份空间填写：

buyer_open_id 不能填写任意支付宝小程序的 open_id。如果订单由 APPID_B 调用接口创建，就不能直接填入从 APPID_A 获取的 open_id，除非已经按照接口要求完成转换。

推荐处理流程

1. 在主体 A 小程序中取得授权码

由用户实际进入的小程序调用授权接口：

my.getAuthCode({
  scopes: ['auth_user'],
  success: (res) => {
    // 将 res.authCode 发送到业务服务端
    console.log(res.authCode);
  },
  fail: (err) => {
    console.error(err);
  }
});

授权范围应以当前接入产品的开放平台文档和用户授权要求为准，不要仅为了取得用户标识而扩大授权范围。

2. 服务端使用主体 A 小程序的应用配置换取用户标识

授权码属于 APPID_A，必须使用 APPID_A 对应的应用身份完成兑换，不能直接使用主体 B 基础应用的密钥。

服务端应保存接口实际返回的字段，例如：

{
  "user_id": "2088xxxxxxxxxxxx",
  "open_id": "xxxxxxxxxxxxxxxx"
}

不同接口、开放平台账号模式和权限配置返回的字段可能不同，应以实际响应为准。不要自行拼接或推算 user_id、open_id。

3. 创建订单时正确传参

如果已经合法取得 user_id，可以采用以下结构：

{
  "out_trade_no": "ORDER_202609130001",
  "subject": "商品名称",
  "total_amount": "0.01",
  "buyer_id": "2088xxxxxxxxxxxx",
  "op_app_id": "APPID_A",
  "op_buyer_open_id": "USER_OPEN_ID_UNDER_APPID_A"
}

此时不要再传 buyer_open_id：

{
  "buyer_id": "2088xxxxxxxxxxxx",
  "buyer_open_id": null
}

如果只能取得下单应用维度的 open_id，则使用 buyer_open_id：

{
  "out_trade_no": "ORDER_202609130002",
  "subject": "商品名称",
  "total_amount": "0.01",
  "buyer_open_id": "USER_OPEN_ID_UNDER_ORDER_APPID",
  "op_app_id": "APPID_A",
  "op_buyer_open_id": "USER_OPEN_ID_UNDER_APPID_A"
}

其中，USER_OPEN_ID_UNDER_ORDER_APPID 必须属于下单接口要求的 APPID，不能直接用 APPID_A 下的 open_id 代替。

4. 使用服务端返回的交易号吊起支付

订单创建成功后，将接口返回的支付宝交易号传给小程序：

my.tradePay({
  tradeNO: serverResult.trade_no,
  success: (res) => {
    console.log('tradePay result:', res);
  },
  fail: (err) => {
    console.error('tradePay failed:', err);
  }
});

不要把商户订单号 out_trade_no 当作 tradeNO，除非当前接入的接口明确支持这种调用方式。

为什么开发工具测试正常，线上却出现 6001

开发者工具、真机预览和正式发布版本，可能使用不同的运行环境、APPID、版本配置或绑定状态。测试环境可以正常吊起支付，不代表正式版本使用的是同一套配置。

排查时应重点核对：

1. 正式版运行时的 APPID 是否确实是已经绑定的 APPID_A。
2. 主体 B 基础应用与 APPID_A 的绑定是否已经生效，而不只是保存配置或提交审核。
3. 绑定关系是否覆盖当前使用的支付产品和商户号。
4. 服务端正式环境使用的 app_id、私钥、商户账号和网关配置，是否与测试环境一致。
5. 下单接口是否确实返回成功，并取得了有效的 trade_no。
6. op_app_id 和 op_buyer_open_id 是否都属于 APPID_A。
7. 用户标识是否来自当前登录用户，是否存在缓存串号或测试账号残留。
8. my.tradePay 返回的完整对象中，除了 resultCode，是否还包含 errorMessage、memo 等信息。

关于 6001 的判断

不要直接把 6001 等同于“缺少 buyer_id”。在常见的支付调用结果中，它通常表示支付流程被取消。不过，以下问题也可能导致支付页快速退出，最终表现得像用户取消：

• 订单中的用户身份与当前登录用户不一致；
• 订单所属应用与当前小程序不匹配；
• 正式版 APPID 没有正确绑定；
• 订单已经关闭、失效或状态异常；
• 使用了错误的下单返回值；
• 支付页面出现提示后被用户关闭。

可以将排查分成两个阶段：

• 如果下单接口已经返回参数错误，应根据服务端响应中的 sub_code、sub_msg，修正 buyer_id 或 buyer_open_id。
• 如果下单成功并返回了 trade_no，但 my.tradePay 返回 6001，应继续检查应用绑定、订单归属、用户一致性和支付页的实际提示，不要只修改用户 ID 参数。

更稳妥的处理方式是，由主体 A 小程序完成用户授权，服务端取得真实的 user_id 后将其填入 buyer_id。op_app_id 和 op_buyer_open_id 则始终填写主体 A 小程序及该用户在主体 A 小程序下的标识。

如果当前账号模式已经不再返回 user_id，应按照所接入支付接口的最新要求，取得下单应用维度的 buyer_open_id。不要伪造、转换或跨 APPID 复用 open_id。

备注：内容仅供参考。