PayPal 信用卡支付失败：9500、5120 等常见错误码怎么查？

顾客说“信用卡付不了”，后台又出现 9500、5120 或一个 DECLINED。对商家来说，先分清失败发生在哪一步、正在看哪个字段、这一笔是否真的收到了钱，比让顾客反复换卡更有用。

本文面向通过网站收单的商家，重点解释 PayPal 直接卡支付中可能返回的 processor_response.response_code。它不是所有支付方式通用的一套错误码，也不能与 API 的 details[].issue 混为一谈。

一、先找对字段，再查错误码

可把一次失败分成三层来查看：

1. 接口调用层：记录失败阶段、HTTP 状态、顶层 name、details[].issue 和 debug_id。例如能力未开通或参数不支持，应先修复商户配置和集成流程。
2. 卡处理层：如果响应提供 processor_response，再按 response_code 查对应定义。不是每个响应都会同时给出全部字段。
3. 收款结果层：检查 purchase_units[].payments.captures[].status，并核对金额、币种和本地订单关联。不要只看 HTTP 200 或最外层订单状态。

二、商家最常遇到的 10 个返回码

下面的英文名称来自官方 Orders v2 schema；右侧是商家下一步的排查方向，并不保证采取某个动作后付款一定通过。

三、订单 COMPLETED，为什么仍不能发货？

下面是为讲解结构整理的脱敏示意，不是客户订单，不保证每个真实响应都包含这些字段：

{
  "id": "ORDER_ID_REDACTED",
  "status": "COMPLETED",
  "purchase_units": [{
    "payments": {
      "captures": [{
        "id": "CAPTURE_ID_REDACTED",
        "status": "DECLINED",
        "amount": {"value": "29.00", "currency_code": "USD"},
        "processor_response": {
          "response_code": "9500",
          "cvv_code": "M"
        }
      }]
    }
  }]
}

这份示意的外层订单是 COMPLETED，但 capture 为 DECLINED，商家应按拒绝处理，不要发货或开通服务。PayPal 官方测试示例也存在外层订单完成而 capture 被拒绝的情况。

• DECLINED：明确拒绝，不履约。
• PENDING：结果待核实，等待服务端查询或后续有效通知，不当作已收款。
• COMPLETED：继续核对 capture 的金额、币种、支付记录和本地订单关联，再推进履约。

有些字段容易让人误读：cvv_code=M 只表示安全码匹配，不代表通过 3DS，也不代表付款成功；seller_protection.status=NOT_ELIGIBLE 仅涉及卖家保障资格；final_capture=true 表示针对授权不再计划继续 capture。即使响应含手续费、净额等字段，也不能替代 capture 成功状态。

四、明确拒绝与超时未知，要走不同流程

明确返回拒绝时，按对应错误处理。请求超时或连接断开时，则可能只是商家尚未收到结果。先查询原订单或 capture，并按该 API 的幂等规则重试；不要为了“试一下”重新创建另一笔扣款。

把本地订单、PayPal 订单、capture 记录和每次调用关联起来，客服才能区分“没创建成功”“顾客已确认但未捕获”“等待核实”和“确实被拒绝”。建议保留失败阶段、HTTP 状态、issue、response_code、认证结果摘要、发生时间和内部支持用 debug_id；日志不记录完整卡号或 CVV，对外示例统一脱敏。

如果已经使用 paylink 收单与订单管理系统，可结合订单详情中的状态和错误记录排查，让同一笔业务的结果有据可查。

官方资料与核验日期

资料核验：2026-10-15。错误定义和处理要求以实际接口返回及官方最新文档为准。

• Orders v2 schema：processor_response 与 response_code 定义
• Orders v2：订单状态定义
• PayPal 官方测试卡与拒绝响应示例
• REST API 幂等请求说明