Payment Gateway 是否必须及直接收款流程

2026-10-24支付阿杰

明确结论

Payment Gateway 并不是法律或银行卡网络规定的必备组件，但绝大多数 Web App 都需要通过网关、支付服务商或收单机构提供的技术通道处理付款。

大型电商网站虽然会在自己的页面中收集银行卡信息，却没有绕过支付体系。银行卡付款最终仍要经过收单机构、卡组织和发卡银行。大型商户可能使用自建支付页面和支付编排系统，也可能直接接入一家或多家收单机构，但这不等于”直接连接用户的银行”。

对普通商户来说，直接处理完整银行卡数据通常不会更便宜，还会大幅增加 PCI DSS、安全、合规、风控、清算和运维成本。更可行的做法是使用 Hosted Fields、iframe、支付服务商 SDK 或 Tokenization。这样既能保留自有品牌的支付页面，也能避免银行卡敏感数据进入自己的服务器。

Payment Gateway 到底负责什么

一次银行卡支付通常涉及这些角色：

商户：销售商品或服务的 Web App。
Payment Gateway：安全接收支付请求，并把请求传递给后续支付系统。
Payment Processor：处理和路由交易报文。
Acquirer：收单机构，为商户提供银行卡受理能力和商户账户。
Card Network：例如 Visa、Mastercard、UnionPay、American Express。
Issuer：向消费者发卡的银行。
3-D Secure 服务：必要时完成持卡人身份验证。
风控、Token Vault、退款及对账系统：可能由支付服务商提供，也可能由大型商户自行建设。

实际产品往往会把多个角色整合在一起。因此，一个统称为”Payment Gateway”的服务商，可能同时提供网关、处理、收单、风控、Tokenization 和结算服务。

一笔交易在幕后如何完成

典型流程如下：

用户在结账页面输入银行卡信息。
银行卡数据通过支付服务商提供的 SDK、Hosted Fields 或 iframe，直接发送给服务商。
服务商返回一个 token，商户服务器只保存和使用这个 token。
商户服务器创建支付或发起 authorization。
请求依次经过网关、Processor、Acquirer 和 Card Network，到达 Issuer。
Issuer 根据余额、额度、卡片状态、风控结果和身份验证结果，批准或拒绝交易。
authorization 成功后，商户根据业务模式执行 capture。
后续通过 clearing 和 settlement 完成资金结算。
退款、拒付和争议仍通过相应的收单及卡组织体系处理。

可以简化为：

Browser
  -> Gateway / Payment Service Provider
  -> Processor / Acquirer
  -> Card Network
  -> Issuer
  -> Authorization Response

authorization 只表示当前交易获得授权，不代表资金已经完成结算。许多系统会把授权和扣款分开：

authorize -> capture -> clearing -> settlement

为什么大型网站看起来像是在直接收款

常见情况有以下几种。

使用自有界面的 Hosted Fields

输入框看起来属于网站，实际由支付服务商通过 iframe 或 JavaScript SDK 托管，完整卡号不会经过商户服务器。

自建结账页面，后端接入收单机构

大型商户可能自行处理银行卡数据，再通过专线、收单 API 或银行卡报文接口接入多家收单机构，但收单机构和卡组织仍然在交易链路中。

自建 Payment Orchestration

大型平台通常会根据地区、银行卡类型、成功率、成本和风险，把交易路由给不同的 Acquirer 或 Processor。例如：

Visa issued in Region A    -> Acquirer A
Mastercard issued in B     -> Acquirer B
Failed authorization       -> Retry through Acquirer C

使用自有支付服务实体

部分大型集团会成立具备相应牌照、资质和运营能力的支付实体。这属于金融基础设施建设，远不只是开发一个支付 API。

是否触发 3-D Secure，和是否使用 Payment Gateway，是两个不同的问题。3-D Secure 是持卡人身份验证机制，并不等同于网关。

普通 Web App 推荐的接入方式

建议由前端直接向支付服务商换取 token，再由后端使用 token 创建支付。

以下代码只是结构示例。API 名称和字段需要替换为所选服务商的正式 SDK，不能直接复制到生产环境。

<form id="payment-form">
  <div id="hosted-card-element"></div>
  <button type="submit">Pay</button>
</form>

<script>
  const client = PaymentProvider.createClient({
    publicKey: "pk_example"
  });

  const cardElement = client.createHostedCardElement();
  cardElement.mount("#hosted-card-element");

  document
    .getElementById("payment-form")
    .addEventListener("submit", async (event) => {
      event.preventDefault();

      const result = await client.createPaymentToken({
        element: cardElement
      });

      if (result.error) {
        console.error(result.error);
        return;
      }

      await fetch("/api/payments", {
        method: "POST",
        headers: {
          "Content-Type": "application/json",
          "Idempotency-Key": crypto.randomUUID()
        },
        body: JSON.stringify({
          orderId: "ORDER_123",
          paymentToken: result.token
        })
      });
    });
</script>

后端接收的是 token，而不是完整卡号：

app.post("/api/payments", async (req, res) => {
  const { orderId, paymentToken } = req.body;

  const order = await loadOrder(orderId);

  // 金额必须由后端根据订单重新计算，不能相信前端传入的金额。
  const amount = calculateOrderAmount(order);

  const payment = await paymentProvider.authorize({
    amount,
    currency: order.currency,
    paymentMethodToken: paymentToken,
    reference: order.id,
    idempotencyKey: req.get("Idempotency-Key")
  });

  res.json({
    paymentId: payment.id,
    status: payment.status
  });
});

生产系统还需要验证 Webhook 签名，并把异步通知作为判断最终状态的重要依据：

app.post("/webhooks/payment", rawBodyMiddleware, async (req, res) => {
  const event = paymentProvider.verifyWebhook({
    payload: req.body,
    signature: req.get("Payment-Signature")
  });

  if (await hasProcessedEvent(event.id)) {
    return res.sendStatus(200);
  }

  await processPaymentEvent(event);
  await markEventAsProcessed(event.id);

  res.sendStatus(200);
});

代码中的 PaymentProvider、createHostedCardElement、authorize 等名称只用于说明架构，不是任何服务商的正式 API。

如果完全不使用第三方网关，需要什么

“不使用第三方网关”通常是指自建网关能力，并直接与 Processor 或 Acquirer 集成，而不是向任意发卡银行直接发送请求。一般需要完成以下工作。

商业和金融接入

与一家或多家 Acquirer 签订商户及处理协议。
申请 Merchant ID，并接受业务类型、财务状况和拒付风险审核。
满足保证金、滚动准备金或最低交易量要求。
处理多币种结算、退款、拒付、争议和对账。
根据所在国家或地区，确认是否涉及支付牌照、资金托管或代收代付监管。
如果是 Marketplace，还要明确谁是 Merchant of Record，以及如何完成分账和商户入驻审核。

如果平台代第三方卖家收款，情况会比普通自营电商复杂得多，可能涉及 KYC、KYB、AML、制裁筛查、资金隔离和当地支付监管。

PCI DSS 合规

只要完整银行卡数据进入商户控制的页面、服务器、日志或网络，PCI DSS 范围通常就会大幅扩大。可能需要：

建立并维护 Cardholder Data Environment。
实施网络隔离、访问控制、MFA 和最小权限管理。
保护传输中和静态存储的数据。
建立密钥生成、轮换、托管和销毁机制。
开展漏洞扫描、渗透测试、补丁管理和持续监控。
做好日志审计、异常检测和事件响应。
接受适用级别的合规评估，必要时由 QSA 参与。
严格限制敏感认证数据的存储。

CVV/CVC 等敏感认证数据通常不能在 authorization 后保存。即使数据经过加密，也不会因此获得长期存储资格。具体要求应以当前 PCI DSS、收单协议和卡组织规则为准。

技术系统

需要自行建设或采购：

安全的银行卡数据接收系统。
Token Vault。
HSM 和密钥管理设施。
与 Acquirer 或 Processor 的 API、专线或消息协议集成。
authorization、capture、void、refund 和 reversal。
3-D Secure 集成。
欺诈检测、限流和异常交易拦截。
重试和智能路由，同时防止重复扣款。
Idempotency、Webhook、账务及状态机。
清算文件、结算文件和财务对账。
拒付证据管理。
7×24 监控、故障切换和灾难恢复。

即使全部系统都由商户自建，Interchange、Card Network Assessment、Acquirer Processing 等费用仍需支付。自建只能减少或重新谈判部分网关及处理服务费，无法消除银行卡支付链路中的全部成本。

多少交易量才值得自建

没有一个适用于所有企业的固定交易量。是否值得自建，取决于每年节省的可变成本能否覆盖系统建设、持续运营等固定成本。

设：

V：年交易金额。
N：年交易笔数。
r_pg：现有方案按金额收取的综合费率。
r_direct：直接接入后仍需支付的综合费率。
f_pg：现有方案每笔固定费用。
f_direct：直接接入后的每笔固定费用。
C_fixed：自建和持续运营的年度固定成本。

自建方案具备直接成本优势的大致条件是：

V × (r_pg - r_direct)
+ N × (f_pg - f_direct)
> C_fixed

如果主要差异来自百分比费率，可以这样估算盈亏平衡交易金额：

V_break_even = C_fixed / (r_pg - r_direct)

以下仅作数学演示：

年度固定成本：C_fixed = 3,000,000
综合费率差：r_pg - r_direct = 0.3% = 0.003

V_break_even = 3,000,000 / 0.003
             = 1,000,000,000

这表示年交易金额达到约 10 亿 个计价货币单位时，节省的费率才刚好覆盖固定成本。例子没有计算事故损失、拒付、合规审计、资金成本和系统机会成本，不能作为行业报价或项目结论。

实际测算至少应包括：

平均客单价和交易笔数。
国内卡、国际卡、借记卡和信用卡的占比。
跨境和货币转换费用。
authorization 成功率变化对收入的影响。
退款率、拒付率和欺诈损失。
工程、安全、法务、财务及运营人员成本。
PCI DSS 评估和基础设施成本。
SLA、容灾和全年值班成本。
与 Acquirer 谈判后获得的真实费率。
多家服务商带来的路由收益和实施成本。

许多企业即使达到一定规模，也不会完全替换第三方服务，而会采用混合架构：保留一个或多个支付服务商，直接接入部分 Acquirer，再通过支付编排层按成本和成功率路由交易。

选择方案时应关注什么

不能只比较 Setup Fees 和 Transaction Fees，还要考虑：

authorization 成功率。
结算周期和资金冻结规则。
退款、拒付和跨境费用。
3-D Secure 与本地支付方式覆盖。
Hosted Fields 和 Tokenization 能力。
是否支持卡片更新服务及网络 token。
Webhook 可靠性和 API 幂等性。
支持的国家、币种和银行卡类型。
风控能力和误拒率。
数据导出、对账和迁移能力。
SLA、故障历史和技术支持质量。
退出合同、最低消费和提前终止条款。

如果低费率方案的 authorization 成功率较差，损失的收入可能远高于节省的手续费。

实际建议

初创项目和中等规模 Web App，可以优先选择支持 Hosted Fields、Tokenization 和服务端 API 的合规支付服务商。这样既能保留自己的结账界面，也能明显缩小敏感银行卡数据的处理范围。

交易量增长后，可以逐步采取以下措施：

根据实际交易结构重新谈判费率。
接入第二家服务商，提高可用性和议价能力。
建立支付编排和智能路由。
在交易量集中的地区直接接入 Acquirer。
当节省的金额足以覆盖长期合规和运营成本时，再考虑自建更完整的网关能力。

无论采用哪种模式，都不要让普通应用日志、分析脚本、客服系统或数据库接触完整卡号、CVV/CVC 等敏感数据。支付系统要解决的并不只是如何把银行卡表单放到自己的网站上，而是如何安全、合规、可审计地完成授权、扣款、结算和争议处理。