payment gateway 与 marchant gateway 有什么区别？

2026-10-24支付老李

结论

payment gateway 是标准术语，通常译为“支付网关”。它负责在商户系统、收单机构和支付网络之间安全传递支付请求及处理结果。

marchant gateway 不是支付行业的通用术语，其中的 marchant 很可能是 merchant 的拼写错误。在实际交流中，对方可能想表达以下两种概念之一：

merchant account：商户账户，用来接收和结算交易资金。
merchant portal 或 merchant dashboard：商户管理后台，用来查询交易、处理退款、对账和配置支付方式。

这些并不是可以互相替代的同类产品。支付网关处理支付通信，商户账户接收和结算资金，商户后台用于管理交易。完整的线上支付方案通常会同时包含这些部分。

Payment Gateway 是什么

支付网关连接商户业务系统和支付服务提供方，通常负责：

接收支付请求；
加密银行卡等敏感信息，或将其令牌化；
把交易提交给收单机构或支付处理系统；
返回成功、失败、处理中等支付状态；
支持退款、撤销、预授权和支付结果通知；
满足风控、身份验证和合规要求。

例如，用户在电商网站提交订单后，商户服务端一般不会直接连接每一家发卡银行，而是通过支付网关创建支付请求，再根据同步响应和异步通知更新订单状态。

支付网关主要解决技术接入问题，不一定直接持有或结算商户资金。

Merchant Account 是什么

merchant account 是商户为了接收银行卡等支付资金而开设的账户或建立的结算关系。消费者付款后，资金通常会经过支付网络和收单流程，再按照约定的结算周期转入商户指定的银行账户。

Merchant Portal 是什么

如果所谓的 merchant gateway 实际指商户管理后台，它一般用于：

查询交易记录；
发起退款；
下载账单；
查看结算状态；
管理 API 密钥；
配置 Webhook；
处理争议或拒付；
管理操作人员权限。

商户后台不能代替支付网关。前者是运营和管理入口，后者是业务系统实际调用的交易接口。

不同场景应该使用什么

电商网站或 App 在线收款

这类业务通常需要支付网关。商户系统通过支付网关的 API 或 SDK 创建支付，并通过 Webhook 接收最终结果。

如果支付服务商提供一体化服务，商户账户通常会在平台开户时一并开通，不需要另外寻找所谓的 merchant gateway。

线下 POS 刷卡

线下收款可能涉及 POS 终端、收单服务和终端网关。是否还需要独立的线上支付网关，要看业务是否同时支持网页支付、App 支付或远程支付链接。

如果只在实体店刷卡，应先确认服务是否包含终端设备、收单关系和资金结算，而不是只关注有没有线上 API。

平台型业务或多商户市场

如果平台需要让多个入驻商户分别收款，普通的单商户支付网关通常无法满足要求。平台还需要账户体系、子商户管理、分账、入驻审核和独立结算等能力。

典型流程如下：

入驻商户完成身份和资质验证；
平台为商户创建或关联子商户账户；
用户通过支付网关付款；
平台按照业务规则计算佣金；
支付服务商把资金结算给对应商户。

能否代收、分账或延迟结算，取决于服务商的能力和当地监管要求，不能仅靠普通支付 API 自行实现。

电话、邮件订单或人工录入卡号

这类场景的风险和合规要求较高。应使用支付服务商明确提供的虚拟终端、支付链接或经过认证的录入方案，不要自行收集和保存完整卡号及安全码。

只需要退款、对账和查询交易

如果支付接入已经完成，日常运营人员一般使用商户后台即可。需要自动处理退款或对账时，则应调用支付网关或支付服务商提供的服务端 API。

推荐的接入步骤

1. 先确认术语

先向服务商确认其所说的 merchant gateway 具体指什么：

商户账户；
商户管理后台；
收单服务；
平台子商户接口；
某个特定品牌的产品名称。

如果这是某家公司的专有产品名称，应以该公司的接口文档和合同定义为准。

2. 明确业务需求

至少需要确认这些问题：

线上支付还是线下支付；
单一商户还是多商户平台；
是否需要预授权、退款或分账；
需要支持哪些国家、币种和支付方式；
资金由谁收取和结算；
是否涉及订阅及周期扣款；
谁负责处理拒付和争议。

3. 选择服务模式

小型企业或初创业务通常适合使用集成式支付服务，由同一家服务商提供支付网关、收单和商户账户，接入和对账会相对简单。

对于交易量较大、跨地区经营或需要复杂路由的企业，可以分别选择支付网关和收单机构，以便获得更大的费率谈判空间，并配置支付路由和容灾方案。

4. 完成服务端接入

下面的通用示例展示了商户服务端调用支付网关的基本结构。接口地址和字段仅用于说明结构，不能直接当作任何支付服务商的真实 API 使用。

async function createPayment(order, paymentToken) {
  const response = await fetch("https://api.example-payment.com/v1/payments", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.PAYMENT_API_KEY}`,
      "Content-Type": "application/json",
      "Idempotency-Key": order.paymentRequestId
    },
    body: JSON.stringify({
      amount: order.amount,
      currency: order.currency,
      payment_method_token: paymentToken,
      merchant_reference: order.id,
      return_url: "https://merchant.example.com/payment/return"
    })
  });

  if (!response.ok) {
    throw new Error(`Payment request failed: ${response.status}`);
  }

  return response.json();
}

前端应优先使用服务商提供的托管支付页面或 SDK，把敏感支付信息转换为 paymentToken。除非已经具备相应的安全和合规条件，否则不要让卡号经过商户自己的服务器。

5. 使用 Webhook 确认最终状态

浏览器跳转到成功页面，并不能证明支付已经成功。用户可能伪造请求或关闭页面，支付也可能还在异步处理中。订单状态应以服务端查询结果或验证通过的 Webhook 为准。

app.post("/webhooks/payment", rawBodyParser, async (req, res) => {
  const signature = req.headers["payment-signature"];

  if (!verifyWebhookSignature(req.body, signature)) {
    return res.status(401).send("Invalid signature");
  }

  const event = JSON.parse(req.body.toString("utf8"));

  if (event.type === "payment.succeeded") {
    await markOrderAsPaid(event.data.merchant_reference);
  }

  if (event.type === "payment.failed") {
    await markOrderAsFailed(event.data.merchant_reference);
  }

  res.sendStatus(200);
});

verifyWebhookSignature 的算法、签名头名称和原始请求体处理方式，必须严格按照实际支付服务商的文档实现。

注意事项

正确拼写通常是 merchant，不是 marchant。
不要把支付网关返回的“交易成功”理解为银行账户中的“资金已结算”。
API 密钥只能保存在服务端，不能写入网页、App 或公开代码仓库。
创建支付和退款时应使用幂等键，防止网络重试导致重复扣款或重复退款。
金额应使用最小货币单位或精确的十进制类型，避免直接使用二进制浮点数计算。
必须验证 Webhook 签名，并妥善处理重复、乱序和延迟通知。
不要自行保存 CVV 等敏感验证数据。处理银行卡数据还可能涉及 PCI DSS 等合规要求。
选择服务时，除了接口费率，还要比较支付成功率、结算周期、退款能力、拒付费用、币种支持和技术稳定性。

简而言之，如果需要让用户在网站或 App 中付款，应使用 payment gateway；如果需要接收和结算资金，则需要 merchant account 或相应的收单关系；如果需要查询交易、退款和对账，则使用 merchant portal。如果服务商把这些能力整合在同一套产品中，按照其一体化接入流程配置即可。