大家好，我是讯享网，很高兴认识大家。

摘要

老王有个杂货店，起初只是经营食品、饮料、玩具，做的都是些大众品牌。老王原本以为自己的商品挺全的，但经营一段时间后发现，他的商品并不能满足所有客户的需求。下面是老王的小本本上记录的几个客户问题，以及老王自己新的问题和新的需求。

• 产品种类无法满足客户，有些客户要买小家电甚至大家电，老王杂货店里经营的品类只有食品、饮料、玩具，因此没法满足这些客户的需求。
• 产品品牌不满足客户，有些客户希望购买中萃方便面、白象方便面，老王的杂货店里只有康师傅和统一，没有其他牌子。
• 产品型号不满足客户，有些客户需求，有客户要买康师傅卤肉面，老王的杂货店只有康师傅红烧牛肉面，甚至老王的供应商李三都没有这个口味的面，但是隔壁村的赵四有。
• 产品产地不满足。有的客户想买国外的产品，甚至还点名要国外的某某产品，比如小老板的海苔。老王的店里都是本土货，满足不了这些需求。
• 客户的付款能力要求，老王有很多企业客户，不管是老王和客户之间，还是老王和供应商之间，一般都是后付月结。以前到了时间点，老王就得挨个给供应商打款，但现在商品种类越来越多，供应商越来越多，老王希望能够给每个供应商发张卡，他往卡里充钱，到期了供应商自动扣钱就行，给自己减少点负担。
• 供应商服务标准的要求，随着生意越做越大，老王对供应商的要求也越来越多。有时候要货要得急，有时候要的货量大，有时候要货的账期长，有时候要货便宜，有时候甚至还要供应商承担售后，对坏的、有问题的货包碎包退，反正最好供应商供货稳定、货源充足、货价便宜、送货快、账期长。

老王的故事其实类似于本博文需要讲的支付通道的问题。我们看看将老王所遇到的问题与要求对应到支付中是怎么样的。

• 种类不满足对应支付方式不满足，支付方式有信用卡支付、借记卡支付、网银支付、账户支付等，这些方式可以归为两类：卡基和账基。卡基是直接输入卡号、有效期等卡要素进行支付的方式，比如信用卡支付、借记卡支付等。卡基是支付最初的形态，无论是早期线下刷卡还是网银都属于卡基。账基是以账户为基础的支付方式，一个账户可以绑定多张卡。微信支付、支付宝都属于账基。如果一个商户一直沿用原有的收银台或者POS机，只支持卡基，不支持微信支付、支付宝，那么他就会越来越落后，甚至极端情况下，他可能无法收款，生意难以开展，毕竟现在用现金支付的人已经成为小众了。就跟老王一样，早期卖食品、饮料可以，而现在客户有更高的要求，他必须拓宽品类。
• 品牌不满足对应支付品牌不满足，同一种支付方式可以有多个支付品牌，比如信用卡支付可以用中国工商银行信用卡、中国农业银行信用卡，第三方支付或账户支付有微信支付、支付宝、京东等各类钱包支付。支付品牌从主流的到小众的、从全国的到地方的都有，一个平台丰富支付品牌的过程就是健壮自己的支付能力的过程。要先支持交易量大的银行，比如全国十几家股份制银行，再支持交易量小的银行，比如各地城商行;先接入第三方（如连连支付等)，迅速支持尽可能多的支付品牌，再与各家银行建立直连。这就和老王的杂货店一样:先做大家耳熟能详的品牌，再根据自身情况做一些小众品牌;先找比较大的批发商迅速补齐和丰富品类，再想办法直接联系厂家，降低进货成本。
• 型号不满足对应卡BIN不满足，每一张银行卡都有一个卡号，每个卡号都含有发卡行标识代码（Bank Identification Number，BIN)，也就是我们俗称的卡BIN，一般由6位数字组成。( 2014年年底，国际标准组织将BIN由6位数字调整到8位数字。）比如某卡号前6位是,这就是卡 BIN，是招商银行借记卡的卡 BIN。对于招商银行信用卡这样的支付品牌，根据合作渠道、发卡组织、发卡种类等的不同会有不同的卡BIN，而一个支付通道往往会由于没有处理权限或未及时更新等，不能覆盖全部的卡BIN。遇到上述问题，要么提示用户不支持，要么通过找别的支付通道健壮自己的支付处理能力进行支持。就像老王的杂货店一样，客户要康师傅卤肉面，老王没有，老王的供应商李三也没有，这时老王可以告诉用户自己没有这种面，但为了做成生意，老王必须找隔壁村的赵四进这个口味的面。
• 产地不满足对应内外卡通道不满足，同一家银行发行的卡有内外卡之分，简单来说，国内发行的卡叫作内卡，国外发行的卡，无论是国内银行发行的还是国外银行发行的，都叫作外卡。要用国外卡在国内支付，或者用国内卡在国外支付，就需要国际支付通道进行收单，否则就可能无法支付。就像同样是百事可乐，客户要的是海外进口商品蓝色网红版，但老王给一瓶国内生产的黑色百事可乐，客户肯定不要，这生意就没法成交。
• 支付能力的要求对应付款能力的要求，同一张卡有多种支付能力。支付能力既包括交易类型，比如同样一张卡有消费、预授权、代扣、代付、鉴权等不同的交易能力，又包括产品特性，比如有的卡不需要CVV，不需要银行发短信验证码，可以免密或免Token进行支付，有的则不能免密。此外，支付能力也包括交易币种，对于同样一张银行卡，有人要用人民币交易，有人要用美元交易，比如在中国用人民币作为交易币种，在美国旅游或“海淘”时用美元作为交易币种，不同的人在不同时间、地点对交易币种的要求不同。对于同一张卡，不同的生活场景里我们会用到它的不同能力。各类实名制要认证或绑定银行卡时，用的是鉴权能力;住酒店时先预付并冻结银行卡金额，用的就是预授权或者扣款＋退款能力;打完车平台自动扣款，用的就是快捷支付能力;每年到时间了自动划扣保险费用，用的就是代扣或快捷支付能力;公司每个月发放工资，用的就是银行的批量代付能力﹔等等。同一张卡在不同场景里应用不同支付能力，这样的案例还有很多。就像老王开店要向供应商打款一样，从主动支付到自动扣钱用的是同一张卡，但是用到的卡能力不一样。
• 支付通道能力的要求对应衡量供应商服务标准版的要求，衡量一个支付通道处理能力的因素有很多，比如单单一家银行就有各类借贷记卡、各类卡等级、各类交易类型,而且即使这些属性都一样，不同的支付通道对于它们的处理能力也是不一样的。比如额度方面，有的支持大额交易，可以到单笔10万元、20万元，有的只能到1万元;限额方面，有的无论单笔、单日还是单月都不限额，有的就要限制单笔5000元、单日10000元;结算时效方面，有的是实时结算，有的要D+1（自然日第二天）结算，有的则要T+1(工作日第二天）结算;风险拒付率方面，有的对于客户拒付风险交易认定是不赔偿的，有的则是包赔的;费率方面，有的按笔收费，有的按百分比收费，有的是阶梯收费，有的是固定费率;还有接入方式是专线还是公网等安全性问题。

以上内容就和老王做生意一样，每家供应商都有自己的强项或者优势。老王要考虑的是如何结合自身实际情况，充分利用供应商的特性，把这些作为衡量供应商质量的标准:额度的要求对应老王对供货量的要求;结算时效的要求对应老王对账期的要求;风险拒付率的要求对应老王对破损、变质商品包退包换的要求;费率的要求对应老王对供应商批发价的要求;专线还是公网对应老王有没有供应商绿色通道。不同的通道特性在.不同场景的最优际准是不一样的。因此老王需要从不同牲度考缝不同的供应商‘实现他的最优解。

一、支付通道结构

老子说:“九层之台，起于累土。”通道支付的重要性相当于是的蔬菜的原始材料，构建房子的基石。如果没有通道，再好的支付系统也是无法应用的，如果解决不了通道，再好的支付的产品也是两眼瞎，给不出好的解决方案。平时大家在微信、支付宝和各类电商网站上进行购物支付时，看到的基本是以下这个界面。从图中，可以看得到的银行和看不到的通道构成了支付通道结构，这个结构包括支付方式、支付品牌、支付通道和支付产品。

讯享网

1.1 支付方式

支付方式是指针对支付种类特性表现的一种归类，也是对自身内部支付产品的包装，即按外部商户的需求将支付产品打包成一种支付方式提供给外部商户。例如信用卡支付，作为内部支付产品,可以划分成信用卡MOTO、信用卡快捷、信用卡代扣。常见的支付方式有信用卡支付、储蓄卡支付、网银支付、第三方支付等。

举个例子，你去超市买薯片、可乐、脸盆，买薯片得去零食区，买可乐得去饮料区，买脸盆得去日用品区，零食、饮料、日用品这些类别就相当于支付方式。

1.2 支付品牌

支付品牌是指支付方式下的具体银行品牌或第三方支付品牌。支付方式下可以有多个支付品牌，它们是映射关系，如上图所示的那样。支付品牌由支付通道支持，支付品牌与支付通道是多对多的关系，既可以多个支付通道支持同一个支付品牌，也可以一个支付通道支持多个支付品牌。

比如信用卡支付，这样的支付方式可以有工商银行信用卡、建设银行信用卡、交通银行信用卡等多个支付品牌。建行直联通道、银联通道这两个支付通道都支持建设银行信用卡;银联通道除了支持建设银行信用卡，还支持农业银行信用卡、民生银行信用卡等支付品牌。常见的微信支付、支付宝也都是支付品牌。

举个例子，就像去超市买东西的时候，方便面有康师傅、统一、日清等品牌，这些品牌就相当于支付里的.工行、农行等支付品牌。

1.3 支付通道

支付通道是指支付品牌背后提供支付受理能力的具体提供方，比如工行直连通道、银联通道、连连支付等。

举个例子，你去超市买东西的时候看到的康师傅方便面是品牌，至于是江西的供货商还是江苏的供货商你并不知道，但商家知道，那些供应商就如同支付里的通道。对于支付通道，物理链路不可拆分的，称为物理通道;物理链路可以按照接人渠道、接入商户、不同品牌、实际用途、价格等因素拆分成不同配置规则的，称为逻辑通道。

1.4 支付产品

支付产品是指把通道根据不同特性与维度（比如渠道、功能、价格等）归类并包装成具有一定特性的商户产品，如信用卡快捷产品、信用卡MOTO产品、鉴权产品等。

要特别注意支付方式与支付产品的区.别、 比如信用卡支付这样的支付方式，由于通道特性不一样，有了信用卡非免密支付产品和信用下卡免密支付产品，两者虽然支持的支付方式都是信用卡，但却是两个不同的支付产品。

支付方式包含支付品牌，支付品牌由支付通道支持，支付通道是颗粒度最细的维度，它根据特性又被包装成不同的支付产品。

二、支付通道的分类

在介绍通道之前，我们先来分析一下出差住酒店和买房。出差的时候住酒店，需要出示证件，前台确认了才可以入住;下次再来的时候,还是要走一遍这个流程，总之不管去过多少次，都要出示证件、登记人住、退房。我们与酒店只是一次性:的契约关系。而买房兹事体大，政府得先看你是否符合购房条件、审核各种材料、看看有没有缴税、有没有缴纳房屋维修基金等，全部都确认没问题了，才给你房本。而一旦领了房本，拿了钥匙，只要不卖房，这房你随便住。我们与房手是长期契约关系，说的其实就类似于支付里快捷与非快捷、客户被动支付与主动支付的关系。

常见的支付通道分类是快捷类通道与非快捷类通道。为了好理解和严谨起见，我们用无磁有密类通道来代表非快捷类，来看看这两类通道各自的支付流程是怎样的。

2.1 非快捷支付与支付流程

采用无磁有密类进行支付时，可以直接支付，无签约鉴权流程。具体支付流程如下。

1. 收集卡信息，比如卡号、姓名、证件类型、证件号、手机号、短信验证码、密码等，并将这些信息提交给支付通道。如果是信用卡，还可能会验证有效期、CVV。
2. 通道验证信息是否正确后，返回扣款结果。如果客户提交信息验证正确，则扣款成功(不考虑其他报错)﹔如果信息不正确，则扣款失败。验证信息不正确的原因有很多，比如卡号不对、姓名不对、证件过了有效期、证件号码不对、手机号不对、短信验证码不对或者失效、密码不对等情况。
3. 客户再次支付时，还是需要完整提供通道所需的卡信息。

注意：银行出于对客户银行卡密码的保护，除了银行自身体系或App，并不会让商家或支付平台处理和接受客户银行卡密码，医此现在很少用无磁有密类．几乎都是无,磁天,密类,快捷类通道不需要用到密码和磁条信息，严格来说，也算无磁无密类，所以拿无磁有密类与快捷对比更好理解，也更为严谨。

2.2 快捷支付与支付流程

快捷类支付需要先签约再支付，具体流程如下。

1. 签约流程:签约要求先验证卡信息，比如卡号、姓名、证件类型、证件号、手机号、短信验证码等。如果是信用卡，还可能会验证有效期、CVV。
2. 通道验证信息正确后，生成协议号或者Token并反馈给商户。
3. 支付流程:商户发起交易并使用协议号或者Token直接扣款。
4. 通道将支付结果返回给商户。
5. 客户再次支付时，商户或者平台只凭协议号或者Token就可以扣款，客户不需要参与。

对比两类通道的支付处理流程，我们可以发现它们有很多差异，很像生活里出差住酒店与买房住自己家。

• 环节不间。非快捷类只有支付这个流程;快捷类支付需要先签约再用协议号支付，有两个流程。非快捷类流程就像在外出差住酒店，核实身份证就好，简单、不麻烦，但每次入住的时候都得要。快捷支付流程就像买房一样，必须先签约再支付，签约成功，凭借Token或者协议号再进行支付。买房必须提交各种材料，验证符不符合买房资格，符合才能拿房本，而交了房拿到钥匙，回家就再也不需要任何证明了，有钥匙就能开门。
• 要素数量不同。如果遇到具体的通道,查看要素会发现，快捷类支付几乎需要全部要素，非快捷类支付需要的要素往往很少，比如卡号、有效期就行，很少有要全要素的。还是拿出差住酒店和买房举例，出差住酒店，提供身份证就行，但是每次都要提供;非快捷类需要提供的信息也很少，但每次支付都要提供。买房就不一样，得提供各种材料、缴纳税和维修基金，所有条件都具备了才能领本拿钥匙，有了钥匙就可以随时进家门;对于快捷类支付，签约的时候往往要的是全信息，一旦验证通过，以后就拿协议号支付就行。

2.3 支付通道分类

按照用途、支持对象、支持形式、支持发卡行地区，可以将支付通道进行如图下所示的分类。下面来分别来介绍各种分类。

根据用途，支付通道可以分为出款通道、入款通道和鉴权通道。

• 出款通道：出款就是出钱，能够实现资产所有人支付款项给他人的通道。出款通道有代发（代付）类、转账类，主要应用于提现、发工资、退款等场景。
• 入款通道：入款就是收钱，能够实现他人把钱付给资产所有人的通道。入款通道有很多类型和形态，如代扣、MOTO、无磁无密、网银、快捷、转账、POS机支付、扫码支付、账户支付、近场支付(各类名词解释见1.5节)。其应用场景很多，网上支付、扣款、信用卡代扣、水电煤代缴等都是。
• 特权通道：与支付无关，只验证信息是否正确的通道。卡信息验证、身份信息认证、OCR验证，比如账户的实名认证、银行卡的绑定等场景都需要用到鉴权通道。

根据支持对象，支付通道可以分为对公支付和对私支付。

• 口对公支付：向企业账户或资产发起扣款或付款的支付行为，包括企业网银、企业账户代扣、企业转账等。
• 对私支付：向个人用户账户或资产发起扣款或付款的支付行为，包括银行卡支付及微信支付、支付宝等第三方个人账户支付。

根据支持形态．支付通道可以分为卡基支付和账基支付，其中，账基支付是卡基支付的高级阶段。卡基支付和账基支付，卡基支衬:以卡片作为支付工具、通过媒介提供并验证卡信息进行支付的行为，媒介包括POS、闪付、电话支付、线上收银台等载体。账基支付：以账户作为支付工具、提供并验证账户信息进行支付的行为，账户包括银行账户、钱包账户等账户种类。

卡基的特性如下：

• 卡基的核心是卡号;
• 资产存储在卡号上;
• 支付媒介不仅有刷卡，还包括POS、闪付、电话支付、网银支付、线上无磁无密支付等通过卡信息进行支付的载体。

账基的特性如下：

• 账基的核心是实名认证＋密码验证，密码可以是密钥、数字、指纹或短信;
• 资产存储在账户里;
• 账基支付既可以使用余额，也可以使用银行卡等各种资产，常见的有微信支付、支付宝。

根据支持发卡行地区的不同，支付通道可以分为内卡通道和外卡通道。

内卡通道是指支持受理境内发行的银行卡交易的通道。内卡有以下特征:

• 发卡行为中华人民共和国境内银行（包括外资银行);
• 卡本币为人民币;
• 卡组织为银联。

外卡通道是指支持受理境外发行的银行卡交易的通道。外卡有以下特征:

• 发卡行为境外银行或者中资银行的境外分支机构;
• 卡本币为外币;
• 卡组织为银联、Visa、Mastercard、JCB等。

必须特别说明的是，内卡和外卡不是泾渭分明、非黑即白的，有的卡在某种情况下算作内卡，而换种情况就是外卡。比如中国境内发行的招商银行Visa 单标卡，从卡的发卡行或者卡组织看既可以视为招商银行，也可以视为Visa 卡。如果招商银行直连通道作为支付服务提供商自己受理自己本行业务，那么肯定就视为招商银行卡，算作内卡;如果是海外支付服务商受理这种卡，那么会视为Visa 卡，算作外卡。

2.4 账基支付起源

账基支付是怎么诞生和发展的呢？支付领域有这样一句话:“控制信息流以控制支付流．控制支付流以控制资金流：获得网络接入权胜过资本所有权；获得数据投入量胜过资金投入量。” 账基支付诞生于第三方，大家最常用的也是第三方，比如微信支付、支付宝。

起初，第三方做的都是银行不太重视的中间收人业务，交易信息过把手，线下铺POS，线上做网关，作为支付网关把商户和客户卡信息抛送给银行通道，赚些手续费，赚银行看不上的这些钱。后来，交易多了，信息也多了，第三方开始想着围绕这些信息做些数据分析（也就是后来说的大数据分析)，分析评估用户交易的风险程度用于风控。这个时候还没有征信体系，第三方分析用户的购物信息、交易金额、交易地点，主要用于精准营销等领域。

再后来,幕后的人不甘心一直在幕后，希望将交易、用户、资金都沉淀到自己的平台上。于是第三方开始做起自己的账户体系，有企业账户，也有个人账户，里面提供充值、扣款、查询等功能，这也就是我们说的账基支付了。

但是怎么让用户用你的账户呢?支付领域有句话是“做支付先要做收单”。大家在开始的时候，围绕账户做应用服务，比如水电煤交费、信用卡还款、电话费充值等;后来玩法变了，直接人股或收购有流量的线上线下公司，要求其只能接入自己的支付或者把竞品支付隐藏或置后等，比如饿了么对于微信支付的处理方式，京东不支持支付宝等。再后来，账户做起来了，用户也多了，第三方开始建设更多应用场景，从支付到理财、贷款、保险，甚至到虚拟银行、实体银行的建设。支付的每一次拓展都改变了这个行业对支付的认知。

从第三方支付这些年的发展历程我们看到，起初大家都是用银行卡进行支付的，也就是卡基支付，后面才一步步发展出现在的账基支付。账基支付要求对账户进行实名认证，可以绑定多张银行卡，有各种各样的应用。

账基支付的意义主要体现在以下几方面。

• 口丰富了支付手段,简化了支付工具。账基支付是卡基支付的高级阶段，是支付领域的一次飞跃，给支付带来了翻天覆地的变化。账基支付不仅支持卡基支付，还支持积分、余额等多种支付方式。过去用户往往要带多张银行卡，而有了账基支付，现在他们只需要用一个账户绑定这些银行卡。
• 更加了解川户深度分辑用户行为、做好各类画像的数据准备.T.作。卡基支付的时候，同一个用户不同银行卡上发生的交易是零散的，没有任何联系，而账基支付将一个用户的所有支付行为都关联起来，为行为分析和征信用户画像做了大量的数据准备。
• 成为支付场景的推动者、投人者、收购者:为了获得自己的账户支付用户，如前文所说，企业先是围绕账户自建或者接人第三方应用场景，比如水电煤交费、信用卡还款.电话费充值,后面发展到入股或者收购前面所说的有流量的线上线下公司，要求排他性，只能接自己的支付，比如阿里收购饿了么，饿了么没有微信支付，腾讯入股京东，京东没有支付宝支付。
• 倒遥银行创新，账基支付报务商收入增长,获得大量沉淀资金。账基支付出现之后，很多用户的转账、交易都通过账基支付实现，比如支付宝转账、微信扫码付款。对于支付宝米说、两个用户之间的转账本质上只发生信息流、并未发生资金的实质变动;同时由于账基支付的特性，如手续费极低甚至免费、无须携带银行卡、账基场景、持续培养支付习惯等，商户和个人都偏好账基支付。相比单一卡基支付时代，当前银行可获得的手续费收入锐减，交易中的沉淀资金也相应减少。

2.5 内卡外抛现象

支付领域有种现象叫“内卡外抛”，内卡外地是指国内发行的银行卡本应该通过阅内支付通道进行爱理交易和清结算．结果被误认为是外卡，抛送给了支持外卡交易的通道的现象。例如网上--个商品订单的金额是1000元人民币，你使用工商银行Visa/银联双币信用卡，银联可以使用工商银行信用卡直连通道（内卡通道), Visa可以使用中银国际（外卡通道)，这里本该使用工行直连系统通道进行交易支付和结算，却被错误地抛送到外卡通道，以外币进行了交易结算。

内卡外抛主要有以下原因。

第一，误操作。

• 比如在线下刷卡时，营业员可能选错收单卡组织。

第二，线上处理机制错误。这又分多种情况。比如错误的卡 BIN识别，把内卡维护进外卡里。

• 卡属性里会有卡 BIN对应的支付品牌、支付通道、卡种名称、卡种类型以及卡的内外卡属性。如果把内外卡配置错误，就会造成内卡外抛。

• 比如错误地制定了路由规则．把外卡通道设为支持内卡银行。前面在介绍支付通道的结构时提到过，通道对应多个支付品牌，如果把内卡品牌配置到外卡通道，那么路由系统就会在进行路由决策时，将可用通道计算为外卡通道，造成内卡外抛。
• 比如错误地制定了双币种卡逻辑，制定错误内卡优先和外卡优先逻辑。在支付系统里，我们会将通道标记上属性是内卡通道还是外卡通道，甚至在进行全球展业的时候，内外卡通道还会与交易国相关联。

第三，商户和收单方一起谋利。

• 内外卡交易时所计费的交易币种不一样，常见机制判断内卡以人民币计价，外卡以美元计价。由于人民币转换成美元计价，需要查汇，查汇调用收单方的汇率接口，有汇率就会有汇差。
• 如果商户为了谋利，将双币种卡当成外卡，直接以美元计价，也就是支付领域所说的 DCC ( Dynamic CurrencyConversion，动态汇率转换)，那么在进行汇率转换的时候，收单方出于应对汇率波动考虑，基本会基于银行标准汇率加成一定比例。由于数值太小，用户几乎感知不到。这部分加成就是多收的钱，收单方会将其用于抵扣一部分商户的手续费或者后返费用给商户。因为在这种支付交易中可以获得收益，所以商户会偏好这样的方式。

第四，收单机构愿意或者故意谋利。

• 由于外卡通道手续费一般高于内卡通道，部分收单机构为了多收手续费而进行内卡外抛。

第五消费者要求。

• 由于各卡组织或银行不定期有营销活动，用户为了获得活动优惠，会指定走某个卡组织的收单受理。

内卡外抛对商户的影响如下:

1. 不合规《中华人民共和国外卡管理条例》规定:境内严禁外币流通，商品不得以外币进行计价、结算。内卡外抛会造成部分交易以外币计价，市场货币供应和交易监控会失真。
2. 造成手绒费成本增加﹒在市场上，外卡通道手续费成本一般显著高于内卡通道，如果在商户不知情的情况下收单方进行内卡外抛，会造成商户的手续费成本增加。
3. 造成学续费成本降低。在市场上，外卡收取手续费，进行汇率转换，通过汇率转换本身获得基准汇率上浮加成的部分，而收单方又通过减免或者后付方式将加成汇率部分返给商户，造成商户的手续费成本降低。

内丰外抛对持卡人的影响如下：

1. 货币转换费成本增加﹒第一种情况，人民币（本币)转外币，还款或者记账时，再将外币转成人民币（本币)，多出两笔货币转换费;第二种情况，在商户计价时，汇率转换上浮加成的比例，导致实际支出成本增加。
2. 获得营销活动收益﹒消费者参与卡组织或者发卡行营销活动时，指定或者愿意内卡外抛以获得营销活动收益。

三、支付通道接入流程

一个通道就跟一双鞋子一样，要裁断、针车、成型，每一个成品都是由很多人、很多道工序和指标点构成，通道接入的过程中也要确认每一项的细节，这些细节就是自己对外支付能力的交付和支付产品包装的基础。流程主要涉及商务人员（含法务人员审理合同)、产品经理、开发工程师、测试工程师、运营人员等，各角色在项目中的出场顺序以及主要责任。

负责人	工作职责
商务人员	商户合同确立（包含费率、赔付款条件、计费方式等) 获得商户号 获取对方联系方式 获取接口等的相关文档
产品经理	评估通道可行性、通道细节点（后面会详细描述哪些点)、测试功能范围 排期立项开发．进行PRD编写，组织PRD评审 将银行返回的原始信息进行归类处理，并映射成前台用户看到的展示信息
运维工程师	服务器准备 专线评估与接入
开发工程师	评估项目内容，给出排期及提测日期 项目开发、自测及提测
测试工程师	测试环境和生产环境准备 测试案例验证 测试报告交付
财务人员	负责基本结算户的开设与管理 负责资金及凭证的核对与核实 负责资金调拨
产品经理以及运营人员	安排生产验证及切量方案 验证通过，观察数据 全面配置生产路由规则

四、内卡支付接入流程

内卡(国内银行卡)是目前大部分商户都支持的，也是我们最熟悉的银行卡，因此下面我们先从内卡通道说起。需要特别说明的是，这里的内卡支付是狭义上的，单指卡基支付.不包含账基支付。

在接入内卡通道的过程中，有很多细节需耍确认.每个细节都可能·会彩响通道是否可利和支付成败,下面我们以提问的形式介绍接入各种通道过程中的一些注意点及说明。

4.1 内卡支付问题

4.1.1 支持的卡种有哪些?

一般支持的卡种有借记卡、贷记卡，极少数情况下会支持准贷记卡。

4.1.2 支持的银行有哪些?是否提供卡BIN表或者对BIN限制？

在接人通道的时候，通道方( Vendor）分为两类:一类是银行直连，一类是第三方支付通道。直连银行支持的支付品牌基本只有本行，比如工行快捷直连通道支持的银行只有工商银行。第三方支付或收单服务商支持多个支付品牌，比如连连聚合支付可以支持农业银行、招商银行、建设银行等支付品牌，在接入的时候需要明确它们各自支持哪些银行。

除了明确支付通道提供方所支持银行外，支付通道接入方还会和支付通道方确认是否提供卡BIN表，或者明确不支持哪些卡BIN。如果没有提供，可以将就使用银联的信用卡或借记卡卡BIN，原因简单来说是按照现行发卡管理办法、银行卡 BIN均需要问卡组织申请,而国内卡组织就是银联,所以理论上银联的BIN段一定是最全的。

4.1.3 为什么需要明确卡BIN支持哪些或者不支持哪些?

前面提过，康师傅方便面的种类有红烧牛肉面、老坛酸菜牛肉面、金汤肥牛面等，假如给所有种类分别标号为1~10，有的商家就只进了种类1~9，如果消费者要买康师傅方便面种类10，商家不确认自己是否有这个种类就收钱，最后就会发生交易失败而退钱。换成卡 BIN也-样，如果通道不支持某个卡 BIN，交易发过去，就会交易失败，造成支付成功率下降。

4.1.4 支持的交易类型有哪些?

交易类型有消费、鉴权、预授权、代扣、代付等，具体说明如下。

• 消费:一般是指我们的扣款交易，狭义上常和预授权区分开来，代表不同的交易类型。比如去超市购物100元，刷卡支付，这个100元的交易类型就是消费。
• 鉴权:与交易无关，不涉及交易金额，指通过一定手段对用户身份或卡信息进行验证。比如很多网站要求实名认证，让用户绑定银行卡，并不扣款，用户绑卡成功后，实名认证即成功，这其实就是通过银行卡鉴权来完成实名认证。
• 预授权:商户向发卡机构取得一定金额内的扣款权利，后续再向发卡机构进行承兑的业务，消费和结算不在同一时间完成。预授权会占用持卡人卡内额度或者金额，一定时间内如果未进行后续承兑操作，发卡机构会进行撤销，恢复额度或者退回金额。
• 代扣：也叫作代收，是由用户授权、商户主动发起，对用户指定账户进行扣款的一种支付交易业务。它具有以下几个特点:支付要素少、按笔收费、没有退回功能、支持单笔实时代扣和批量代扣。有人这么评价代扣通道，“代扣是支付公司生命线,其他的都是重在参与”“代扣是万丈高楼平地起的基石”从中可以看出，如果一家公司储备了代扣的支付能力和支持较多银行，那么在支付竞争中就会占有很大优势。在早期支付里，撒开合规性，有代扣能力相当于有了核武器，对竞争对手简直是降维打击。
• 代付：由商户主动发起，从自身结算账户付款给用户资金账户的一种支付交易业务。它具有以下几个特点:支付要素少、按笔收费、没有退回或者撤销功能、支持单笔实时代付和批量代付。

4.1.5 关联交易类型有哪些?

关联交易类型有冲正、查询（查询范围签约、交易、退货、协议号状态等)、撤销（当日撤销)、退货（隔日走退货,当日退货是否也支持)、预授权关联交易、解约/解绑。下面来看一个冲正与查询交易类型的使用案例。

在支付交易里，返回的结果不只有预料中的成功或失败，也会因为各种问题（如系统异常）导致收不到支付服务提供商反馈的结果。但是交易订单必须有一个最终时间，不能无限期地等待下去，让用户一直看着自己的订单在处理中，不知道购买是成功还是失败。遇到这种情况，可以通过冲正或查询来解决。

冲正是系统对于交易结果未知的补偿机制。商户因为系统超时、异常等，不确定支付结果，为避免用户等待或者重复扣款，向支付服务提供商发起冲正交易请求，进行交易回滚。无论原交易是成功还是失败、均要求取消该笔交易。冲正成功后，商户可以向用户反馈支付失败或者再组织报文重新发起交易。

冲正与撤销、退货看起来有些相似，但是使用起来有很大区别:冲正可以对未知结果的订单进行交易回滚,而撤销和退货都只能明确结果成功的订单进行交易回滚。

查询是另一种对于交易结果未知的补偿机制。系统对于无明确交易结果返回的订单，设定好脚本规则，定时向支付服务提供商发起请求，查询交易结果，比如每5分钟查询一次，一直查询到第30分钟。在这期间，如果查询到明确结果成功或者失败，更新订单状态;如果查到最后还是没有结果，通常的做法是直接置为失败，第二天商户查看对账单确认该交易是否成功，如果成功，则进行退款处理。

此外，在协议支付或者快捷支付里，需要先签约，生成协议号，而有生成就有解除，解除协议的过程就叫作解约或者解绑。

4.1.6 是否支持预授权关联交易?

预授权关联交易有多种、在通道接入时需要和通道方明确是香支持以及支持哪些预授权关联交易有以下几类。

• 预授权完成:预授权交易取得的扣款转为实际全额扣款结算的处理业务。预授权时，扣款金额并没有结算给商家，只是在用户账户上临时冻结;预授权完成时，扣款金额实际全额结算给商家，用户账户全额从冻结变成实际扣款消费。
• 预授权部分完成:预授权交易取得的扣款转为实际部分扣款结算的处理业务。预授权部分完成时，扣款金额实际针对请求的部分金额结算给商家，用户账户上从部分金额冻结变成实际扣款消费，剩余金额则会自动撤销，恢复额度或者退回款项。
• 预授权完成撤销:针对已经扣款结算的预授权金额做全额撤销，退回用户账户，相当于退款功能。撤销普遍是指全额撤销。
• 预授权完成部分撤销:是指针对已经扣款结算的预授权金额，进行部分金额撤销，退回用户账户，相当于退款功能。预授权撤销:解除预授权交易取得的扣款权利的处理业务。预授权撤销时，扣款金额从用户账户解冻，恢复额度或者退回款项。
• 预授权追加:原有预授权因为各种原因需要增加预授权金额，发起交易类型为预授权追加的处理业务。在现实中，有很多商户会将原有预授权进行预授权撤销，重新发起一笔预授权追加。

4.1.7 预授权自动解冻时间是多久?

银行对于预授权有如下规定:一定时间没进行预授权完成，就会自动撒销，一般是30天。一些业务（如酒店业务）为了防止到期自动撤销、造成损失，就需要明确这个日期，并在这个日期之前进行预授权完成。

4.1.8 关于快捷通道的.些问题。

快捷交易一般需要先签约，生成协议号( Token）后再进行支付。银行的快捷签约对于商户来说基本上有两种设计结构：

• 口商户—卡号结构，与商户和卡号相关，同一卡号下协议号不变。
• 商户一会员号—卡号结构，与商户、会员号和卡号相关，不同的会员号对应的同一卡号的协议号不一样。

两种结构对于以下问题处理的灵活度是不一样的。商户—卡号结构比较简单，可用性较差。不同的用户绑定一张卡，如果跟着卡走，一个解绑了，另一个用户也会自动解绑，但是现实生活里多个用户绑一张卡的情形很多。比如老板让秘书绑定自己的卡买东西，秘书离职了或者换秘书解绑了，结果老板自己的账户也不能用了。

4.1.9 快捷支付是否支持重复签约?

答:重复签约是指已经签过约的卡号再次进行签约。需要确认这样的行为是否得到支持，比如进行重复签约时通道依旧会如第一次签约那样，验证卡信息是否正确，如正确再返回给商户或者支付平台“签约成功”;反之，则会签约失败。

在实际应用中，会有以下几种场景:

• 实名制，只能将自己的卡用于自己已实名认证的账户下;
• 允许多个用户绑定同一张卡;
• 同一个用户多次绑定同一张卡。

对于这些场景，一定要明确是否支持重复签约，并且每次签约信息验证是否独立、不影响之前的已签约情况。若不支持，则需要进一步确认是否会对已签约的卡号验证要素正确及返回协议号。

比如通道不支持重复签约，当已签约过的卡号再次进行签约时，通道返回“已签约”。那我们需要区分处理逻辑，通道方的不同处理逻辑对应的支付平台处理机制完全不同。

如果返回“已签约”的逻辑是验证了卡要素且为正确（否则会返回“卡信息错误”)，那么这代表卡要素一定是正确的，支付平台可以将原卡号对应的协议号直接取出来进行支付。如果在此逻辑上，还能顺便返回原协议号给调用方，那么连调取该卡对应的原协议号流程都可以省略。

当然，作为支付平台，我们理想中的情况是银行支持重复签约，且是独立验证的，不影响之前的已签约情况。万一不支持，也希望银行先验证要素正确再告知结果“已签约”，或者支付通道告知“已签约”的时候可以将原协议号一并返回。

当然实际情况可能会更差，什么都没有，支付通道只返回结果“已签约”，剩下的就得支付平台的产品经理自己想办法解决了。确认的情况不同，针对的方案也会不一样;如果不进行确认，会造成诸多问题。下面我们分两种场景来介绍。

实名制，自己的卡只能用于自已!已实名认证的账户下或者同个用户多次绑定同一张卡。

在该场景下，会有以下问题。

• 若不支持重复签约，则该用户删除了该卡或者因忘记再次绑卡的时候，会发生签约失败或者报错“该卡已签约”。
• 若会影响之前已经签约的结果，则用户其余模块里已存在的协议号就会失效，但是用户和商户并不知道，依然发起支付，会支付失败。对于系统来说，这就是无效的脏数据了。
• 如果针对“已签约”情况，返回结果的时候不验证要素，也不返回协议号，那么就需要自己借助额外鉴权数据库去完成鉴权，以及在验证要素正确后调取此卡号原协议号。

允许多个用户绑定同一张卡

在该场景下，会有以下问题。

• 若不支持重复签约，在其他用户签约同一张卡的时候，会发生签约失败或者报错“该卡已签约”。
• 若会影响之前已经签约的结果，则A用户签约失败，结果B用户原本已经绑定了的卡也一并失效，造成B用户后续也会支付失败。对于系统来说，这就是无效的脏数据了。
• 如果针对“已签约”情况，返回结果的时候不验证要素，也不返回协议号，那么就需要自己借助额外鉴权数据库去完成鉴权，以及调取之前关于此卡号的协议号。

举个例子，大卫在某网站用自己的账户购买过东西，当时使用自己招商银行信用卡进行过签约，卡号为123。大卫把这张银行卡放在了助理小黄那里。小黄在同样网站登录自己的账户为公司购买东西，支付中使用大卫卡号为123的卡进行支付，支付流程也需要签约再支付。无论小黄使用的时候是否签约成功，均不能影响大卫账户的支付签约情况。如果小黄签约的时候，不支持重复签约，那么需要网站自己去验证要素正确性;结合鉴权、卡服务、用户数据进行相当复杂的处理，才能保证老板和小黄各自独立使用，互不影响。

如果银行对于已重复签约的情况不返回协议号，那么商户需要自己去捞取协议号和验证信息。

4.1.10 用户签约后若支付信息变化、协议号是背有效?

答:支付信息包括卡号、姓名、证件类型、证件号、手机号，如果是信用卡，还要加上有效期和CVV。因为快捷支付是以协议号作为扣款凭证的，所以信息的变化是否造成协议号失效关系着支付能否成功。

接入过境内外几百家支付通道，以下实操经验如下。

• 协议号是与卡号关联的，如果卡号变了，协议号一定会失效。
• 对于绝大多数通道，姓名、证件类型、证件号、手机号这些要素变化，协议号不变。
• 如果过了有效期，用户未续办卡，协议号会失效;有效期，如果变化，用户续办卡，协议号依然有效。
• CVV依据各银行设定，有些CvV变化后协议号依然有效，而有些CVV变化后协议号会失效。

4.1.11 需要退款时丝否区.分报销和退货?被销是否只支持全额撤销?

有的银行或者第.三方通道只提供退货接口，有的则提供撤销和退货两个接口。那么在接入的时候，由于撤销一般都是全额撤销，并且只支持当天走撤销，就需要根据银行或者第三方通道接口情况做如下处理。

• 情况一：只有退货功能。需要确认当天的交易，是否不管全额还是部分金额退款均可以调用退货接口，还是同一般退货接口一样，需要隔日才能调。
• 情况二：提供撤销和退货功能。需要确认当天交易部分退款的时候，是可以使用撤销功能，还是由于撤销只支持全额，只能隔日使用退货功能。
• 一般情况下，商户系统需要先承担当天交易的部分金额的退货，过了日切时间点后，也就是隔日再交给通道受理。

4.1.12 订单最退货时间是多久?

退货时间就是指退款时间，通道方通常会对于订单线上联机退货时间有个最长时间规定，比如60天、90天、180天、360天等，过了这段时间，系统就不能联机发起退款流程，需要人工线下处理。

4.1.13 退款发起和到账时间分别是什么时候?

用户会关心什么时候退款资金到账，出于降噪需要，也需要提示用户预计到账时间。在接入通道的时候,要尽量与通道方确认好每个通道或者银行的到账时间是几个工作日，否则给的到账时间过短，结果没按时到，用户会投诉;给的到账时间过长（比如明明3天可以到账的，却写了15天)，会被用户给差评。

4.1.14 退款是否要求当日进款大于退款?

.---些通道会规定当天的正交易必须大于负交易才可以退款。如果不确认这个问题，进行测试或者分析问题的时候可能会发现，昨天进行的扣款测试交易，今天发起退款时，就是不成功，找来找去也找不出问题。其实就是因为通道做出了这样的规定，当天发起退款时，还没有进款，因为负交易大于正交易，所以无法进行。

之所以会这样规定，是因为通道资金往往是T+1日结算。前一天的款项已经结算给商户了，如果第二天交易不做限定，允许商户直接退款，万一发生恶意事件，只有退款，没有进款，且数额巨大，那么会给通道系统带来系统性风险。

4.1.15 退款退不退手续费?

退款是否退手续费的属性在账户系统落地数据、收银系统匹配账单定制规则时，均需要用到。
一般情况下，代扣、代付类型通道退款不退手续费，无磁无密、MOTO、快捷类型等通道退款退手续费。

4.1.16 当天一笔订单问时发生正交易和负交易﹑对账单是否有体现？

正交易一般指收入业务，比如代扣、消费、预授权。负交易一般指退货、撤销、代付。如之前所说，一般都是当天走撤销，隔日走退货，且撤销只支持全额撤销。

如果发生一笔交易，且当天又进行了全额退款，需要明确第二天对账单里是否会体现，是两笔对冲均不显示，还是均会显示。这个规则关系到后面的结算对账系统怎么处理。

4.1.17 支付要素有哪些?

内卡支付全要素通常情况如下，而外卡会多很多其他要素。

• 借记卡:卡号、姓名、证件类型、证件号、手机号、短信验证码。
• 信用卡:卡号、姓名、证件类型、证件号、手机号、短信验证码、CVV、有效期。

证件类型有很多，一般做国内业务的主要关注是否支持这几个证件:身份证、护照、港澳居民来往内地通行证（俗称“回乡证”)、台湾居民来往大陆通行证（俗称“台胞证”)。表2-3给出了银行开户时需要的证件类型。

在接入时，各个银行和第三方通道会根据自身实际情况及对于接入通道类型的熟悉程度来确定需要哪些要素。大家对要素的要求各不一样，也不一定需要上送全要素，而多送和少送要素在支付里均不被允许，会带来系统性风险，因此明确需要什么要素很重要。测试人员进行测试的时候不仅要测要素正确时会不会支付成功，还要进行排列组合测试某个要素错误后支付结果会怎么样。

4.2 内卡支付场景分析

4.2.1 场景一：支付请求时多送了要素，多送得要素是错误的。

• 结果一：扣款成功。首先，系统里如果保存数据，这些数据就成为脏数据。其次，如果用户后续发起拒付，银行调单，发现要素确实是错的，那么很可能就会判断通道或者商户失责，将金额退回给用户。毕竟用户支付要素都是错误的，你怎么可以允许支付成功呢?
• 结果二：扣款失败。支付里关注的无非三个方面:支付成功率、支付收益（成本或收入)、支付方式覆盖面。如果银行不接受多送的要素或者对多送要素也进行验证，导致支付失败,那么这些无效交易就会造成支付成功率下降。

4.2.2 支付请求时少送了要素。

• 结果一:扣款失败。如上面所说，支付里关注的一个方面是支付成功率。少送的原因多数是商户自己内部配置或者系统错误，在中间传输的过程中某些要素被拦截或者丢失导致未上送。要素少送的话，结果多数是支付失败，这些无效交易造成了支付成功率下降，是很严重的事情。
• 结果二;扣款成功。要素少送时,极少数情况下会扣款成功。这种情况发生的原因最有可能是通道方自己内部对于某些要素并不做强制校验，至少不是每次都校验，极端情况下甚至不校验。这样的情况很严重，意味着如果正常上送要素，有些要素会不被验证就支付通过，从而带来上面提到的拒付风险。

4.2.3 验证码的规定？

短信验证码有几个方面需要确认，这里为了全面，拿涉及签约和支付两个流程的快捷通道为例来说明。

问：短信发送方是谁?

答：需要明确签约短信发送方、交易短信发送方分别是谁，是通道侧还是商户侧。

问：同一笔交易里，签约与交易两个环节均为通道发送，短信如何发送?

答：需要明确是两个环节均需要发送，用户会收到两条短信，还是只会下发一条。更好的用户体验是，在一笔交易里如果既有签约流程又有交易流程，下发了签约短信，支付短信就不下发了;如果已签约，本次只有支付交易，那么就单独下发支付短信。总之用户只会收到一条短信。

问：短信验证码长度是多少?

答：前端页面基于尽可能在前面拦截一些已知错误的思路，会做出-一些设计，比如输入短信验证码字符数量超了会报错，因此需要明确短信验证码字符长度，通常为6位或4位。

问：短信验证码发送间隔时间与次数分别是多少?

答：由于短信发送是有成本的，各通道方出于成本考虑以及防止恶意点击或者错点，通常会规定短信发送间隔时间（比如60s)，有些甚至会规定每天最多发送的次数。在接人通道的时候，需要根据这些属性做好相应的前端系统配置。

比如通道规定短信验证码发送间隔时间为60s，那么前台倒计时就需要至少60s，防止用户因点击收不到短信验证码，对支付体验不满，甚至放弃支付。比如通道规定了每张卡短信验证码最多发送的次数，那么前台就需要做好相应的计数服务，统计好发送次数。

问：短信验证码发送方是否与赔付相关?

答：出于各种原因用户可能会有拒付要求，比如非本人支付、卡被盗等，短信验证码作为一种身份信息验证，需要与通道方明确是否谁发送谁验证谁负责。

问：短信内容是什么?

答：短信中会有相关的行为＋发送方，通常会在开头或末尾。

展示发送方或交易商户，以便用户知道发送主体。在交易中，一些第三方通常会以自己作为后缀结尾，如【 ××支付】，导致用户在商户网站购物时看到短信来自一个完全不认识的短信发送方，会产生困惑，甚至投诉。

在接入的过程中，商户应当尽可能要求通道方用自己的商户名称作为发送方显示在短信中。支付服务提供方应当在设计短信内容配置模板时，支持根据签入商户主体不同展示不同名称。

4.2.4 通道是否限制商户侧和用J侧的单笔、单H、单月额度?

大多数通道会对用户有个限额，单笔限额多少、单日限额多少、单月限额多少，不能超限。如果超限还上送交易，通道会返回类似“该笔交易已超限额”的错误。对于一些代扣类、鉴权类通道，一些银行对商户也有限额，甚至限次，不希望调用太多。对于银行通道以及用户限额限次，如何避免超限呢?一种方法是进行计数服务，对当天的交易笔数进行计数统计。此外，还可以进行重试服务，遇到这种情况就将交易抛送到其余通道去处理。

4.2.5 支付要索对于可选项和必选项是怎么要求的?

在接入通道的实际过程中，有些银行或第三方支付会提供可选项，允许商户按照自己的需求自行选择，既可以上送最小支付要素（只有必选项）的交易请求，也可以上送最大支付要素（必选项＋可选项)的交易请求。

什么情况用最小支付要素，什么情况用最大支付要素呢?可以看下面的几种情形。

对于有风险的用户，希望要素验证尽量全，这时候往往选择最大支付要素。

对于新用户，或者在某些场景希望进行某些鉴权认证的时候，需要收集尽量全的信息，也会用到最大支付要素。如果希望支付成功率高、用户转换率高，就会倾向于让用户输入少一些、停留时间短一些，会选择使用最小支付要素。

4.2.6 接入的方式是专网还是公网？

顾名思义，专线就是专用网络，谁接人谁独享，安全性高，但流程复杂，整个项目周期也会拉长，另外需要定期支付专线费用。公网是指公共网络，会有多个商户一起在同一网络进行请求交易，接入方式快，也没有费用，缺点就是可能会因为其他商户的问题（如瞬时交易过大等）影响自己的交易。

4.2.7 通道每秒并发量是多少?公用还是专用?

并发量相当于网红饭店的同时最大接纳量。如果人过多，已经超过同时最大接纳量，饭店就需要采取分流、排队甚至推荐到分店的做法来缓解人流压力。支付通道也是一样，需要明确通道并发量是多少，这个并发量是自己独享还是很多商户公用。当并发量过大的时候，就采取与分店缓解人流压力类似的做法。支付中常用的方法有以下两种。

• 分队列处理如果通道每秒最多只能受理10笔交易，由于上线了营销活动，现有100笔交易同时进来，那么可以把这100笔交易分成10 队，每队10笔排队处理。这样，就让原本全部交易蜂拥而入、超过容量,结果可能会有90 笔失败的情况，变成秩序井然、每笔都会成功的情况。
• 转通道处理还是一样的情况，通道每秒最多只能受理10笔交易，那么平时在通道的建设中都要有多个通道互为备份。遇到这种情况的时候，可以把多出的交易上送给其余通道进行支付。就像我们在超巿结账时，一个收银台忙不过来，排队人太多，那就再开一个柜台处理，加快速度，缓解压力。

4.2.8 是否有最低交易金额的限制

在接入支付通道的过程中，日常我们的最低交易金额为0.01元，即1分钱，但是也会有一些通道做出不一样的规定，比如最低交易金额为0.1元或1元。在接人的时候要明确这些细节，避免因为这些小细节而交易失败。

4.2.9 日切时间和账单获取时间分别什么时候？

日切时间点是指上一个工作日结束的时间点。比如我们说日切时间是每天24点，一般不特别说明，下--.工作日就是次日0点之后。交易数据、给出的对账单数据等就是以О点至24点为一个统计日，0点以后的交易对账单要到下一个工作日给出。

除了日切时间外，还要关注账单获取时间。只有通道方上传了账单，商户才能下载到。为了避免不停地轮询下载，商户需要与通道方明确他们上传的时间，然后在给出的时间基础上设置一个时间差，到时间了再去下载。

4.2.10 对账支持那些获取方式？

对账单的获取方式有以下三种。

• 登录后台下载。通道方为商户开设后台账号和密码，商户登录后进行人工对账单下载或导出。
• 邮件推送。商户向收单机构（通道方）提供邮箱地址，收单机构按照规定定时推送。
• FTP下载，这是推荐的方式。随着接入通道增多，人工下载变得费时费力，i而FTP下载可以自动完成、实现加活不加人.这是系统轻量化运营中重要的一环。

FTP下载根据对象关系不同可分成两种:一种是商户主动去收单机构下载，一种是由收单机构主动推送到商户FTP地址。不管是哪种，在接入的时候，均会涉及地址、用户名、密码、目录、IP白名单。

如果是商户去收单机构下载，需要收单机构向商户提供下载的目标地址、用于身份允许的用户名、密码、下载的目录地址;而商户需要给收单机构对应的IP地址，以事先配置到收单机构白名单里。

如果是收单机构主动推送到商户，则反过来，由商户向收单机构提供下载的目标地址、用于身份允许的用户名、密码、推送的目录地址;而收单机构需要给商户对应的IP地址，以事先配置到商户的白名单里。

4.2.11 结算是用全额结算还是净额结算？

全额结算( Gross Settlement）是对交易的已收资金进行全数结算、划拨，不做费用扣除。净额结算( Net Settlement）是对交易的已收资金扣除手续费之后再进行结算、划拨，或者是双方互有买卖，对各自应收应付资金互为抵扣之后再进行结算。

采用什么样的结算方式关系到后续程序的对账规则是结算扣手续费净额结算，还是不扣手续费全额结算，手续费后续另算。

4.2.12 是否有测试环境并提供测试卡信息、生产卡信息?

商户平时会接入的支付通道很多，大大小小的银行都会涉及，而测试人员基本不太可能拥有每一家银行的借贷卡。在接入通道的初期，如果能够与支付服务提供商（通道）确认好，收集好相关卡信息，或者测试时有可进行协助的联系人，会使得项目测试全面、高效很多。

博文参考

《支付论》