客户在手机银行点"申购 1 万元基金"，一秒后页面显示"申购受理"。这一秒背后是一笔跨行资金的划出：从客户的借记卡账户，到基金销售机构的归集户，再到产品募集账户。这篇讲这条资金链路的通道结构、限额控制和日终对账——基金销售系统的地基工程，平时没人看见，出问题全天停售。
两条扣款通道
基金申购款从客户卡到募集户，主流两条通道：
银行代扣（协议支付/受托支付）：客户首次购买时签代扣协议，授权销售机构（或基金公司直销）从其银行账户扣款。走的是人民银行大小额支付系统或银联代扣通道。特点是协议一次签、扣款免验——后端批量扣款场景（比如定投扣款）走这条最合适，客户无感。
快捷支付：客户绑卡时做一次要素鉴权（卡号、姓名、证件号、预留手机号 + 短信验证码），之后每次支付只需短信码或支付密码。走的是银联或网联的快捷通道。特点是交互式、实时性强，单笔实时申购走这条。
两条通道的取舍很实际：代扣通道费低（批量扣款按笔计费，几分钱），但签约流程重、首次体验差；快捷支付体验好，但通道费高（千分之几）且限额严。所以直销平台的标准组合是：首笔快捷支付绑卡 + 签约代扣协议，后续定投走代扣。系统上要维护"客户-卡-协议"三元组的支付档案，协议状态（有效/解约/过期）是扣款前置校验的一部分。
限额管理：通道侧的最后一道闸
快捷支付和代扣都有限额，三层叠加：
- 通道限额：银联/网联对单笔、单日的统一上限（快捷支付常见单笔 5 万、单日 5 万的档位）；
- 银行限额：发卡行对快捷支付的自定义限额，各行差异巨大，同一家银行不同卡种（一类户/二类户）限额也不同。二类户是重灾区：监管规定二类户单日支付限额 1 万，大额申购直接卡在银行侧；
- 销售机构限额：基金公司或代销渠道自己的风控限额（单笔上限、当日累计上限），防的是异常大额申购和反洗钱监测要求。
系统实现上，限额是网关层的拦截器：下单请求进来，按"客户 × 卡 × 通道"查当日累计，超限直接拒单并给出可读的错误文案。难的不是拦截，是限额数字的维护——银行限额经常调，靠运营手工维护表会过期，成熟做法是接银联/网联的限额查询接口动态取，取不到就按保守值挡。定投场景要专门处理：定投扣款走代扣通道，单笔限额和快捷支付不同档，不能用同一套限额表。
扣款时序与申购受理的关系
一个容易踩的业务坑：扣款成功和申购受理的先后。两种模式：
- 先扣款后受理（直销常见）：扣款成功才生成申购申请流水。优点是账务干净——没有"受理了但钱没到"的在途单；缺点是扣款通道抖动时客户体验差（钱扣了页面卡死）；
- 先受理后扣款（部分代销）：先生成申请流水（资金状态"待扣款"），日终批量扣款，扣款失败的申请整笔拒绝。优点是受理快；缺点是批量里要处理大量"扣款失败拒绝"，确认文件的拒绝码里专门有一类支付失败。
先扣款模式要处理的核心异常是扣款成功但确认失败：钱在归集户、申请没生效，要自动退款路径；先受理模式要处理重复扣款防护：同一申请流水号在批量重跑时不能扣两次（幂等键 = 申请流水号 + 扣款日期）。我在对接一个代销渠道时踩过后者：渠道批量文件重发，我们侧没去重，同一批客户扣了双份款，当天退款流水做到半夜。
日终三方对账
支付通道的日终是基金销售最硬的对账场景，三方各自记账：
- 销售机构（或直销平台）：记申请流水（该扣多少）；
- 支付通道（银联/网联/银行）：给扣款回执文件（实际扣了多少、成功失败明细）；
- 银行清算户：归集户的实际资金变动（到账多少）。
三方逐笔对：申请流水 ∩ 扣款回执 ∩ 银行入账。差异分类处理：
- 有申请无扣款：先受理模式下的扣款失败，确认文件里出拒绝；
- 有扣款无申请：通道侧异常扣款（极少，一般是渠道重发或伪造报文），直接退款并报警；
- 金额不符：部分扣款、通道费口径差异（有些通道费内扣、有些外扣），按协议口径调整；
- 状态不符：扣款回执"成功"但银行未入账（在途资金），挂账等 T+1 银行对账文件到达再追平。
挂账是《对账体系》篇的模式在支付侧的原样复用：差异不冲正、先挂"待查"，限期追平，追不平的按差错处理流程走人工。日终对账跑完之前，当天的销售数据不封账——这和 TA 确认批量的依赖关系是：确认链可以开始跑（份额确认只依赖申请数据），但资金对账必须在下一场划款批次前清干净，否则募集户的资金余额不可信，划往托管户的净申购款就划不准。
支付通道这条链路上没有复杂的数学，它的难度全在工程纪律：限额表的新鲜度、扣款幂等、对账差异的分类处理，每一件都是"不出事时 invisible、出事时全天停售"的部件。基金销售的可用性 SLA，最终是支付通道对账跑完的时间点决定的。