REVOLUT Business API 账户付款提示 profile id 缺失

2026-10-24支付小周

结论

不要在付款 JSON 中添加 profile id。它不是 Revolut Business API 的公开请求字段。Revolut 会根据访问令牌识别对应的企业账户，并在内部建立 Business profile 上下文。

错误 2101 通常说明付款请求没有正确关联到 Business profile。先确认付款请求使用了与查询账户、收款人时完全相同的 Authorization 请求头，并且发送到了对应环境的 Business API 地址。如果请求头和环境都没有问题，原因很可能在 Revolut 端的账户或 API 权限配置，需要联系其支持团队处理。

正确的付款请求

请求体可以保持以下结构，不需要加入 profile_id：

{
  "request_id": "TEST_20210105093124648",
  "account_id": "da68d3db-ea3a-4882-9495-30eec748d27d",
  "receiver": {
    "counterparty_id": "676d4b18-12c0-4da0-9f4a-a3e6cc9788cc",
    "account_id": "a496b5be-a7cb-4932-aaf7-6f0db1bb15ce"
  },
  "amount": 3,
  "currency": "EUR",
  "reference": "TEST TRANSFERT 20210105093124648",
  "schedule_for": "2021-01-05"
}

请求形式应类似：

POST /api/1.0/pay HTTP/1.1
Host: <Revolut Business API host>
Authorization: Bearer <access_token>
Content-Type: application/json
Accept: application/json

需要重点确认的是：

Authorization: Bearer <access_token>

不要发送文档中没有定义的字段：

{
  "profile_id": "..."
}

即使猜到了某个内部 ID，将它加入请求体通常也解决不了问题，反而可能导致请求校验失败。

建议的排查步骤

1. 确认 POST 请求确实携带了令牌

能够正常获取账户和收款人列表，不代表 Windev 在发送付款请求时也正确附带了请求头。记录实际发出的 HTTP 请求，逐项排除以下情况：

Authorization 只添加到了 GET 请求。
HTTP 客户端在重定向后移除了 Authorization。
请求头被误写成 JSON 字段。
使用的 access token 已过期。
Bearer 格式错误，例如 Bearer 后缺少空格。
刷新令牌后，付款逻辑仍在使用旧的 access token。

正确格式如下：

Authorization: Bearer eyJ...

2. 确认 API 环境一致

账户、收款人、令牌和付款请求必须属于同一个环境。不要混用：

Sandbox 与 Production；
不同的 Revolut Business 账户；
不同 OAuth/API 应用生成的令牌；
Merchant API 与 Business API 的地址或凭据。

如果 account_id 和 counterparty_id 来自生产环境，付款请求却被发送到沙箱，服务端可能无法建立正确的企业 profile 上下文。

3. 检查 URL 和重定向

直接调用文档中对应环境的付款端点，不要依赖 HTTP 301、302 或 307 重定向。部分 HTTP 客户端在跨主机请求或重定向后不会保留 Authorization。

可以暂时关闭自动重定向，查看服务器返回的原始状态码和 Location 响应头。

4. 使用同一个令牌进行最小验证

发起付款前，使用同一个 access token 调用账户接口，确认响应中包含付款请求所使用的账户 ID：

da68d3db-ea3a-4882-9495-30eec748d27d

还要确认指定的 counterparty 和 receiver account 都是在同一身份上下文中查询到的，不要使用之前缓存的其他客户数据。

5. 移除非必要字段进行测试

如果当前 API 版本支持立即付款，可以暂时移除 schedule_for，排除日期和定时付款能力的影响：

{
  "request_id": "TEST_20210105093124648",
  "account_id": "da68d3db-ea3a-4882-9495-30eec748d27d",
  "receiver": {
    "counterparty_id": "676d4b18-12c0-4da0-9f4a-a3e6cc9788cc",
    "account_id": "a496b5be-a7cb-4932-aaf7-6f0db1bb15ce"
  },
  "amount": 3,
  "currency": "EUR",
  "reference": "TEST TRANSFERT 20210105093124648"
}

这一步不能直接解决 profile id 问题，只是用来缩小排查范围。哪些字段可以省略，仍需以当前使用的 Business API 版本文档为准。

如果仍然返回 2101

如果已经确认以下各项，继续修改 payload 通常没有作用：

Authorization 请求头确实到达了付款端点；
access token 有效；
API 环境、账户和收款人 ID 一致；
调用的是 Business API 付款端点；
账户具备发起付款所需的权限；
请求没有因重定向而丢失认证头。

此时应通过 Revolut Business 网页端或移动端的在线客服联系支持团队，请其将工单转交给 Business API 或 Developer Support 团队。提交工单时，建议附上：

HTTP 状态码和完整错误体；
请求时间及所在时区；
request_id；
API 环境和端点路径；
响应中的 request/correlation ID（如果响应头提供）；
已脱敏的请求头和请求体；
Business 账户及 API 应用标识。

不要发送 access token、refresh token、私钥或客户端证书。

因此，错误 2101 应重点排查认证上下文、API 环境以及 Revolut 端的 Business profile 配置，而不是在付款 JSON 中添加未公开的 profile_id 字段。