硬拒绝

硬拒绝（Hard Decline） 是指支付网关或收单行因永久性、不可逆的原因（如卡片被盗、账户已关闭、卡号不存在）而拒绝一笔交易，这类拒绝无论你重试多少次都不会成功，必须更换支付方式或联系持卡人解决。

生活化类比

想象你去一家酒店前台办入住，刷卡时系统提示“此卡已注销”。

- 硬拒绝就像前台告诉你：“这张卡已经被银行永久停用了，你换一张卡吧。”——你再刷100次，结果都一样。

- 软拒绝（Soft Decline） 则像前台说：“网络超时了，稍等一下再试。”——过几分钟重试，可能就成功了。

区别的核心在于：硬拒绝是“卡本身有问题”，软拒绝是“这次尝试有问题”。

核心概念/公式

在支付风控与路由系统中，硬拒绝通常由以下维度判定：

硬拒绝 = 永久性原因码 + 不可重试标志

常见硬拒绝原因码（ISO 8583 / 网关返回码）：

原因码	含义	是否可重试
04	卡片被没收（Pick Up Card）	❌ 不可
07	卡片被没收（特殊情况）	❌ 不可
12	无效交易	❌ 不可
14	无效卡号	❌ 不可
15	发卡行不存在	❌ 不可
41	卡片已挂失	❌ 不可
43	卡片被盗	❌ 不可
54	卡片已过期	❌ 不可
57	该卡不允许此类交易	❌ 不可
62	受限卡	❌ 不可

判定逻辑：

如果网关返回码属于“硬拒绝集合”，则订单状态直接标记为 `failed_permanent`，禁止进入重试队列。

与相关术语对比

术语	英文	原因性质	可否重试	典型场景	处理方式
硬拒绝	Hard Decline	永久性	❌ 无效	卡被盗、账户关闭	换卡/联系持卡人
软拒绝	Soft Decline	临时性	✅ 有效	余额不足、网络超时	稍后重试/换网关
风险拒绝	Risk Decline	风控判定	⚠️ 视情况	疑似欺诈、IP异常	人工审核/3DS验证
技术拒绝	Technical Decline	系统故障	✅ 有效	网关宕机、超时	自动重试
发卡行拒绝	Issuer Decline	发卡行决定	⚠️ 视原因	余额不足/风控	区分软硬再处理

关键区别： 硬拒绝与软拒绝的最大分水岭是——重试是否有意义。硬拒绝重试是纯粹的浪费，还会推高拒付率（Chargeback Ratio）。

应用场景（含数据/案例）

场景1：订阅制电商的续费失败

某SaaS订阅平台月费$29，续费时遇到硬拒绝：

- 数据： 在订阅续费失败中，约 15%-20% 属于硬拒绝（卡过期、卡被盗换新卡号）。

- 案例： 用户信用卡被盗后银行补发新卡，旧卡号自动失效。平台继续用旧卡号扣款，连续3个月硬拒绝，用户被动流失。

- 解法： 接入卡更新服务（Account Updater），自动获取新卡号，可将硬拒绝导致的流失降低 30%以上。

场景2：独立站高客单价订单

某独立站客单价$299，支付失败率8%：

- 数据： 其中硬拒绝占比约 25%，即总订单的2%。

- 案例： 风控系统对硬拒绝订单自动重试3次，结果全部失败，反而触发发卡行风控，导致该商户整体授权率下降 5个百分点。

- 解法： 识别硬拒绝后立即停止重试，引导用户更换支付方式（如PayPal、Apple Pay）。

场景3：跨境支付路由优化

某跨境商户接入5个收单行：

- 数据： 硬拒绝订单若错误路由到其他收单行重试，成功率仅 0.3%，几乎可忽略。

- 案例： 系统将硬拒绝订单误判为软拒绝，跨网关重试，每月浪费 $1,200 手续费。

- 解法： 建立硬拒绝码库，命中后直接终止路由，节省成本并保护商户评分。

常见误区

误区1：所有拒绝都可以重试。

→ 错。硬拒绝重试不仅无效，还会增加发卡行对商户的负面评分，甚至触发风控封禁。

误区2：硬拒绝一定是持卡人的问题。

→ 不一定。有时是商户提交的卡号格式错误、BIN号不匹配，导致网关误判为“无效卡号”（原因码14）。需先排查自身数据质量。

误区3：硬拒绝和欺诈拒绝是一回事。

→ 不是。欺诈拒绝（Fraud Decline）属于风控拒绝，可能可申诉；硬拒绝是卡本身状态问题，无法申诉。

误区4：硬拒绝后发邮件让用户重试同一张卡。

→ 无效。正确做法是引导用户更换支付方式，或通过Account Updater获取新卡信息。

误区5：硬拒绝率不影响商户账户健康。

→ 错。硬拒绝率过高会被收单行视为“高风险商户”，可能导致保证金上调或账户关闭。