资金冻结不是无限期的收款承诺
Stripe 对符合条件的支付方式支持将授权与请款分开，先冻结一定金额，再于之后请款。[3] 如果授权在请款前到期，冻结资金会被释放，支付状态变为 canceled。[3] 编辑建议：将授权表示为在有限时间内收取已批准金额的机会，而不是已经完成的收款。应指定人员或服务，负责在授权仍然有效时决定请款还是取消。这项责任不应隐含在订单状态中，也不应等到期限已过才分派。本文仅讨论 Stripe 文档中的授权流程，不讨论库存预留或稳定币结算，也不宣称其他支付产品提供了对应功能。
读取实际期限，不承诺统一时长
对于银行卡支付，Stripe 文档将 Charge 对象中的 payment_method_details.card.capture_before 定义为授权到期时间戳。[3] 授权窗口会因卡组织、交易类型及其他文档条件而变化，不能统一承诺为七天。[3] 编辑建议：将相关 Charge 及其期限与待决策的业务事项一起保存。在到期前安排内部决策节点，并根据具体集成留出运营处理余量；不要把自行选择的缓冲时间说成 Stripe 的统一要求。如果预期的期限缺失或无法解析，应进入调查流程，而不是凭记忆填入某个授权时长。业务判断的依据应是当前这笔授权的实际信息，而不是过去某笔支付的经验。
分别核对适用资格与请款就绪状态
Stripe 的手动请款仅适用于支持该能力的支付方式，文档明确指出 ACH、iDEAL 等方式不支持将授权与请款分开。[3] 手动请款模式下，授权成功的 PaymentIntent 会进入 requires_capture，amount_capturable 表示可请款金额。[3] 编辑建议：设计流程时先核对支付方式是否适用，执行决策前再核对该笔支付是否确实具备请款条件。内部团队将订单标记为就绪，并不能证明对应的 PaymentIntent 已经就绪。使用结账会话时，Stripe 要求通过结账会话返回的 PaymentIntent 标识进行请款。[3] 因此，操作人员应能区分订单标识、会话标识和真正用于请款的支付对象，避免用业务准备状态代替支付状态。
在授权窗口结束前解决业务判断
编辑建议：建立待办队列，区分仍在等待履约决定、已经批准请款，以及应该取消的支付。根据实际授权期限安排未决事项的优先级，而不只是按订单创建时间排序。说明性示例，并非测试结果：商户在确认服务是否可用期间先取得银行卡授权，待确认能够提供服务且授权仍有效时再请款。如果无法及时确认，应升级给负责人员处理，而不是假定冻结期限可以自动延长。Stripe 文档说明，取消授权可以通过取消对应的 PaymentIntent 实现。[3] 队列中的每一笔授权都应有明确的下一步负责人，不能仅因客户曾经完成授权，就让尚未解决的履约问题无限期停留。
除非确认适用例外，否则将部分请款视为最终分配
Stripe 默认请款全部授权金额；可用 amount_to_capture 指定较小金额，部分请款会自动释放剩余金额。[3] 大多数支付只支持一次请款，虽然部分符合条件的银行卡支付支持多次请款，但普通部分请款并不会留下可以正常再次收取差额的机会。[3] 编辑建议：提交部分请款前，先确定最终金额和本次履约范围。面对拆分交付，不要假设第二次交付仍能使用原来的剩余冻结金额。若业务确实需要多次请款，应进入独立的资格核验流程，而不是将某些支付的例外条件默认为所有授权都适用。金额决策必须在操作之前明确，避免在第一次请款后才发现原计划依赖了不存在的第二次机会。
规定到期、结果不明和范围变化的处理路径
编辑建议：授权已经到期时，停止把旧冻结视为仍可收取的资金，并判断是否需要启动新的客户支付流程。请款请求的结果不明确时，先检查当前支付状态再决定下一步，不要让内部请求超时直接决定是否已经收款。订单批准金额发生变化时，应重新取得明确的金额决策，而不是自动照搬原授权金额。Stripe 指出，一些发卡行账单和支付界面无法清楚区分授权与已请款支付。[3] 向客户解释这一区别时，不要承诺缺乏依据的冻结释放显示时间，也不要把资金冻结描述成已经完成的扣款。异常处理应帮助确定真实状态和可执行动作，而不是用客服措辞掩盖不确定性。
用拟议清单验证期限决策流程
编辑建议——以下为拟议测试清单，并非已执行结果：让适用的手动请款流程进入 requires_capture；验证保存的期限来自相关银行卡 Charge；将选定金额与 amount_capturable 核对；检查期限缺失、即将到期及已经到期时应用如何处理。加入部分请款情境，确认释放的剩余金额不会被安排为普通的第二次请款，这与 Stripe 文档描述的默认行为一致。[3] 还应覆盖取消授权、不支持的支付方式，以及请款响应中断的情况。真正执行时，应记录支付服务端实际状态和应用作出的决策。这份清单提供验收标准，不代表测试已经成功，也不保证所有支付方式都具有与银行卡相同的行为；不同方式仍须核对各自适用条件。
来源与日期
本次核验日期：2026-09-20。来源日期按原页面明确标注的发布或更新时间分别列示；未标注不等于本日发布。本文为公开文档研究，未进行真实支付、安全审计或辅助技术合规认证。厂商事实仅归属于被引用厂商；流程建议为编辑综合。