Postman 中 PaymentsOS Authorization 无法正常工作

2026-10-24支付小周

结论

只看到 Problem here，还无法判断具体原因，因为缺少实际请求内容、HTTP 状态码和响应体。问题往往不在 Postman，而在于请求缺少 PaymentsOS 要求的认证头或环境配置、前置资源尚未创建，或者 Authorization 的 JSON 结构不符合接口要求。

先查看响应状态码和响应体，再按以下顺序排查。

重点检查项

1. 确认请求地址和环境一致

测试环境和生产环境不能混用。API 地址、应用凭据、支付方式 Token，以及 x-payments-os-env 之类的环境标识，都必须属于同一个环境。

例如，使用测试凭据向生产环境发送请求，通常会导致认证失败、资源不存在或 Token 无效。

2. 检查认证请求头

具体配置取决于 PaymentsOS 账户和 API 版本。请求通常需要提供应用标识、私钥、API 版本和环境信息，例如：

Content-Type: application/json
api-version: <API_VERSION>
app-id: <APP_ID>
private-key: <PRIVATE_KEY>
x-payments-os-env: <ENVIRONMENT>
idempotency-key: <UNIQUE_VALUE>

这些名称只用于展示常见结构，实际配置应以当前 PaymentsOS API 文档和账户设置为准。检查时注意以下几点：

请求头的值两侧不要添加多余引号。
确认 Postman 环境变量已经正确展开。
检查变量名称是否拼写正确。
不要混用公钥、客户端 Token 和服务端私钥。
每次独立请求都应使用合适且唯一的 idempotency-key，不要长期重复使用同一个值。

可以通过 Postman Console 查看最终发出的请求头，但不要在截图或日志中泄露 private-key。

3. Authorization 通常不能脱离 Payment 单独创建

常见流程是先创建 Payment，取得 payment_id，然后针对该 Payment 创建 Authorization：

Create Payment
    ↓
取得 payment_id
    ↓
Create Authorization

Authorization 请求地址中的 {payment_id} 必须替换成真实 ID，不能保留占位符：

POST /payments/{payment_id}/authorizations

例如：

POST /payments/pay_123456/authorizations

如果 Payment 不存在、属于其他环境，或者当前状态不允许再次授权，Authorization 请求都可能失败。

4. 检查支付方式数据

Authorization 通常需要有效的支付方式信息。使用 Token 时，应确认：

Token 是通过 PaymentsOS 支持的方式生成的。
Token 尚未失效。
Token 与当前测试或生产环境一致。
Token 类型符合相应支付服务商的要求。
请求体中的字段名称和嵌套层级正确。

以下内容只是结构示例，不表示所有账户和支付服务商都使用相同字段：

{
  "payment_method": {
    "type": "tokenized",
    "token": "<PAYMENT_METHOD_TOKEN>"
  }
}

不要将完整银行卡号、CVV 等敏感数据直接写入普通请求，也不要保存到 Postman Collection。应使用 PaymentsOS 提供或认可的安全采集和 Tokenization 方案。

Postman 配置示例

取得 Payment ID 后，可以按以下方式配置请求。

请求方法和地址：

POST https://<PAYMENTSOS_API_HOST>/payments/<PAYMENT_ID>/authorizations

Headers：

Content-Type: application/json
api-version: <API_VERSION>
app-id: <APP_ID>
private-key: <PRIVATE_KEY>
x-payments-os-env: <ENVIRONMENT>
idempotency-key: <UUID_OR_OTHER_UNIQUE_VALUE>

Body 选择 raw，格式选择 JSON：

{
  "payment_method": {
    "type": "tokenized",
    "token": "<PAYMENT_METHOD_TOKEN>"
  }
}

根据支付服务商、账户配置和交易场景，实际请求体可能还需要其他字段。仅凭现有信息无法确定具体内容。

根据状态码定位问题

400 Bad Request：JSON 格式、字段类型、必填参数或业务参数有误。
401 Unauthorized：app-id、private-key 或其他认证信息不正确。
403 Forbidden：凭据有效，但无权访问相应环境、资源或操作。
404 Not Found：接口地址错误，或者 payment_id 不存在、环境不匹配。
409 Conflict：可能重复使用了幂等键，或当前 Payment 状态不允许执行该操作。
422 Unprocessable Entity：请求格式可以解析，但支付方式、金额、币种或业务状态不符合要求。
5xx：可能是服务端或下游支付服务商异常，仍需结合响应体中的错误代码判断。

建议的排查顺序

在 Postman Console 中核对实际发送的 URL、请求头和请求体。
记录 HTTP 状态码和完整的响应 JSON。
检查 app-id、private-key 与环境配置是否配套。
确认 Payment 已成功创建，并使用响应中的真实 payment_id。
确认支付方式 Token 来自同一环境，而且仍然有效。
检查 Content-Type、API 版本和 JSON 字段结构。
更换幂等键，再发起一次独立请求。

如果问题仍未解决，需要提供脱敏后的请求 URL、Headers 名称、Body、HTTP 状态码和完整错误响应。缺少这些信息，就无法准确区分认证失败、参数错误、Payment 状态异常或支付服务商配置问题。