跨境支付：支付网关与技术方案

本文是「跨境支付」系列第二篇，聚焦跨境支付网关和技术方案。

本文根据公开资料、服务商文档和支付系统工程实践整理。文中出现的覆盖国家数、支付方式数量、成功率、结算周期、风控模型指标和通道策略，应被理解为方案设计口径或服务商能力示例，不应直接作为未验证承诺。实际接入前，应以目标市场监管要求、服务商合同、卡组织规则和银行结算文件为准。

跨境支付网关是连接商户、消费者、金融机构、支付机构和卡组织的核心枢纽。它既要处理高并发支付请求，也要处理多币种、清结算、风控、拒付、合规、对账和商户运营。

开发一套支持境外商户使用、允许消费者通过外卡或本地支付方式完成消费的系统，不能只看一个 POST /pay 接口。复杂度来自完整的交易生命周期：创建、授权、认证、扣款、清算、入账、退款、拒付、对账、报表、审计和监管留痕。

网关边界

跨境支付网关通常处在商户系统和下游支付网络之间。

它至少承担 6 类职责：

1. 接入。 为商户提供 API、SDK、Webhook、插件和后台配置能力。

2. 路由。 按币种、地区、卡组织、支付方式、成本、成功率和合规要求选择通道。

3. 支付处理。 发起授权、捕获、取消、退款、查询和异步通知。

4. 资金处理。 记录交易金额、手续费、汇率、清算状态、结算账户和入账时间。

5. 风险控制。 识别欺诈、账户盗用、异常交易、制裁风险和拒付风险。

6. 运营支撑。 提供交易查询、对账报表、通道监控、商户配置和合规报告。

它不等同于卡组织，也不等同于银行清算系统。Visa、Mastercard、American Express、JCB 等卡组织负责卡网络规则和交易交换；SWIFT、CIPS 等更偏银行间报文、跨境人民币清算或资金清算基础设施；支付网关则负责把商户侧业务请求转换成可被下游处理的支付请求，并把下游结果稳定地带回商户系统。

聚合支付网关

聚合支付网关需要在高可用、低延迟和强合规之间做工程取舍，接入通道数量只是一个维度。

游戏、电商、订阅、数字内容和跨境服务平台通常需要同时支持以下能力：

• 国际卡组织：Visa、Mastercard、American Express、JCB、Discover、Diners Club、UnionPay 等。

• 本地钱包：GrabPay、Dana、GCash、AlipayHK、STC Pay 等。

• 本地银行转账和实时支付：SEPA、iDEAL、Pix、PromptPay、FPX、PayNow 等。

• 现金凭证和延迟付款：Boleto、OXXO、Konbini 等。

• BNPL：Klarna、Atome、Afterpay 等。

• 移动钱包：Apple Pay、Google Pay 等。

• 加密资产支付：USDT、BTC 等，只适合明确合规边界和会计处理方式的业务。

部分头部 PSP 会宣称支持上百个国家和大量本地支付方式。例如 Airwallex 公开文档提到 cards 和 160+ alternative payment methods。类似「180+ 国家 / 160+ 支付方式」这类指标，更适合作为服务商覆盖能力或目标市场地图，不适合写成自建网关上线后的默认能力。

更实际的设计方式是先做目标市场矩阵：

这张表比单纯罗列支付方式更有用。它能让产品、技术、风控和商务围绕相同的优先级推进。

国际支付网络与清算层

支付网关需要连接多个层级的网络。

卡网络层。 卡支付通常涉及商户、支付服务商、收单机构、卡组织和发卡行。网关要支持授权、捕获、取消、退款、3D Secure、拒付证据和卡品牌规则。Stripe 文档中列出的 Visa、Mastercard、American Express、JCB、UnionPay 等卡品牌，可以作为全球卡支付能力的公开参考。

本地支付层。 不同市场的主流支付方式差异很大。Stripe 支付方式文档把支付方式分为 cards、bank debits、bank redirects、bank transfers、BNPL、real-time payments、vouchers 和 wallets。这个分类适合用来设计支付方式抽象，而不是把所有方式都压成「信用卡」模型。

清结算层。 SWIFT、CIPS、代理行和本地清算网络更接近资金清算与金融报文层。普通商户网关通常不会直接接入 CIPS，而是通过银行、支付机构、结算银行或持牌主体间接使用相关能力。CIPS 官网将其定义为经中国人民银行授权、专注跨境人民币支付清算的批发支付系统，这决定了它更适合放在跨境人民币结算方案中，而不是放在 checkout 接口文档里。

外汇服务层。 多币种业务需要报价、锁汇、换汇、资金归集和手续费处理。Currencycloud 这类服务提供余额、汇率、换汇、付款和子账户等 API 能力；Airwallex、Wise 等多币种账户产品也可以作为产品形态参考。这里要区分三件事：商户收单、账户换汇、跨境付款。它们可以组合，但不是同一个系统职责。

链上结算层。 Ripple、Stellar 等链上网络可以探索跨币种转移、资产发行和链上清算。例如 XRP Ledger 文档描述了 cross-currency payments。这类网络适合作为补充结算通道或特定业务试点，不应默认放进所有外卡收单方案。

动态路由

动态路由是支付网关的核心模块。它的目标是在成功率、成本、时延、合规和用户体验之间做实时选择。

常见策略包括：

• 成本优先。 选择手续费、换汇成本和清算成本更低的通道。例如本地清算网络可能优于跨境卡收单或中转行路径。

• 成功率优先。 按发卡国家、BIN、币种、卡组织、支付方式和历史授权结果调整权重。

• 时延优先。 对游戏充值、数字内容和即时交付订单，优先选择响应稳定的通道。

• 合规优先。 对制裁国家、受限 IP、禁售品类和高风险商户，自动屏蔽或提高审核强度。

• 用户体验优先。 对本地支付偏好明显的市场，优先展示本地支付方式，而不是默认展示国际卡。

「整体支付成功率提升至 95% 以上」可以作为成熟市场的优化目标，但不能作为泛化承诺。支付成功率要按国家、支付方式、卡组织、发卡行、客单价、MCC、风控分层和通道分开统计。否则一个平均值会掩盖关键问题：某些地区可能已经很高，另一些地区仍在持续失败。

一个可执行的路由评分可以写成：

channel_score =
  success_rate_30m * 0.45 +
  success_rate_7d * 0.20 +
  latency_score * 0.15 +
  cost_score * 0.10 +
  risk_score * 0.10

当 channel_score < 80，系统可以把对应通道降级为备选；当连续 5 分钟失败率异常升高，可以触发熔断；当通道恢复稳定，再按灰度比例逐步恢复流量。

实现方式可以从加权轮询开始，每 5 分钟更新一次通道健康状态，包括授权成功率、响应时间、错误码分布、超时率、拒付率和费用变化。配置同步可以使用 ZooKeeper、etcd、Consul 或内部配置中心。无论选择哪种组件，配置都要有版本、有审计、有灰度、有回滚。

支付流程

一笔外卡支付可以拆成 8 个步骤：

1. 消费者在商户侧提交订单，选择卡支付或本地支付方式。

2. 商户调用网关创建支付请求，传入订单号、金额、币种、用户 IP、设备信息和风险上下文。

3. 网关生成内部支付 ID，做幂等检查和参数校验。

4. 风控引擎评估交易风险，决定放行、拒绝、人工审核或触发 3D Secure。

5. 路由引擎选择通道，例如 visa_direct、adyen_cards_eu、stripe_cards_us 或 grabpay_sg。

6. 通道适配器把统一请求转换成下游协议，可能是 HTTP API、ISO 8583、文件清算或私有 SDK。

7. 下游返回授权结果，网关更新交易状态并给商户返回同步结果。

8. 后续清算、结算、退款、拒付和对账通过异步任务继续推进。

对外 API 应该把「支付已受理」「授权成功」「扣款成功」「待结算」「已结算」「失败」「已退款」「发生拒付」区分清楚。只返回 success 或 failed，会让商户无法判断是否发货、是否发放游戏道具、是否允许用户再次尝试。

预授权和 3D Secure 也要按风险使用。酒店、租车和部分高客单价业务适合先授权再捕获；低风险小额数字内容可以减少认证摩擦；高风险新设备、大额交易、异常地区或高拒付商户应提高认证强度。

API 与插件接入

支付网关对外通常提供三类接入方式。

第一，标准 API。 适合自研电商、游戏、App 和服务平台。API 要覆盖创建支付、查询状态、取消授权、捕获、退款、Webhook、对账文件和争议处理。

第二，SDK。 适合移动端、Web checkout 和服务端快速接入。SDK 应尽量只处理 tokenization、支付方式展示、前端认证和错误提示，不应把核心路由和资金逻辑放到客户端。

第三，平台插件。 Shopify 和 WooCommerce 这类平台都有自己的支付扩展机制。Shopify 支付扩展需要符合平台准入和审批要求，WooCommerce 则通过 payment gateway plugin 接入。插件能把开发周期压缩到 1 到 2 周，但会牺牲一部分深度定制能力。

移动端还要支持 Apple Pay、Google Pay 和 HTML5 checkout。这里要注意两点：

• Apple Pay 和 Google Pay 往往仍然以卡为资金来源，网关侧看到的可能是钱包 token 或卡网络 token。

• 移动 Web、小程序和原生 App 的支付体验不同，3D Secure、跳转、回调、App 切换和失败恢复都要单独测试。

多币种账户与汇率管理

多币种能力至少包括 4 个层次。

第一，币种展示。 按用户地区显示本地币种价格，例如 USD、EUR、GBP、JPY、BRL、THB、SAR。展示币种不一定等于最终结算币种。

第二，原币种收款。 在目标市场开设本地银行账户或虚拟本地账户，例如美国 USD 账户、欧元区 SEPA 账户、英国 GBP 账户、新加坡 SGD 账户。部分服务商支持数十种币种原币种收款。原始材料中的「60+ 币种」应作为服务商尽调指标，而不是系统默认能力。

第三，实时汇率和锁汇。 接入外汇服务商、银行报价、ECB 参考汇率、Reuters 数据源或内部做市商，提供报价、有效期、锁汇和换汇执行。商户可以提前 24 小时锁定汇率，也可以在结算时按市场汇率转换。

第四，资金归集和对账。 多币种账户不能只看余额，还要记录每一笔交易对应的原始币种、扣款币种、清算币种、结算币种、汇率来源、报价时间、手续费和调账记录。

系统建模时，不要只存一个 amount。至少需要区分：

• order_amount：订单金额；

• presentment_amount：消费者看到并确认的金额；

• authorized_amount：授权金额；

• captured_amount：实际捕获金额；

• settlement_amount：商户入账金额；

• fee_amount：手续费；

• fx_rate：汇率；

• value_time：交易价值时间；

• booking_time：系统入账时间；

• settlement_time：资金清算时间。

这也是第一篇提到的核心原则：支付成功不等于资金到账，金额展示不等于资金入账，账本必须能解释每一分钱从哪里来、到哪里去。

系统架构

跨境支付网关可以采用分层架构，也可以采用微服务架构。微服务不是目的，职责边界才是目的。

一个可落地的架构可以分成 5 层。

接入层

接入层负责处理商户请求和消费者 checkout 流量。

主要能力包括：

• HTTP/JSON API；

• Webhook 接收和签名验证；

• API key、OAuth 2.0 或 mTLS 认证；

• 幂等键校验；

• 请求限流，例如令牌桶或滑动窗口；

• 协议转换，例如 HTTP/JSON 到 ISO 8583 或下游私有 API；

• 灰度发布和版本管理；

• Web、移动端和插件接入。

边缘节点可以承载静态 checkout 资源、地区识别、支付方式发现和轻量风控预检查。涉及 PAN、CVV 和敏感认证数据时，应优先使用 PSP 托管字段、网络 token、客户端 tokenization 或合规服务端处理，避免把边缘函数扩大到 PCI DSS 高风险范围。

业务层

业务层负责支付决策和交易状态推进。

核心模块包括：

• 支付订单服务；

• 路由引擎；

• 通道适配器；

• 风控引擎；

• 3D Secure 和认证策略；

• 退款和拒付服务；

• 清结算模块；

• 对账服务；

• 商户配置服务；

• 通知和 Webhook 服务。

状态机是这一层的核心。每一笔交易都应该只能按允许的状态迁移，例如 pending -> authorized -> captured -> settled，或者 pending -> failed，或者 captured -> refunded。任意改状态会直接破坏对账和审计。

资金与账本层

资金层记录交易、费用、汇率、结算批次、账户分录和调账。

高频交易流水可以进入分区表或事件流，财务事实应进入强一致账本。Cassandra、ClickHouse、BigQuery 这类系统适合交易查询、日志分析或报表加速，但不应随意替代可审计账本。

账本建议采用追加式分录：

• 商户应收；

• 支付机构待清算；

• 手续费收入；

• 拒付损失；

• 退款挂账；

• 汇兑损益。

每一笔资金变动都要有来源、去向、币种、金额、时间和业务引用。

数据层

数据层可以按职责选择不同存储：

• PostgreSQL 或 MySQL：订单、交易、商户配置、结算批次；

• Redis：汇率缓存、风控规则缓存、幂等锁、短期限流；

• Kafka：交易事件、清算事件、风控事件、Webhook 投递；

• ClickHouse / BigQuery：支付运营分析、通道成功率、风控特征离线分析；

• 对象存储：清算文件、拒付证据、审计报告和对账文件；

• KMS / HSM：密钥管理、加密和签名。

原始材料提到「Cassandra 存储交易流水 + Redis 缓存汇率、风控规则」。这个方向可以保留，但要明确：交易核心状态和账本事实需要强一致和可审计，Cassandra 更适合作为大规模事件查询或日志存储。

运营层

运营层面向支付运营、风控、财务、客服和商户成功。

它包括：

• 商户后台；

• 交易查询；

• 风控工单；

• 通道配置；

• 结算设置；

• 对账中心；

• 拒付处理；

• 合规报告；

• 监控告警；

• SLA 和容量看板。

没有运营层的支付网关，只能完成技术接入，无法长期优化成功率和成本。

高可用设计

支付网关必须按故障设计，而不是按正常路径设计。

多区域部署

全球业务可以在美国东部、法兰克福、新加坡等区域部署节点，对应 AWS us-east-1、eu-central-1、ap-southeast-1 等区域，或使用同等云服务商区域。用户访问可以通过 GeoDNS、latency-based DNS、Anycast edge 或全局负载均衡就近接入。

这里要区分两类流量：

• 消费者 checkout 流量。 对时延敏感，可以靠近用户部署。

• 资金事实写入。 对一致性和审计敏感，不应因为多活而牺牲资金正确性。

多活不是所有模块都多活。支付请求接入可以多区域，账本写入和清算批次可以按主区域、分片或严格一致性策略处理。

故障自愈

Kubernetes 的 liveness、readiness 和 startup probes 可以用于服务健康检查和自动重启。数据库层应使用托管数据库高可用、主从切换、读写分离和备份恢复。传统 IDC 或部分 VPC 架构可能会使用 VIP 漂移；云上更常见的是代理层切换、DNS 切换或托管数据库 failover。

自愈不能只依赖重启。支付系统还需要：

• 幂等键，防止重试导致重复扣款；

• outbox pattern，保证数据库状态和消息投递一致；

• 死信队列，保存无法处理的异步任务；

• 补偿任务，恢复失败的通知、清算和对账流程；

• 人工处理台，处理自动恢复不了的资金差异。

熔断与降级

通道故障不能拖垮主流程。

可以使用熔断器、bulkhead、限流、超时和重试策略隔离下游。原始材料提到 Hystrix，它是早期常见方案，但 Netflix 已将 Hystrix 置于 maintenance mode。新项目可以评估 Resilience4j、Envoy、service mesh 或自研熔断组件。

降级策略要明确：

• 某卡通道超时，切换备用卡通道；

• 某本地钱包不可用，隐藏对应支付方式；

• 风控模型不可用，回退到规则引擎和更保守的人工审核；

• 汇率服务不可用，停止报价或使用短期缓存并标记报价来源；

• Webhook 投递失败，进入重试和死信队列。

降级不能悄悄发生。每次降级都要记录原因、范围、持续时间和影响交易数。

核心功能模块

路由引擎

路由引擎的输入包括金额、币种和更多交易上下文。

更完整的输入包括：

• 商户 ID、商户行业、MCC、风险等级；

• 订单金额、币种、商品类型、是否虚拟交付；

• 消费者 IP、国家、设备指纹、登录状态；

• 卡 BIN、卡品牌、发卡国家、是否支持 3D Secure；

• 当前通道健康度、费率、限额和可用币种；

• 合规限制、制裁筛查和禁售品类；

• 商户配置，例如成本优先或成功率优先。

路由输出也不应只是通道名。它应该包括决策原因：

{
  "payment_id": "pay_202607070001",
  "selected_channel": "cards_eu_primary",
  "fallback_channel": "cards_eu_backup",
  "strategy": "success_rate_first",
  "reason_codes": ["BIN_REGION_MATCH", "LOW_LATENCY", "3DS_SUPPORTED"],
  "score": 91
}

这种结构方便支付运营解释为什么某笔交易走了某个通道，也方便风控和财务在事后复核。

多币种处理

实时汇率服务可以由三类报价组成：

• 外部市场数据源，例如 Reuters、ECB 或银行报价；

• 外汇服务商报价，例如 Currencycloud、Airwallex 或合作银行；

• 内部做市商或资金池报价。

系统可以做 Best Bid/Offer 聚合，但必须记录报价来源、报价时间、有效期和最终成交价。

锁汇功能可以按两种方式实现：

1. 订单级锁汇。 适合高客单价交易，报价在几分钟到数小时内有效。

2. 商户级锁汇。 适合稳定流水商户，例如提前 24 小时锁定某币种汇率。

多币种账户可以使用虚拟子账户建模，例如 USD_001、EUR_002、GBP_003。每个子账户应绑定主体、用途、币种和资金归属。跨境清算中还可能涉及 Nostro / Vostro 账户，用于银行间资金存放和对应账户关系。文章级方案可以说明这个概念，实际落地需要银行合作和合规审核。

风控与反欺诈

风控模块要同时支持规则、模型和人工复核。

规则引擎可以覆盖：

• 单笔金额超过 5000 美元触发人工审核；

• 1 小时内同卡号或同设备多次失败；

• IP 国家与发卡国家长期不一致；

• 高风险国家、受限地区或制裁名单命中；

• 虚拟商品高额订单要求 3D Secure；

• 同一邮箱、设备或卡 BIN 出现异常拒付集中。

机器学习模型可以使用以下特征：

• 设备指纹、浏览器特征、Canvas 指纹；

• IP 信誉、代理、VPN、机房 IP；

• 用户行为序列，例如页面停留时间、输入卡号速度、失败后重试频率；

• 卡 BIN、发卡国家、账单地址、收货地址；

• 商户历史拒付率、退款率、异常交易占比；

• 社交图或账户图，用于识别团伙欺诈。

XGBoost 分类模型、图神经网络和异常检测模型都可以使用。原始材料中的「AUC 0.92」可以作为内部模型评估目标示例，但不能脱离样本、时间窗口和业务类型单独宣传。

处置策略要分层：

• 放行。 低风险交易直接授权。

• 增强认证。 中风险交易触发 3D Secure、短信验证码或钱包认证。

• 实时拦截。 高风险交易在毫秒级返回拒绝。

• 人工复核。 金额高、证据不足或命中灰名单的交易进入工单。

• 事后监控。 对已完成交易继续监控拒付、退款和账户异常。

EMV 3-D Secure 是卡不在场交易的重要认证协议。它可以帮助发卡行评估风险并决定是否需要消费者参与认证，但它不是万能风控。过度触发会降低转化，触发不足会增加欺诈和拒付。

合规与安全

跨境支付系统不能把合规当成上线前文档。合规会影响产品功能、数据模型、日志留存、客户准入、交易限额和通道选择。

KYC 与 AML

KYC / KYB 主要用于确认个人或商户主体身份。AML 主要用于反洗钱、反恐怖融资、制裁名单筛查和异常交易监测。

常见能力包括：

• 对接 Jumio、Onfido / Entrust、Mitek 等身份核验服务；

• 证件 OCR、证件真伪识别、活体检测和人脸比对；

• 企业工商、UBO、受益所有人和经营范围核验；

• OFAC、UN、EU 等制裁名单筛查；

• PEP 和负面新闻筛查；

• 交易监测、可疑交易报告和风控工单；

• 至少 5 年或按监管要求保存交易日志和审核记录。

FATF Recommendations 是 AML / CFT 的国际标准参考，OFAC 和 UN Consolidated List 是制裁筛查的重要数据源。实际系统需要按服务地区选择具体名单、阈值和复核流程。

PCI DSS 与卡数据安全

只要系统存储、处理或传输 cardholder data 或 sensitive authentication data，就会进入 PCI DSS 范围。PCI SSC 对 PCI DSS 的定位是保护支付账户数据的技术和运营要求基线。

工程上应尽量减少 PCI DSS 范围：

• 使用 PSP 托管字段或 hosted checkout；

• 用 token 替代 PAN；

• 不保存 CVV；

• 卡数据传输使用 TLS 1.2+ 或 TLS 1.3；

• 敏感数据加密存储，密钥放在 KMS / HSM；

• 按最小权限访问卡数据；

• 记录访问审计和密钥使用审计；

• 生产环境禁止明文日志输出卡号、CVV、身份证件号和完整地址。

如果确实需要自建卡数据处理能力，PCI DSS Level 1、渗透测试、ASV 扫描、日志审计、密钥轮换和供应商评估都会成为长期成本。

GDPR 与数据隐私

欧盟 GDPR 包含访问、更正、删除、限制处理和数据可携带等权利。European Commission 对 right to erasure 的说明也指出，个人可请求删除数据，但在法律义务、公共利益等情况下存在例外。

支付系统不能简单「用户申请删除就删除所有交易」。交易、税务、反欺诈和 AML 记录可能必须保留。更合理的做法是：

• 区分支付事实、风控证据、客服信息和营销数据；

• 对不再需要的个人识别信息做删除或匿名化；

• 对法定留存数据保留最小必要字段；

• 建立数据访问、导出、删除和保留期限流程；

• 记录每次数据处理请求的处理结果和依据。

审计与报告

合规报告不应只靠人工导出 Excel。

系统可以自动生成：

• 每日交易摘要；

• 高风险交易列表；

• 可疑交易报告草稿；

• 商户交易限额监控；

• 制裁名单命中复核记录；

• 退款和拒付趋势；

• 清算批次和银行入账差异；

• SWIFT / ISO 20022 报文字段映射说明；

• 监管或合作银行要求的专项报表。

原始材料提到 MT103 和 FATF 可疑交易报告。SWIFT 跨境支付已进入 ISO 20022 迁移阶段，MT 与 ISO 20022 的关系正在变化。新系统应优先按 ISO 20022 和合作银行要求建模，不应只围绕 MT103 做长期设计。

API 设计

支付 API 要把幂等、状态、错误码、回调和可观测性放在第一版设计里。

创建支付

POST /v1/payments
Idempotency-Key: 7fd0327d-62d9-4f2e-8ac7-2a3c7d9f2b10
Content-Type: application/json

{
  "merchant_id": "mch_10001",
  "merchant_order_id": "ord_202607070001",
  "amount_minor": 10000,
  "currency": "USD",
  "payment_method": {
    "type": "card",
    "token": "tok_card_abc"
  },
  "customer": {
    "ip": "203.0.113.10",
    "country": "US",
    "email_hash": "sha256:..."
  },
  "risk_context": {
    "device_id": "dev_8f31",
    "session_id": "sess_7a21",
    "goods_type": "digital"
  }
}

幂等键是支付 API 的基本要求。Stripe 文档中强调，POST 请求可以通过 idempotency key 安全重试，避免网络错误后重复创建对象。自建网关也应遵守这个原则。

支付状态

建议至少包含以下状态：

• created：已创建，尚未发起下游请求；

• risk_review：进入风控或人工复核；

• requires_action：需要 3D Secure 或跳转认证；

• authorized：已授权；

• captured：已捕获；

• settlement_pending：待清算；

• settled：已结算；

• failed：失败；

• cancelled：已取消；

• refunded：已退款；

• disputed：发生争议或拒付。

状态机要防止非法迁移。例如 failed 不应直接变成 settled；settled 之后发生退款，应创建退款记录和账本分录，而不是改写原交易。

Webhook

Webhook 要支持：

• 签名校验；

• 事件 ID；

• 幂等处理；

• 至少 3 次重试；

• 指数退避；

• 死信队列；

• 商户后台重放；

• 事件版本；

• 完整审计日志。

Webhook 不是「通知一下」那么简单。它是商户系统更新订单、发货、发放权益和做财务对账的关键输入。

错误码

错误码要能指导商户下一步动作。

错误码要稳定，不要把下游原始错误直接暴露给商户。内部可以保留下游错误码，用于通道分析和排障。

数据库设计

交易核心表要优先保证可审计和可扩展。

下面是一个简化示例：

CREATE TABLE transactions (
  id BIGINT NOT NULL COMMENT '网关内部交易 ID',
  merchant_id VARCHAR(32) NOT NULL COMMENT '商户 ID',
  merchant_order_id VARCHAR(64) NOT NULL COMMENT '商户侧订单号，用于幂等和对账',
  amount_minor BIGINT NOT NULL COMMENT '交易金额，按币种最小单位存储',
  currency CHAR(3) NOT NULL COMMENT 'ISO 4217 三位币种代码',
  status VARCHAR(32) NOT NULL COMMENT '交易状态，例如 created、authorized、captured、settled、failed',
  gateway_channel VARCHAR(64) COMMENT '实际使用的支付通道标识',
  risk_score INT COMMENT '风控评分，数值越高表示风险越高',
  value_time TIMESTAMP(6) NOT NULL COMMENT '交易价值时间，通常对应消费者发起支付的时间',
  booking_time TIMESTAMP(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) COMMENT '系统入账时间，即交易写入本系统的时间',
  settlement_time TIMESTAMP(6) NULL COMMENT '资金清算或商户入账时间',
  created_at TIMESTAMP(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) COMMENT '记录创建时间',
  updated_at TIMESTAMP(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) COMMENT '记录最后更新时间',
  PRIMARY KEY (id, created_at),
  UNIQUE KEY uniq_merchant_order (merchant_id, merchant_order_id, created_at),
  KEY idx_merchant_status (merchant_id, status),
  KEY idx_channel_created (gateway_channel, created_at)
)
PARTITION BY RANGE COLUMNS (created_at) (
  PARTITION p202607 VALUES LESS THAN ('2026-08-01'),
  PARTITION pmax VALUES LESS THAN (MAXVALUE)
);

这个示例使用 amount_minor 存最小单位金额，避免浮点精度问题。MySQL 分区表要求唯一键包含分区列，因此主键和唯一键都包含 created_at。实际生产中，可以按数据库版本和查询模式调整为月表、分库分表、PostgreSQL declarative partitioning 或事件流加账本存储。

风控日志可以单独建表或进入事件存储：

CREATE TABLE risk_logs (
  id BIGINT PRIMARY KEY COMMENT '风控日志 ID',
  payment_id BIGINT NOT NULL COMMENT '关联的支付或交易 ID',
  merchant_id VARCHAR(32) NOT NULL COMMENT '商户 ID',
  device_id VARCHAR(64) COMMENT '设备指纹或设备标识',
  ip_country CHAR(2) COMMENT '按 IP 解析得到的 ISO 3166-1 alpha-2 国家或地区代码',
  rule_hits JSON NOT NULL COMMENT '命中的风控规则及规则参数快照',
  model_score INT COMMENT '模型风险评分',
  decision VARCHAR(32) NOT NULL COMMENT '风控决策，例如 pass、review、challenge、block',
  reviewer_id VARCHAR(64) COMMENT '人工复核人员 ID，自动决策时为空',
  created_at TIMESTAMP(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) COMMENT '风控日志创建时间',
  KEY idx_payment_id (payment_id),
  KEY idx_merchant_created (merchant_id, created_at)
);

风控日志要保存设备指纹、IP 地理位置、规则命中、模型分数和最终决策，用于拒付争议、内部复核和监管审查。

性能与可靠性

支付系统不应把所有事情放在同步请求里完成。

同步路径只处理：

• 参数校验；

• 幂等校验；

• 风控快速决策；

• 路由选择；

• 下游授权请求；

• 状态写入；

• 给商户返回可解释结果。

异步路径处理：

• 清算文件生成；

• 对账文件下载；

• Webhook 重试；

• 邮件和短信通知；

• 风控特征回流；

• 报表汇总；

• 拒付证据整理；

• 合规报告生成。

Kafka 可以用来解耦支付请求和后续清算、通知、报表流程。RabbitMQ / Celery 适合任务队列和后台处理。选型取决于团队语言栈和消息语义，但都要处理至少一次投递、重复消费、死信队列和重放。

缓存策略要谨慎：

• 汇率缓存可以用 Redis，每 10 秒或按报价有效期更新；

• 风控规则可以用 Redis 或 Guava 本地缓存，但要支持版本号和即时失效；

• 通道健康度可以短期缓存，但每次路由决策仍要记录使用的健康度版本；

• 幂等键缓存可以用于快速判断，但最终幂等结果应落到持久化存储。

缓存只能提升性能，不能成为资金事实来源。

运营支撑系统

跨境支付网关必须配套运营后台。

监控与告警

监控指标至少分 5 类：

• 可用性。 API 成功响应率、通道可用率、Webhook 投递成功率。

• 时延。 创建支付 P50/P95/P99、下游通道响应时间、3D Secure 完成时间。

• 支付结果。 授权成功率、支付完成率、失败原因分布、通道超时率。

• 资金状态。 待清算金额、待入账金额、差异金额、退款和拒付金额。

• 风险状态。 拦截率、人工复核量、拒付率、黑名单命中、异常交易占比。

Prometheus 适合采集指标和告警，Grafana 适合做可视化看板。支付成功率不应和系统可用性混在一起。系统 SLI 可以设置为 API availability ≥ 99.9%，支付体验指标可以设置为授权 P95 ≤ 800 ms 或按通道拆分的授权成功率。

智能告警可以预测容量瓶颈，例如未来 2 小时流量可能增长 30%，提前扩容 EC2/ECS 实例或 Kubernetes 节点。但容量预测不能替代硬阈值告警，通道失败率、账务差异和拒付异常仍要用明确规则触发。

商户管理平台

商户后台至少应支持：

• 交易查询：按时间、状态、币种、支付方式、通道、国家和订单号筛选；

• 支付详情：展示授权、捕获、退款、拒付和清算事件；

• 结算设置：配置结算币种、自动提现阈值，例如余额超过 5000 美元触发提现；

• 风控配置：允许商户调整部分规则阈值，例如欺诈评分从 70 调到 65；

• Webhook 管理：查看投递记录、重放失败事件、配置签名密钥；

• 对账下载：导出交易、手续费、汇率、退款、拒付和结算批次；

• 权限管理：区分财务、运营、客服、技术和管理员权限。

商户自定义风控要有边界。平台可以允许商户调低风险阈值，但不能允许商户绕过制裁筛查、监管限制或平台强制规则。

典型交易流程

下面是一笔 100 美元游戏充值的简化流程。

1. 支付请求。 用户提交 100 美元订单，商户调用 POST /v1/payments。网关生成 payment_id，用幂等键防止重复扣款。

2. 路由选择。 路由引擎根据卡 BIN、发卡国家、币种、历史成功率和通道健康度，选择 cards_us_primary，备用通道为 cards_us_backup。

3. 风控评估。 设备指纹命中历史欺诈记录，但账户历史正常。系统不直接拒绝，而是触发 3D Secure。

4. 消费者认证。 发卡行要求短信验证码或银行 App 确认。消费者完成认证后，网关继续授权。

5. 卡网络授权。 下游通过卡网络发送授权请求，发卡行返回批准。交易状态变为 authorized。

6. 捕获。 数字商品即时交付，系统在授权后立即捕获。交易状态变为 captured。

7. 待结算。 交易进入清算批次，每日 23:00 生成清算文件或调用服务商结算 API。

8. 资金入账。 境外合作银行或 PSP 处理清算，T+1 入账至商户 USD 账户。账本记录手续费和商户应收。

9. 对账。 对账系统核对网关交易、服务商报表、银行入账和账本分录。若差异小于配置阈值，例如 0.1%，进入自动平账候选；超过阈值进入人工处理。

这条流程保留了原始材料中的「用户提交 100 美元订单、路由引擎选择 Visa_Direct、触发 3D Secure、通过 VisaNet 授权、T+1 入账」这些信息点，但把通道名写成示例而非默认推荐。实际系统不应硬编码 Visa_Direct，而应通过通道配置选择。

挑战与解决方案

分阶段建设建议

跨境支付网关适合分阶段建设。

第一阶段：接入成熟 PSP。 目标是验证市场。优先接 Stripe、Adyen、Airwallex、PayPal 或目标市场本地服务商，快速覆盖卡支付、本地支付方式、基础风控和结算报表。

第二阶段：建立统一支付抽象。 目标是降低业务系统对单一服务商的依赖。统一订单、支付、退款、拒付、Webhook、错误码和通道适配模型。

第三阶段：建设动态路由和对账中心。 目标是优化成功率和成本。引入通道健康度、费率模型、路由实验、清算文件解析和账本分录。

第四阶段：强化风控和合规。 目标是支持规模化客户。建设规则引擎、模型评分、制裁筛查、KYC / KYB、拒付处理和合规报告。

第五阶段：资金和牌照能力。 目标是提升资金效率。根据业务规模评估本地账户、合作银行、持牌主体、多币种钱包、外汇服务和跨境清算能力。

这个顺序可以避免一开始就自建过重系统，也能在交易规模上来后逐步把关键能力收回内部。

小结

跨境支付网关是一套围绕交易、资金、风控、合规和运营建立的系统，单点支付接口只是入口。

它的技术难点包括高并发、资金正确性、状态可追溯、失败可恢复、风险可解释和合规可审计。支付方式覆盖越广，越需要稳定的抽象层；币种越多，越需要严谨的金额模型；通道越多，越需要路由、监控、对账和运营能力。

对游戏和电商业务来说，早期可以依赖成熟 PSP 快速上线；当市场、交易量和风险复杂度上升后，再逐步建设动态路由、多币种账户、风控引擎、账本、对账中心和商户后台。这样更符合跨境支付系统的真实演进路径。

参考资料

支付方式、网关与插件：

• Stripe Docs：Supported payment methods

• Stripe Docs：Cards

• Stripe Docs：Idempotent requests

• Stripe Docs：Webhooks

• Adyen：Payment methods

• Adyen Docs：Risk management

• Airwallex Docs：Payments

• Airwallex Docs：Cards

• Shopify Dev：Extensions for payments

• WooCommerce Developer Docs：Payment Gateway API

• Apple Developer：Apple Pay

• Google for Developers：Google Pay API

• EMVCo：EMV 3-D Secure

外汇、清算与链上结算：

• Currencycloud Developer Portal：Integration guides

• Currencycloud：Converting funds from one currency to another

• CIPS：Introduction

• Swift：ISO 20022 Standards

• XRP Ledger Docs：Cross-Currency Payments

合规与安全：

• PCI Security Standards Council：PCI DSS

• European Commission：Do we always have to delete personal data if a person asks?

• OFAC：Sanctions List Search

• United Nations Security Council：Consolidated List

• FATF：The FATF Recommendations

• Jumio：Identity Verification

工程与运维：

• Kubernetes Docs：Liveness, Readiness, and Startup Probes

• Apache Kafka：Documentation

• Prometheus Docs：Overview

• Grafana Docs：Dashboards

• Cloudflare Workers Docs

• Cloudflare Docs：HTTP/3

• Netflix Hystrix：GitHub

• Resilience4j：CircuitBreaker