Stripe ACH Direct Debit 为什么不是即时到账
先给答案
因为 ACH Direct Debit 走的是美国银行间清算网络，Stripe 在扣款发起时无法确认这笔钱最终一定能收到。按 Stripe 文档，它属于“延迟通知”的支付方式：从发起扣款到收到成功或失败的最终答复，最长可能需要 4 个工作日（T+4）。所以“不是即时到账”不是 Stripe 故意压款，而是 ACH 网络的确认节奏决定的——扣款指令先发出，银行系统事后才回传结果。
三个状态必须分开看
很多人把“支付成功”当成“钱到手”，在 ACH 场景下这是最容易出错的假设。至少要拆成三层：
- 支付发起与授权：客户同意了付款条款，银行账户也通过了验证。这一步较快，但它只说明指令已被受理，不代表钱一定能收到。
- 资金可用：钱进入你的 Stripe 余额、可以动用。文档把这段等待称为 settlement timing，ACH Direct Debit 最长 T+4。
- 退回风险：即使资金已经可用，ACH 仍可能出现失败付款和争议。文档明确说明 ACH Direct Debit 不是保证到账的支付方式，存在失败付款与争议的风险。
因此，看到“支付成功”就发货、就确认收入，是把第 1 层当成了第 2、3 层。
按工作日推算时要注意什么
文档给出的上限是 T+4 个工作日，但这是一个上限，不是承诺的最终成功时限。实际拿到成功或失败答复的时间可能短于这个上限，也可能因银行假日、周末而顺延。
可以这样理解时间结构：假设扣款在某工作日发起，该日记为 T，那么 T+4 个工作日是理论上限；如果中间夹着周末或银行假日，日历日会相应拉长。举例来说，周一发起、期间无假日时，T+4 落在周五；若周四发起，则要跨过周末，日历日上会明显更晚。具体到某一笔，应以系统返回的预期扣款日为准，而不是自己按发起日硬算。
这个例子只演示时间结构，不涉及任何具体费率或资格判断。
能立刻执行的核对动作
- 查预期扣款日：在 Charge 的
payment_method_details下读取 ACH Direct Debit 的expected_debit_date。文档说明这是估算值，用它来安排对账和履约，而不是用“下单时间”。 - 确认账户验证已完成：文档要求银行账户必须验证，可用即时验证，必要时用微额打款（microdeposits）延迟验证；若在期限内未完成验证，PaymentIntent 或 SetupIntent 会退回要求提供新的支付方式信息。
- 检查账单信息完整性：
billing_details必须包含账户持有人姓名；若记录商户（merchant of record）在美国境外，还需完整地址。 - 在 Dashboard 里按状态核对：把支付状态、资金可用状态和退回/争议状态分别查看，不要用单一“成功”标签判断能否履约。
- 区分场景再定策略：如果业务确实需要即时确认和更快结算，文档提到 Instant Bank Payments 提供类似卡支付的流程，但仅作为 Link 的一部分提供；不需要即时确认、且偏大额或周期性交易的业务，文档说明 ACH Direct Debit 成本更低。
不要和电汇混为一谈
ACH Direct Debit 是美国银行账户扣款，不是电汇。电汇的到账路径和确认逻辑不同，不能用“电汇多久到”的经验去推断 ACH 的时间。本文结论仅限美国 ACH 扣款场景。
一句话收束：ACH Direct Debit 的“慢”来自延迟通知机制和 T+4 的结算上限，把授权、资金可用、退回风险三件事分开管理，才是使用它的正确姿势。