内卡（国内银行卡）是目前大部分商户都支持的，也是我们最熟悉的银行卡，因此下面我们先从内卡通道说起。需要特别说明的是，这里的内卡支付是狭义上的，单指卡基支付，不包含账基支付。
在接入内卡通道的过程中，有很多细节需要确认，每个细节都可能会影响通道是否可用和支付成败。下面我们以提问的形式介绍接入各种通道过程中的一些注意点及说明。
1、支持的卡种有哪些？
一般支持的卡种有借记卡、贷记卡，极少数情况下会支持准贷记卡。
2、支持的银行有哪些？是否提供卡BIN表或者对卡BIN有限制？
在接入通道的时候，通道方（Vendor）分为两类：一类是银行直连，一类是第三方支付通道。直连银行支持的支付品牌基本只有本行，比如工行快捷直连通道支持的银行只有工商银行。第三方支付或收单服务商支持多个支付品牌，比如连连聚合支付可以支持农业银行、招商银行、建设银行等支付品牌（图1所示为某支付通道支持的支付品牌），在接入的时候需要明确它们各自支持哪些银行。
图1 某支付通道支持的支付品牌（信用卡）
除了明确支付通道提供方所支持银行外，支付通道接入方还会和支付通道方确认是否提供卡BIN表，或者明确不支持哪些卡BIN。如果没有提供，可以将就使用银联的信用卡或借记卡卡BIN，原因简单来说是按照现行发卡管理办法，银行卡BIN均需要向卡组织申请，而国内卡组织就是银联，所以理论上银联的BIN段一定是最全的。
为什么需要明确卡BIN支持哪些或者不支持哪些？如果通道不支持某个卡BIN，交易发过去，就会交易失败，造成支付成功率下降。
3、支持的交易类型有哪些？
交易类型有消费、鉴权、预授权、代扣、代付等，具体说明如下。
·消费：一般是指我们的扣款交易，狭义上常和预授权区分开来，代表不同的交易类型。比如去超市购物100元，刷卡支付，这个100元的交易类型就是消费。
·鉴权：与交易无关，不涉及交易金额，指通过一定手段对用户身份或卡信息进行验证。比如很多网站要求实名认证，让用户绑定银行卡，并不扣款，用户绑卡成功后，实名认证即成功，这其实就是通过银行卡鉴权来完成实名认证。
·预授权：商户向发卡机构取得一定金额内的扣款权利，后续再向发卡机构进行承兑的业务，消费和结算不在同一时间完成。预授权会占用持卡人卡内额度或者金额，一定时间内如果未进行后续承兑操作，发卡机构会进行撤销，恢复额度或者退回金额。
·代扣：也叫作代收，是由用户授权、商户主动发起，对用户指定账户进行扣款的一种支付交易业务。它具有以下几个特点：支付要素少、按笔收费、没有退回功能、支持单笔实时代扣和批量代扣。
有人这么评价代扣通道，“代扣是支付公司生命线，其他的都是重在参与”“代扣是万丈高楼平地起的基石”。从中可以看出，如果一家公司储备了代扣的支付能力和支持较多银行，那么在支付竞争中就会占有很大优势。在早期支付里，撇开合规性，有代扣能力相当于有了核武器，对竞争对手简直是降维打击。
·代付：由商户主动发起，从自身结算账户付款给用户资金账户的一种支付交易业务。它具有以下几个特点：支付要素少、按笔收费、没有退回或者撤销功能、支持单笔实时代付和批量代付。
代扣代付交易的诞生史最早的代扣交易大概是水电煤缴费。经历过20世纪90年代水电煤缴费的人应该还有印象，当时每个月有人定期上居民家中查水电表度数，之后居民就可以去邮局缴纳账单。但是这样不太方便，会占用人们的业余时间，一个三四线城市网点就那么多，很多人经常要在周末排长队。
后来一些银行与电信公司、电力公司、自来水公司等公共事业缴费单位合作，允许居民在银行开通委托支付账单协议，每个月账单出诟，自动从居民的银行卡中将资金划扣至公共事业缴费单位。
代扣早期常见的应用业务如图2所示。
图2 早期代扣业务
而代付最早可以追溯到理财产品分红，比如基金分红、保险分红，当时理财产品会定期付款给客户，所以产生了代付业务。代付早期常见的应用业务如图3所示。
图3 早期代付业务
4、关联交易类型有哪些？
关联交易类型有冲正、查询（查询范围签约、交易、退货、协议号状态等）、撤销（当日撤销）、退货（隔日走退货，当日退货是否也支持）、预授权关联交易、解约/解绑。下面来看一 个冲正与查询交易类型的使用案例。
在支付交易里，返回的结果不只有预料中的成功或失败，也会因为各种问题（如系统异常）导致收不到支付服务提供商反馈的结果。
但是交易订单必须有一个最终时间，不能无限期地等待下去，让用户一直看着自己的订单在处理中，不知道购买是成功还是失败。遇到这种情况，可以通过冲正或查询来解决。
冲正是系统对于交易结果未知的补偿机制。商户因为系统超时、异常等，不确定支付结果，为避免用户等待或者重复扣款，向支付服务提供商发起冲正交易请求，进行交易回滚。无论原交易是成功还是失败，均要求取消该笔交易。冲正成功后，商户可以向用户反馈支付失败或者再组织报文重新发起交易。
冲正与撤销、退货看起来有些相似，但是使用起来有很大区别：
冲正可以对未知结果的订单进行交易回滚，而撤销和退货都只能对明确结果成功的订单进行交易回滚。
查询是另一种对于交易结果未知的补偿机制。系统对于无明确交易结果返回的订单，设定好脚本规则，定时向支付服务提供商发起请求，查询交易结果，比如每5分钟查询一次，一直查询到第30分钟。
在这期间，如果查询到明确结果成功或者失败，更新订单状态；如果查到最后还是没有结果，通常的做法是直接置为失败，第二天商户查看对账单确认该交易是否成功，如果成功，则进行退款处理。
此外，在协议支付或者快捷支付里，需要先签约，生成协议号，而有生成就有解除，解除协议的过程就叫作解约或者解绑。
5、是否支持预授权关联交易？支持哪些？
预授权关联交易有多种，在通道接入时需要和通道方明确是否支持以及支持哪些。
预授权关联交易有以下几类。
预授权完成：预授权交易取得的扣款转为实际全额扣款结算的处理业务。预授权时，扣款金额并没有结算给商家，只是在用户账户上临时冻结；预授权完成时，扣款金额实际全额结算给商家，用户账户全额从冻结变成实际扣款消费。
·预授权部分完成：预授权交易取得的扣款转为实际部分扣款结算的处理业务。预授权部分完成时，扣款金额实际针对请求的部分金额结算给商家，用户账户上从部分金额冻结变成实际扣款消费，剩余金额则会自动撤销，恢复额度或者退回款项。
·预授权完成撤销：针对已经扣款结算的预授权金额做全额撤销，退回用户账户，相当于退款功能。撤销普遍是指全额撤销。
·预授权完成部分撤销：是指针对已经扣款结算的预授权金额，进行部分金额撤销，退回用户账户，相当于退款功能。
·预授权撤销：解除预授权交易取得的扣款权利的处理业务。预授权撤销时，扣款金额从用户账户解冻，恢复额度或者退回款项。
·预授权追加：原有预授权因为各种原因需要增加预授权金额，发起交易类型为预授权追加的处理业务。在现实中，有很多商户会将原有预授权进行预授权撤销，重新发起一笔预授权追加。
6、预授权自动解冻时间是多久？
银行对于预授权有如下规定：一定时间没进行预授权完成，就会自动撤销，一般是30天。一些业务（如酒店业务）为了防止到期自动撤销、造成损失，就需要明确这个日期，并在这个日期之前进行预授权完成。
7、是否支持多次退货、部分退货？
交易场景里，用户有可能不止一次退货，也有可能仅退部分商品。
需要明确退货的这些基本属性，如果银行不支持，那么就要 考虑转账或代付等替代方案。
8、需要退款时是否区分撤销和退货？撤销是否只支持全额撤销？
有的银行或者第三方通道只提供退货接口，有的则提供撤销和退货两个接口。那么在接入的时候，由于撤销一般都是全额撤销，并且只支持当天走撤销，就需要根据银行或者 第三方通道接口情况做如下处理。
情况一：只有退货功能。需要确认当天的交易，是否不管全额还是部分金额退款均可以调用退货接口，还是同一般退货接口一样，需要隔日才能调。
情况二：提供撤销和退货功能。需要确认当天交易部分退款的时候，是可以使用撤销功能，还是由于撤销只支持全额，只能隔日使用退货功能。
一般情况下，商户系统需要先承担当天交易的部分金额的退货，过了日切时间点后，也就是隔日再交给通道受理。
9、订单最长退货时间是多久？
退货时间就是指退款时间，通道方通常会对于订单线上联机退货时间有个最长时间规定，比如60天、90天、 180天、 360天等，过了这段时间，系统就不能联机发起退款流程，需要人工线下处理。
10、退款发起和到账时间分别是什么时候？
用户会关心什么时候退款资金到账，出于降噪需要，也需要提示用户预计到账时间。
在接入通道的时候，要尽量与通道方确认好每个通道或者银行的到账时间是几个工作日，否则给的到账时间过短，结果没按时到，用户会投诉；给的到账时间过长（比如明明3天可以到账的，却写了15天），会被用户给差评。
11、退款是否要求当日进款大于退款？
一些通道会规定当天的正交易必须大于 负交易才可以退款。
如果不确认这个问题，进行测试或者分析问题的时候可能会发现，昨天进行的扣款测试交易，今天发起退款时，就是不成功，找来找去也找不出问题。其实就是因为通道做出了这样的规定，当天发起退款时，还没有进款，因为负交易大于正交易，所以无法进行。
之所以会这样规定，是因为通道资金往往是T+1日结算。前一天的款项已经结算给商户了，如果第二天交易不做限定，允许商户直接退款，万一发生恶意事件，只有退款，没有进款，且数额巨大，那么会给通道系统带来系统性风险。
12、退款退不退手续费？
退款是否退手续费的属性在账户系统落地数据、收银系统匹配账单定制规则时，均需要用到。
一般情况下，代扣、代付类型通道退款不退手续费，无磁无密、MOTO、快捷类型等通道退款退手续费。
13、当天一笔订单同时发生正交易和负交易，对账单是否有体现？
正交易一般指收入业务，比如代扣、消费、预授权。负交易一般指退货、撤销、代付。如之前所说，一般都是当天走撤销，隔日走退货，且撤销只支持全额撤销。
如果发生一笔交易，且当天又进行了全额退款，需要明确第二天对账单里是否会体现，是两笔对冲均不显示，还是均会显示。这个规则关系到后面的结算对账系统怎么处理。
14、支付要素有哪些？
内卡支付全要素通常情况如下，而外卡会多很多其他要素。
·借记卡：卡号、姓名、证件类型、证件号、手机号、短信验证码。
·信用卡：卡号、姓名、证件类型、证件号、手机号、短信验证码、CW、有效期。
证件类型有很多，一般做国内业务的主要关注是否支持这几个证件：身份证、护照、港澳居民来往内地通行证（俗称“回乡证”）、台湾居民来往大陆通行证（俗称“台胞证”）。表1给出了银行开户时需要的证件类型。
表1 银行开户常见证件类型
在接入时，各个银行和第三方通道会根据自身实际情况及对于接入通道类型的熟悉程度来确定需要哪些要素。大家对要素的要求各不一样，也不一定需要上送全要素，而多送和少送要素在支付里均不被允许，会带来系统性风险，因此明确需要什么要素很重要。测试人员进行测试的时候不仅要测要素正确时会不会支付成功，还要进行排列组合测试某个要素错误后支付结果会怎么样。
下面分成几个场景来说明。
场景一：支付请求时多送了要素，多送要素是错误的。
结果一：扣款成功。
首先，系统里如果保存数据，这些数据就成为脏数据。其次，如果用户后续发起拒付，银行调单，发现要素确实是错的，那么很可能就会判断通道或者商户失责，将金额退回给用户。毕竟用户支付要素都是错误的，你怎么可以允许支付成功呢？
结果二：扣款失败。
支付里关注的无非三个方面：支付成功率、支付收益（成本或收入）、支付方式覆盖面。如果银行不接受多送的要素或者对多送要素也进行验证，导致支付失败，那么这些无效交易就会造成支付成功率下降。
场景二：支付请求时少送了要素。
结果一：扣款失败。
如上面所说，支付里关注的一个方面是支付成功率。少送的原因多数是商户自己内部配置或者系统错误，在中间传输的过程中某些要素被拦截或者丢失导致未上送。
要素少送的话，结果多数是支付失败，这些无效交易造成了支付成功率下降，是很严重的事情。
结果二：扣款成功。
要素少送时，极少数情况下会扣款成功。这种情况发生的原因最有可能是通道方自己内部对于某些要素并不做强制校验，至少不是每次都校验，极端情况下甚至不校验。
这样的情况很严重，意味着如果正常上送要素，有些要素会不被验证就支付通过，从而带来上面提到的拒付风险。
15、关于短信验证码的规定。
短信验证码有几个方面需要确认，这里为了全面，拿涉及签约和支付两个流程的快捷通道为例来说明。
问：短信发送方是谁？
答：需要明确签约短信发送方、交易短信发送方分别是谁，是通道侧还是商户侧。
问：同一笔交易里，签约与交易两个环节均为通道发送，短信如何发送？
答：需要明确是两个环节均需要发送，用户会收到两条短信，还是只会下发一条。更好的用户体验是，在一笔交易里如果既有签约流程又有交易流程，下发了签约短信，支付短信就不下发了；如果已签约，本次只有支付交易，那么就单独下发支付短信。总之用户只会收到一条短信。
问：短信验证码长度是多少？
答：前端页面基于尽可能在前面拦截一些已知错误的思路，会做出一些设计，比如输入短信验证码字符数量超了会报错，因此需要明确短信验证码字符长度，通常为6位或4位。
问：短信验证码发送间隔时间与次数分别是多少？
答：由于短信发送是有成本的，各通道方出于成本考虑以及防止恶意点击或者错点，通常会规定短信发送间隔时间（比如60s），有些甚至会规定每天最多发送的次数。在接入通道的时候，需要根据这些属性做好相应的前端系统配置。
比如通道规定短信验证码发送间隔时间为60s，那么前台倒计时就需要至少60s，防止用户因点击收不到短信验证码，对支付体验不满，甚至放弃支付。比如通道规定了每张卡短信验证码最多发送的次数，那么前台就需要做好相应的计数服务，统计好发送次数。
问：短信验证码发送方是否与赔付相关？
答：出于各种原因用户可能会有拒付要求，比如非本人支付、卡被盗等，短信验证码作为一种身份信息验证，需要与通道方明确是否谁发送谁验证谁负责。
问：短信内容是什么？
答：短信中会有相关的行为+发送方，通常会在开头或末尾展示发送方或交易商户，以便用户知道发送主体。在交易中，一些第三方通常会以自己作为后缀结尾，如[xx支付]，导致用户在商户网站购物时看到短信来自一个完全不认识的短信发送方，会产生困惑，甚至投诉。
在接入的过程中，商户应当尽可能要求通道方用自己的商户名称作为发送方显示在短信中。支付服务提供方应当在设计短信内容配置模板时，支持根据签入商户主体不同展示不同名称。
16、通道是否限制商户侧和用户侧的单笔、单日、单月额度？
大多数通道会对用户有个限额，单笔限额多少、单日限额多少、单月限额多少，不能超限。如果超限还上送交易，通道会返回类似“该笔交易已超限额”的错误。
对于一些代扣类、鉴权类通道，一些银行对商户也有限额，甚至限次，不希望调用太多。
对于银行通道以及用户限额限次，如何避免超限呢？一种方法是进行计数服务，对当天的交易笔数进行计数统计。此外，还可以进行重试服务，遇到这种情况就将交易抛送到其余通道去处理。
17、支付要素对于可选项和必选项是怎么要求的？
在接入通道的实际过程中，有些银行或第三方支付会提供可选项，允许商户按照自己的需求自行选择，既可以上送最小支付要素（只有必选项）的交易请求，也可以上送最大支付要素（必选项+可选项）的交易请求。
什么情况用最小支付要素，什么情况用最大支付要素呢？可以看下面的几种情形。
对于有风险的用户，希望要 索验证尽全，这时候往往选择最大支付要素。
·对于新用户，或者在某些场景希望进行某些鉴权认证的时候，需要收集尽量全的信息，也会用到最大支付要素。
·如果希望支付成功率高、用户转换率高，就会倾向于让用户输入少一些、停留时间短一些，会选择使用最小支付要素。
在有可选支付要素的情况下，我们需要明确以下问题。
问题一：必选项+可选项的排列组合是怎样的？
答：如果有多个可选项存在，比如3个，那么这些可选项的排列组合是C？3=3，而现实情况肯定不会允许随意组合，送什么都行。接口开发文档中也只会标记哪些是可选的，不会对这些做特别说明，所以就要明确如果需要可选，到底要怎样上送。
问题二：对于可选项上送的要素，是否一定会验证？
答：理想情况是对于上送的要素一定会验证，但实际情况并非如此，有的银行或通道是送了就一定会验证，有的对于可选要素的定义则是上送了也不保证一定验证，比如其系统库不支持，或者 其路由策略会路由到不需要这个要素的通道等。
因此这一点需要明确，对于前者，可选要素是可以使用的；而对于后者，则需要放弃可选要素，只使用必选要素，否则还是会带来上面提到的要素错误弓|起的持卡人拒付或者“脏数据”问题。
支付里的一个很重要的准则是支付要素应准确。
18、接入方式是专线还是公网？
顾名思义，专线就是专用网络，谁接入谁独享，安全性高，但流程复杂，整个项目周期也会拉长，另外需要定期支付专线费用。
公网是指公共网络，会有多个商户一起在同一网络进行请求交易，接入方式快，也没有费用，缺点就是可能会因为其他商户的问题（如瞬时交易过大等）影响自己的交易。
19、通道每秒并发量是多少？公用还是专用？
并发量相当于网红饭店的同时最大接纳量。如果人过多，已经超过同时最大接纳量，饭店就需要采取分流、排队甚至推荐到分店的做法来缓解人流压力。支付通道也是一样，需要明确通道并发量是多少，这个并发是自己独享还是很多商户公用。当并发过大的时候，就采取与分店缓解人流压力类似的做法。支付中常用的方法有以下两种。
·分队列处理。如果通道每秒最多只能受理10笔交易，由于上线了营销活动，现有100笔交易同时进来，那么可以把这100笔交易分成10队，每队10笔排队处理。这样，就让原本全部交易蜂拥而入、超过容量，结果可能会有90笔失败的情况，变成秩序井然、每笔都会成功的情况。
·转通道处理。还是一样的情况，通道每秒最多只能受理10笔交易，那么平时在通道的建设中都要有多个通道互为备份。遇到这种情况的时候，可以把多出的交易上送给其余通道进行支付。就像我们在超市结账时，一个收银台忙不过来，排队人太多，那就再开一个柜台处理，加快速度，缓解压力。
20、否有最低交易金额限制？
在接入支付通道的过程中，日常我们的最低交易金额为0·01元，即1分钱，但是也会有一些通道做出不一样的规定，比如最低交易金额为0·1元或1元。在接入的时候要明确这些细节，避免因为这些小细节而交易失败。
21、日切时间和账单获取时间分别是什么时候？
日切时间点是指上一个工作日结束的时间点。比如我们说日切时间是每天24点，一般不特别说明，下一工作日就是次日0点之后。交易数据、给出的对账单数据等就是以0点至24点为一个统计日，0点以后的交易对账单要到下一个工作日给出。
除了日切时间外，还要关注账单获取时间。只有通道方上传了账单，商户才能下载到。为了避免不停地轮询下载，商户需要与通道方明确他们上传的时间，然后在给出的时间基础上设置一个时间差，到时间了再去下载。
22、对账单支持哪些获取方式？
对账单的获取方式有以下三种。
登录后台下载。通道方为商户开设后台账号和密码，商户登录后进行人工对账单下载或导出。
·邮件推送。商户向收单机构（通道方）提供邮箱地址，收单机构按照规定定时推送。
FTP下载，这是推荐的方式。随着接入通道增多，人工下载变得费时费力，而FTP下载可以自动完成，实现加活不加人，这是系统轻量化运营中重要的一环。
FTP下载根据对象关系不同可分成两种：一种是商户主动去收单机构下载，一种是由收单机构主动推送到商户FTP地址。不管是哪种，在接入的时候，均会涉及地址、用户名、密码、目录、IP白名单。
如果是商户去收单机构下载，需要收单机构向商户提供下载的目标地址、用于身份允许的用户名、密码、下载的目录地址；而商户需要给收单机构对应的IP地址，以事先配置到收单机构白名单里。
如果是收单机构主动推送到商户，则反过来，由商户向收单机构提供下载的目标地址、用于身份允许的用户名、密码、推送的目录地址；而收单机构需要给商户对应的IP地址，以事先配置到商户的白名单里。
23、结算是用全额结算还是净额结算？
全额结算（Gross Settlement）是对交易的已收资金进行全数结算、划拨，不做费用扣除。净额结算（Net Settlement）是对交易的已收资金扣除手续费之后再进行结算、划拨，或者是双方互有买卖，对各自应收应付资金互为抵扣之后再进行结算。
采用什么样的结算方式关系到后续程序的对账规则是结算扣手续费净额结算，还是不扣手续费全额结算，手续费后续另算。
24、是否有测试环境并提供测试卡信息、生产卡信息？
商户平时会接入的支付通道很多，大大小小的银行都会涉及，而测试人员基本不太可能拥有每一家银行的借贷卡。
在接入通道的初期，如果能够与支付服务提供商（通道）确认好，收集好相关卡信息，或者测试时有可进行协助的联系人，会使得项目测试全面、高效很多。
以上是笔者这些年接入通道的一些经验，只要按照上面这些问题确认好，一个通道的接入基本就已经成功了大半。