配好 Stripe dunning，别把用户弄丢
Stripe dunning 怎么运作：Smart Retries 与自定义计划、Stripe 帮你发的邮件、你自己要定的宽限期，以及后台永远不会显示的那一步核对。
Stripe 给你 dunning 的机制，策略留给你。重试、拒付处理、追回邮件都已经有了。Stripe 替你决定不了的，是用户能保留访问权限多久，以及卡刷通之后用户仍然不回来时你怎么办。
这一页给的是一个能避开常见失败的配置顺序：别让重试计划只为支付通道服务，而要为人服务——那个需要看到邮件、并且去找一张新卡的人。
先定重试行为，再写文案
订阅账单扣款失败后会进入重试流程。Stripe 可以用 Smart Retries，根据它掌握的时机信号来决定什么时候重试，也可以由你定义固定计划。
两种选择的取舍都很诚实：窗口越长，追回的钱越多，同时更多账号会在坏状态里待更久。这个要主动决定，因为后面每一步——邮件措辞、宽限期、降级——都是照着这个窗口写的。
分清哪些邮件 Stripe 发，哪些你自己发
Stripe 可以自带发「付款失败」和「更新卡片」的邮件。对多数团队来说这是正确的起点：在后台配置就行，链接指向 Stripe 托管的换卡页，你什么都不用建。
自己写邮件的理由是上下文。如果你的产品本来就会告诉用户「你的成果都还在」，追回邮件可以说同一件事。一旦你接管邮件，就接管整套活：用自己的域名发，并保证换卡链接一直能用。
宽限期是你的策略，不是默认值
付款失败期间是否保留访问权限，是产品决定。立刻掐掉权限，等于惩罚一位银行误拒了正常扣款的用户；永久保留，订阅就悄悄变成了免费版。
无论怎么选，都要写进邮件和产品里。毫无预警的锁权限，就是非自愿流失变成自愿流失的那一刻，用户的理由也从银行问题变成了你的产品。
在用户回答的地方衡量追回
追回一笔账单是财务事件，不是留住了一个用户。要分清这两者，就在事情发生的那一刻提问。MorePaying 的组件跑在你自己结账页和定价页上，「刚才是什么让你没有完成付款」这个问题在失败还停在屏幕上时就被问出来，回答也直接绑到挡住的金额，而不是落到客服收件箱。
dunning 闭环也是这样收口的：你改了重试窗口或邮件，通过 CLI 带着发布 SHA 上线，这次发布之后的实付结果会和同一份基线对比。
FAQ
Stripe dunning 在哪里配置？
在 Stripe 后台订阅和账单相关的设置里，重试计划和追回邮件都在那里。菜单名在不同后台版本之间会变，按「重试设置」找，不要照着截图找。
Stripe 会自动发 dunning 邮件吗？
Stripe 可以发付款失败和更新卡片的邮件，你也可以改或关掉。一旦关掉，通知和换卡路径就由你自己负责。
dunning 邮件应该用我自己的域名发吗？
如果你想要回复、送达率和品牌都是自己的，就用。不想自己维护邮件系统时，用 Stripe 托管的那套是最快且正确的选择。