PAYATHON 2026

网页直接处理信用卡与 3rd party gateway 有何区别？

支付小周

结论

直接通过自己网站的表单收集信用卡信息，通常不会比跳转到第三方支付页面更便宜，也不意味着可以绕过 payment gateway。

如果信用卡号、有效期或 CVV 会经过自己的服务器，商户需要承担更多 PCI DSS 合规责任、安全建设成本和数据泄露风险。对大多数中小型 online shop 来说，以下方式更合适：

  • 跳转到支付服务商托管的 checkout 页面。
  • 在店铺页面中嵌入服务商提供的 Hosted Fields、iframe 或支付组件，让服务商直接接收卡片数据。
  • 使用服务商的前端 SDK 对卡片信息进行 tokenization，自己的服务器只处理 token 或 Payment Method ID。

第二种和第三种方式在用户看来仍是“直接在网页上付款”，但敏感卡片数据并没有进入商户服务器。一些小型商店很可能采用的就是这类方案。

首先要区分 gateway、checkout 页面和收单服务

“使用 3rd party gateway”和“在自己的页面付款”并不是互相排斥的两种支付模式。

Payment gateway 在商户系统、支付处理机构和收单银行之间传递支付请求，可以提供多种前端接入方式：

接入方式客户体验卡片数据是否进入商户系统商户合规负担
Hosted Checkout跳转到第三方页面通常不会最低
Embedded Hosted Fields / iframe留在店铺页面通常不会较低
前端 SDK Tokenization留在店铺页面通常不会经过商户服务器较低至中等
商户服务器直接接收卡号留在店铺页面会最高

即使选择最后一种模式，商户通常仍然需要 merchant account、acquirer、payment processor 或 gateway 来完成授权、清算和结算。自行收集信用卡号不能替代这些机构。

为什么直接处理不一定更便宜

比较支付成本时，不能只看每笔交易的百分比。完整成本通常包括：

  • 交易费和固定手续费；
  • gateway 月费或平台费；
  • 跨境卡、外币卡及不同卡种的附加费；
  • 拒付处理费和退款费；
  • rolling reserve、保证金或延迟结算产生的资金成本；
  • PCI DSS 合规、漏洞扫描和安全审计费用；
  • 反欺诈工具及人工审核成本；
  • 系统开发、监控、密钥管理和事故响应成本；
  • 数据泄露后的调查、通知、罚款及业务中断风险。

Hosted Checkout 可能会收取额外的平台费用，但也能缩小商户直接处理卡片数据的范围。对于交易量不大的店铺，这笔费用往往低于自行建设和维护安全支付环境的成本。

只有当交易量较大、商户拥有成熟的安全团队，并且能从收单机构获得更优惠的费率时，自建程度较高的方案才可能在成本上占优。最终是否便宜，需要根据实际报价和总拥有成本计算，不能只看付款页面有没有跳转。

可以用下面的公式粗略比较：

年度总成本 =
交易金额 × 百分比费率
+ 交易笔数 × 单笔固定费用
+ 月费
+ 拒付与退款成本
+ 保证金或延迟结算成本
+ 合规与安全成本
+ 开发和运维成本

自己的网站接收卡号需要什么条件

如果商户服务器会直接接触未经 tokenization 的信用卡数据，通常至少要处理以下事项。

PCI DSS 合规

商户需要按照适用范围满足当前有效的 PCI DSS 要求。具体验证方式可能包括 SAQ、外部漏洞扫描、渗透测试和网络分段，甚至需要 QSA 参与评估。实际要求取决于交易量、接入架构、收单机构及卡组织的规定。

不能因为“我们不保存卡号”就认定自己不在合规范围内。只要卡片数据经过服务器、日志、代理、监控系统或应用程序，相关组件就可能被纳入 PCI DSS 范围。

安全基础设施

通常需要具备：

  • 全站 HTTPS 和正确配置的 TLS；
  • 严格的访问控制及多因素认证；
  • 安全存储密钥和凭证，并定期轮换；
  • 系统补丁、依赖更新和漏洞管理；
  • 日志审计、异常检测和事件响应流程；
  • 网络分段和最小权限设计；
  • 安全开发、代码审查及定期测试；
  • 防止恶意脚本篡改卡片表单的措施。

授权完成后不应保存 CVV。完整卡号也不应出现在日志、分析平台、错误报告、客服系统或备份中。如果确实需要保存卡片数据，还要满足加密、密钥管理、保留期限和删除机制等额外要求。

商户及收单审核

商户还需要获得愿意承接该业务的收单银行或支付服务商批准。审核通常会检查：

  • 公司注册和实际控制人信息；
  • 产品成分、标签及销售地区；
  • 网站条款、隐私政策和退款政策；
  • 配送周期和客户服务能力；
  • 历史交易量、退款率及拒付率；
  • 营销文案是否包含未经允许的健康或治疗声明；
  • 是否采用订阅、自动续费或免费试用模式。

因此，技术上能在网页中显示信用卡输入框，不代表商户已经具备合法、合规的处理条件。

更推荐的实施方式

中小型店铺可以使用 payment provider 提供的 Hosted Fields 或前端 SDK。浏览器将卡片数据直接提交给服务商，并取得一个短期 token，店铺后端再使用这个 token 创建支付。

下面是概念性流程。API 名称需要替换成实际支付服务商提供的接口：

<form id="payment-form">
  <div id="provider-hosted-card-field"></div>
  <button type="submit">支付</button>
</form>

<script src="https://provider.example/sdk.js"></script>
<script>
  const payments = PaymentProvider.initialize({
    publicKey: "pk_example"
  });

  const cardField = payments.createHostedCardField();
  cardField.mount("#provider-hosted-card-field");

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

      const result = await cardField.tokenize();

      const response = await fetch("/api/payments", {
        method: "POST",
        headers: {
          "Content-Type": "application/json",
          "X-CSRF-Token": getCsrfToken()
        },
        body: JSON.stringify({
          paymentMethodToken: result.token,
          orderId: "ORDER_ID"
        })
      });

      const payment = await response.json();

      if (payment.requiresAction) {
        await payments.handleRequiredAction(payment.clientSecret);
      }
    });
</script>

后端只接收 token，不接收原始卡号：

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

  // 金额必须从服务端订单中读取，不能信任浏览器提交的金额。
  const payment = await paymentProvider.createPayment({
    amount: order.totalMinorUnits,
    currency: order.currency,
    paymentMethodToken: req.body.paymentMethodToken,
    idempotencyKey: order.paymentAttemptId,
    metadata: {
      orderId: order.id
    }
  });

  res.json({
    status: payment.status,
    requiresAction: payment.requiresAction,
    clientSecret: payment.clientSecret
  });
});

这只是一个架构示例，不是某家服务商可以直接运行的代码。实际实现还需要加入身份校验、CSRF 防护、幂等控制、库存锁定、超时处理和 webhook 签名验证。

支付是否成功，应以后端查询结果或经过验证的 webhook 为准，不能只依赖浏览器的跳转结果：

app.post("/webhooks/payment", rawBodyMiddleware, async (req, res) => {
  const event = paymentProvider.verifyWebhook({
    rawBody: req.body,
    signature: req.headers["payment-signature"],
    secret: process.env.PAYMENT_WEBHOOK_SECRET
  });

  if (event.type === "payment.succeeded") {
    await markOrderPaidOnce(event.data.orderId, event.data.paymentId);
  }

  res.sendStatus(200);
});

Food supplements 是否一定属于 high risk

Food supplements 并非在所有国家和所有收单机构那里都会自动归为 high risk。风险等级通常取决于：

  • 产品成分是否受限制；
  • 销售国家和发货国家；
  • 是否宣称治疗、预防或治愈疾病；
  • 是否涉及减肥、性健康、健身增肌等争议较大的类别；
  • 是否采用订阅或自动续费；
  • 配送周期、退款率和拒付率；
  • 商户历史记录及供应链证明。

同一家店铺可能被一家服务商拒绝，也可能得到另一家专业 high-risk acquirer 的接纳。这种差异来自各机构的风险政策、发卡行网络、地区覆盖和承保能力，而不只是技术接口不同。

不要为了获得普通费率而错误申报商品类别或隐藏产品内容。如果服务商之后发现实际经营范围与申报信息不符，可能会暂停收款、冻结结算资金或终止账户。

高风险业务的费用差异

高风险商户常见的额外条件包括：

  • 更高的交易费率；
  • rolling reserve；
  • 更长的结算周期；
  • 更高的拒付处理费；
  • 月度最低费用或账户管理费；
  • 单笔、每日或每月交易限额；
  • 更严格的退款率和拒付率阈值；
  • 要求提供检测报告、成分证明或特定经营许可。

具体费率没有统一标准，也不能根据“跳转支付”或“站内支付”来判断。真正影响报价的因素是商户类别、销售地区、历史数据、平均客单价、订阅模式和预期拒付水平。

比较报价时，应要求服务商以书面形式列明交易费、固定费用、reserve、结算周期、退款费、拒付费、跨境附加费和提前终止条件。

实施建议

可以按照以下顺序落地：

  1. 确认目标市场对 supplements 的标签、成分、广告宣传及销售许可要求。
  2. 准备公司资料、产品清单、成分证明、供应链文件、配送政策和退款政策。
  3. 向普通支付服务商及有相关行业经验的 high-risk acquirer 申请正式审核。
  4. 按年度总成本比较报价，不要只看交易费率。
  5. 优先选择 Hosted Checkout、Hosted Fields 或 tokenization，避免服务器接触原始卡片数据。
  6. 请支付服务商或合格的 PCI 顾问确认准确的 PCI DSS 范围和验证方式。
  7. 上线 webhook、幂等处理、3-D Secure 或服务商要求的身份验证机制。
  8. 持续监控退款、欺诈和拒付原因，并保留订单、物流及客户沟通证据。

如果店铺目前规模较小，最实际的选择通常不是自行处理原始信用卡数据，而是在保留站内付款体验的同时，使用支付服务商托管的安全输入组件。这样可以减少跳转造成的转化损失，也不用承担完整卡片处理环境的成本和风险。

备注：内容仅供参考。