一家独立站单日产生了 10 万美元已支付订单。订单后台显示 Paid，支付后台则有 Pending Balance、Available Balance、Reserve 和正在处理的 Payout；银行账户当天收到的金额，却少于 10 万美元。
这些数字可以同时成立。即使核对的是同一批交易，平台记录的资金也可能处于不同阶段；当天银行收到的款项，还可能来自更早的销售。
消费者看到 Payment Successful、商户看到平台余额、财务看到银行入账，分别对应不同系统中的记录。支付成功描述交易进度，银行到账描述资金入账；两者之间还涉及授权、捕获、清算、机构间结算、余额可用、风险保留和出款。
这个时间差会影响营运资金：广告今天扣款，供应商要求预付款，库存、仓储和物流持续花钱，销售资金却可能还在 Pending、Reserve 或等待 Payout。在支出先发生、收入存在等待的业务中，销售增长会增加这段期间需要垫付的现金。
要判断钱什么时候能用，先把交易处理与资金进度分开看。
一、把一笔支付分成三个观察层次
线上银行卡支付可以从三个层次观察。它们各自回答不同的问题。
交易生命周期从消费者发起付款开始，涉及 Authorization（授权）和 Capture（捕获）：
Customer Payment → Authorization → Capture
这一层关心交易是否获准继续，以及商户是否把已授权交易正式提交收取。
机构间处理涉及收单侧、卡网络与发卡侧之间的信息核对和结算义务：
Capture → Clearing → Settlement
这一层关心各参与方如何传递和核对交易信息、计算应履行的资金义务，以及完成机构间结算。
商户资金生命周期则观察平台余额和出款。Pending / Settling、Available、Reserve、Payout 等名称来自具体平台或资金系统；企业可以另设 Bank Received（银行实际入账），作为内部经营字段。
Paid ≠ Available ≠ Payout ≠ Bank Received
Paid 表示业务系统认为付款达到了某个成功状态；Available 表示资金满足平台定义的可用条件；Payout 记录平台出款；Bank Received 记录企业银行账户实际收到资金。
图中三层是不同参与方和系统的观察视角。商户资金项没有被连成一条严格的状态链：平台未必提供相同字段，各状态也未必依次出现或能够一一映射。
Payment Successful 在某个产品中究竟对应授权、捕获、异步确认还是业务系统自己的 Paid，需要根据支付方式、产品文档和账户状态映射确认。
二、Authorization 与 Capture：获准继续和正式收取
Authorization 是向发卡侧请求批准或拒绝交易。业务团队可以把它理解为「允许交易继续，并可能预留相应额度或资金」。这是帮助理解的简化解释，不能据此认定商户已经无条件拿到了钱。
Capture 可以理解为「把已授权交易正式提交收取」。授权与捕获可以由系统连续处理，也可以在支持这项能力的产品中分开执行。
例如，商户先授权，再在发货、客人入住或服务确认等业务节点捕获；具体触发点由业务和产品安排决定。Stripe 的官方示例是酒店先授权、客人退房后捕获。如果超过适用的授权有效期仍未捕获，授权可能失效，预留资金或额度可能被释放。
采用自动捕获的即时交付电商，可以让消费者只看到一次 Payment Successful。产品把处理步骤隐藏在一次操作里，授权与捕获仍承担不同工作。
企业需要确认：订单显示 Paid 时，支付后台是 Authorized、Captured 还是其他状态？如果尚未 Capture，由谁触发、触发条件是什么？
三、Clearing 与 Settlement：先核账，再履行结算义务
在上面的银行卡处理视角中，Capture 后还有机构间处理。对于不直接参与卡网络处理的商户，这些工作由参与机构完成，日常经营无法直接控制每一步。
CPMI 将 Clearing（清算）解释为结算前传递、核对，并在一些情况下确认交易的过程；其中可能涉及交易净额计算和最终结算头寸的确定。用直白的话说，就是先把账算清楚。
CPMI 将 Settlement（结算）定义为按照基础合同条款履行义务。在这里讨论的银行卡支付中，可以简化为「按规则履行机构间的资金结算义务」。
这两句是业务解释，不是可套用到所有系统的法律或会计定义。同一个术语在不同网络、支付方式和产品里，边界可能不同。
机构间完成 Settlement，与资金记入商户的外部银行账户，是不同的观察节点。企业还要看平台如何记录 Pending、Available、Reserve、Payout 和 Bank Received，才能判断销售何时形成可以调度的现金。
四、商户余额到银行到账，还要看哪些状态
卡网络或金融基础设施中的 Clearing / Settlement，与支付服务商面向商户使用的 Settlement Timing、Balance 和 Payout，需要分别理解。以下讨论商户能在平台和自身系统中观察的资金项，名称与含义以实际产品为准。
Pending / Settling：有记录，尚未满足可用条件
Pending 或 Settling Balance 表示平台已记录相关资金，但尚未达到该产品的可用条件。后台看得到余额，不代表这部分金额已可提现。
可用时间要结合商户地区、支付方式、币种、账户历史、风险安排和产品规则判断。例如，Stripe 将支付余额分成 Pending 与 Available，并为余额交易记录对应的可用时间。
Available：可以用于平台允许的操作
Available Balance 中的资金，可以用于产品允许的出款、退款、转账或其他借记。Stripe 文档列出了这些用途，但其他平台的权限和限制需要另行确认。
资金即使已满足出款条件，也可能仍在平台或商户余额体系中。Available 并不表示企业的外部银行账户已经收到款项。
Reserve：按约定保留的受限资金
账户存在 Reserve 时，服务商可能保留部分资金，用来覆盖退款、争议、拒付等风险。以 Stripe 为例，Reserve Balance 内的资金在保留期结束前不能出款或转账。
因此，账户总余额、Available Balance 和当前可立即出款金额，可能是不同数字。要依据账户的记账结构和资金限制核对，不能默认用总余额计算可提现现金。
Payout 与 Bank Received：分别记录出款和实际入账
Payout 是平台向外部银行账户出款的记录。平台可能分别展示计划状态 scheduled，以及 pending、in transit、paid 等处理状态；例如 Stripe API 使用 in_transit，实际名称和定义以对应产品为准。
平台标记 Payout 完成后，银行仍可能需要处理、记账，才能让资金在企业账户中可见。平台的 paid 应按其定义理解，财务还要核对银行实际记录。Stripe 文档也提示，出款可能先显示 paid，之后又因失败改为 failed。
Available Balance ≠ Payout ≠ Bank Received
通过 Marketplace 平台收款的卖家，同样需要区分订单完成、平台可拨付余额、平台打款和银行入账，即使卖家不直接管理消费者的银行卡收单。
五、T+N 要写清五项口径
「我们是 T+3 结算」还不能回答银行什么时候到账。这个表达至少需要补齐五件事。
1. T 从哪个事件开始
T 可能指交易确认、Capture、批次处理或合同约定的其他事件。Stripe 将 T 定义为原始付款确认或 Capture 的交易时点，同时说明其他处理商可能从内部结算时点开始计算。
企业要核对实际服务商的起算定义。相同的「T+3」，如果起点不同，描述的等待区间就不同。
2. N 按自然日还是工作日计算
「3 天」还需要说明日历口径。周末、当地公共假期和跨时区批次截止，都可能影响实际日期；工作日与自然日也不能机械换算成同一个银行入账日。
3. T+N 的终点是什么
T+N 可能表示 Pending 变为 Available，也可能描述机构间或产品内部的结算时点。要确认这段时间结束时资金处于哪个状态，不能直接把终点认定为已经向银行出款。
4. Payout Schedule 是否另算
在 Stripe 这类定义下，Settlement Timing 描述资金何时变为可用，Payout Schedule 描述平台何时把可用资金发出去。可以把它们理解成两只时钟：一只等资金可用，另一只按出款计划运行。
资金进入 Available 后，仍可能等待下一次自动出款，或等待商户手动发起。
5. 出款后银行还要处理多久
平台发出款项后，银行、币种、支付或清算轨道、节假日及账户审核，还可能影响最终入账。Stripe 也明确说明，银行收到资金后，可能需要额外时间使其可用。
T+N 可能只覆盖这条时间线中的一段。把「T+3」写成完整的到账预期，需要说明：从哪个 T 起算，按什么日历，何时变为 Available，按什么计划 Payout，以及预计何时 Bank Received。
六、退款、争议和余额调整也影响现金预测
Available 表示当前满足平台定义的可用条件。此后发生的退款、争议、拒付，或账户层面的风险安排，仍可能影响余额和未来出款。
Reserve / Hold（资金保留或限制）需要按具体平台的余额结构理解。有的平台会将这部分资金排除在正常可出款余额之外；保留多久、如何释放，由实际账户安排决定，不能据一个账户推算行业平均水平。
退款、争议或拒付发生时，交易金额及相关费用可能被扣减或暂时占用。以 Stripe 为例，退款使用可用余额，争议会扣减争议金额及相关费用；余额不足时，可能影响后续出款或形成负余额。
现金预测需要同时考虑销售收入、退款、争议和拒付。当天销售增长，无法单独说明未来能出款多少。
七、GMV 增长，可用现金为什么未必同步增长
GMV（Gross Merchandise Value，商品交易总额）衡量交易规模，银行可调度现金还受资金回笼时间和余额调整影响。在广告、供应链等支出先发生的情况下，销售资金若仍等待可用、处于受限余额或出款处理中，扩大业务就需要为这段时间差准备现金。
回到开头的案例：一天 Paid Orders 或 Captured Sales 达到 10 万美元（$100,000），当天 Bank Received 未必增加相同金额。这是说明经营问题的假设，不代表任何平台、账户或行业的平均水平。
要找到差额，可以按下面的顺序建立一条「资金桥」，逐段核对销售与到账之间的金额和进度：
Captured Sales → 平台确认的净资金 → Pending / Available → 可出款金额 → Payout / In Transit → Bank Received
差额可能处于 Pending、已经 Available 但尚未出款、Reserve / Hold、Payout in transit，也可能对应 Refund / Dispute 等调整或跨日银行记账。
Fees、Refunds、Disputes、Reserve / Hold 和其他调整项，要按实际平台记账方式放进资金桥。净资金中已扣除的费用，不应再次扣减；受限资金也要分清是在余额内部单列，还是已经从可出款金额中排除，避免重复计算。
日度核对还需要跨日匹配。今天的 Bank Received 可以来自前几天的 Captured Sales，不能直接用两者相减来认定差错。企业可以借助 payout batch（出款批次）、transaction ID（交易标识）、settlement reference（结算参考号）或产品提供的其他标识，核对出款和对应交易。
这些标识的能力也有边界。例如，Stripe 自动出款可以查询组成该笔出款的交易；手动出款由商户选择时间和金额，Stripe 不会自动识别每笔出款对应哪些交易，需要商户自行核对。
不同业务要观察的环节有所不同：
独立站：Capture、余额可用、Reserve、Payout 和银行到账。
Marketplace：订单完成、平台结算、可拨付余额、平台打款和银行入账。
SaaS 与数字产品：订阅确认、资金可用，以及退款和争议对现金的影响。
经营团队可以先定位自己的 Money Flow（资金流）：哪一段等待最长，哪一段时间波动最大，哪一段占用现金最多。这样才能把优化目标落到具体环节。
更快的资金路径可能有不同成本、资格要求、风险安排或账户管理条件。选择时需要一起评估速度、成本、风险，以及业务自身的退款和拒付情况。
八、支付资金看板：字段、时间指标与五个问题
支付看板除了 GMV、订单数和 Payment Success，还需要能说明资金位置与可用程度的字段。可以先记录六项：
Captured Sales：已捕获的销售金额。
Pending：尚未满足可用条件的资金。
Available：满足平台可用条件的余额。
Reserve / Restricted Funds：被保留或受限制的资金。
Payout / In Transit：已发起或正在处理的出款。
Bank Received：银行账户实际入账金额。
再按业务情况补充四项：
Payment Successful / Authorization：付款成功提示与授权状态。
Refund：退款。
Dispute / Chargeback：争议与拒付。
Fees / Adjustments：费用及其他余额调整。
这些字段未必来自同一个后台，名称也未必一致。企业需要用交易号、结算批次或可追踪标识，把订单系统、支付平台、出款记录和银行流水对应起来。上面的看板是经营记录方式，不是要求所有服务商提供同名状态。
另外固定两个时间指标：
Payment-to-Available Days：从企业定义的付款成功或 Capture 节点，到资金成为 Available 的时间。
Available-to-Bank Days：从资金变为 Available，到企业银行账户实际收到资金的时间。
指标的起点、终点、日历口径和统计方式要结合实际支付产品固定下来。它们适合观察自身资金周期的变化、异常和趋势；定义不一致时，不能直接跨平台比较。
对主要支付方式和收款主体，再逐项确认五个问题：
Payment Successful 对应什么状态？ 是 Authorized、Captured、异步确认完成，还是业务系统自定义的 Paid？
机构间何时进入 Clearing / Settlement，平台怎样定义 Settlement Timing？ 分别记录机构间术语和商户余额术语，避免混用。
资金什么时候从 Pending 变为 Available？ 写清起点、自然日或工作日，以及节假日和币种的影响。
账户是否存在 Reserve 或其他资金限制？ 记录形式、适用交易、释放条件与复核机制。
Available 后何时 Payout，银行何时实际收到？ 确认自动或手动出款、频率，以及银行是否还有额外处理时间。
缺少这些定义，就无法确认后台显示的「到账周期」覆盖了完整过程，还是其中某一段。
九、先为一个支付方式画出真实时间线
跨境企业可以从交易完成、资金可用、平台出款到银行入账，记录完整的营运资金时间线。沿途包括捕获、清算结算、风险保留等处理或限制，具体进度按对应系统确认，再比较哪一段最长、波动最大、占用现金最多。
先选交易量最大的一个支付方式，从 Payment 追踪到 Bank Received。为每个节点写清当前状态、所属系统、责任方、起算点、正常处理时间、异常情况，以及下一步由谁处理。这样，团队才能具体回答一笔钱现在在哪里、由谁继续处理，以及预计什么时候可用。