先确认客户到底拥有哪一种余额
来源事实：Stripe 区分客户现金余额与客户发票余额。现金余额代表可用于付款的资金；发票余额表示商户与客户之间的债权债务关系，可以抵扣未来发票，却不能作为付款资金使用。[1] 编辑建议：客服排查应先确认余额类型、客户标识和币种，而不是只看界面上的一个总数。如果页面仅写“余额”，运营人员就难以判断是银行资金已经到账，还是账单被做了调整。本文解决的是余额分类问题，不重复一般订单对账流程，也不讨论稳定币充值。引用规则仅属于 Stripe，不代表 PayIn 已实现同样功能，也不是所有支付服务都遵循的统一产品定义。阅读与核验日期为 2026-09-20，不能据此推断规则在这一天发布。
把现金余额追溯到银行转账
来源事实：客户多付，或银行转账未自动匹配任何待付款项时，Stripe 会把相关资金加入客户现金余额。资金可以用于同一客户后续付款，也可以退回该客户银行账户，但不能超过可用余额。[1] 编辑建议：在显示可用现金时，一并说明它对应哪位客户以及资金来源。例如客户询问为何付完发票后仍有结余，应先查看现金记录，而不是为了让界面数字变化再增加一笔发票抵扣。这里是假设性的客服场景，并非采访或真实事故记录。两类余额都可能影响运营人员对“客户还欠多少”的理解，但并不因此可以互换。操作之前先分清记录性质，有助于避免把一笔银行资金重复解释为另一笔账单优惠。
不要把发票调整当成增加现金
来源事实：客户发票余额属于 Invoices 功能，Stripe 明确说明不能用它支付；商户可以通过调整型 Customer Balance Transaction 更新发票余额。[1] 编辑建议：后台按钮应写清“调整发票余额”，不要笼统写成“加钱”，并给这类操作单独的确认提示。纠正计费错误的员工，应当能解释这次调整如何影响未来发票，而不是声称客户又汇入了一笔资金。建议在内部记录调整原因及操作责任人，便于后续交接。这里提出的是编辑整理的审查方式，并不表示原文要求所有商户采用同一审批层级、会计处理或保存年限；涉及企业账务制度的部分仍需按自身适用规则确定。
不要把对账用途包装成钱包
来源事实：Stripe 明确说，现金余额不是数字钱包或电子货币，也不是供客户充值的钱包余额；商户不能直接向其中添加资金。它只是对账层，只能用于关联客户的未来付款或向该客户退还资金。[1] 编辑建议：对外展示余额之前先检查产品文案。“可用银行转账资金”通常比泛称“钱包”更能说明这里讨论的对象。不能仅凭这份文档承诺用户之间转账、任意提现或通用储值功能，更不能把发票调整入口伪装成充值入口。这一节解释的是 Stripe 文档中的产品使用边界，不是在判断其他服务是否需要金融牌照，也不提供适用于所有地区的法律结论。功能定位与合规结论应分开核实。
保留不同币种之间的边界
来源事实：客户可在商户接受银行转账的各币种中拥有现金余额，每个币种有自己的入金指引；查询现金余额变化时，返回记录会包含该客户不同币种的变化。[1] 编辑建议：页面应分币种列示，导出数据、客服工单与操作确认也应保留币种。一个接口返回混合币种记录，不等于这些余额可以任意互换，也不表示可以直接相加成一个可花费总额。处理客户请求前，应同时识别相关现金记录与目标付款的币种。本文引用页面没有证明任何商户地区都支持所有币种；具体可用性仍应按对应银行转账产品检查，不能从某个示例字段推断全球支持范围。
发起付款前检查真正可用的现金
来源事实：Stripe 要求创建相应 intent 前先启用银行转账；文档中的现金余额付款使用 customer_balance 类型的 PaymentIntent，现金足够时付款成功，不足时失败。[1] 编辑建议：不要把“发票抵扣额不为零”作为可以执行这类现金付款的前提。运营检查中应把“有可用现金”和“有发票调整”拆成不同判断。如果现金不足，应按适用的银行转账补款流程处理，而不是修改发票余额来制造看似充足的资金。本文没有提供可直接运行的 API 集成代码，也没有进行真实扣款；上述步骤是帮助设计内部操作边界的概念性说明，不是某个账户已经通过支付测试的证明。
理解交易类型后再关闭工单
来源事实：funded 现金余额交易表示客户通过银行转账汇入资金；如果资金被自动用于付款，还会出现 applied_to_payment 交易。Stripe 也列出 unapplied_from_payment：部分获得资金的 PaymentIntent 被修改或取消后，资金返回客户现金余额。[1] 编辑建议：向客户解释实际观察到的事件顺序，而不是把每次余额增加都翻译成“新付款到账”。交接记录应写清哪种余额发生变化、变化原因，以及客户要求的下一步是否仍未完成。上线前可以自行准备只有现金、只有发票抵扣和混合币种三类验收案例，验证页面与按钮不会误导操作人员。这些只是建议执行的验收情境，并不是本文已经对 Stripe 或 PayIn 执行了相关测试。
来源与日期
本次核验日期：2026-09-20。来源日期按原页面明确标注的发布或更新时间分别列示；未标注不等于本日发布。本文为公开文档研究，未进行真实支付、安全审计或辅助技术合规认证。厂商事实仅归属于被引用厂商；流程建议为编辑综合。