把等待验证作为独立的业务状态
来源事实：在文档介绍的美国 ACH 设置流程中，Stripe 默认采用即时银行账户验证，同时提供手动输入账户资料和小额存款验证作为后备路径。[2] 当设置需要小额存款验证时，SetupIntent 的状态为 requires_action，且 next_action 中包含 verify_with_microdeposits。[2] 编辑建议：围绕这一明确状态设计恢复流程，而不是统一显示“付款失败”。客户此刻需要完成的是银行账户验证，不是重新购买，也不是为另一笔扣款授权。内部应保留正在恢复的设置记录标识，客户页面则只展示与本次操作有关的账户识别信息。客服指引应区分“等待存款到账”“等待客户输入验证信息”和“需要重新收集银行资料”，让工作人员能够说明当前停在哪一步。这些是建议采用的业务标签，不是额外的 Stripe 接口状态。本文仅讨论美国 ACH 账户验证，不介绍 PayIn 功能，不认证任何集成，也不声称已经执行实际支付测试。
依据存款类型选择输入表单，不要猜测
来源事实：Stripe 首先发送交易描述验证码类型的小额存款，如果验证过程遇到进一步问题，可能改用金额类型的小额存款。[2] 验证码路径使用一笔 0.01 美元存款，以及以 SM 开头的六字符验证字符串；虽然原文使用了“六位数字”的措辞，但其示例中包含字母。[2] 金额路径使用两笔并非唯一的存款，交易描述为 ACCTVERIFY，客户需要提供这两笔存款的金额。[2] 集成应检查 next_action.verify_with_microdeposits.microdeposit_type，并且只提交 descriptor_code 或 amounts 中的一种，不能同时提交。[2] 编辑建议：每次只展示一种明确的操作任务。验证码路径应说明所需信息位于交易描述中，不是那一美分的金额；金额路径则应要求填写两笔金额，并说明应查找的交易描述。不要把来源示例中同时列出两个参数的对象直接复制为实际请求，因为相邻说明明确要求只选择其中一种路径。[2]
分别说明预计到账时间与验证截止期限
来源事实：小额存款通常需要一至两个工作日，才会出现在客户的网上账户流水中。[2] next_action 数据包含 arrival_date 和 hosted_verification_url，而小额存款验证的超时期限为十天。[2] 引用文本对到账延迟明确使用工作日，对超时则仅表述为十天，没有给出完整的时区或截止时间计算规则。[2] 编辑建议：不要未经说明就把这两个时间段当成同一种计时方式。将预计到账时间与实现中能够可靠确定的截止时间分开展示。在预计到账之前，应说明客户之后需要查找什么，而不是鼓励提前猜测并提交信息。超过预计到账时间后，可先请客户查看对应账户的交易详情，再判断是否需要进入恢复流程。不要承诺存款一定在某个具体时刻出现。如果已有时间信息不足以计算精确截止点，应坦诚说明这一限制，并根据当前设置状态决定操作，而不是展示自行编造的倒计时。
把金额不匹配变成明确的纠正步骤，避免浪费机会
来源事实：Stripe 文档规定，交易描述验证码验证最多允许十次失败，金额验证最多允许三次失败。[2] payment_method_microdeposit_verification_amounts_mismatch 是同步错误，不改变当前状态，其错误消息会说明剩余尝试次数。[2] 超过允许次数时，错误为 payment_method_microdeposit_verification_attempts_exceeded，状态变为 requires_payment_method，并设置 last_setup_error。[2] 编辑建议：在界面和客服流程中，明确区分仍可纠正的不匹配与已经耗尽次数的情况。遇到不匹配时，应请客户重新核对真实交易详情，而不是换一组数字继续猜测。只有实际响应或另一个经过核实的集成字段提供依据时，才显示剩余次数；不要为两条路径自行设计一个看似通用的处理方计数器。在请求尚未得到结果时，防止客户意外重复提交。刷新页面或再次发送邮件，不应被描述为能够重置处理方允许的尝试次数。机会耗尽后，应引导客户重新提供银行资料，而不是无限保留原输入表单。
按超时与存款失败的不同原因恢复
来源事实：客户未在规定的十天内完成验证时，payment_method_microdeposit_verification_timeout 会通过异步事件通知到达，SetupIntent 回到 requires_payment_method，并填入 last_setup_error。[2] 另一种错误 payment_method_microdeposit_failed 可以同步或异步出现，同样要求重新提供付款方式资料。[2] 编辑建议：不要把这两种情况都说成再次输入验证码就能解决的普通笔误。对于超时，应说明旧验证窗口已经结束，并引导客户重新进入银行资料收集流程。对于存款失败，应请客户在安全的资料收集页面检查银行信息后再继续。引用页面明确了需要新付款方式资料，但没有规定应用层完整的重新开始架构。[2] 因此，内部设置记录究竟应复用还是替换，应在核对适用的集成约定后决定。不要声称重新打开旧链接、补发通知或修改本地截止时间，就能让已经过期的验证恢复有效。
让客户返回路径明确、安全，并检查最新状态
来源事实：提供账单电子邮箱后，Stripe 会发送有关预计存款到账的通知，其中包含托管验证页面的链接。[2] 自定义通知可以将客户引导至 next_action 中的 hosted_verification_url，集成也可以提供自己的验证表单。[2] Stripe 提醒，不应记录客户端密钥、将其嵌入网址，或向客户以外的人员暴露。[2] 编辑建议：选定一个主要恢复入口，并让通知内容对应当前的验证类型。客户返回时，应先检查设置的最新状态，因为此前发出的提醒可能已经对应一个完成、超时或因其他原因失败的设置。下一步应根据当前情况决定，而不是默认邮件发送时的指引一直有效。如果使用自建流程，应将设置记录与正确客户关联，并避免要求客服通过普通聊天或邮件收集银行登录凭据或完整账户资料。运营统计也应区分通知送达和验证完成；发送一个链接只是邀请客户操作，并不是账户已经验证的证据。
以设置成功关闭恢复，不要推断后续款项已到账
来源事实：小额存款验证成功后，Stripe 返回状态为 succeeded 的 SetupIntent，并发送 setup_intent.succeeded 事件。[2] 失败既可能表现为直接响应，也可能通过 setup_intent.setup_failed 事件出现，因此文档中的流程不限于浏览器当场看到的结果。[2] 通过手动输入和小额存款完成关联的账户，不提供余额、所有权和交易记录等额外银行数据。[2] ACH 直接借记本身也是延迟通知的支付方式，验证成功不能被当成后续扣款已经结算的通知。[2] 编辑建议：让客户界面的恢复进度与服务端设置状态相互核对，并在确认成功后停止过时提醒。审查时分别覆盖验证码输入、两笔金额输入、不匹配、次数耗尽、存款失败、超时以及完成后再次打开入口等场景。未解决的账户设置和恢复结果，应与后续支付结果分别统计。这些是拟议的审查场景，不是本文已经执行的测试。本文核验日期为 2026-09-21；来源发布日期未知，不能把核验日期解释为功能上线时间，也不能据此保证文档行为以后不会变化。
来源与日期
本次核验日期：2026-09-21。来源日期按原页面明确标注的发布或更新时间分别列示；未标注不等于本日发布。本文为公开文档研究，未进行真实支付、安全审计或辅助技术合规认证。厂商事实仅归属于被引用厂商；流程建议为编辑综合。