先识别原支付采用哪种收款架构
Stripe 的目标账户收款在平台账户创建交易，再将资金转入关联账户；Stripe 费用、退款与拒付会扣减平台余额。[3] 编辑建议：批准市场平台的退款前，先确认原支付确实采用了这种架构。不要只记录订单号，还应记录收款交易、关联账户、转账及可能存在的平台应用费。本文不介绍直接收款，也不要求把相同退款参数用于分别创建的收款与转账。它讨论的是卖家收到转账之后，退款成本由谁承担，而不是客户依据退款政策是否有资格退款。来源是 Stripe 网页托管支付流程中的目标账户收款指南，不代表 PayIn 经营市场平台或已经集成 Connect。
默认情况下，转出去的资金仍由卖家保留
Stripe 说明，对带有 transfer_data[destination] 的收款退款时，目标账户默认保留已经转入的资金，由平台承担退款产生的负余额。在创建退款时设置 reverse_transfer=true，可以从关联账户收回资金以覆盖退款。[3] 编辑建议：批准记录应同时说明客户退款金额和预定承担资金的一方。退款请求成功，并不足以证明成本已由卖家承担。如果平台主动承担善意补偿，保留卖家转账可能是有意选择；如果卖家应退回其份额，就必须明确作出转账决定。不要将其中某一种选择描述成普遍正确。应依据卖家协议和账户可用能力执行，并将批准依据与实际返回的对象一起保留。
全额与部分冲回应分别检查
Stripe 默认退还整笔收款，也可通过正整数 amount 请求部分退款。在文档所述的转账冲回流程中，整笔收款全部退款时会冲回整个转账，否则按比例冲回转账金额。[3] 编辑建议：检查实际生成的冲回记录，而不是假设它等于口头计算的卖家份额。例如，设想客户只退回订单的一部分，而卖家协议约定的成本分摊与平台默认分账比例不同。这个示例不宣称任何具体数字。应先判断文档描述的比例处理是否符合已约定的分摊；如果不符合，就停止并审查设计，而不是叠加没有记录的手动资金移动。所有部分退款都应关联同一笔原支付，使审核人员能够分别解释累计客户退款和累计卖家资金回收。
平台应用费必须另作决定
对于带有应用费的收款，平台默认保留该费用。设置 refund_application_fee=true 会把应用费资金退还关联账户。[3] 对于目标账户收款，退还应用费还必须同时冲回转账；整笔收款全部退款时，应用费也全额退还，部分退款则按比例退还应用费。[3] 编辑建议：应用费处理应与客户退款金额分别批准，但必须遵守两个参数之间的文档依赖关系。不要把两个布尔参数的四种组合都展示成同样有效的目标账户收款操作。来源也允许将 refund_application_fee 保持为 false，再通过接口单独退还应用费。[3] 如果采用独立流程，应将其标识保存在同一事项中，避免另一位操作人员重复退费。应用费不等于 Stripe 支付处理费，本文不承诺处理费会被退还。
退款失败后可能还需要资金分配决策
Stripe 说明，如果退款失败或被取消，失败退款金额会回到平台的 Stripe 余额；必要时，可创建转账把资金移到关联账户。[3] 编辑建议：在事项关闭之前，把客户退款状态和卖家资金回收状态分别记录。不要自动认定退款失败就会恢复卖家此前的余额状态。批准新转账前，应查清是否已经发生转账冲回、应用费是否已经退还，以及是否确实需要另一笔资金移动。不要仅因客户仍在等钱，就机械重复同一动作；重新尝试客户退款和内部资金重新分配回答的是不同问题。该来源说明资金退回的方向，但没有保证每个地区、每种账户配置下的后续转账都具备资格。
分别准备客户与卖家的说明
编辑建议：客服应解释客户退款当前处于什么状态，但不必暴露不必要的卖家账户资料；卖家运营则应依据相关协议，单独解释获准执行的资金回收与应用费处理。同一事项标识可以关联两组记录，但发给客户的通知并不能证明卖家转账已经冲回。如果请求的资金分摊与原批准不一致，应安排第二次审核。若操作人员有意让卖家保留资金，应明确记录由平台承担，而不是把未发生的冲回描述成技术故障。对意图的清楚说明，有助于后来核对余额，也避免把退款与转账金额之间的每一处差异都当成错误。无法确认原批准范围时，应保留待审核状态，不要自行补出一笔资金移动来让账面看起来整齐。
以可解释的资金记录关闭事项
编辑建议：审核资料应包括原收款架构、客户退款金额与状态、请求的冲回参数、实际冲回标识、应用费退还决定，以及任何后续转账。演练同时使用两个文档参数的全额退款、带资金回收的部分退款、平台承担成本的退款，以及退款失败后的复核。每种情形都应核实谁保留了资金、谁承担了成本，而不是把控制台一个绿色状态当成完整结果。这些是拟议验收场景，不是真实执行记录。本文及来源核验日期为 2026-09-21；来源未注明发布或更新时间。本文不认证法律合规、结算资格，也不判断企业是否有权依据合同追回资金。账户支持地区和转账限制需要另行审查；不要把这种厂商特定流程扩展成通用跨境支付规则。
来源与日期
本次核验日期：2026-09-21。来源日期按原页面明确标注的发布或更新时间分别列示；未标注不等于本日发布。本文为公开文档研究，未进行真实支付、安全审计或辅助技术合规认证。厂商事实仅归属于被引用厂商；流程建议为编辑综合。