支付域——支付通道

摘要

老王经营着一个杂货店，在最初的阶段仅限于销售食品类、饮料类以及玩具类商品；这些产品大多来自大众品牌的官方渠道。尽管老王曾认为自己能够覆盖大部分消费者的需求范围；但在持续经营了一段时间后发现；现有的产品线已无法满足所有客群的具体选择偏好；顾客反馈的问题包括缺货频发、产品陈列不够吸引人以及配送时间较长等多重方面；与此同时；老王自身也在服务品质和服务效率方面遇到了新的挑战。

• 产品线未能完全满足客户需求 ，部分客户希望购买小家电或大家电等多样化产品，在此背景下老王杂货店仅销售食品类、饮料类及玩具类商品。
• 品牌选择受限 ，一些客户明确表示希望购买康师傅旗下品牌的产品如方便面，在现有销售范围内仅有康师傅和统一两种品牌可供选择。
• 型号供应不足 ，个别客户对口味有特定需求，在现有库存中康师傅红烧牛肉面能满足部分需求但无法满足所有特殊定制化需求。
• 产地限制影响销售 ，针对部分高端市场定位客户群体存在采购国外特色产品的强烈愿望但在现有供应链体系中尚无法实现。
• 客户的付款模式要求 ，企业客户多采用账期后付模式导致老王在 Moon 节点前需逐一为各供应商核对款项情况目前该流程较为繁琐。
• 供应商服务质量标准 ，随着业务规模扩大老王对其供应商的服务质量要求日益增多包括交货及时性、订单响应速度及售后服务保障等方面均需严格把控。

老王的经历其实类似于本博文探讨的支付问题。我们来看看将老王所遇到的问题与支付要求对应起来分析。

• 种类不满足对应支付方式不满足 ，支付方式有信用卡支付、借记卡支付、网银支付、账户支付等，这些方式可以归为两类：卡基和账基 。卡基是直接输入卡号、有效期等卡要素进行支付的方式，比如信用卡支付、借记卡支付等。卡基是支付最初的形态，无论是早期线下刷卡还是网银都属于卡基。账基是以账户为基础的支付方式，一个账户可以绑定多张卡。微信支付、支付宝都属于账基。如果一个商户一直沿用原有的收银台或者POS机，只支持卡基，不支持微信支付、支付宝，那么他就会越来越落后，甚至极端情况下，他可能无法收款，生意难以开展，毕竟现在用现金支付的人已经成为小众了。就跟老王一样，早期卖食品、饮料可以，而现在客户有更高的要求，他必须拓宽品类。
• 品牌不满足对应支付品牌不满足， 同一种支付方式可以有多个支付品牌，比如信用卡支付可以用中国工商银行信用卡、中国农业银行信用卡，第三方支付或账户支付有微信支付、支付宝、京东等各类钱包支付。支付品牌从主流的到小众的、从全国的到地方的都有，一个平台丰富支付品牌的过程就是健壮自己的支付能力的过程。要先支持交易量大的银行，比如全国十几家股份制银行，再支持交易量小的银行，比如各地城商行;先接入第三方（如连连支付等)，迅速支持尽可能多的支付品牌，再与各家银行建立直连。这就和老王的杂货店一样:先做大家耳熟能详的品牌，再根据自身情况做一些小众品牌;先找比较大的批发商迅速补齐和丰富品类，再想办法直接联系厂家，降低进货成本。

在卡片类型或 Bin 不满足对应要求的情况下, 每一张银行卡都有一个唯一的 Bin 号码, 每个 Bin 号码都包含发卡行标识代码 (Bank Identification Number, Bin), 即我们常说的 Bin, 通常由六位数字组成。自 2014年底起, 国际标准组织将 Bin 从六位数字调整为八位数字。例如某张卡片的前六位是 621485, 这就是该卡片对应的 Bin, 是招商银行借记信用卡的 Bin 标识码。对于招商银行信用卡这样的支付品牌, 根据合作渠道、发卡组织、发卡种类等的不同因素会产生不同的 Bin, 而一个支付通道往往因为缺乏处理权限或信息更新不及时等原因无法涵盖所有 Bin 号码。遇到上述情况后, 要么告知客户无法提供该服务功能, 要么通过引入其他支付渠道来增强自身的支付处理能力来支持客户

在内外卡通道下（即对应不同类型的卡片系统中），产地不满足的情况同样存在）。内卡指的是由同一国家内的银行发行的信用卡；而外卡则包括由其他国家银行发行的信用卡）。在外卡系统下（即国际 interchange 系统中），若使用国外银行卡在国内进行支付交易，则需要通过国际支付通道完成收单流程）。否则可能导致交易失败或被拒绝）。例如：客户需要的是海外进口商品蓝色网红版（即具有独特设计和定位的产品），但老王却提供了一款同一家国内银行发行的一百零八号位百事可乐黑钻版产品（即与目标品牌定位不符的产品），这显然无法达成理想的商务合作效果）。

付款要求的对应付功能 ，同一张卡有多重付款功能。付款功能不仅包含交易类型如一张卡可进行消费、预授权、代扣等不同功能的操作；还包含特性如有的卡无需CVV密保或短信验证码即可完成免密或免Token支付；有的则需要严格的密保措施以确保交易安全。此外付款功能还涉及交易币种方面针对同一张银行卡在不同使用场景下可能采用不同的币种进行结算如在国内使用人民币进行日常消费而在海外使用美元进行国际旅行等情形下同一张卡在不同时间地点会因使用需求而展现出不同的功能特征。对于同一张卡在特定的生活场景中则会调用其特定的功能以满足实际需求如入住酒店需先预付并冻结银行卡资金即调用预授权/扣款+退款功能；打车后自动扣款则调用快捷支付功能；公司按月发放工资时则会调用批量代发功能等具体情况不一而足。同一个银行卡在不同的应用场景中会切换并运用其相应的功能特点以适应多样化的使用需求如同老王经营小店向供应商转账时从主动转账到自动扣款的过程实际上也是对同一张银行卡不同功能的切换与应用过程

支付渠道的能力要求与供应商服务标准版的规定相对应

与老王经营商业事务相仿，在选择供应商时也各有侧重。他需要考虑如何根据自身实际情况去充分利用供应商的特性作为评价标准：货款要求与供货量需求相匹配;结账时效要求与对账期安排相协调;拒付风险率要求与商品破损变质退货换货政策对应;费率水平要求与供应商批发价标准相一致;专用通道设置（专线或公网）则取决于企业是否拥有绿色通道特权。不同业务场景下各供应商的特点决定了各自适用的标准体系是不一样的。因此，在选择过程中他必须针对不同供应商进行深入考察以实现其最佳效益方案的建立。

一、支付通道结构

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

1.1 支付方式

支付方式专指针对各类支付产品特性进行归纳与整理，并以特定形式呈现出来。
即为根据商户需求将内部的支付产品整合成统一的结算方案提供给商户使用。
例如, 信用卡支付作为内部结算产品可细分类型如信用卡MOTO, 信用卡快捷付款及代扣等。
常见类型包括但不限于: 信用卡支付, 储蓄卡交易, 网上银行转账, 第三方 payment服务等。

在超市购物时，请注意将薯片放置在零食区、可乐放在饮料区、脸盆放置在日用品区等不同的区域里。这些类别（即薯片、可乐、脸盆等）实际上相当于支付方式这一概念。

1.2 支付品牌

支付品牌是由特定的银行或第三方平台提供的特定服务标识，在同一类别的服务中可能存在多个不同品牌的提供者。 在同一服务类别下可能同时存在多个不同的提供者（即多个不同的银行或第三方平台），它们之间通过映射关系连接（如上图所示）。其中每一个提供的服务都对应着一个特定的品牌标识（即每一个提供者都对应一个独特的服务标识）。这种服务提供机制允许一个服务通道同时支持多种不同的服务标识（即一个渠道可能同时服务于多种不同的产品线），而每个服务标识也可能被多个渠道所支持（即一种产品线可能通过多种不同的渠道实现其功能）。

例如这类的 信用卡 支付 方式 包括 工商 银行 和 交通 银行 等 多家 金融机构 的 卡片 选项 。 其中 建行 直连 渠道 以及 银 联 渠道 均 能 使用 建 设 卡片 ; 银 联 渠道 不 仅 支持 建 设 卡片 还 支持 农 行 和 民 生 等 多家 商业 银行 的 卡种 。 同时 微信 与 支付 安卓 这两种 移动 payment 工具 也 属于 常见 的 payment 品牌 。

举个例子来说吧，在超市买东西时经常会看到康师傅、统一和日清等多个方便面品牌出售；这些方便面品牌的种类则类似于支付平台中的工商银行和农业银行等主要支付机构。

1.3 支付通道

支付通道具体指为由支付品牌背后提供的具备处理支付交易能力的具体服务提供商，如中国工商银行直连结算系统、中国银联标准清算系统以及连连通付款等。

举个例子，在超市购买商品时看到康师傅方便面的时候你会觉得这是一个品牌产品至于具体的供货商地区商家却并不清楚然而商家很清楚这些供应商的角色与作用类似于支付系统里的通信线路对于支付系统而言不可分割的部分被称为物理通道而根据接人渠道接入商户等因素拆分出来的部分则被称为逻辑通道

1.4 支付产品

支付产品是指根据通道的不同特性与维度进行分类和包装, 整理并包装成具有特定特性的商户类支付产品, 例如: 信用卡快捷支付功能、具备MOTO功能的信用卡支付服务以及用于鉴权的 specialized 支付工具等。

为了准确区分"payment method"与"product type"之间的差异，请关注以下几点：例如将"credit card payment"作为一种常见的payment tool时，在其特性上存在明显差异。因此，在这一领域内出现了两种不同的解决方案：一类是针对'credit card non-secure payment products'设计的解决方案；另一类则是专门针对'credit card secure payment products'进行优化的技术方案。值得注意的是，在支撑这些技术实现的基础之上（如基于相同的payment methods），这两种解决方案虽然均采用'credit card'作为主要处理对象，并提供了一定的安全保障机制（例如无闪付功能），但在实际应用场景上仍存在显著差异。

在现有支付体系中存在多种品牌化服务，在这些服务背后各品牌通过自身渠道触达消费者。各品牌通过自身渠道触达消费者，在现有技术架构下实现最低粒度的划分，并根据不同特性又形成了各自独特的服务形态。

二、支付通道的分类

在介绍流程之前，我们先探讨了出差住宿与购房的不同之处。出差期间选择酒店住宿时需要携带必要证明文件进行前台确认才能入住，在下一次行程中仍需重复这一系列步骤，并需确保每次都持有相关入住记录以及退房凭证方能离店。双方仅为一次性合同关系，在此过程中仅需完成订立合同时的各项手续即可。而购房过程则更为复杂繁琐，在这一过程中政府部门将对申请者进行全面审查包括但不限于各项条件是否达标、各项材料是否齐全以及税务缴纳情况等环节均需通过方能完成交易流程并颁发房产证。一旦房产证正式发放并领取钥匙后双方即转变为长期合同关系这种状态类似于客户被动支付与主动支付之间的差异在此期间客户可无 worrying地使用房产无需向房东提出任何额外要求

常见的支付渠道可分为便捷型和非便捷型两类。为确保理解的全面性和逻辑的严密性,本研究采用无磁条码、高密度编码作为非便捷型支付渠道的代表,并深入分析这两类渠道各自的结算流程。

2.1 非快捷支付与支付流程

使用无磁有密类进行支付时，则可以直接完成，并无需与银行等第三方机构鉴权。具体来说，在使用该类别的时候，则无需与银行等第三方机构鉴权直接完成支付流程。

1. 收集必要的个人信息（如卡号）、名字（姓名）、证件类型以及相关的证件号码等，并将这些资料提交至支付渠道。
   如果是使用信用卡进行交易的话，则还需核实其有效期以及CVV码。
2. 验证通过后会返回扣款结果：若所有提交的信息均准确无误，则付款成功（暂不考虑其他可能出现的问题）；若存在任何一项错误，则付款失败。
3. 在后续的付款过程中（即客户再次尝试支付时），仍需提供完整的卡片信息。
4. 如果客户提交的信息经过验证是正确的，则此次扣款操作成功完成；
   如果存在任何一项未能通过验证，则此次扣款操作将无法完成。
5. 验证失败的原因多种多样：
   主要原因是卡片号有误或缺失；
   持卡人姓名不符；
   证件已过有效期；
   证件号码有误；
   手机号填写错误；
   短信验证码不正确或已失效；
   密码不符合要求等情况。

注意 ：为确保客户银行卡密码的安全性，在常规操作中，并不会将银行卡密码交给商家或其他支付平台处理。因此现在很少使用“无磁有密”类型。几乎都是“无磁、天密、类”以及“快捷类”通道无需处理卡片信息。严格来说，“快捷类通道”也可视为属于“无磁无密”的范畴。因此在比较时建议将“无磁有密”类型与其他类型进行比较更能理解其特点。

2.2 快捷支付与支付流程

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

1. 签约流程: 签约方需首先进行卡片信息核验, 包括卡片号码、持卡人姓名、证件类型、证件号码、联系电话以及短信验证码等基础信息的核查工作。对于采用信用卡进行支付的情形,还需同步核查发卡银行的有效期及CVV值等关键参数。
2. 通道验证信息正确后, 在线系统会自动生成相应的协议编号或认证令牌, 并及时反馈至商户端。
3. 支付流程: 商户通过在线系统发起交易请求, 并通过协议编号或认证令牌完成扣款操作。
4. 通道将在线系统将上述交易结果即时返回至商户端。
5. 在后续付款操作中，则只需凭协议编号或认证令牌完成扣款即可。

分析两类支付渠道的处理流程可以看出它们存在显著差异，类似生活中的一个过程——比如出差外宿酒店与购置自用房产的情形。

• 环节间断 。非快速类的支付仅限于完成单一环节；而快速类的支付则分为两个步骤：首先需签订协议并获取协议编号后再进行付款操作。与非快速类类似，在出差期间使用信用卡完成住宿预订时也需要提供身份证明文件；但相比之下，在快速类中所需提供的各类文件则更为繁多。
  • 涉及的要素数量存在显著差异 。在实际操作中会发现，在完成具体业务时所涉及的必要要素也存在明显差异性特征；例如，在办理信用卡申请时通常需要齐全各项个人信息资料；而相比之下，在快速业务办理过程中所需提供的各类文件则较为简洁。
    拿到差旅住宿预订为例：出差期间使用信用卡完成住宿预订时只需提供身份证明文件即可；而在快速业务办理过程中所需提供的各类文件则更为繁多。

2.3 支付通道分类

依据用途、支持对象、支持形式以及发卡行地区的不同特点, 我们可以将支付通道具体分为如图所示的几类. 下面将详细阐述各类别的具体情况.

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

• 出款通道：完成资产所有者的资金支付行为的资金流动渠道被称为出款通道。该渠道主要包含两种类型：一是通过银行的代发/代付服务实现的资金转移；二是基于转账结算的方式完成资金转移任务。该功能主要用于处理提现操作、员工工资发放以及商品和服务退款等业务场景。
• 入款通道：接收资金的资金流动渠道被称为入款通道。该渠道具有多样的形式和类型，在实际应用中主要包括但不限于网银转账、微信/支付宝扫码支付以及银行卡快捷支付等多种方式；其应用场景也非常广泛，在日常生活中主要体现为网上购物结账时的网上支付功能、扣款业务的操作流程以及水电费等日常服务项目的在线代缴功能。
• 特权通道：与支付环节无关的信息验证确认的专用渠道被称为特权通道。该类渠道主要用于对交易双方的身份信息进行核实确认，在实际应用中主要包含但不限于卡信息验证（如信用卡背面数字验证）、身份信息认证（如手机号码校验）以及OCR文字识别验证等功能；这些功能在实际使用中常见于微信实名认证功能或支付宝实名认证模块的应用场景。

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

• 口对公支付 ：针对企业账户或资产进行扣款或付款的操作，具体涵盖如企业网银服务、代扣业务以及内部转账等多种形式。
  • 对私支付 ：针对个人用户账户进行扣款或付款的操作, 其中涵盖了如银行卡支付、微信支付及支付宝等多种第三方个人账户的结算方式。

根据支持形态．．．

卡基的特性如下：

• 卡基的核心要素由单个银行卡构成;
  • 资产主要以单个银行卡为载体进行存储;
  • 除了刷卡交易之外, 支持的方式包括POS机刷卡交易, 手机闪付交易, 银行电话转账及短信通知, 网上银行转账及短信通知, 以及线上非磁条非密钥式交易等多种方式。

账基的特性如下：

• 账基的主要功能是身份认证与密码验证相结合。
  • 资产被存储于账户中。
  • 在线交易中，
    • 用户可以选择以账户余额作为支付依据，
    • 或者选择通过银行卡或其他电子钱包的形式进行支付，
    • 常见的主流支付方式包括微信支付和支付宝。

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

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

• 发采用发卡方式的境内银行（包括外资银行）;
  • 卡上的本币代码对应人民币;
  • 卡 issuer 为银联。

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

• 发卡主体包括境外银行和中资银行的海外分支机构；
  • 卡片采用外币作为其本体货币；
  • 卡组织涵盖银联、Visa、Mastercard和JCB等多个品牌。

特别强调的是：内类与外类并非泾渭分明、非此即彼的情况；有些卡片在特定情况下可被视为内类；而另一种情况则被视为外类；例如：发源于中国的招商银行Visa单标信用卡；从发Card行或Card组织的角度来看：这类信用卡既可以被视为招商银行信用卡；又可被视为Visa品牌下的单标信用卡；如果该直连通道作为本行业的支付服务提供商自行受理相关业务；那么它应被视为招商银行信用卡（inner card）；然而；如果该直连通道被海外支付机构接受：那么它则被视为Visa类型的信用卡（outer card）。

2.4 账基支付起源

如何起源与发展账基支付这一现象？在支付领域有这样的理念：通过掌控信息流动来调节支付流程；通过管理支付流程来影响资金流动；拥有网络接入许可的价值高于拥有资本的所有权；数据投入的规模胜过资金投入的规模。账基支付最初源于第三方平台，在实际应用中最为普及的就是像微信支付和支付宝这样的第三方服务。

最初阶段, 第三方专注于那些银行并不十分重视的中间业务, 这类业务通常涉及交易信息层层过手, 包括铺设线下终端点（pos机）, 搭建线上支付接口（网关）, 并将商户与客户的信息提供给银行渠道, 收取一定的服务费, 从中获取额外收益。随着交易量的增加, 产生的数据也随之增长, 第三方开始将注意力转向对这些数据进行深度挖掘与分析（即我们常说的大数据分析）。由于当时尚未建立完善的征信体系, 第三方主要通过分析用户的购物行为、交易金额以及地理位置等数据来评估风险并应用于风控工作

随后,那些身处幕后的人不再甘心一直隐秘 operates,而是渴望将交易活动、用户群体以及资金资产转移到自己的平台上来。于是他们开始建立自己的账户体系,其中设有企业账号和个人账号，并提供存款、转账以及查询等服务功能。这就是我们所说的账基支付。

但是如何让用户通过你的账户进行操作呢？在传统支付模式中，“做支付先要做收单”。初期阶段的应用服务主要集中在围绕账户提供基础功能服务,例如水电煤-like的费用缴纳,信用卡还款,电话费充值等场景;然而随着行业的发展和竞争加剧,这些平台逐渐转变思路,将 focus 放在通过直接投资控股或并购拥有大量流量的线上线下公司,并要求这些公司必须仅能接入自身平台的支付系统,或者采取措施将竞争对手的其他 payment 系统隐藏或置于次要地位（例如饿了么对微信支付的操作策略）。到了 account 系统成熟阶段后,用户的数量显著增加,第三方势力开始不断拓展更多应用场景,从原来的单纯的 payment 业务延伸至理财类业务、信贷产品发行以及保险销售等多个领域（甚至延伸至虚拟银行与实体银行的合作构建）。每一次业务拓展都带来了行业的认知更新

通过分析第三方支付的发展历程可以看出 初始阶段采用的是银行卡（卡基支付）的形式 随后逐渐演变为今天的账基支付体系 实名认证是账基支付的重要特征之一 并且该系统还支持绑定多张银行卡 并广泛应用于多种应用场景

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

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

2.5 内卡外抛现象

在支付领域存在一种称为"内卡外抛"的现象，在这种情况下"内卡外地"指的是国内发行银行卡应当通过内部支付渠道进行交易与清算但因操作失误而被错误地转移至支持外部卡片交易的渠道这种失误导致的结果是原本应通过内部渠道完成的操作却借助外部渠道执行例如一个价值1000人民币元的商品订单若使用工商银行Visa/银联双重品牌信用卡进行支付理论上应通过工商银行内部卡片连接系统完成交易与清算然而由于操作失误该笔交易实际上却被错误地引导至发卡行外部卡片处理系统

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

第一，误操作。

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

第二阶段的线上处理流程出现了若干问题。这些异常情况具体表现为多种不同的问题类型。例如，在BIN识别环节出现偏差时,可能导致将内部设备的数据或资源迁移到外部系统中。

在卡片(BIN)属性中包含支付品牌、支付通道、卡片类型名称、卡片类型类别以及内/外卡属性等信息。如果将内/外卡设置错误就会导致出现内牌在外抛出的情况。

例如错误地设置了路由规则．将外卡通道配置为支持内卡银行。
在介绍支付通道结构时已经提及，在该系统中每个通道都对应多个支付品牌。如果将内牌产品配置到外牌渠道，则会导致当路径选择时系统误判可用通路。
例如错误地设置了双币种种类逻辑，并设置错了内外牌优先策略。
在支付系统里我们会根据是否涉及内/外交往进行分类设置，并根据交易国家进行关联配置。

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

• 内外卡交易时涉及的费用币种不同。通常情况下，默认按人民币计费的是内卡，在与国际银行卡发生交易时则按美元计价。
  • 如果商户出于自身利益考虑（将双币种卡视为外币信用卡处理），将其视为外币信用卡按照美元进行结算处理，则在外汇兑换过程中会产生汇差。
  • 如果商户为了谋利（ Dynamic Currency Conversion, DCC），即直接按美元进行结算，则在外汇兑换操作时必须按照银行标准汇率加上一定比例的服务费（通常按照银行标准汇率加上一定比例）。其产生的额外费用非常微小，在实际操作中几乎察觉不到。
  • 因为这种方式能够在结算中带来一定的收益优势（即多出部分服务费用于冲抵部分手续费或返点），所以商户倾向于采用这种方式。

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

因为 Magnetic card terminal operators typically charge higher fees for foreign transactions than domestic ones, some Magnetic card terminal operators aim to obtain higher fees by engaging in cross-border Magnetic card transactions.

第五消费者要求。

因为各卡组织或银行会有定期或不定期的营销活动, 所以用户为了享受各项优惠而采取行动, 并选择使用某个特定卡组织进行交易。

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

1. 不合规《中华人民共和国外卡管理条例》规定:境内禁止流通外币货币,商品不得以外币进行计价、结算,若出现内卡与外币混杂的情况,会导致部分交易以人民币以外币计价,进而使市场货币供应量和交易监控数据失真。
2. 在市场上,由于外卡通道手续费成本通常显著高于内卡通道,若在商户不知情的情况下发生收单方进行内卡与外币现钞混杂交易的情形,将会导致商户的手续费成本上升。
3. 在市场上,由于银行通过outer card收取一定手续费,并利用汇率转换机制获取基准汇率水平上的浮动收益部分;而收单方则可退还这部分上浮差额。

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

1. 费用上升的情况有两种：
   情况一，在本币兑换外币的过程中，在还贷或记账时再次兑换回本币，会导致额外产生两笔货币兑换费用；
   情况二，在商户计价时引入了汇率上浮比例的处理方式，从而增加了实际支出的成本。
2. 消费者若参加发卡机构或组织的营销活动，则可获得相应的收益。

三、支付通道接入流程

一条通道犹如一双鞋子，在连接过程中必须经历裁剪缝制成型这一系列工艺步骤。每个成品都凝聚了多个人力与多个工艺环节及标准指标的支持与保障。在连接过程中必须核对各项细节以确保后续服务能够顺利开展。这些细节构成了公司对外支付能力的实现基础，并为产品的打包提供了技术保障。项目管理流程涵盖商务团队（包括负责合同审查的法务团队）、产品经理以及开发工程师等多个核心岗位。各角色在其项目中的出现次序及其职责分配将直接影响项目的推进效果

负责人	工作职责
商务人员

• 筹 unsigned 合同（包含费率、赔付款条件、计费方式等)
  • 确定商户编号
  • 收集对方联系方式信息
  • 整理相关接口文档资料

• 考察通路可用性、关键节点的具体说明以及测试功能范围
• 安排项目开发周期并完成需求分析文档的撰写与评审会议
• 对银行返回的信息数据进行整理分类，并生成相应的展示呈现形式

• 服务器准备
• 专线评估与接入

• 评估项目内容，给出排期及提测日期
• 项目开发、自测及提测

• 测试环境和生产环境准备
• 测试案例验证
• 测试报告交付

主管基本结算户的开立和维护
审查和验证资金文件以及相关凭证材料
负责资金调配

• 安排生产验证及切量方案
• 验证通过，观察数据
• 全面配置生产路由规则

||

四、内卡支付接入流程

内卡(国内银行卡)如今普遍被各商家采用的一种便捷支付工具，在我们的日常生活中也屡见不鲜。由此可见，在介绍相关业务时，我们首先应当了解内卡通道的具体运作方式。特别强调的是，在本节内容中所涉及的内卡支付仅限于卡片基础支付（card-based payment），而账基支付（account-based payment）则不在本次讨论范围内。

在内卡通道接入过程中需要注意很多细节，在这些细节中每一个都会影响到通道能否顺利接入和成功支付。下面我们将通过提问的方式介绍在不同情况下需要注意的各种事项及其相关说明。

4.1 内卡支付问题

4.1.1 支持的卡种有哪些?

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

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

在接人渠道中（Vendor）被划分为两类：其中一类是与本行直接连接的业务伙伴；另一类则是通过第三方支付平台进行连接的服务商。对于直接与本行实现业务对接的企业（如工行快捷通业务），其仅能服务本行信用卡；而不同机构可以通过第三方平台服务多种银行卡号（如农商总聚合可覆盖农商行、招银卡中心等多家机构信用卡）。在实际操作中，请确保能够明确各合作方对应的银行卡号范围

除了明确支付通道提供方所能使用的银行之外, 支付通道接入方还会与支付渠道商确认是否可获得卡片 BIN 表信息, 或者明确不支持哪些卡片 BIN。如果无法获得, 可以临时使用银联发行的信用卡或借记卡卡片 BIN。这是因为按照现行发卡管理办法及银行卡 BIN 的申请流程, 所有卡片 BIN 都需要由发卡机构向国家银联申请, 所以理论上银联提供的 BIN 段位最为全面。

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

在之前的介绍中提到，在康师傅旗下方便面产品线丰富多样，并按编号系统进行分类管理。按照编号系统进行分类管理后发现，在康师傅方便面产品线中按照编号系统进行分类管理的情况下，并非所有产品都能实现同步供应。部分商家在实际经营中存在缺货现象，在这种情况下若顾客希望购买编号为10的产品时（即康师傅旗下某款特色方便面），若商家无法确认库存情况则可能存在问题。类似地，在卡片交易系统中（即Bin码支付系统）也存在同样的问题：若通道不支持某个卡种（即Bin码），则可能导致支付过程受阻，并出现退款现象。

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

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

• 消费:主要指我们的扣款交易行为，在狭义上具体来说是与预授权交易相区分的特定类型交易。例如，在超市购物支付100元时使用信用卡完成的这笔100元交易就是典型的消费类交易。
  • 鉴权:与支付交易无关的验证过程,不牵涉到任何交易金额,其核心在于对用户身份信息或卡片信息的有效确认。例如很多网站都会要求实名认证流程,需要用户绑定银行卡信息,但不会发生资金扣除的情况,一旦银行卡信息成功认证,则完成实名认证这一目标。
  • 预授权:商户向发卡机构申请一定额度范围内的扣款权力,该权力会在后续操作中由发卡机构进行审核批准后才得以正式执行。预授权操作会占用持卡人卡片内的可用额度或资金余额,只有在发卡机构确认并批准了后续的结算操作后,卡片内的额度才会恢复或者退还相应的资金。
  • 代扣:也被称为代收业务,是由用户主动申请并由商户发起的一种针对指定账户的资金扣除业务流程。它具有以下显著特点:支付操作要素简单、按笔收取费用、无资金退回功能、支持单笔实时扣除以及批量处理等多种服务模式。有人这样评论道：“代扣是支付公司运营的生命线,其他业务都是辅助性质”、“代扣是构建支付体系的基础模块”。由此可见,一家公司具备较强的代扣能力并且能够覆盖较多的银行账户类型,将在激烈的支付市场竞争中占据极大的优势地位。
  • 代付:由商户主动发起的一种从自身结算账户向客户资金账户进行付款的操作模式。它具有以下显著特点:支付操作要素简单、按笔收取费用、无资金退回或撤销功能、支持单笔实时付款以及批量处理等多种服务模式。

4**.1**.5 关联交易类型有哪些?

关联交易类型主要包含核销（包括每日核销）、检索（涉及签约范围内的查询以及具体的业务操作如交易处理、退货管理等）、取消（仅限当日操作）、退货运费（隔日结算或当日处理）以及预授权的关联业务等。以下将展示核销及检索交易类型的具体操作流程。

在涉及支付交易的各种情况下,不仅包括预期的成功与失败,还可能因系统异常等因素导致无法获取到服务提供商的反馈信息.但每笔交易都必须设定一个明确的时间截止点,不可无限制地拖延下去,避免让用户持续关注订单处理状态而不了然于心.当出现类似情况时,可以通过发起退款请求或者重新查询状态来应对这种情况.

冲正是系统为应对交易结果未知而设立的一种补偿机制。
商户因系统出现超时或异常导致支付结果不确定性，
因此向支付服务提供商提交冲正交易请求，
并进行回滚处理。
无论原订单是否成功或失败……均需取消该笔订单。
完成冲正后……向用户反馈支付失败……
并重新发起相关支付指令。

冲正当面对无法预判订单结果时能够实现交易回滚, 而撤单与退单仅限于已确认成功完成的订单,无法用于处理其他情况。

查询是一种用于解决交易结果未知问题的补偿机制。当系统无法明确确定无交易结果返回订单的状态时，它会建立相应的规则框架，并每隔5分钟发送一次请求指令给支付服务提供商进行状态查询，在持续至第30分钟结束期间执行此操作。如果在查询过程中获得明确的成功或失败结果，则更新相应订单的状态；如果持续到最终时间仍未获得结果，则一般情况下会被标记为失败状态；商家在对账单期间检查交易状态后确认交易是否成功：若确认成功，则完成退款流程。

在协议式支付或快速式支付中，在使用这些服务时首先要进行签约流程，并根据系统自动生成独一无二的合同编号；每个合同都有对应的解除程序，这个过程被称为解约或者解绑。这是一种常见的术语。

4**.1**.6 是否支持预授权关联交易?

预授权关联交易种类繁多，在通道接入时需要与通道方明确商支持以及支持哪些预授权关联交易具体可分为几类

• 预 authorization 完成：涉及将 pre-authorization 交易产生的 partial payment 转换为 实际全额支付 的处理流程。在 pre-authorization 过程中, 支付额尚未结算至商家账户, 只会在客户账户临时冻结; 当 pre-authorization 完成时, 支付额将 实际全额结算给商家, 客户账户从冻结状态转变为实际扣款消费状态。
• 预 authorization 部分完成：涉及将 pre-authorization 交易产生的 partial payment 转换为 实际按对应的部分金额 结算给商家 的处理流程。当 pre-authorization 部分完成时, 支付额 将针对请求的相应部分金额 进行结算, 客户账户从 partial payment 冻结状态转变为实际扣款消费状态, 剩余未结算的金额则会自动撤销, 恢复额度或退回款项。
• 预 authorization 完成撤销：针对已经 实际全额结算 的 pre-authorization 支付额进行 全部撤销 处理, 退回客户账户等同于退款功能。“普遍是指 全部撤销 ”。
• 预 authorization 完成部分撤销：涉及针对已经 实际全额结算 的 pre-authorization 支付额 中的部分金额 进行 全部撤销 处理, 退回客户账户等同于退款功能。“是指针对已经 实际全额结算 的 pre-authorization 支付额 中的部分金额 进行 全部撤销 处理”。pre-authorization 撤销：解除 pre-authorization 交易所获取的 partial payment 权利 的处理业务。“pre-authorization 撤销时, 支付额 将从客户账户解冻”, 恢复额度或退回款项。
• pre-authorization 追加：原有 pre-authorization 因各种原因需 增加支付额度 ，发起交易类型为 “pre-authorization 追加”的处理流程。“在现实中有很多商户会将原有 pre-authorization 进行 撤销 , 然后重新发起一笔新的 pre-authorization 追加 交易。”

4**.1**.7 预授权自动解冻时间是多久?

银行对预授权的相关规定如下：若在特定时间段内未进行预授权操作，则会被系统自动撤销权限，并通常设置为30天的有效期。然而，在某些特定的业务场景中（例如酒店预订服务），为了避免因未及时处理而导致的损失问题，则需提前明确规定的截止日期，并在此期限内完成相应的预授权操作。

4**.1**.8 关于快捷通道的.些问题。

快捷交易通常需要在签订协议前生成协议编号（Token），之后才能进行支付。银行的快捷签约方案对商户而言主要包含两种常见的设计模式：一种是基于电子签名的模块化设计；另一种是基于区块链技术的分布式记录方案。

• 开口商户—银行卡号码结构，在基于商户信息及其相关的银行卡号码上实施统一管理规则。
  • 不同会员账号对应具有相同银行卡号码的不同业务类型或服务。

两种架构在应对复杂业务需求时表现出不同的灵活性特点。商户-卡号架构相对较为单一，在处理多用户共享同一张银行卡的情形时显得力不从心。当一个用户解绑银行卡时，在这种架构下会导致与之关联的其他用户的账户受到影响而无法使用该银行卡进行交易操作。这种连锁反应在实际运营中容易引发业务中断的风险，在现实场景中这种情况的发生频率较高。例如，在公司日常运营中常见的情形是：公司老板指示部门秘书将公司的信用卡与公司账户关联起来用于采购费用报销；一旦秘书离职或更换，则由接替者负责操作该信用卡导致公司账务无法正常结算；当秘书离开后其使用的信用卡随之被解绑无法继续用于后续工作流程的申请

4**.1**.9 快捷支付是否支持重复签约?

重复签约涉及卡片号的再次签约行为。
需要确认该行为是否被认可，
例如，在进行重复签约时，
系统会自动核实卡片信息无误。
如果上述条件满足，
则系统将返回"成功"状态；
反之，
则无法完成签约。

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

• 实名制规定：仅能将身份卡用于已实名认证的账户;
  • 允许一个身份卡片同时服务于多个注册账户;
  • 同一注册账户的身份卡片可重复绑定。

在这些场景中, 必须明确该方案是否支持重复签约, 并确保每次签约的信息验证独立且不影响之前的已签约情况. 若方案不支持该功能, 则需进一步确认其对已签卡号的验证要素是否正确并返回协议号.

例如通道不支持重复签约操作，在已有卡片号被成功签约后再次尝试签约时，系统会显示‘已签约’的状态。那么我们有必要将不同渠道的处理逻辑进行区分对待，并认识到同一渠道下的不同处理逻辑会导致支付平台内部的处理机制存在显著差异。

当系统判断卡片处于"已签约"状态时，并且经过验证确认其卡片要素无误（若非如此则会输出"卡片信息有误"）。由此可知该卡片要素必然是正确的。支付机构可因此直接获取该原始卡片号所对应的交易流水编号来进行结算。在此判断框架下若同时提供原始交易流水编号，则可一次性完成后续服务处理流程。

鉴于此为支付平台，在预期的情况下要求银行能够支持独立验证的重复签约行为，并且这一机制不应干扰先前已经完成的签约记录。若该条件未能得到满足，则希望银行在确认要素无误后告知'已签约'状态，并在告知'已签约'状态时，请确保同时提供原始协议编号。

实际上情况可能不如预期那么好,完全没有支付通道会仅返回确认状态信息'已签约',其余部分则需由支付平台的产品经理自行处理.根据确认情况的不同,对应的解决方案也会有所差异;若未进行确认,则可能导致一系列问题.我们将在两种不同的场景下分别阐述.

在实名制下,用户的卡片仅限于该用户使用！经过实名认证的账户可以在同一时间段内绑定多张相同的卡片。

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

• 若重复签约功能不可用，则该用户选择删除该卡片或者由于遗忘未能再次绑定卡号而导致订单无法完成支付。
• 若重复签约行为会影响先前签署的协议，则可能导致其他业务模块记录的有效性受到影响（即其他业务模块记录中的协议编号信息可能失效），但系统方并未意识到这一问题继续发起交易操作将会产生交易拒绝的情况（即这种情况会成为数据完整性的问题）。
• 如果跳过对"已签约"状态的要素验证以及不再返回对应的协议编号信息，则必须依赖额外的身份认证数据库来完成鉴权流程，并在确认交易要素有效性后调取此卡号下的原始协议编号信息。

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

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

• 当其他用户尝试在同一个时间点为同一张卡进行续签时（无法实现），将会导致续签操作失败或出现报错提示信息："该卡已由他人占用"。
• 如果这影响了原有用户的成功续签，则A用户的续签请求将被拒绝（导致B用户的原有绑定关系失效），从而使得B用户后续的操作也将无法成功完成（从系统角度来看这就是一种无效的认证数据）。
• 在处理"已签约"的情况时（未返回关键要素），则需要通过独立的鉴权流程获取该卡片的相关信息（包括协议编号等重要参数）。

比如说大卫在一个网站上使用自己的账户购买过东西 当时他使用的是招商银行信用卡完成了一次支付操作 卡号是123 大卫将这张银行卡交由助理小黄保管 小黄同样在这个网站上登录其账户进行公司采购 在其支付过程中使用相同的卡号（123）完成交易 该支付流程也需要先完成签约流程 如果小黄在支付时没有完成签约流程 这种情况不会对大卫的账户支付操作产生任何影响 如果系统不支持重复签约功能 那么在这种情况下 系统必须验证相关的要素以确保安全 为了实现双方独立的操作环境和数据保护需求 该平台需要对鉴权机制 卡片服务功能以及用户数据进行全面而细致的审核

如果金融机构在处理重复签订协议的情况时无法提供协议编号，则商家需自行获取相关协议号码并核实相关信息。

4**.1**.10 用户签约后若支付信息变化、协议号是背有效?

支付所需的信息主要包括银行卡号码、持卡人姓名、证件类别以及相关的证件号码和手机号码。如果使用的是信用卡，则还需要附加发卡行的有效期以及 accompanying CVV号码。由于快捷支付采用协议编号作为扣款依据的方式，请确保这些关键信息不会发生变更以避免影响交易的安全性与可靠性。

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

• 协议号码与卡片号码具有密切联系，在多数情况下卡片号码的变化会导致协议号码必然失效。
• 在多数情况下，在以下信息发生变更时（包括但不限于姓名、证件类型以及证件号码等），不会影响到协议号码的有效性：证件号码的变化、姓名的变化或证件类型的变化。
• 如果超过了有效期且未进行卡片续办，则该协议号码将被终止生效；然而即使是在有效期发生变更的情况下（如更换了新卡片），原有的协议仍然能够继续使用。
• 受不同银行的具体规定影响，在某些情况下（即当CVV数值发生变化时）该协议依然保持有效性；而在另外一些情况下（即当特定条件下的CVV数值发生变化时）该协议则会失去其原有的效力。

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

部分金融机构或第三方支付平台仅提供退款功能。而其他金融机构可能同时支持撤单和退款两种功能。当进行对接操作时，在实际应用中通常情况下撤单操作会全额结算，并且仅限于当日处理。因此，在实际操作中需要根据具体对接的金融机构或第三方支付平台的接口类型采取相应的策略

• 情况一：仅包含单一的退货功能。需要核实当天交易是否允许直接调用该平台提供的退货接口（无论是全额还是部分金额），或者该接口仅与常规的退货流程一致，在隔日后才可使用。
• 情况二：包含撤销和退货两种功能。需要核实当天交易发生的部分退款时能否利用撤销功能处理（但根据规定撤销仅针对全额退款适用），否则需等到隔日后才能通过常规的退货流程完成退款操作。
• 通常情况下，在商户系统中当天发生的交易将首先处理部分金额的退款请求（如果是存在的话），而待到隔日后则会将这部分款项转交给通道进行最终处理。

4**.1**.12 订单最退货时间是多久?

退换货时间为退款完成的时间段，在线结算方通常会对订单线上退换货操作设定最长处理期限（如60天、90天、180天、360天等），当超过该段时间后，系统将无法通过线上系统直接操作完成退款流程，请及时联系相关部门进行人工处理

4**.1**.13 退款发起和到账时间分别是什么时候?

用户会关注退款资金的到账时间。为了解除噪音干扰的同时也需要告知用户预计到账的时间。在接入通道时应尽量与通道方确认每个渠道或银行的到账所需工作日数。如果给出的时间偏短可能导致未能及时到位而引发投诉。如果给出的时间过长（例如实际仅需3天却声称需要15天），这将导致用户的差评。

4**.1**.14 退款是否要求当日进款大于退款?

一些渠道设定每天正向付款额必须超过逆向付款额方能申请退款。当未验证此问题时，在执行测试或深入分析时可能遇到昨日完成的一笔扣款测试交易 today发起退款却无法成功 find查找问题也无果而终的情况。实际上这是因为该渠道设置了当天退款要求尚未入账因负向付款额超过正向付款额故无法操作。

因此需要采取这一措施是因为在进行T+1结算的情况下通常是前一天就已经完成了款项结算。如果第二天不设置具体操作限制允许商户可以直接申请退款若发生异常情况可能会导致通道系统的重大风险因为此时不会进行进账操作且涉及金额巨大这将可能引发通道系统的严重问题

4**.1**.15 退款退不退手续费?

在账户系统进行落地数据与收银系统的匹配过程中涉及的账单定制规则中的退款属性项都会被应用到。通常情况下，在代扣和代付类型的交易通道中进行退款操作时不会退还手续费；而对于无磁条和无密条等其他特定类型的交易通道来说，在进行退款操作时会退还相应的手续费。

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

正交易通常指的是收入类业务。例如，在具体操作中会遇到代扣、消费和预授权等情形。负交易则涉及退货操作、撤销申请以及代付请求。如同前面所述，在系统中仅允许进行全额撤销操作

当发生一笔交易时，并且当天也完成了全额退款，请明确第二天的对账单是否会出现相关记录？是两笔交易均不会在对账单中显示还是都会显示？这一规定将直接影响后续的结算与核对流程。

4**.1**.17 支付要素有哪些?

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

• 借记设备:账号编号（持卡人账号）、持卡人名称（卡片持有者名字）、身份验证类型（认证方式）、身份证号码（身份证号码记录）、联系电话（联系电话记录）、短信验证码。
  • 信用设备:账号编号（卡片持有者账号记录）、持卡人名称（卡片持有者名字记录）、身份验证类型（认证方式记录）、身份证号码（身份证号码详细信息）、联系电话（详细联系电话记录）、短信验证码（手机短信验证码记录）。
    此外, 卡片后三位数字密码 （CVV） 和有效期限也是重要参数。

证件种类繁多；一般会关注的是国内业务能否办理这几类证件：身份证、护照、港澳居民往来内地通行证（俗称‘回乡证’）、台湾居民往来大陆通行证（俗称‘台胞证’）。表2-3给出了银行开户时需要的证件类型。

在实现接入过程中

4.2 内卡支付场景分析

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

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

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

• 结果一: 交易失败. 根据以往经验, 支付效率方面存在较多关注点. 发现缺少的部分原因通常源于商户自身配置不当或系统运行异常, 在数据传输环节可能存在某些关键信息被截断或遗漏导致未能完成发送. 当缺少关键要素时, 大多数情况会导致交易失败, 这些无效操作直接造成了支付成功率的下降, 是一个不容忽视的问题.
• 结果二;当缺少部分信息时, 极少数情况下仍能完成扣款. 导致这种情况的主要原因是通道方自身在特定条件下可能缺乏强制性检验机制, 通常并非每次都进行严格校验, 在极端情况下甚至完全跳过检验步骤. 这种情况极为危险, 因为即使正常发送所有信息也能顺利通过支付流程的同时仍可能面临拒付风险.

4.2.3 验证码的规定？

在短信验证码的设计过程中，有几个关键要素需要进行严格审查。为了全面覆盖各种使用场景，在介绍具体的验证机制时，默认选择一个常见且重要的应用案例：通过便捷通道快速完成签约及支付流程。

问：短信发送方是谁?

请解答：需明确签约短信发送方与交易短信发送方各自的身份是什么，并由哪一方操作？

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

需要明确的是，在两个环节均需发送的情况下（即用户将收到两条短信），而如果是只会下发一条的话（即用户将只收到一条短信），则需进一步确认具体逻辑设置。为了提升用户体验，在一笔交易中如果既存在签约流程又存在交易流程，则应确保以下两种情况：如果已发送了签约短信，则支付相关的短信就不会再下发；如果已完成了签约，则本次仅有的支付流程是单独的支付请求处理。综上所述，在这两种情况下（即两步操作均需发送相关通知），用户只会收到一条相关的短信。

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

回答：前端页面主要通过早期阶段拦截已知错误并采取相应措施。例如，在用户输入短信验证码时出现字符数量超出设定时系统会报错提示。为了确保准确性和可靠性我们通常将短信验证码字符长度设置为6位或4位。

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

答：考虑到短信发送存在一定的成本，在实际应用中各通信渠道方为了节省运营成本、同时又能有效防范恶意点击及误点行为等风险问题，在制定相关操作规范时通常会设定短信发送间的最小间隔时间（例如60秒），而部分企业则会对每日允许的最大发送次数进行严格限定；在接收通道端口时，则需依据这些参数设置相应的前端系统参数配置

例如通道规定短信验证码每分钟发送一次，则前台应设置倒计时至少为60秒以避免用户因无法及时收到短信验证码而影响支付体验进而导致支付体验的不满或用户放弃支付行为。例如通道还规定了每张信用卡最多可发送的短信验证码数量限制因此前台系统需相应地建立计数机制并准确统计每次发送的数量。

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

答：由于多种原因可能导致用户出现拒付情况，在具体情形中可能包括非本人完成交易、银行卡被盗等情况。短信验证码作为一种身份认证工具，则必须明确责任归属：是谁发送验证码、是谁接收并验证。

问：短信内容是什么?

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

××支付

××支付

××支付

××支付

在接入过程中，商家应尽量要求通道方使用自身商家名称作为短信发送方；支付机构在制定短信内容模板时应支持根据不同入网商户主体显示不同名称。

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

大多数通道为用户提供了一个限制标准...分别设置为单笔、单日和单月的限制值...若超出限制则会出现错误提示...其中部分银行不仅对商户设定有相关限制...甚至规定每次调用次数不得超过一定范围以防止资源被过度占用...针对这一问题如何规避呢？一种可行的方法是采用计数服务来统计当天交易笔数以确保不会超出预设阈值...同时也可以引入重试机制将未能完成的交易重新分配至其他可用通道以便提高处理效率

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

在实际接入通道操作中, 某些银行或第三方支付机构提供可选服务, 帐号商户可以根据自身业务需求自主选择相关服务项. 在提交交易请求时, 可以选择最小支付要素, 即仅包含必选项; 或者提交最大支付要素, 包括所有必选和选修要素.

具体来说，则分为以下几种情形：当需要最小化支付成本时采用最小支付要素；而当要求最大化收益或满足特定约束条件时则采用最大支付要素。

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

在特定情况下（尤其是针对新用户或某些特定场景），为了确保信息的完整性与全面性（尽可能覆盖所有相关信息），系统会要求用户提供尽可能全面的信息以完成鉴权认证流程。基于此原则，在实际应用中发现：当目标是降低交易失败率、提升转化效率时，则更倾向于采用最小支付要素策略。

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

从名称上可以看出，
银线即为专用网络，
采用银线后即可实现独自使用，
安全性较高，
操作流程较为繁琐，
可能导致整个项目的周期延长，
相关费用需定时支付，
公网即为公共网络，
在同一时段有多家商户在此进行业务请求，
接入方式快捷且无须支付任何费用，
不法行为可能导致自身服务中断或受到性能影响

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

并发度相当于高流量餐饮场所的最大承载能力。若顾客数量过多超过该场所的最大承载能力，则需采取分流、排队或引导至分店等措施来缓解客流量压力。支付渠道同样面临类似挑战：需明确其承载能力是否属于单一使用或共用场景。当支付渠道的承载能力超出限制时，则应借鉴分流策略。针对支付环节的优化方法主要有两种

• 分队列管理当系统单秒最高可接收10条事务时,因营销活动上线带来了同时在线的100条事务请求.此时可将这些事务划分为若干队列,每个队列包含若干事务等待处理.这种管理策略将导致约95%的事务失败率,但通过合理分配负载后即可实现所有事务都能得到及时响应和处理.
• 与前一场景类似,对于单秒最多接待1条事务的情况.为了确保系统稳定运行,在设计时应预留冗余配置.当出现突发高负载时,系统会自动将多出来的事务转移至其他可用通道进行支付.类似零售业应对高峰期的情况（如 overwhelm the checkout counter when multiple customers are queuing）,加快服务流程以缓解压力.

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

当我们接入支付通道时，在日常操作中我们通常会将最低交易金额设定为零点零一元（即1分钱），但是一些特殊通道可能会设定不同的最低交易标准（例如零点一元或一元）。操作过程中需要注意这些细节设定从而防止因这些细微差别导致的交易失败

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

"日切时间段是指上一工作日后一天的时间段结束时刻。举例来说,我们通常将'当日截断时间'定义为每日午夜时分,除非另有特别说明,否则所说的'工作日后一天'即指次的日界线零时之后。所有交易记录及提供给系统的对账单数据均基于从:（即午夜）至第二天同一时间区间内作为单一统计周期,而产生于:时刻之后的交易或记账单需在下一完整工作日后完成记录与发布流程。
"]

除日常结算时长之外

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

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

• 登录后台下载。商户需要先在系统中开通后台账号并设置好密码后方可进行登录操作；登录成功后即可完成对账单的手动下载或导出打印。
• 邮件推送服务。商户需将收单机构的邮箱地址发送至通道方系统；系统将按照相关协议自动定时发送相关资料。
• 采用FTP技术进行文件下载是被推荐的方式。随着网络接入通道数量的不断增加，在线完成文件下载的工作量会显著增加；而采用FTP技术则能够实现无需人员在线操作即可完成文件自动下载的功能；这不仅大大降低了工作强度、提高了工作效率。

基于对象间的关系不同，FTP下载可划分为两种类型：一种是商户主动向收单机构获取FTP下载服务；另一种则是由收单机构将FTP文件自动推送给商户指定的FTP地址。无论采取哪种方式，在完成连接时都会涉及以下关键要素：目标服务器IP地址、用户名称与权限信息（即用户名和密码）、文件存储路径（即目录）以及用于限制访问范围的访问控制列表（即IP白名单）。

当商户欲通过收单机构进行交易支付时，则需先由该机构向商户提供以下信息：包括交易支付所需的目标地址、具有身份验证功能的用户名以及相应的密码，并明确指定可访问的目录位置；与此同时，则需将该交易所涉及的相关IP地址发送至收单机构以便预先将其加入到白名单中进行管理。

当收单机构主动向商户发送推送给其下载的目标地址时，则相反地由商户向收单机构提供下载目标地址、用于身份验证的用户名和密码以及推送目录地址；同时将该IP地址预先配置至商户的白名单中。

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

全额结算（Gross Settlement）是对交易已收资金实施全面结算与划拨操作，并不涉及任何费用扣除。净额结算（Net Settlement）则是指在扣除相关手续费后进行的资金结算操作；此外，在净额结算的情况下还可能涉及到双方之间的直接买卖操作：即双方各自之间的应收款与应付款会通过互相抵扣的方式实现 settle 过程

选择何种结算模式将直接影响后续程序的对账流程。具体而言，在进行支付操作时需要决定采取以下两种方案之一：一是扣除交易产生的手续费后的净额进行结算；二是直接采用未扣除手续费的全额支付方式。在实际操作中，请确保计算过程中将手续费部分单独处理以避免混淆。

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

商户日常会接入多种多样的支付渠道，在各大小规模金融机构均会参与的情况下，在初始阶段，在与支付服务提供商建立良好关系并收集相关信息方面取得进展，则有助于提升项目的全面性和效率。

博文参考

《支付论》