Stripe拒付证据应对

解决什么问题

当 SaaS 收到 Stripe 的拒付通知时，团队往往面临两难：应诉需要提交证据，但每次提交还要再付一笔费用，算下来可能得不偿失。很多团队要么不了解自己的真实胜诉历史而盲目应诉，要么不懂如何从自家用户数据库里提取登录、使用记录，把本来能赢的争议白白输掉。这个技能要解决的就是「该不该应诉」和「怎么把证据做对」这两件事。

工作机制

技能的顺序是先判断、后取证：

1. 先算经济账：核实当前 Stripe 定价（标准价格下，收到争议即扣 $15，提交证据再扣 $15，胜诉才退还后者），然后拉取商家自己的历史争议数据——只统计真正提交过证据（evidence_details.submission_count > 0）且已结案的争议，区分首购与续费、按相同理由过滤，据此算出真实胜率与盈亏平衡概率。
2. 决策门槛：默认采用 30% 的最低胜诉概率阈值。如果历史数据撑不起这个阈值，明确建议放弃应诉，避免再付一笔应诉费——尽管争议金额和已扣费用仍然损失。
3. 先授权再动手：任何生成文件、上传证据或提交的动作，都必须在用户明确同意之后进行，因为 submit=true 是一次性且不可撤销的。
4. 组装证据包：按争议原因（fraudulent、product_not_received、product_unacceptable、subscription_canceled）走不同的取证策略，从数据库提取登录会话、创建的项目、消耗的额度等具体数字，生成包含摘要网格、支付历史、结算尝试、登录日志和时间线的活动记录 PDF。
5. 提交前复查：向用户展示答辩文案、证据文件和胜率评估，等待确认后再上传文件并提交。

一个高价值的矛盾点：用户在应用内取消订阅时自填的 cancel_reason（比如「用户体验差」）可能直接反驳其后来以 "product not received" 发起的拒付，技能要求在答辩中原样引用这条记录。

适用边界与注意点

• 仅适用于使用 Stripe、且有用户数据库（含登录或使用日志）的 SaaS。
• 数据库查询严格只读（SELECT），建议给连接配置最小权限角色。
• 证据文件必须上传到 files.stripe.com 而不是 api.stripe.com；每个争议使用独立的 file_id，同一客户 N 个争议就要上传 N 份副本。
• 提交截止时间以 evidence_details.due_by 为准，过期后无法再提交。
• 活动日志 PDF 中不得混入其他客户的数据；建议把每份证据包保存到磁盘，方便同一客户后续争议复用。
• 所有对外写入动作（上传、提交）都会先向用户展示目标与影响，取得明确确认后才执行。