支付业务角色与概念：Payment Gateway、PSP 与资金生命周期

AI 参与说明（Agent：Codex）：本文依据 BIS、Stripe、Adyen、PayPal 与 Polar 的公开资料整理，核验日期为 2026-09-16。运行记录：模型 gpt-6-astra，reasoning effort medium，提供方 openai，执行入口 Codex Desktop，CLI 版本 0.154.0-alpha.6.2（不代表桌面 App 版本）。关系图为教学简化；未执行真实支付交易。文中代码仅用于本地概念验证，不调用支付 API。

理解支付业务，先把三个问题分开：谁在交易、谁提供支付服务、钱走到了哪一步。 Payment Gateway 是一种技术能力，Stripe 是提供多项能力的服务商，PayPal 既可提供商家收款服务，也可作为买家选择的钱包。它们不属于同一层级，不能按产品名称一一对应角色。

本文以常见的线上银行卡支付为主线。钱包、银行转账和本地支付方式可能采用不同网络与流程；这里的角色名称是工程导读，不是某个司法辖区的牌照分类。服务商实际承担哪些职责，需要结合所选产品、地区与合同判断。

先认识参与者与服务

这些角色可以由不同公司承担，也可以由同一家公司整合。表中的 Payment Processor 侧重商家收款链路；发卡侧也存在专门的处理服务。不能从“用了某个 Payment Processor”推导出“它就是给客户发卡的银行”。Stripe：Payment Processor 与 Acquirer、Stripe：Acquirer 与 Issuer

1. Payment Gateway 到底在做什么

A payment gateway transmits payment information; it is not the merchant’s bank account.

客户在结账页面输入银行卡信息或选择钱包后，需要有人安全地接收这些信息、将请求交给后续支付系统，再把批准、拒绝或需要进一步操作的结果返回。Payment Gateway 主要处在这个连接位置；它可能还提供风控、支付方式展示和交易管理功能。Stripe：Payment gateways

可以把它理解为支付系统的“接入窗口”，但不要把窗口当成整条业务链：

• 结账页面是客户看到的界面；页面背后才是 Payment Gateway 等服务。
• Payment Gateway接收和路由支付信息，不等于它自己决定银行是否批准。
• Payment Processor处理交易消息与后续支付操作，不只是展示表单。
• Acquirer承担商家受理与结算关系，不只是一个转发接口。

这些功能有重叠，商业产品的边界也未必完全一致。购买独立 Payment Gateway 服务时，可能还要配置 Payment Processor 或 Acquirer；使用整合型 PSP 时，这些连接通常已被包装进同一服务。把服务商简称为“网关”很常见，但讨论选型与责任时，应问清实际包含什么。Adyen：Payment service provider

2. 一笔银行卡付款经过哪些角色

假设客户用某银行发行的 Visa 卡，在一个网站购买商品：网站经营者是 Merchant，发卡银行是 Issuer，Visa 是 Card Network，商家侧另有 Acquirer 与相关处理服务。

下面只表示典型授权请求的信息传递方向，不是逐站转账路线。结果通常沿相应链路返回；风控也可能在到达 Issuer 前拒绝请求。具体系统可能合并节点或采用不同连接方式。

flowchart TB
    C["Cardholder"] -->|"在结账界面发起付款"| M["Merchant"]
    M -->|"提交支付请求"| G["Payment Gateway"]
    G --> P["Payment Processor"]
    P --> A["Acquirer"]
    A --> N["Card Network"]
    N -->|"请求批准交易"| I["Issuer"]

图中的 Merchant 节点表示商家的结账业务，不要求敏感卡号先经过商家服务器。使用托管页面或支付组件时，卡信息可以直接交给支付服务商。

对角色最有帮助的区分是：Issuer 在付款人一侧，Acquirer 在商家一侧，Card Network 连接这两侧。 同一家银行可以在不同交易中承担不同角色；商家最终收款银行也未必就是其 Acquirer。服务商把若干节点整合后，开发者只需要调用一个接口，但底层职责仍然存在。Stripe：Acquirer 与 Issuer、Stripe：Payment Processor 与 Acquirer

Visa、Mastercard 这样的品牌在这个例子里是 Card Network，不是给客户开信用额度的银行。卡上同时出现银行名称和网络标志，正是因为它们承担不同角色。其他卡体系可能整合发卡与收单，不能把这张图当成所有支付系统的固定拓扑。Stripe：Card networks 与争议流程

3. PSP、PayFac 与 MoR 为什么不能混为一谈

PSP 是商家购买支付服务时常见的整体入口。它可以整合 Payment Gateway、Payment Processor、多个付款方式、风控和报表；是否自行承担 Acquirer 职责，取决于具体服务。它不是必须插在 Payment Gateway 与 Payment Processor 中间的另一个节点。Adyen：Payment service provider

另外两个常见名称需要单独认识：

PayFac 模式通常简化子商家的入网与 Merchant Account 管理，但帮助商家收钱，不自动等于成为商品的销售责任主体。第三方 MoR 服务则关注后一件事：例如 Polar 作为数字产品转售方，在其服务范围内处理相关销售税及交易责任。Stripe：MoR 与 PayFac、Polar：Merchant of Record

中文市场中的“聚合支付”可能指多个付款入口整合，也可能被用于描述更完整的商户服务。界面上聚合了几个支付按钮，不足以证明其采用 PayFac 模式，更不能证明它是 MoR。 阅读产品介绍时，应追问它究竟聚合支付方式、技术接口，还是商户入网与结算关系，不把营销称呼当成法律身份。

直接使用普通支付处理产品时，商家通常仍是自己的 MoR；选择第三方 MoR 产品才可能改变相应责任分工。也不能只凭公司品牌判断：Stripe 另有 Managed Payments 这一 MoR 产品，不能据此说所有 Stripe Payments 接入都由 Stripe 承担同样责任。Stripe：Merchant of Record

MoR 也不意味着承接商家的所有义务。以 Polar 的公开说明为例，其销售税服务不替代商家自身的所得税责任。Polar：税务责任边界

4. Stripe、PayPal 和钱包放在哪里

Stripe 的整合能力见其 Payment Processor 与 Acquirer 说明；PayPal 的独立网站接入见 PayPal Checkout；Polar 的销售关系见其 MoR 文档。

钱包还要区分付款入口与资金来源。客户选择 PayPal 后，实际资金可以来自 PayPal 钱包、绑定的银行卡或银行账户等来源。因此，页面上看见一个 PayPal 按钮，不足以确定后面采用哪条资金路径。Stripe：PayPal payment flow

同理，Stripe 结账页支持 PayPal，只表示某种产品集成关系；不表示两家公司属于同一个体系。标准集成的账户地区限制、需申请的 custom payment method，以及资金可留在 PayPal 的情况，见 Stripe 接入指南。

5. 从授权到到账：这些步骤并不相同

Clearing 与 Settlement 的基础定义采用 BIS 的支付术语资料。日常产品文档有时会宽泛地使用“结算”，阅读时应明确：说的是参与机构间的结算、平台余额变为可用，还是商家银行入账。BIS：CPMI glossary、BIS：Central banks and payments

下面是支持分离 Authorization 与 Capture 的银行卡流程概览。某些环节可自动执行或在产品界面中合并；箭头表示概念上的推进，不保证各产品账本按相同时间更新。

flowchart TB
    A["Authorization<br/>交易获批，预留资金或额度"] --> B["Capture<br/>提交实际收款要求"]
    B --> C["Clearing<br/>核对交易与结算金额"]
    C --> D["Settlement<br/>履行相关资金义务"]
    D --> E["可用余额<br/>取决于平台结算与风控安排"]
    E --> F["Payout<br/>向商家外部账户打款"]
    F --> G["商家银行入账"]

Authentication 不等于 Authorization

3D Secure 属于 Authentication：它增加持卡人身份核验。即使身份核验通过，交易也可能因为额度、余额或风险控制等原因未获批准。短信验证完成不是已经收款的证明。Stripe：3D Secure

Authorization 不等于 Capture

酒店可以先预留一笔额度，离店时再按规则 Capture。若取消预订，未 Capture 的预留通常走取消或释放流程。不是所有支付方式都支持这种拆分；支持时也必须遵守有效期和具体规则。Stripe：Separate authorization and capture

例如 Stripe 手动 Capture 的 PaymentIntent 可以处于 requires_capture；它表达“还需要请款”，不能作为已完成收款的标志。自动 Capture 可能让开发者看不到一个需要手工处理的中间阶段，但概念仍然不同。Stripe：支付测试场景、Adyen：Capture

支付成功不等于商家银行已到账

支付状态、平台余额可用状态和 Payout 状态分别回答不同问题。Stripe 的 Payout 从可用余额发往银行，打款计划与资金何时可用也不同；银行收到后还可能需要处理时间。Stripe：Receive payouts

因此，不要用“银行卡扣了钱”“页面显示成功”“后台余额增加”“银行收到打款”互相替代。排查时应定位具体对象、状态及时间点。Adyen：Payments lifecycle

6. Refund、Dispute 和 Chargeback

商家主动给客户退钱，是 Refund；客户向 Issuer 表示“不认可这笔交易”，进入的是 Dispute 流程，可能产生 Chargeback、举证及裁决。服务商有时会近义使用 Dispute 和 Chargeback，实际处理应以对应支付方式的事件与流程为准。Stripe：Refunds、Stripe：How disputes work

已经收到 Payout，也不意味着此后不会发生退款或争议。资金处理之外，应用还需要按业务规则决定是否取消订单、关闭权益或停止后续订阅；这些动作不应被假定为自动发生。

7. 用一个例子区分订单、收款与打款

假设销售一件价格为 100 元的商品。以下金额与费用完全是假设，不是任何服务商报价；忽略税、换汇、保证金与争议，假设平台余额已经可用，退款不会退还手续费。

1. 客户通过 Authorization：预留 100 元，不等于商家已获得可提现的 100 元。
2. 商家完成 Capture：进入后续处理，仍需区分平台余额与银行到账。
3. 本例扣除 3 元费用，再退款 20 元：可用于打款的金额为 77 元。
4. Payout 尚未到银行时，商家银行新增入账仍为 0 元；确认入账后才变为 77 元。

这也解释了 Reconciliation 为什么不能只比较“订单总额”和“银行到账”：费用、Refund、时间差等都会造成合理差异。真实平台还可能把多笔付款合并进一次 Payout。Adyen：Reports and the payments lifecycle

下面用 Python 3 标准库验证本例账面关系。将代码保存为任意本地 .py 文件后用 python3 文件名.py 运行；它不连接服务商，也不代表完整财务账本。

from decimal import Decimal

captured = Decimal("100.00")
fee = Decimal("3.00")
refunded = Decimal("20.00")
available = captured - fee - refunded
bank_received = Decimal("0.00")

assert available == Decimal("77.00")
print(f"Payout 前: available={available}, bank_received={bank_received}")

# 模拟已经确认银行收到全部 Payout，而非仅仅提交打款请求。
bank_received += available
available = Decimal("0.00")

assert bank_received == Decimal("77.00")
print(f"银行入账后: available={available}, bank_received={bank_received}")

预期输出：

Payout 前: available=77.00, bank_received=0.00
银行入账后: available=0.00, bank_received=77.00

8. 开发者接入时怎样使用这张概念地图

这些角色知识最终要帮助你问对问题，而不是让每个应用都自己建设整套支付基础设施。

订单是应用的业务对象；PaymentIntent、PayPal Order 等是服务商各自的对象，不能只因名称相似就共用一套状态假设。Webhook 则是状态通知机制，它既不是新的支付角色，也不是资金通道。具体实现还需要验证通知、处理重复事件，并检查相应支付状态。Stripe：Fulfill orders、PayPal：Checkout integration

推荐按这个顺序继续阅读：

1. Stripe 接入指南：角色、对象、Checkout 与 Webhook：把通用角色映射到具体 API 和对象。
2. Polar 接入指南：理解第三方 MoR 路径。
3. WebHook URL：理解支付结果如何通知应用。
4. 系统集成文档导航。