万字：境外支付收单通道接入实战指南！【内附银行国际+promptpay实战案例】
都说能用图表不用文字，墨玉直接掏出了一张表格，让小明自己看。
小明：我看出来了，这里面有一些共同的规律。
【收单类通道】
- 单一通道：仅支持单个国家/地区的卡片支付，存在单笔/单日额度限制，需授权且结算周期较长。
- 聚合通道：覆盖多国及多币种支付，交易处理能力更强，但需匹配合规审查流程。
【账户管理类通道】
-
VA（虚拟账户）：通过独立虚拟子账户实现收款、付款及余额查询，支持银行账户汇款或转账，资金可自动归集主账户并批量分配子账户。
【货币兑换类通道】
- 换汇通道：无地区限制，支持多种货币对兑换，仅限同主体账户操作，可选择即时或延迟交割。
- 结汇通道：支持主流货币兑换人民币，需申报且存在额度限制，部分场景可突破额度限制。
【资金流转类通道】
- 发卡通道：面向特定地区用户发行支付卡，支持线上无卡交易，充值来源限于账户余额或同名银行转账。
- 代发通道：支持约定地区/币种的代付服务，通过汇款或转账实现充提，T+1完成结算且额度较高。
）
）
）
）
）
）
）
）
【接口文档】中国银联银行卡联网联合技术规范V2.1（跨境卷）
【应用范围】用于银联卡的跨境线下支付场景（POS场景）
【文档结构】1.交易处理说明（联机交易的处理流程）
2.报文接口规范（报文接口+交易报文的结构、报文格式以及报文域说明）
3.文件接口规范（文件交互流程、文件内容说明、文件格式说明）
4.数据安全传输规范（数据传输安全要求、密钥管理方法和加密方法）
5.通信接口规范（通信链路的选择、接入方式选择、接入设备的要求和通信协议的规定
6.附录（标准代码、交易种类、交易信息关联、清分对账、标准版本转换）
2.1.2 交易类型一览
【交易类型分类】：可分为请求类、通知类。
又从是否需要卡组织转接又可以分为需要转接和不需要转接两种。
【请求类交易定义】：请求类交易从交易的请求方（如：受理方）发送至接收方（如：发卡方），接收方收到后直接给予交易批准或拒绝的应答。
【通知类交易定义】：发送方将已采取动作通知接收方的交易，只要求响应不要求批准。通知类交易可由受理方、发卡方、CUPS发出。
【说明】
1.预授权+预授权完成是单信息模式，授权+结算文件则用于双信息模式。
2.MOTO交易是指通过电话、信件、邮件等非面对面形势委托商户发起的交易。
3.结算通知是双信息转单信息时，CUPS将双信息请求转发给单信息发卡方的，对已批准的预授权的资金结算通知。双信息模式下入网的机构没有对账通知和结算通知。
【请求类交易流程】：需要转接则先依次传递信息，而后再反向依次应答。不需要转接则直接应答成功或失败或处理中。
【通知类交易流程】：需要转接则先应答，再转接传递消息。不需要转接则直接应答收到即可。
【定义规范】：ISO 8583定义+其它域由CUPS自定义
【报文组成】：分4部分，分别是报文头、报文类型标识符、位图、报文域。
part01【报文头】：主要记录报文的长度、路由、批次号等。
part02【类型标识符】：定义了报文一般性分类，比如是金融类报文还是管理类报文。
part03【位图】：位图定义了哪些报文域会出现在报文中。位图一定义域2到域64，位图二定义域66到域128。
pat04【报文域】：由2-128域组成，每个域可以视为一个字段，代表独特的含义。
下面我们4部分一个个详细说说：
part01【报文头】
报文头：报文头一共46个字节，所有域都是必填。
备注：1个字节（byte）=8bit=8个二进制数字。
part02【类型标识符】
也就是说当你发起一笔预授权类、消费类交易，报文的类型标识符就是01XX，如果是退货（联机）那类型标识符就是02XX 。以此类推来区分这笔报文的交易类型。
part03【位图】
主位图：主位图由8字节构成，一共64个二进制数字，除了第一位（第一位用来说明有没有位图2），其他每一位和2-64域相对应，即和域2到域64相对应，0表示该域不出现在报文中，1表示在报文中出现。
位图二：和主位图相同，位图二也由64个二进制位(八字节)构成。可以认为位图二是主位图的扩展，和域66到128相对应。报文域65不存在。
part04【报文域】
一共有128个域，每个域你可以理解为一个报文里的字段，每个域有不同的含义，以上图里是比较重要的域含义解析。
知道了含义，后面对接就好办了。
2.1.5 文件交互传输流程
CUPS与入网机构之间的文件传输
文件存取方式：流传输方式、SFTP方式。
文件加密算法：DES算法，密钥长度8字节。
传输连接方式：采用短连接的方式。也就是双方建立一条全双工的连接，连接建立后，双方在同一条连接上收发请求和应答。当文件传送完成后，双方关闭连接。
2.1.6 文件的种类和命名规则
IFDYYMMDD??ICOM/ICOMB，面对一个这样的文件名，你是不是很懵逼？
这是个啥，这个文件是干啥的？如何去解读？有这一张图你就明白了。
跟银联有关的交互文件常用的有以下这些(以下CUPS指银联）：
|
文件名称 |
说明 |
|
IFDYYMMDD??ICOM/ICOMB |
机构作为发卡方/二级发卡方的一般交易清算明细 |
|
IFDYYMMDD??ACOM |
机构作为受理方的一般交易清算明细 |
|
IFDYYMMDD??IERR/IERRB |
机构作为发卡方/二级发卡方的差错清算明细 |
|
IFDYYMMDD??AERR |
机构作为受理方的差错清算明细 |
|
IFDYYMMDD??ALER |
基于PBOC借贷记标准的脱机消费差错交易受理方流水格式 |
|
IFDYYMMDD??ILER |
基于PBOC借贷记标准的脱机消费差错交易发卡方流水格式 |
|
IFDYYMMDD??FCPB |
机构（二级机构）的收/付费明细，不区分受理和发卡 |
|
IFDYYMMDD??FCP |
不区分受理和发卡 |
|
IFDYYMMDD??ALFEE |
机构作为受理方的品牌费明细 |
|
IFDYYMMDD??ILFEE/ILFEEB |
机构作为发卡方/二级发卡方的品牌费明细 |
|
IFDYYMMDD??ISTI |
机构作为发卡方的即时代授权交易明细 |
|
IFDYYMMDD??ISTIFEE |
机构作为发卡方的代授权费用文件 |
|
IFDYYMMDD??ALOD |
机构作为受理方的电子现金的圈存类交易明细 |
|
IFDYYMMDD??ILOD |
机构作为发卡方的电子现金的圈存类交易明细 |
|
IFDYYMMDD01ACOMPOS |
机构作为直联收单方的一般交易明细 |
|
文件名称 |
说明 |
|
OFCYYMMDD5?C |
受理机构传送到CUPS的银联卡跨境业务交易清算文件 |
|
IFCYYMMDD5?R |
CUPS传送到受理机构的银联卡跨境业务交易拒绝文件 |
|
IFCYYMMDD51C |
CUPS传送到受理方的成功清算的银联卡跨境业务交易文件 |
|
IFCYYMMDD51S |
CUPS传送到受理机构的银联卡跨境业务交易统计文件 |
|
IFCYYMMDD99C |
CUPS传送到发卡方的成功清算的银联卡跨境业务交易文件 |
|
IFCYYMMDD99S |
CUPS传送到发卡方的银联卡跨境业务交易统计文件 |
|
IFCYYMMDD99CB |
CUPS传送到二级发卡方的成功清算的银联卡跨境业务交易文件 |
|
IFCYYMMDD99SB |
CUPS传送到二级发卡方的银联卡跨境业务交易统计文件 |
与银联交互，常见的有以下几种秘钥：
PIN：个人银行卡的密码。
PIK: 即PIN key，用于加密PIN的密钥。
MAC(message authentication code): 报文鉴别码，是消息来源正确性鉴别的数据
MMK(member master key):指在银行卡安全体系中，分配给成员机构的密钥加密密钥，用于加密下一层密钥受主密钥(MK)加密保护。
MAK：即MAC key，用于生成交易报文合法性验证数据(MAC)的密钥。
工作密钥：指加密PIN和计算MAC的密钥，包括MAC密钥（MAK）和PIN密钥（PIK）。
HSM（hardware and security module）：硬件加密机，对传输的数据进行加密的外围硬件设备，用于PIN的加密和解密、验证报文和文件来源的正确性以及存储密钥。
2.1.9 密钥的加解密流程
加密流程细说的话非常复杂，我们挑一个PIN的加解密过程让大家体会下一个秘钥是如何流转的：
上图中终端机具、受理方、CUPS（银联） 以及发卡方之间的加密解密信息为:
1 :终端机具输出PIN的密文
2:受理方用与终端机具约定的密钥解密，
3 :受理方用与CUPS约定的密钥加密
4 :受理方输出PIN的密文
5 :CUPS与受理方约定的密钥解密
6 :CUPS用与发卡方约定的密钥加密
7 :CUPS输出
8 :发卡方用CUPS约定的密钥解密
9 :发卡方用与发卡行约定的密钥加密。
10:发卡方输出PIN的密文
2.2.1 概况介绍
【背景介绍】PromptPay是泰国政府积极推动的数字钱包支付系统，于2017年1月正式推出， PromptPay支持大多数的泰国银行。本次接入的PromptPay的通道方是泰国最大的银行之一，其为PromptPay背后的核心成员之一，相当于直连钱包终端。
【市场分析】截至2021年7月，PromptPay的注册用户已达6220万，覆盖了泰国89%的民众（泰国总人口约7000万人）。泰国客户平均每个月使用PromptPay进行近8亿笔交易。
2.2.2 PromptPay支付流程介绍
1.泰国用户在购物时选择PromptPay为支付方式。
2.商户调用我方，我方自行按照通道给的规则生成收款二维码，并传输给商户展示。
3.泰国用户用手机银行APP扫码识别并完成支付。
4.通道发支付确认,我方确认交易（有这一步是因为码是我方生的，所以通道来要确认下是否是我方发起的交易）。
5.通道发送异步支付结果通知，我方异步通知商户支付结果。
6.如果未收到通知，则通过查询接口向通道查询。
生成QR、订单确认接口、支付结果通知接口、订单查询接口
注：常见的接口其实还有下单接口、退款接口、对账单获取接口等。
本案例中我方无需下单（因为二维码可以自己根据通道给的规则生成）、并且通道不支持退款，对账单只能通过web端后台手工下载获取，故以上接口未列出。
2.2.4 生成QR
生成QR是根据通道提供的规则，由我方自己生成。
生成QR所需要的字段如下：
1.支付方式类别（指支付方式的本身属性）
例如银行卡支付、电子钱包支付、运营商支付、线下支付、网银转账、银行转账、预付卡支付等等。
2.所属渠道（指支付方式从哪个PSP接入的）
如果是转接的一般名称为聚合网关名称（如adyenstripedelocal等等，如果是直连通道则名称一般是支付方式本身（例如VISA、Truemoney等等）。需要注意的是，不同的渠道可以接入同一个支付方式，构成主备通道。
3. 支付方式名称（一般是支付方式本身的名称）
4. 通道状态（即通道是否处于上线状态）
5. 通道优先级（用来区分同一支付方式多条通道都是上线状态时，谁的路由优先级更高）
6.支持的国家地区（该要素一般在发起支付时决定是否调用该通道）
有了这些分类方法，再结合业务场景，就可以建立起一套通道管理系统啦
