H7.06.1payment failure copy设计研究
失败原因需可理解且可行动
别名: 支付失败文案 · 扣款失败 · declined payment
概念解释
渠道或风控明确拒绝这一笔之后，界面要说出发生了什么和人可以改哪一处：余额不足、卡过期、银行拒绝、超限额、商户不支持该卡组。可行动指下一步不是「请重试」这句空话，而是换方式、换卡、降金额、联系发卡行。这条处理的是已知失败的说明，不是超时后状态不明，也不是重试会不会再扣一次。
机制
支付失败的原始信号是渠道码，对人没有意义。人需要把码映射到自己能操作的对象：这张卡、这个钱包、这一单的金额。映射错了会生成错误动作——余额不足却让人再点同一张卡，银行拒绝却让人改地址。语气把责任推给「您的操作有误」会叠加上羞辱，人离开不再试别的方式。可理解还要求区分本站能修的（换方式）和只有银行能修的（风控拒），避免人在商户页空等。
怎么研究
用几种真实拒绝（余额不足、过期、银行拒、商户不支持），比较渠道原文、笼统「支付失败」、映射后的行动文案。
自变量：是否点名原因对象、是否给出替代方式、是否暴露原始码。 因变量：正确改换方式的比例、无意义重试、离开、能否向第三人复述失败原因。
实验室里把原因写在任务脚本里会污染理解。要用真实或仿真的拒绝码。不要把「最终付成」当成文案成功——可能是人随机换卡碰巧对了。
边界
反欺诈拒绝不能写细规则，可行动变成「用别的方式或稍后再试」，并给客服编号。用户当面不想让旁边的人看见「余额不足」时，要有可折叠的详情，默认一句中性失败加「查看原因」。完全未知的渠道码不要编造具体原因，那会变成猜测；未知应走查询，而不是假装已知失败。
怎么落地
- 把拒绝映射成对象 + 动作：卡、钱包、金额、银行；主按钮指向最可能的修复（换方式、换卡），而不是再次提交同一意图。
- 原始码可作次要信息给客服，不作为唯一文案。
- 同一失败连续出现时，升级建议（换方式、联系银行），不要无限「再试一次」。
- 验证：对余额不足、卡过期、银行拒各走一单，遮住内部文档，问「要改什么才能付」。答「再点一次」或改无关字段，文案失败。