支付更快，背后先要有人垫钱
支付行业里一直存在一个很容易被忽略的时间差。商户的资金可能要到 T+1 才真正结算，但收款人今天就要求到账；Marketplace 刚完成消费者收款，卖家已经发起提现；一家跨境支付公司刚在美国收进 USD，墨西哥的受益人却希望几秒钟后就收到 MXN。
站在用户视角，这些都很简单，页面上只显示一件事：Payment completed。
但从资金管理和资产负债表角度看，问题完全不同：钱还没到，为什么已经可以付出去？中间这几个小时，甚至这一天的钱，究竟是谁先出了？
文章作者 Steven 给出的直接答案是，最常见的做法当然是支付公司自己先出。如果对应资金要到第二天才真正到账，而 PSP 今天先用企业自有现金完成付款，这首先是一种 Self-funded Prefunding，也就是由 PSP 用自己的资产负债表吸收这段时间差。
不过，文中强调，这里面有两个经常被混在一起的问题。
第一，PSP 先用自己的钱完成支付，并不自动等于它已经在法律或产品意义上向客户发放了一笔贷款。从 Treasury 的视角，这更先体现为资产负债表占用和资金暴露。
第二，PSP 每天经手大量资金，并不代表这些钱都可以被拿来垫付。客户资金、企业现金和授信能力，本来就是三套不同的东西。支付业务做大以后，Credit 会从一个金融产品逐渐变成支付基础设施的一部分，本质上就是因为这三套数字会越来越不匹配。
经手的交易规模，不等于可以动用的垫资能力
文中以连连数字为例说明这一点。根据作者引用的数据，连连数字 2025 年全年 Global Payment TPV 达到人民币 4,524 亿元，同比增长 60.7%。
但继续看其资产负债表，截至 2025 年末，公司 Cash and Cash Equivalents 约为 16.28 亿元，Total Equity 约为 30.72 亿元，与此同时，Customer Segregated Funds 约为 194.66 亿元。
这些数字放在一起，作者认为最直观的结论是：客户资金和企业流动性不是一回事。
一家支付公司每年可以处理几千亿、几万亿资金，但它既不需要，也不可能拥有与全年 TPV 等量的自有资产负债表，这本来就是支付业务能够扩张的基础。可一旦付款义务与资金实际到账时间发生错位，真正能被拿出来提前付款的，并不是平台经手的全部资金，而是自己的企业流动性，以及预先安排好的外部融资能力。
连连同期还披露了约 14.07 亿元未使用银行授信额度。文章也指出，这并不意味着这些授信一定被用于支付垫资，但它说明了另一层资金能力：支付公司真正可以调用的资金，并不只等于账上的现金。
作者把支付行业里最容易混淆的三组数字拆开成了三层：
- Customer Funds 决定你管理了多少钱；
- Own free Cash 决定你自己能垫多少钱；
- Credit Capacity 决定当自有现金不够时，你还能继续承诺多少钱。
钱没到先付款，本质是 Funding Gap
文章举了一个例子：假设一家 Marketplace 在今天上午 10 点要向卖家支付 1 亿元，但对应的消费者资金要到下午，甚至第二天才真正可用。这种延迟可能来自收单结算周期、业务架构 C2B2B2C/B 的安排，也可能来自银行审核效率。
从产品页面看，这只是一次 Payout。但从上午 10 点开始，平台已经形成了 1 亿元 Payment Obligation，而与之对应的现金还没有进入可以自由使用的状态。
这中间出现的，就是 Funding Gap。
如果 Marketplace 选择等待，这段时间就由卖家承担，什么时候资金真正可用，什么时候再付款。可一旦产品承诺 T+0、Same-day 甚至 Instant Payout，平台其实是把原本由卖家承担的等待时间接了过来。问题并没有消失，只是换了一个承担者。
最简单的方案当然还是平台自己先付。只要企业现金足够，今天先完成付款，等明天资金到账后再恢复现金头寸。这首先是一个资产负债表决策：平台选择用自己的资本，换更好的支付体验。
规模小的时候，Credit 的存在感并不强。Treasury 多留一些 Buffer，可能就能解决。但如果每天的 Payment Volume 从 10m 变成 100m，再变成 1bn，同样一天的时间错位会迅速放大所占用的资金。
而且，即使 PSP 有钱，也不代表长期这样做就是更好的资本配置。为了应对一年可能只出现几次的峰值交易量，永久在账户里多放几亿元现金，本身就意味着很高的机会成本。
于是问题很快会变成：当自有可用现金不够，或者继续使用自有现金已经不划算时，该怎么办？
文中给出的两条路径，一条是把支付体验往回收，延迟付款、提高预付金要求、降低交易限额，极端情况下甚至暂停部分支付。另一条则是去找另一张资产负债表，也就是调用 Bank Credit Line、Overdraft、Intraday Facility、Settlement Financing、Private Credit 等外部能力。
作者据此提出，Payment 与 Credit 的第一次相遇，并不是 PSP 上线了一个贷款产品，而是支付开始跨越时间。
流动性管理和授信，不是一回事
文章接着区分了 Liquidity 和 Credit。
如果墨西哥今天需要 20m MXN，但当地账户里只有 5m，而集团香港账户里有足够的 USD，且现在可以完成外汇兑换，再把对应的 MXN 头寸调到墨西哥，这首先是流动性管理。企业资产负债表并没有因此变大，资金只是从一个币种、地点和头寸，转移到了另一个头寸。
作者认为，Liquidity 解决的是已有资源怎么调度。
但如果集团所有当前可调用的自有流动性加总后只能提供 80m，而今天已经形成了 100m 的 Payment Obligation，剩下的 20m 就不是简单把钱从 A 搬到 B 能解决的了。这个时候真正的问题是，缺口由谁补上。
公司当然可以永久多准备 20m 现金，这仍然是 Self-funded。但如果不想为了所有潜在峰值需求长期占用自己的资本，就需要银行、授信提供方或其他资金提供者提供额外的资金能力。
作者因此把三者关系写得更明确：
- Liquidity 解决现有资源怎么用；
- Funding 解决缺口从哪里补；
- Credit 是获得额外 Funding Capacity 的重要方式之一。
文中强调，这个区分很关键，因为 Self-funded Prefunding 本身并不等于 Borrowing，也不意味着 PSP 向客户提供了一个 Credit Product。
但随着支付规模扩大，如果始终依赖自有可用现金覆盖所有峰值需求，资本效率一定会越来越差。到了这个阶段，Credit 真正提供的，不只是再借来一笔钱，而是一种 Elasticity。Liquidity 决定已有资金怎么用，Credit 决定当已有资金不够时，Capacity 能否临时变大。
即时支付体验，很多时候由资产负债表在后台承担
作者回顾，过去十几年支付行业一直在把资金速度做得更快，从 T+3、T+2、T+1、Same-day、T+0，到越来越多的 Instant。站在用户体验角度，这是一条明确的演进路径。
但文中提出一个很反直觉的问题：收款人收到钱的速度变快，并不代表上游资金到账速度也同步变快。
过去商户在 T+1 收款，PSP 也在 T+1 收到对应结算，两边时间大致匹配。现在为了竞争，平台把商户打款提前到 T+0，但如果底层结算仍是 T+1，原本不存在的一天资金缺口就会出现。
所以，行业表面上是在不断消灭结算时间，实际上很多时候只是把这段时间从客户体验里拿掉，再转移到金融机构的资产负债表上。作者的原话是：Instant Payment 的用户体验，很多时候是 Balance Sheet 在后台买单。
Payment 越实时，Timing Risk 并不会凭空消失，它只是被重新分配：卖家不等了，平台等；商户不等了，收单方等；客户不愿意预付金，PSP 就必须决定，是自己承担，还是找别人承担。
文章称，这套逻辑现在已经被做成产品。文中以 YouLend 的 Instant Settlement / Instant Payout 为例，称其本质是在 Sale 已经发生、正常 Settlement 还没有完全完成的时候，让 Merchant 更早拿到与应收款对应的资金。换句话说，Sale happened，Cash hasn't fully followed，但 Merchant gets paid anyway，中间原本需要等待的那段时间被 Financing 吃掉了。
Stablecoin 也不会自动让这个问题消失。文中指出，区块链可以 24/7 转账，但 Fiat Banking、FX、Redemption、Local Clearing 和传统 Funding Market 不一定同步 24/7，因此 24/7 Settlement 并不等于 Zero Funding Requirement。
作者还给出一个反向思考：过去周六一笔钱走不了，用户默认等周一；未来如果支付轨道在周六凌晨也能实现 Instant Settlement，那么新的问题会立刻出现——周六凌晨那笔流动性和融资能力从哪里来？支付轨道越实时，后台团队越不能只靠一句「等钱到账」。
支付规模越大，拼的是授信弹性
作者用一个简单例子解释规模问题。每天 1m 的交易量，其中 10% 存在几个小时的时间错位，只需要临时覆盖 100k；如果每天交易量变成 1bn，同样 10% 的时间错位，就变成 100m。
但真实的支付网络从来不会每天沿着一条平滑曲线运行。发薪日、大促、Bank Holiday、Weekend、FX Volatility、Settlement Delay、Banking Disruption，都可能让某个市场在几个小时内突然形成远高于常态的 Payment Obligation。
因此，大型 PSP 不可能只是按照历史最高峰值，在几十个市场里永久堆满现金。理论上这当然安全，但在经济上代价极高。
文中认为，成熟的支付网络，最终都会形成一套分层资金能力。正常流量由 Natural Flow、Netting 和 Own Liquidity 消化；普通波动由 Treasury Buffer 承担；更大的缺口才开始调用 Bank Credit Line、Overdraft、Intraday Facility，甚至 Settlement Financing 或其他 External Funding。
所以，支付网络做大以后，需要的不只是一个固定的 Liquidity Pool，而是一种 Credit Elasticity。Liquidity Capacity 回答的是，正常情况下今天能付多少；Credit Elasticity 回答的是，今天突然不正常，还能多付多少。
作者因此提到 Huma/Arf 和 MANSA 这类玩家值得关注。文中认为，它们试图改变的不是 Payment Rail，而是支付网络背后的 Capital Deployment Model。
过去更常见的是 Pre-positioned Capital，也就是 Treasury 先借钱、先调钱、先在各个市场准备好头寸，再等待支付系统去消耗这些资金。而 Huma/Arf、MANSA 所代表的方向，更接近于：
- Payment 发生；
- Liquidity / Credit 被调用；
- Settlement 完成；
- Capital 回收。
作者把这套方式概括为 On-demand Financial Capacity。
文中写道，Huma 和 Arf 合并以后，核心场景之一就是 Cross-border Payment Financing，通过 on-demand liquidity 降低部分 Payment Institution 对静态预先注资的依赖；MANSA 则直接围绕 PSP、EMI、Remittance 等机构提供 Settlement-time Liquidity。
作者认为，更值得关注的不是这些公司是否用了 Stablecoin，而是 Credit Capacity 正在从静态存在，走向动态调用。如果这一模型继续扩大规模，改变的不只是 Funding Cost，也会影响整个 Treasury Architecture。支付公司不再需要为了所有可能出现的需求，在所有走廊里永久准备同等规模的现金。Own free Cash 提供基础 Capacity，Credit 提供 Elasticity。
掌握支付流的平台，为什么会自然走向信用业务
前文讨论的是 Credit for Payment，也就是信用如何支撑支付流。文章随后转向另一个方向：Credit from Payment。
作者借此解释，为什么 Stripe、Adyen、PayPal、Block 这类掌握 Payment Flow 的平台，最后很容易延伸出 Merchant Financing 和 Working Capital 业务。
原因在文中被概括得很直接。传统放贷机构做 Underwriting，需要理解一家公司的收入、现金流、季节性、增长、客户集中度以及未来偿付能力。支付公司每天就在看到这些信息：TPV、交易频率、平均客单价、退款、拒付、销售趋势、季节性；如果再结合账户和结算关系，还可能看到现金流入、现金流出、账户余额、供应商付款和营运资金周期。
这些并不是企业一年提交一次的财务报表，而是持续发生的实时经营活动。因此，Payment Data 会自然变成 Underwriting Data。
不过，作者认为支付公司在信用上的特殊之处，不只是数据更多，更重要的是很多时候它还控制现金流。
文章举例称，假设一家商户每天通过平台产生 100k Sales，平台为其提供 1m Working Capital。此时还款不一定需要商户每个月主动电汇。它完全可以直接发生在未来的 Settlement → Deduction → Repayment 流程里。
Stripe Capital 被文中视为一个典型结构。作者写道，Stripe 会结合 Processing Volume 和 Payment History 等因素形成 Financing Offer，而还款可以直接按比例从未来 Stripe Sales 中完成；与此同时，Stripe 的商户关系、支付流和最终提供资产负债表的主体，也不一定是同一家公司。
这一模式在作者看来很有代表性，因为它说明，拥有 Credit Product，并不等于必须拥有最终资产负债表。支付平台可以负责 Flow、Data、Distribution；银行或其他资金提供方则负责 Funding 和 Risk Capital。
这也是支付公司与传统贷款机构的一项结构性差异：支付公司不仅能看见现金流，很多时候还控制现金流。Flow 一边解决 Underwriting，另一边又直接成为 Repayment Rail，于是 Underwriting、Disbursement 和 Repayment 都开始 Embedded in Flow。
从这个角度看，支付公司进入信用业务，并不只是产品扩张，而是来自一套很强的基础设施逻辑：Flow 本身既是 Data，也是 Repayment Rail。
信用做到最后，仍然绕不开资产负债表
既然支付平台已经有 Flow、Data 和 Customer Relationship，为什么不把信用全部自己做掉？作者的答案是，Data 和 Balance Sheet 是两种完全不同的能力。
文中认为，支付平台更擅长的是 Flow、Data、Distribution、Customer Relationship 和 Repayment Control；银行和机构资金更擅长的则是 Funding、Credit Capacity、Risk Capital 和 Balance Sheet。双方拥有的资源并不一样。
所以，未来 Payment 与 Credit 的结合，未必表现为越来越多 PSP 自己变成银行，反而更可能是整个 Credit Stack 被拆得更清楚：
- Payment Platform：Flow + Distribution
- Credit Infrastructure：Underwriting + Orchestration
- Bank / Private Capital：Balance Sheet
作者提到，Stripe Capital 已经可以看到这种结构：信用产品可以嵌入支付体验，但最终的融资提供方不一定就是支付平台自己。Huma/Arf 和 MANSA，则是在尝试把类似的解耦进一步带进支付结算本身。
过去，银行授信额度和支付系统经常是两套相对独立的基础设施。未来，Credit Capacity 本身可能会越来越直接接入 Payment Flow，在 Settlement 真正发生时被动态调用。
因此，作者认为，未来更值得问的问题不是「哪家 PSP 开始放贷款了」，而是：谁控制 Flow？谁决定 Credit？谁最终提供 Balance Sheet？这三件事，越来越不需要发生在同一家公司里。
支付公司手里有 Flow，银行和资本市场手里有 Balance Sheet，而 Credit 就是把 Flow 和 Balance Sheet 连接起来的那一层。
文章结尾：信用不是支付的旁支，而是时间的价格
回到文章最初的问题：钱还没有到，为什么已经可以付？
规模小的时候，答案可能很简单，PSP 自己先垫，这首先是 Self-funded Prefunding。规模再大一点，可以通过 Treasury 在全球资产负债表内部调度头寸。但当 Payment Obligation 越来越实时、Volume 越来越大，而 Own free Cash 又不可能无限扩张时，就必须开始寻找 External Funding。
作者把 Payment、Liquidity、Funding 和 Credit 的关系逐层拆开：
- Payment 解决的是 Money Movement；
- Liquidity 解决的是已有资金如何在正确时间出现在正确位置；
- Funding 解决的是现有头寸不够时，缺口从哪里补；
- Credit 进一步解决的是，如何基于未来偿付能力，把额外 Financial Capacity 提前带到今天。
文中称，这种偿付能力可以来自未来现金流、应收账款、抵押物，也可以来自机构本身的信用状况。对应地，Liquidity 管的是 Position，Credit 提供的是 Elasticity。再往下一层，真正决定整个网络能做多大的，仍然是 Balance Sheet。
作者据此认为，支付行业最终会越来越靠近 Credit，并不是因为所有 PSP 最后都想成为 Lender，而是因为支付越实时、交易量越大、结算链条越复杂，就越需要有人回答一个很现实的问题：今天的钱还没到，但 Payment 不能停，怎么办？
如果自己的资产负债表足够，就自己承担；如果不够，就必须调用别人的资产负债表。
文章也补充说明，所谓「Credit 是 Time 的价格」，并不是说信用只对时间收费。真正被定价的，是这段时间错位背后的 Credit Risk、Liquidity Cost、Capital Consumption，以及资金提供方愿意承担这段不确定性的价格。
因此，Credit 从来都不只是一个 Loan Product。按照作者的表述，它更像是支付网络在面对时间、峰值交易量和结算错位时，可以动态扩张的一层 Financial Capacity。
文章最后再次总结了三组核心关系：
- Customer Funds 决定你管理了多少钱；
- Own free Cash 决定你自己能垫多少钱；
- Credit Capacity 决定当自有现金不够后，你还能继续承诺多少钱。
而支付行业最底层的一条事实一直没变：Payment Volume 可以远大于 PSP 自己的资产负债表，但当 Cash Arrival 和 Payment Obligation 不同步时，这段缺口最终必须由某一张资产负债表来承担。
Payment 负责移动资金，Liquidity 负责调度资金，Credit 则让未来的 Financial Capacity 能够提前支撑今天的支付。最终，一张资产负债表决定的不是你历史上处理过多少交易，而是在钱还没有真正到的时候，你到底还敢承诺多少。