Radar 把可疑交易挡在前面，但争议发生后，战场已经换了。Stripe 转交证据，发卡行判断输赢。你要做的是在截止日前交一份能读懂的证据包。
Stripe 文档给的时间窗口很短：通常 7-21 天，取决于卡组织。错过 deadline，基本就是自动输。
第一眼先看哪几个字段？
表 1：Stripe 争议字段表
| Dashboard / API 字段 | 为什么重要 | 从哪里拿 |
|---|---|---|
dispute.reason | 决定证据方向 | Disputes 页面、Dispute object |
evidence_due_by | 决定最后提交时间 | Disputes 页面 |
payment_intent / charge | 连接付款授权和风控信号 | Payments、PaymentIntent |
invoice / subscription | 证明订阅、金额、账期 | Billing、Invoices |
customer.email | 连接客户账号和付款 | Customer object、App 用户表 |
billing_details | 账单姓名、地址、邮箱 | Charge、PaymentMethod |
radar.risk_score / Radar action | 说明付款时风险判断 | Payment details、Radar |
three_d_secure / ECI | 证明是否有 3DS 或 liability shift | Payment details |
先别上传文件。把这些字段导出来，按时间排一条线：客户什么时候注册，什么时候付款，什么时候使用，什么时候联系支持，什么时候发起争议。
不同 reason 要交什么？
表 2：SaaS 争议证据包
| Dispute reason | 材料名 | 证据要点 | 常见无效材料 |
|---|---|---|---|
| fraudulent / 未授权 | 付款授权记录、3DS、登录日志、IP/设备摘要 | 证明客户本人或账户持有人完成付款并使用服务 | 只截一张付款成功页 |
| product_not_received / 未收到服务 | 欢迎邮件、账号开通、功能使用记录、API 调用日志 | 证明服务已交付且客户可访问 | 只说「系统自动开通」 |
| product_unacceptable | 工单记录、修复记录、退款沟通 | 证明服务内容、客户反馈和处理过程 | 营销页面截图 |
| credit_not_processed | 退款政策、退款申请记录、是否已退款 | 证明按政策处理或客户不符合退款条件 | 没有日期的 policy 文本 |
| duplicate | 两张 invoice、两个 PaymentIntent、客户授权记录 | 证明不是重复扣款，或解释不同账期 | 只列金额，不列账期 |
| subscription_canceled | 取消记录、续费提醒、条款、最后使用时间 | 证明取消时间和扣款时间关系 | 模糊的客服聊天长图 |
Stripe 最佳实践里还有一个很实用的限制：同一 evidence type 只能一个文件，总文件大小限制 4.5MB；Mastercard 还有 19 页限制。把材料压缩成短 PDF，不要上传 40 页聊天记录。
SaaS 应该提前留哪些日志？
争议发生后再补日志，通常已经晚了。至少在系统里留这些字段：
表 3：SaaS 交付留证表
| 材料名 | 后台字段 | 留多久 | 用途 |
|---|---|---|---|
| 注册记录 | user id、email、created_at、signup IP 国家 | 至少覆盖争议窗口 | 连接客户账号和付款 |
| 付款记录 | PaymentIntent id、Invoice id、amount、currency、card country | 永久或随会计周期 | 证明金额和账期 |
| 登录记录 | login_at、device、IP country、session id | 90-180 天 | 证明服务使用 |
| 产品使用记录 | feature event、API calls、project id | 90-180 天 | 证明交付和价值 |
| 邮件记录 | welcome、receipt、renewal、cancel confirmation | 永久或至少 1 年 | 证明通知已发 |
| 政策快照 | Terms、Refund、Pricing 发布版本 | 每次改版保存 | 证明付款时政策是什么 |
注意隐私。证据包里不需要放完整 IP、完整卡号、内部风控 secret 或客户无关数据。给发卡行看的材料要够用，但不要泄露更多。
Radar 规则在证据里怎么用？
Radar 可以作为上下文，但不是核心证据。你可以说明付款时 risk level、3DS、CVC/AVS、review action 和是否进入人工审核。真正打动发卡行的，仍是客户授权和服务交付。
比如未授权争议，3DS 成功、同一邮箱登录、多次使用产品、账单描述清楚，这些比「Radar 没拦」更有用。
处理争议时经常要同时打开 Stripe、客服系统、日志平台和产品后台。团队可以把退款、争议和人审操作固定在同一套工作环境，用Stripe Dashboard 稳定访问减少登录中断。
提交前做 5 分钟自检
第一，证据是否只围绕 reason。未授权就别放一堆产品路线图。
第二，时间线是否闭合。付款、交付、沟通、退款政策展示要按时间排。
第三，文件是否能打开。Stripe 不接受外部链接让发卡行联系你，也不适合上传音视频。
第四，大小是否符合限制。4.5MB 不是很多，截图要压缩。
第五，提交后不能改。点 submit 前，让另一个人读一遍。
输了以后还要看什么？
不要只看单笔输赢。把争议原因、金额、渠道、国家、套餐、是否 3DS、是否使用服务放进表里。5-10 笔之后，你会看出是广告流量差、账单描述不清、退款政策太硬，还是 Radar 规则太松。
争议费、坏账、客服时间和误伤损失都要算。SaaS 早期每月 2 笔 chargeback，可能比服务器费更值得处理。