惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Blog — PlanetScale
Blog — PlanetScale
B
Blog
A
About on SuperTechFans
大猫的无限游戏
大猫的无限游戏
爱范儿
爱范儿
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
H
Help Net Security
H
Hackread – Cybersecurity News, Data Breaches, AI and More
博客园 - 三生石上(FineUI控件)
有赞技术团队
有赞技术团队
酷 壳 – CoolShell
酷 壳 – CoolShell
WordPress大学
WordPress大学
IT之家
IT之家
D
Docker
Google DeepMind News
Google DeepMind News
罗磊的独立博客
T
The Blog of Author Tim Ferriss
aimingoo的专栏
aimingoo的专栏
博客园 - 叶小钗
Recent Announcements
Recent Announcements
阮一峰的网络日志
阮一峰的网络日志
D
DataBreaches.Net
博客园 - 司徒正美
Engineering at Meta
Engineering at Meta

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
一文看懂跨境收单流程
唐僧扫塔 · 2025-08-25 · via 人人都是产品经理

你是否也曾在“收单失败”“结算延迟”“合规风险”中迷失方向?本篇文章将用一张流程图、一套关键概念,带你快速掌握跨境收单的核心机制。

跨境收单(Acquiring/Payin)是指一个国家的商家,通过收单服务商,接受来自另一个国家或地区的消费者支付的信用卡、借记卡或其他本地化支付方式的过程。跨境收单解决了商家“出海卖东西,怎么收钱”的问题。

由于卡支付(Debit/credit card或Cards)在全球范围内是最主流、占有率最高、交易流程最复杂的支付方式,本文主要基于国际卡(如VISA、MasterCard、American Express等卡组织发行或授权的银行卡),并辅以本地支付方式(Alternative payment methods/APM,包括电子钱包、银行转账 、现金支付、先买后付等)的交易及结算信息流,全面讲解跨境收单的主要流程。

图1 卡交易主要流程

* 3DS是基于一定的风控或合规要求而开启的,并非所有卡交易都必须经过该步骤

身份验证Authentication

身份验证主要指3DS,通过持卡人密码、短信验证码、生物识别等方式实现交易身份确认,有效防止账户盗用与非授权交易。由收单行或卡组织根据目标市场合规要求、商品风险级别等因素决定交易是否开启3DS。

对于各参与方来说,身份验证与交易授权分别属于不同的独立信息交互系统。

图2 3DS验证流程图(实时)

*此处,收单行是指卡组织的主会员,某些品牌商家或交易量大的商家可能会直接对接收单行,而无需对接三方支付服务商。

3DS流程步骤:

  1. 持卡人输入卡支付信息。
  2. 商家向收单行发起3DS验证请求。
  3. 收单行(3DSServer)进行风控校验、判断是否满足豁免,然后发送请求至卡组织。
  4. 卡组织DS(DirectoryServer)路由验证请求至发卡行。
  5. 发卡行ACS(AccessControlServer)进行风控校验、是否需要发起challenge验证流程(例如,短信验证码OTP/App应用确认/生物识别);如需challenge验证或只支持0版本,将会触发App端OOB或返回一个网址url,需要商家展示该url在网页端展示给持卡人。
  6. 持卡人在商家网站上所跳转的发卡行页面输入短信验证码,或登录银行App确认身份,完成验证。
  7. 发卡行ACS返回验证结果(CAVV/ECI)至卡组织。
  8. 收单行收到卡组织返回的结果后,携带认证数据发起支付授权。

交易授权Payment authorization

交易授权是指商家在完成一笔销售交易前,向消费者的发卡行发起请求,以确认该支付卡有效、账户状态正常且卡内有足够信用额度或账户余额来支付该笔交易的过程。

简单来说,它就是 “预先批准” 或 “资金预留” 的步骤。它确保了交易的安全性,保护了商家、持卡人和银行各方的利益。

图3 信用卡交易授权流程图(实时)

*此处,收单行是指卡组织的主会员,某些品牌商家或交易量大的商家可能会直接对接收单行,而无需对接三方支付服务商。

卡交易授权主要参与方及步骤:

  1. 持卡人/消费者在网站或App收银台页面,选择对应的支付方式,发起支付。
  2. 商家将收集的订单及支付信息发送给上游收单行/支付服务商/网关
  3. 收单行/支付服务商/网关接收到支付请求后,首先进行风控检查,随后将数据加密并路由至对应的卡组织。
  4. 卡组织将交易信息发送给发卡行进行授权。
  5. 发卡行对交易进行校验(如,卡状态、卡余额、限额、欺诈规则等),判断授权通过或拒绝,并将结果返回给卡组织。
  6. 卡组织将授权结果中继返回给收单行。
  7. 商家接受到收单行返回的授权结果后,在页面上展示订单状态。
  8. 持卡人在完成支付后,会收到交易确认信息。如果交易被授权,发卡行将在一定时间内结算款项给收单行,最终到达商家账户;若交易被拒绝,持卡人需根据提示重新选择支付方式或联系发卡行处理。

与卡支付相比,本地支付方式交易授权流程更简单。

图4 本地支付方式交易授权流程

清算Clearing

清算是指发卡行、卡组织、收单行等相关金融机构,在每天结束时或约定的cut-off时间,批量对交易信息(如金额、币种、状态、商家、时间等)进行数据交换,发现差异、矫正差异并进行数据对齐的过程。清算过程中,若发现数据不一致或异常交易,相关机构会及时进行调查与修正,以确保账务的准确性与完整性。该阶段不仅是对交易数据的集中处理,更是对支付链条中各方权益的保障。通过严格的清分流程,每一笔交易的资金流向都能被精准追溯,从而为后续的结算奠定坚实基础。

结算Settlement

结算是指发卡行将资金(扣除手续费interchange fee后)转账至收单行,收单行按照合同约定的结算条款及周期,在扣除对应手续费后,转账至商家指定的银行账户的过程。结算流程非实时、异步处理,通常需要几个工作日。此处涉及汇款remittance的相关知识,后续补充。

图5 结算流程图(非实时)

Stakeholders主要参与方释义

  • Cardholder/Customer持卡人/消费者是支付链条的发起者,提供有效的支付信息以完成交易。此外,持卡人可与发卡行协作,解决交易中出现的争议或问题。
  • Merchant商家作为支付流程中的核心参与方,负责提供商品或服务,并通过支付系统完成与消费者的资金交易。商家需与收单机构签订协议,遵守相关支付规则与合规要求,确保交易数据的真实性、安全性与完整性。
  • Gateway/PaymentServiceProvider网关或三方支付服务商是连接商家与金融机构的关键桥梁,负责处理支付请求、验证交易信息,并将资金流转至商家账户。它们需具备高效稳定的系统架构,确保交易的实时性与可靠性。与此同时,支付服务商还需采用多重加密技术与风控机制,以防范欺诈行为与数据泄露,保障交易链路的安全闭环。
  • AcquiringBank(或Acquirer)收单行是支付链条中的关键金融机构,与卡组织、发卡行进行交易数据交互和清结算,负责为商家提供专业的支付解决方案、风险控制措施、资金结算服务,同时承担合规审查、交易风险管理的责任,处理多币种结算、汇率转换及跨境清算等复杂流程,确保交易符合卡组织及各国监管要求。
  • CardNetwork(或Scheme)卡组织是支付生态系统中的核心枢纽,负责制定支付标准与交易规则,协调发卡行与收单行之间的业务对接,处理全球范围内的交易清算与结算事务,承担风险管理的重要职责,保障支付网络安全稳定运行。
  • IssuingBank(或Issuer)发卡行负责对每笔交易进行授权,监测交易行为、防范欺诈,确保持卡人的账户安全,及时响应交易争议与投诉;并为持卡人提供清晰的账单与交易记录,准确披露跨境交易中涉及的货币兑换与手续费。

在整个支付流程中,卡组织负责信息的准确传递,收单行与发卡行则分别承担商家与持卡人端的对接工作。各方通过紧密协作,确保交易高效、安全完成,为用户提供顺畅的支付体验。

本文由 @唐僧扫塔 原创发布于人人都是产品经理。未经作者许可,严禁转载、搬运以及二创,禁止任何人抓取本文内容,用于AI内容的输出。

题图来自Unsplash,基于CC0协议