用问题严重度安排响应

所有请求按到达顺序处理，可能让普通用法问题排在重复扣款或数据风险前面。可以建立四级队列：

响应时间承诺要与团队能力一致。用户最需要的是有人确认问题、知道下一步和更新时间。无法立即修复时，清楚说明状态和绕行方案，比自动发送「问题已经解决」更可靠。

关闭工单前应确认用户是否恢复任务。若同类问题重复出现，更新页面、错误提示、Onboarding 和帮助内容。支持的价值体现在减少下一次问题，而不只是一张「已关闭」工单。

留存分为价值流失和非自愿流失

用户主动停止使用，常见原因包括任务完成、结果不够好、频率低、产品改变、价格不匹配或支持失败。非自愿流失则可能来自卡片过期、余额不足、认证未完成、银行拒绝和支付方式失效。

两类问题需要不同处理。价值流失应回到产品和定位；支付失败要让用户更新支付方式，并清楚说明重试、权益和取消状态。仅靠增加催款次数，会打扰本来已经不需要产品的人，也不能修复结果质量。

留存邮件可按使用周期安排：

• 用户还没完成首次价值时，帮助恢复当前任务；
• 已成功一次时，说明怎样保存、复用或完成下一项相关工作；
• 到达自然复用时间时，提醒已有数据和未完成事项；
• 长期没有使用时，询问原因并提供清楚退出；
• 已取消时，确认到期、数据导出和重新启用方式。

日留存并不适合所有产品。报税、旅行、招聘和季度报告等低频任务，应按真实业务周期观察再次使用、任务完成和续费，不能用社交产品的每日活跃标准评价。

支付失败是一种状态，不应立即当作取消

一次扣款失败可能是临时问题，也可能需要用户采取行动。系统至少要记录失败时间、付款对象、账单、原因类别、是否可重试、下一次尝试、用户通知、权益状态和最终结果。

以 Stripe Billing 当前文档为例，invoice.payment_failed 等事件可通知系统支付失败；部分失败可以自动重试，Hard Decline 或缺少可用付款方式等情况需要用户更新资料。订阅可处于 incomplete、past_due、unpaid、canceled 等不同状态，产品要按实际配置决定何时保留宽限、何时限制权益，并通过 Webhook 与账单事实同步。^[1]

失败邮件应包含：

• 哪一项账单未成功，金额和币种是什么；
• 是否已经产生扣款，不能用含糊语言制造重复支付；
• 用户可以在哪里安全更新付款方式；
• 是否会再次尝试，预计何时；
• 当前权益、宽限期和最终停止条件；
• 无法处理时怎样联系支持。

支付方式更新必须指向产品或支付服务商的可信页面。邮件不能索要完整卡号，也不应通过普通回复收集敏感支付资料。系统还要防止旧默认付款方式继续被重试，并测试支付平台、订阅和产品权益三处状态是否一致。

退款流程要区分申请、资金和权益

「已经同意退款」与「资金已经回到用户账户」是不同状态。一个完整流程包括：

1. 收到申请并确认订单；
2. 按公开政策判断范围、金额和原因；
3. 批准、拒绝或请求必要信息；
4. 向支付平台发起退款；
5. 记录 Pending、Succeeded 或 Failed；
6. 同步额度、许可证、订阅和后续账单；
7. 通知用户实际进度；
8. 将原因进入产品复盘。

Stripe 当前文档说明，退款使用可用余额；余额不足时，卡退款可能保持 Pending，其他付款方式的处理可能不同。退款成功出现到账还取决于卡网络和发卡行，失败时需要商户另行处理。^[1] 因此客服不应在只提交请求后承诺「已经到账」，也不能把平台状态和银行显示混为一谈。

退款政策应在购买前可见，写清适用期限、数字内容或服务是否已经交付、部分退款、订阅取消、税费和法定权利。政策不能覆盖当地消费者强制权利，也不应设置重复证明、隐藏入口和长时间沉默来阻止合理退款。

Chargeback 是银行争议流程

退款由商户按政策处理；Chargeback 或 Payment Dispute 通常由持卡人向发卡行提出。支付平台协助传递通知和证据，最终决定通常由发卡行作出。用户声称已经撤回争议，也不代表商户可以忽略平台要求。

Stripe 当前文档显示，正式争议会影响账户余额和争议率，商户通常只有有限时间回应；证据应针对具体 Reason Code，一次提交前完整检查，外部链接和要求银行另行联系通常不会被审阅。^[1]

可用证据来自正常经营过程：

• 购买页面上的准确产品、价格和续费说明；
• 用户接受的条款与退款政策版本；
• 订单、付款认证和账单描述；
• 数字产品下载、登录、使用、导出和交付记录；
• 物流、服务日期或预约事实；
• 客服沟通、问题解决和已提供退款；
• 与争议原因直接相关的账户或设备证据。

证据要按时间线组织，内容简洁，并只提交允许使用、与争议相关的信息。为应对未来争议而无限记录用户行为，会增加隐私和安全风险。保存期限和访问范围应由交易、法定义务、争议窗口和实际必要性共同决定。

争议原因也要回写产品。用户「不认识这笔交易」可能与账单描述、品牌名和收据不一致有关；「未收到」可能来自交付邮件被拦截或账户绑定失败；「与描述不符」可能暴露页面夸大；「已取消仍扣款」可能说明取消状态和账单系统不同步。把所有争议归类为恶意盗刷，会错过可以修复的经营问题。

防盗刷要保护正常用户

Card Testing 常使用自动化脚本、小额支付或保存卡片接口验证被盗卡信息。短时间大量尝试、低金额成功、异常姓名邮箱、同一设备或网络反复换卡，都可能是信号。单一 IP 规则往往不足以处理分布式攻击。^[2][1]

基础防护包括：

• 使用支付服务商当前推荐的 Checkout 或支付组件；
• 保护 Secret Key，限制端点权限；
• 在创建客户、保存卡片和支付接口设置会话校验、速率限制与必要的 CAPTCHA；
• 传递支付服务商需要且允许收集的真实交易信号；
• 监控尝试次数、失败、低额异常、退款和 Dispute；
• 对可疑成功交易及时人工核查；
• 保留关闭被攻击入口和轮换密钥的预案。

历史案例曾展示以 risk_score、卡国家、同 IP 或同卡尝试次数配置 Radar 的历史规则。^[2] Stripe 当前文档已经调整通用风险控制：Risk Settings 使用独立模型进行相应阻断，旧的 High Risk risk_score Block Rule 正在弃用；Radar for Fraud Teams 仍可用自定义分数规则。正式配置应以账户当前功能和文档为准，不能复制历史阈值。^[1]

Radar 等工具可以 Request 3DS、Review 或 Block。阈值过松会放进欺诈，过严会拒绝正常客户。团队应分别记录拦截、人工审核、3DS 完成、正常支付误拒和最终争议，再按客单、地区、支付方式和真实攻击调整。3DS 可能带来责任转移或更强认证，也会增加结账步骤，且不能解决产品误导、交付失败和所有争议类别。