from: http://www.cnblogs.com/zhengyun_ustc/p/paybg.html
评点： 实在是长见识， 全干货！！！谢谢原作者
郑昀编纂 基于网络资料 创建于2015/9/7 最后更新于2015/9/7
特别感谢知乎梁川、天顺等知乎网友的精彩答案
关键词：在线支付，POS，第三方支付，清算，银企直连，快捷支付，对公对私，支付宝，对账，App
本文档适用人员：交易领域的产品研发人员
提纲：
- 银联
- 一些错综复杂的关系
- 银联是什么
- 银联商务是什么
- 快捷支付绕过银联了吗
- 能通过卡号判断是对公账户或对私账户吗
- 快捷支付
- 为什么要推快捷支付
- POS
- POS签单上的各种号码
- 信用卡刷卡后都发生了什么
- 第三方支付公司
- 为什么需要有备付金
- 直联网关和间联网关
- 何谓银企直连
- 支付宝是怎么对账的
- 我们作为商户如何接入
- 预付费卡牌照与第三方支付牌照有什么区别
- 大宗交易电商网站如何接入
做电商开发总会遇到各种不知所谓的产品和不知所云的术语，下面串一下。
0x00，银联
1.1.一些错综复杂的关系
现如今手机 App 接入支付宝和微信支付即可，早年间 PC 端还得通过与银联商务对接，接入银联在线支付。但这是什么东西？unionpay，chinapay，银联在线支付，银联在线，这又是什么鬼？
据说银联自己人都不一定能搞清楚这些东西的历史渊源。
首先，这是中国银联的官方网站：www.unionpay.com，现在是银联总公司办公室打理。它是这么介绍自己的：
中国银联是中国银行卡联合组织，通过银联跨行交易清算系统，实现商业银行系统间的互联互通和资源共享，保证银行卡跨行、跨地区和跨境的使用。中国银联大力推进各类基于银行卡的综合支付服务。
我们应该拿银联与 Visa、Mastercard 这样的卡组织相提并论。
其次，银联在线支付其实是个支付网关（注：由于支付宝和微信支付的大行其道，支付网关这个词已经慢慢地难以理解了）。这是银联在线支付的网站：http://online.unionpay.com，现在的域名统一到 www.95516.com 了，变成了银联持卡人服务网站。
银联在线支付网站也是一波三折，最开始是银联的互联网部搞的，只有在线支付的介绍内容，比较简洁。后来因为银联主站的调整，加上老的持卡人服务网站 www.95516.net 的调整，整个网站杂乱了起来。再后来互联网部解散了，移交给产品部，之后又移交给其他事业部。
最后，银联在线的网站是：www.chinapay.com，银联的子公司 ChinaPay 搞的。ChinaPay 历史悠久，开始算是一家搞电子商务的创业公司，后来因经营不善被银联收购，用以发展电子商务及在线支付服务。这个网站原来是 ChinaPay 和银联的互联网部一起搞的，后来银联的人觉得这么做不行，还是要单独做，于是就做出来 online.unionpay.com 那套东西了。
长江后浪推前浪，前浪死在沙滩上，现在在银联里大家谈支付网关都是说银联在线支付。
（出处1）
1.2.银联到底是什么
银联，是2002年国内80多家金融机构共同出资组建的股份制金融机构，其本身定位是银行卡组织。
他对国内商业银行的银行卡制定了统一的标准，凡是商业银行按照银联标准发卡，这些卡就能够进入银联的清分网络。
原本两家银行数据假使是互相独立的，银联制定规范前，工行的 ATM 机没法受理华夏银行卡的提现。在银联介入后，由于卡信息规范得到了统一，工行 ATM 机能够读懂华夏银行卡内的磁条信息。更重要的是，工行可以通过银联的网络查询到华夏借记卡中的余额，并受理用户的提现需求。用户在提现后，根据银联的清分数据，华夏银行会在规定账期内将资金结算给工行。
银联在这个过程中，不参与交易和收单，不负责出款，仅仅负责信息传递并产生清分数据，赚的是“信息费”。这和其他著名卡组织的功能基本相同，制定标准、打通发卡行、负责清分信息。
（出处2）1.3.银联商务又是什么
中国银联控股银联商务。
因为银联是后台部门，当然这几年也开始面向前端了，但总体来说，主要精力放在后台建设上，因此很多业务落地是要委托银联商务来做的，特别是省级银联分公司更是要依托于当地的银联商务来完成其业务指标，所以说关系是很近的。
同时也是上下级的关系，银联商务 POS 直连业务必须要接入当地银联（总部也有，但是占比很小，而且总部也基本上不承接实际业务，都是要落地到各地分子公司），于是银联对银商上报的商户就有审核义务，还有一些指标要求或者规范化要求等。
（出处3）
1.4.快捷支付绕过银联了吗
一句话总结：支付宝的快捷支付，通过机制设计代替了银联跨行结算的作用，绕过了银联通道。
支付宝直接对接银行，所以不涉及跨行，既然不跨行，那跟银联就没有关系。
快捷支付或第三方支付的流程是这样：
张三买了一包100元的茶叶，用他的工行卡绑定快捷支付，付款100元至支付宝的工行对公账户；
支付宝从支付宝的建行对公账户中转给茶叶商的建行账户中100元；
为了完成上述的过程，第三方支付公司需要在各家商业银行开立对公结算账户，并打通各行银行卡快捷支付的接口。用户通过网络完成快捷支付的绑定后，即可完成个人银行卡向第三方支付对应本行对公结算账户的付款。交易发生时，第三方支付公司再从商户账户所在银行对应的对公结算账户把对应资金划给商户即可。
（出处4）
1.5.能根据账号/卡号判断是对公账户还是个人账户吗
直接通过卡号或账户来区分对公、对私，没什么好办法。
银行卡有银联标准规范，但对公账户每家银行规则都不同。由于对公账户也可以办理银行卡（不能在 ATM 上提现），因此单纯依靠 卡bin 无法区分出银行卡对应的银行账户是对公账户还是对私账户。
一般采用如下一些方法：
- 对公、对私业务入口不同，分流到不同接口，
- 让用户在业务处理过程中提供银行账户对应的属性信息（例如代收付批量文件中），
- 维护各家银行的对公账户规则。这个比较费劲，关键是维护成本较高，
- 一般对公账户的账户名称至少在6位以上，对私账户的名称一般最多3、4位，因此可以先根据账户名称长度做一下判断，再查找是否包含股份公司、有限公司、协会之类的关键词。（注：仅靠长度判断的话遇上维吾尔族人账户名称也是醉了）
（出处12）
0x01，快捷支付
顺着上面的话题，我们说说快捷支付吧。
快捷支付本质是代扣服务（对私）的产品包装。
什么是代扣？
代扣一般指用户通过线上或线下柜台方式签署“用户-商户-银行”的三方协议，授权商户可以从其银行账户中扣钱。典型应用场景是电视费、保险费定期的扣除。
传统的代扣服务的授权过程较为麻烦，而且行业应用场景限制较多（例如只对实名行业开放）。快捷支付针对小额支付的需求场景，简化了授权过程（例如只需要完成持卡人银行卡、身份证、手机号的实名认证即可），同时通过下行短信验证码的形式来完成消费确认，很好平衡了安全性、便捷性。
（出处15）
2.1.为什么要推快捷支付
首先，我们要知道，一个网上支付的过程，对第三方支付机构（如支付宝）和银行后台系统整个交互流程来说，可分为主动扣款和被动付款两种调用模式。两种模式有什么分别呢？
上图是快捷支付的简化版流程。顺序来看，小明买了9.9元包邮的鼠标垫之后，第一步跳转到支付宝页面上选择了快捷支付，支付宝将小明绑定的银行卡、姓名、金额通过调用主动扣款指令传给银行（注意，没有密码），银行核对卡号姓名、指令来源、余额等信息无误之后，把扣款成功的信息发给支付宝，支付宝再把扣款成功的信息告诉小明，小明可以等待卖家发货了。
这个流程里，支付宝是主动的一方，是支付宝主动扣了小明的款项。
这个流程里，支付宝是主动的一方，是支付宝主动扣了小明的款项。
上图是通过银行网银支付的简化版流程。在快捷支付推出之前，这个是支付宝唯一的在线支付方式。顺序来看，小明通过支付宝页面选择了网银支付，支付宝通过页面跳转，调用订单支付指定传 给银行（注意，此时没有个人客户的任何信息，只有一个支付订单号），小明需要事先插好U盾，此时再通过展现的网银页面来进行支付。银行将扣款成功指令传给小明和支付宝，支付宝再把付款成功信息告诉小明。
这个流程里，支付宝是被动的一方，是小明主动支付给了支付宝。
注意到上面两个流程的诸多不同了吧？正是这种种不同促使支付宝异常坚定地推行快捷支付，也正是这种种不同促使银行对支付宝又爱又恨，时远时近。
这个流程里，支付宝是被动的一方，是小明主动支付给了支付宝。
注意到上面两个流程的诸多不同了吧？正是这种种不同促使支付宝异常坚定地推行快捷支付，也正是这种种不同促使银行对支付宝又爱又恨，时远时近。
越高的成功率，就意味着支付宝越多的资金沉淀，在早期，这个资金沉淀就是支付宝和银行合作的基础所在。在通过银行网银支付流程中，影响支付成功率有三个主要因素：
一是有个致命的前提，客户需要先去银行开通网银。有银行卡的用户（可开通快捷支付）和开通网银的用户，这绝对是几个数量级之间的用户数差别。支付宝无法忍受用户群体被这个限定死。
二是需要用户来主动保证网银支付环境的正常。而各位一定对我国各大银行各式各样的网银问题抓过狂发过浪，而且这种种问题是支付宝完全干涉不了也帮助不了。在早期，支付宝恨不得能人工指导每一个用户怎么使用各大银行的网银。
三是网银支付的流程过长。有过开发经验的前辈们一定有体会，越长的流程意味着各种可能的异常处理情形越复杂，出错的概率也越高。这也是在早期为什么支付宝出现许多支付结果不确定的情况，这其实对支付宝和银行两方都非常头疼。因为双方能够定位问题的就是一个订单号。
二，快捷支付有助于更好的构筑阿里渴望的大数据。
我们有没有发现在两个流程中，支付宝和银行交互的数据是有巨大差别的？在快捷支付的过程中，支付宝掌握了用户的所有信息，包括身份、账号、验证方式、手机号，如果是信用卡，还有到期日、CVV码等，用时髦的话来说，这就天然的和用户购物流程形成了完整的闭环。这些信息都可以用于构建用户信用基础信息。
而在网银支付的流程中，支付宝只掌握了一个订单号，只知道这个用户下了一个订单，然后订单就被付款成功了。至于谁付的？账号多少？姓甚名谁？手机验证是否准确？等等一系列，都是黑盒子。
如果换做是你，你会希望用户用那种方式呢？
二，快捷支付有助于更好的构筑阿里渴望的大数据。
我们有没有发现在两个流程中，支付宝和银行交互的数据是有巨大差别的？在快捷支付的过程中，支付宝掌握了用户的所有信息，包括身份、账号、验证方式、手机号，如果是信用卡，还有到期日、CVV码等，用时髦的话来说，这就天然的和用户购物流程形成了完整的闭环。这些信息都可以用于构建用户信用基础信息。
而在网银支付的流程中，支付宝只掌握了一个订单号，只知道这个用户下了一个订单，然后订单就被付款成功了。至于谁付的？账号多少？姓甚名谁？手机验证是否准确？等等一系列，都是黑盒子。
如果换做是你，你会希望用户用那种方式呢？
（出处5）
0x02，POS
POS 你可能天天刷，但下面的这些知识你未必都知道。
3.1.POS签单上的各种号码
POS签单上有很多序列号，都是什么意思呢？如果收单后处理投诉时让你提供流水号，那指的是哪一个字段呢？
批次号(Batch NO.)：POS从签到起至结算、签退为止的交易为一批次，交易批次号标识一批交易。POS中心为每个POS的每个批次分配一个批次号，在签到响应报文中下传给POS终端。
对应银联ISO8583报文的报文头域7： 批次号(Batch Number)
序号(Refer NO.)：或称参考号。POS中心为交易分配的流水号，在响应报文中下传给POS终端作为对账参考号，并用于事后查证。
对应银联ISO8583报文的域37：检索参考号（Retrieval Reference Number）
授权号(Auth Code)：授权标识应答码，简称“授权码”。是发卡行返回或银联CUPS代授权时返回的授权序号。
对应银联ISO8583报文的域38：授权标识应答码 Authorization Identification Response
查询号(Trace NO.)：或称流水号。POS机为每一笔交易产生的顺序编号。POS每上送一次交易此号码增加1。 POS流水号为6位数字，值从1至999999循环使用。在自动冲正时，POS中心依据POS流水号作为确定被冲正交易的要素之一。
交易发起方赋予交易的一组数字，与域7（交易传输时间 Transmission Date/Time）、域32（受理机构标识码 Acquiring Institution Identification Code）和域33（发送机构标识码 Forwarding Institution Identification Code）的组合值唯一标识一笔交易的编号。
凭证号(Voucher NO.)：查询号（Trace NO. 也叫POS流水号）也作为交易凭证号（在签购单上打印为Voucher NO.），在进行撤销等交易时，输入原交易凭证号作为确定原交易的要素之一，并且必须上送原交易的凭证号。
如果要确认一笔交易，分为发卡行查和收单方查：
-
对发卡行来说——卡号+参考号+授权号，就能够确定一笔交易；
-
对于收单方来说——凭证号+域7（对应签购单上的日期/时间）+域32（对应签购单上的收单机构）+33域（对应签购单上的发卡机构）能够唯一确定一笔交易。
因此如果是向发卡行投诉，则需要提供卡号、参考号、授权号，
如果是向收单方投诉，则需要提供凭证号、交易日期时间、收单机构、发卡机构。
（出处6）3.2.信用卡刷卡后都发生了什么
对于银联的直联商户，流程如下：
-
刷卡信息（包括磁道和密码）由 POS 机具受理后通过收单机构送往银联的收单系统。
-
银联收单系统将报文通过银联核心交换平台送到信用卡的发卡银行，根据交易指令，在发卡银行的对应的卡片账户进行扣款。
-
银联核心交换系统收到扣款成功的返回后，将交易结果原路返回到 POS 终端上。
-
当天晚上11点，清算信息开始批量处理。
-
T+1日，各行在人行的头寸账户根据银联的清算文件（指令）将资金进行划拨，即交易资金从信用卡的发卡银行转移到商户的收单银行。
-
收单银行将资金转入商户的具体清算账户（也可以由银联直接转入）。
就扮演的角色而言，有持卡人、商户、收单机构（为商户提供服务的银行或机构）、转接清算机构（银联、VISA等卡组织）、发卡机构（信用卡银行）。
（出处9）
3.3.清算到底是什么
上一节提到了清算，看图理解这个概念吧：
0x03，第三方支付公司
支付宝，财付通，这些都属于第三方支付公司。
4.1.为什么需要有备付金
一，为什么第三方支付公司的资金需要有备付金管理办法
最初，支付公司的资金是不受监管的。
比如小明在网上看中了一款产品，使用了支付宝进行付款，在使用支付宝付款的时候，选择的是小明的招商银行卡，付款成功后，小明的招行账户会扣除资金，同时支付宝会将支付成功的信息告诉卖家，卖家发货。
在第二天，招商银行会将小明被扣除的资金结算给支付宝，这个时候这笔钱是由银行结算给支付宝在招商银行开设的对公账户。
而小明由于还没有确认收货，或者可能一周之后才会确认收货，那么在这段时间，这笔钱会一直停留在支付宝的对公账户中。
这笔钱，没有任何人会去监管，而且因为存在着时间差，所以支付宝可能会将这笔钱挪去他用。
也有可能存在着一些小的支付公司，甚至之前资金链断裂，卷钱走人。
所以，政府认为，这个钱我是肯定要去监管起来的。
于是在2013年6月7日，中国人民银行公告〔2013〕第6号公布《支付机构客户备付金存管办法》，核心就是要监管起支付公司里面那些实际上是用户的钱。这部分钱被称为客户备付金，需要严格和支付公司自己的钱区分开来。
二，备付金管理办法的核心是什么
核心就是三种账户，分别为存管账户、收付账户、汇缴账户。
存管账户就是大老婆，每家支付公司只能在一家银行开立存管账户。你选择了工商银行，就不能选择华夏银行。存管账户里的钱可以跨行划款、同行划款、用起来和普通的对公账户完全一模一样，不受限制。但一般存管账户只能开一个，也有的支付公司，会选择在同一个银行不同地区的分行之间开账户。
收付账户就是姨太太，每家支付公司可以在每一家银行都开立一个收付账户，但收付账户不能跨行划款，除非收款账户是存管账户。收付账户只能同行划款，A支付公司可以在工行开一个收付账户、在农行也开一个收付账户，但一旦在农行上海分行开一个账户，就不能在农行深圳分行再开收付账户了。
汇缴账户就是情人，随便在哪家银行随便开几个，但是这个账户日终清零，只能把这个账户里的钱每天归集到本行收付账户或是跨行归集到存管账户，好可怜。
有的人问，那汇缴账户有啥用？比如某个支付公司和某家分行合作了一个网上收单业务，那么这个汇缴账户就是这家银行每天把收单的钱结给这个支付公司的账户。
三，备付金账户之间头寸是如何调拨的
存管账户、收付账户、汇缴账户之间的钱是如何调拨的？
首先明确的一点，这个钱不会走银联的系统，这件事情和银联没有一毛钱关系。
那么汇缴账户到收付账户，就是通过每家银行的行内转账进行调拨。
汇缴账户、收付账户到存管账户，就是通过人行的大小额系统、跨行清算系统（俗称超级网银）或是同城系统进行调拨。
当然我们说的系统，都是背后的系统，实际上前端的产品就是各家银行的企业网银、银企直联，甚至极端点，你去柜台把这个钱完成调拨都没问题。
每家银行现在陆续的都上了备付金管理系统，这个系统对接了每家支付公司，让银行能够掌握支付公司在自己银行开设的所有备付金账户的每日余额和资金调拨明细，并且做到汇缴账户能每日清零，控制收付账户、汇缴账户的跨行转账权限，并且每日能生成报表报送给人行。
这些措施都上了的话，基本可以杜绝支付公司卷款跑人的问题了。
跟 B2B 技术团队交流时，他们老说银企直连，那这又是什么呢？
4.2.直联网关和间联网关
间联网关是第三方支付公司提供网银支付网关的最标准模式。
消费者需要支付时，商家向第三方支付公司的网关接口提交标准报文请求将消费者引导到“收银台”，没错，就是支付宝那个熟悉的选择支付银行的页面。用户在收银台选择银行后，支付宝再将用户引导到网银界面……后面的流程大家都懂的。
直联网关是在标准网关基础上进行的衍生网关服务。
做过电商的同学都知道，消费者完成消费行为前的任一步骤都可能产生用户跳出，为了尽可能减少用户跳出，缩短支付流程就成为很重要的优化点。基于此需求，第三方支付公司提供了直联网关接口，消费者在需要支付时，电商网站直接告诉第三方支付公司消费者需要使用哪家银行进行付款，支付公司受理信息后迅速引导消费者到网银支付页面，这个过程中支付公司界面就不再出现，用户体验会好一些。这类产品几乎所有支付公司都有。
4.3.何谓银企直连
此外比较常见的有银企直连接口。银企直连不是一个简单交易接口，不少银行包装银企直连是一堆业务接口的集合。
银企直连通常用在即时出款到银行账户（提现、代发代付业务）业务上比较多。支付公司也会提供这类出款接口给商户，帮助其完成系统对接的付款需求。
（出处8）
4.4.支付宝是怎么对账的
分为支付宝与银行对账，商户与支付宝对账。
为了可以更好地解释支付结算系统对账过程，我们先把业务从头到尾串起来描述一下场景，帮助大家理解：
一个可能得不能再可能的场景，请大家深刻理解里面每个角色做了什么，获取了哪些信息：
某日阳光灿烂，支付宝用户小明在淘宝上看中了暖脚器一只，价格100元。犹豫再三后小明使用支付宝网银完成了支付，支付宝显示支付成功，淘宝卖家通知他已发货，最近几日注意查收。
我们来看看这个过程中有几个相关方，分别做了什么。我语文不好，写得饶口，如果看不懂请多看几次：
小明：持卡人，消费者，淘宝和支付宝的注册会员，完成了支付动作，自己的银行账户资金减少，交易成功。
银行：收单银行，接受来自支付宝的名为“支付宝BBB”的100元订单，并引导持卡人小明支付成功，扣除小明银行卡账户余额后返回给支付宝成功通知，并告诉支付宝这笔交易在银行流水号为“银行CCC”。
支付宝：支付公司，接收到淘宝发来的订单号为“淘宝AAA”的商户订单号，并形成支付系统唯一流水号：“支付宝BBB”发往银行系统。然后获得银行回复的支付成功信息，顺带银行流水号“银行CCC”。
淘宝：我们支付公司称淘宝这类电商为商户，是支付系统的客户。淘宝向支付系统发送了一笔交易收单请求，金额为100，订单号为:“淘宝AAA”，支付系统最后反馈给淘宝这笔支付流水号为“支付BBB”。
以上流程貌似大家都达到了预期效果，但实际上仍然还有一个问题：
对支付公司（支付宝）而言，虽然银行通知了它支付成功，但资金实际还要 T+1 后结算到它银行账户，所以目前只是一个信息流，资金流还没过来。
Tips:插一句话，对支付系统内部账务来说，由于资金没有能够实时到账，所以此时小明的这笔100元交易资金并没有直接记入到系统资产类科目下的“银行存款”科目中，而是挂在“应收账款”或者“待清算科目”中。大白话就是，这100元虽然答应给我了，我也记下来了，但还没收到，我挂在那里。
对商户（淘宝）而言，虽然支付公司通知了它支付成功，他也发货了，但资金按照合同也是 T+1 到账。如果不对账确认一下，恐怕也会不安。
倒是对消费者（小明）而言：反正钱付了，你们也显示成功了，等暖脚器呀等暖脚器~
基于支付公司和商户的困惑，我们的支付结算系统需要进行两件事情：一是资金渠道对账，通称对银行帐；二是商户对账，俗称对客户帐。对客户帐又分为对公客户和对私客户，通常对公客户会对对账文件格式、对账周期、系统对接方案有特殊需求，而对私客户也就是我们一般的消费者只需要可以后台查询交易记录和支付历史流水就可以了。
我们先聊银行资金渠道对账，由于支付公司的资金真正落地在商业银行，所以资金渠道的对账显得尤为重要。
在一个银行会计日结束后，银行系统会先进行自己内部扎帐，完成无误后进行数据的清分和资金的结算，将支付公司当日应入账的资金结算到支付公司账户中。于此同时，目前多数银行已经支持直接系统对接的方式发送对账文件。
于是，在某日临晨4点，支付宝系统收到来自银行发来的前一会计日对账文件。根据数据格式解析正确后和前日支付宝的所有交易数据进行匹配，理想情况是一一匹配成功无误，然后将这些交易的对账状态勾对为“已对账”。
Tips：此时，对账完成的交易，会将该笔资金从“应收账款”或者“待清算账款”科目中移动到“银行存款”科目中，以示该交易真正资金到账。
以上太理想了，都那么理想就不要对账了。所以通常都会出一些差错，那么我总结了一下常见的差错情况：
1）支付时提交到银行后没有反馈，但对账时该交易状态为支付成功
这种情况很正常，因为我们在信息传输过程中，难免会出现掉包和信息不通畅。消费者在银行端完成了支付行为，银行的通知信息却被堵塞了，如此支付公司也不知道结果，商户也不知道结果。如果信息一直没法通知到支付公司这边，那么这条支付结果就只能在日终对账文件中体现了。这时支付公司系统需要对这笔交易进行补单操作，将交易置为成功并完成记账规则，有必要还要通知到商户。
此时的小明：估计急的跳起来了……付了钱怎么不给说支付成功呢！坑爹！
Tips：通常银行系统会开放一个支付结果查询接口。支付公司会对提交到银行但没有回复结果的交易进行间隔查询，以确保支付结果信息的实时传达。所以以上情况出现的概率已经很少了。
2）我方支付系统记录银行反馈支付成功，金额为100，银行对账金额不为100
这种情况已经不太常见了，差错不管是长款和短款都不是我们想要的结果。通常双方系统通讯都是可作为纠纷凭证的，如果银行在支付结果返回时确认是100元，对账时金额不一致，可以要求银行进行协调处理。而这笔账在支付系统中通常也会做对应的挂账处理，直到纠纷解决。
3）我方支付系统记录银行反馈支付成功，但对账文件中压根不存在
这种情况也经常见到，因为跨交易会计日的系统时间不同，所以会出现我们认为交易是23点59分完成的，银行认为是第二天凌晨0点1分完成。对于这种情况我们通常会继续挂账，直到再下一日的对账文件送达后进行对账匹配。
如果这笔交易一直没有找到，那么就和第二种情况一样，是一种短款，需要和银行追究。
以上情况针对的是一家银行资金渠道所作的流程。实际情况中，支付公司会在不同银行开立不同银行账户，用以收单结算（成本会降低），所以真实情况极有可能是：
临晨1点，工行对账文件丢过来（支行A）。
临晨1点01分，工行又丢一个文件过来（支行B）。
临晨1点15分，农行对账文件丢过来。
……
临晨5点，兴业银行文件丢过来。
……
不管什么时候，中国银行都必须通过我方业务员下载对账文件再上传的方式进行对账，所以系统接收到中行文件一般都是早上9点05分……
对系统来说，每天都要处理大量并发的对账数据，如果在交易高峰时段进行，会引起客户交互的延迟和交易的失败，这是万万行不得的。
所以通常支付公司不会用那么傻的方式处理数据，而是在一个会计日结束后，通常也是凌晨时段，将前一日交易增量备份到专用对账服务器中，在物理隔绝环境下进行统一的对账行为，杜绝硬件资源的抢占。
以上是银行资金渠道入款的对账，出款基本原理一致，不过出款渠道在实际业务过程中还有一些特别之处，由于又不是让大家亲自要建设系统，就不再赘述了。
谈完了资金渠道的对账，我们再来看看对客户帐。
前面提到了，由于资金落在银行，所以对支付公司来说，对银行帐非常重要。那么同理，由于资金落在支付公司，所以对商户来说，对支付公司账也一样重要。能否提供高品质甚至定制化的服务，是目前支付公司走差异化路线的一个主要竞争点。
Tips：之前说过，银行与支付公司之间的通讯都是可以作为纠纷凭证的。原理是对支付报文的关键信息进行密钥加签+ md5 处理，以确保往来报文“不可篡改，不可抵赖”。
同理，支付公司和商户之间也会有类似机制保证报文的可追溯性，由此我们可以知道，一旦我方支付系统通知商户支付结果，那么我们就要为此承担责任。由此我们再推断一个结论：
即便某支付订单银行方面出错导致资金未能到账，一旦我们支付系统通知商户该笔交易成功，那么根据协议该结算的资金还是要结算给这个商户。自然，我们会去追究银行的问题，把账款追回。
1）对支付系统而言，最基本的对账功能是供商户在其后台查询下载某一时间段内的支付数据文件，以供商户自己进行对账。
这个功能应该是个支付公司就有，如果没有就别混了。
2）对大多数支付系统而言，目前已经可以做到对账文件的主动投送功能。
这个功能方便了商户系统和支付系统的对接，商户的结算人员无须登录支付平台后台下载文件进行对账，省去了人工操作的麻烦和风险。
对大型支付系统而言，商户如果跨时间区域很大，反复查询该区域内的数据并下载，会对服务器造成比较大的压力。各位看官别笑，觉得查个数据怎么就有压力了。
现在比较主流的做法是把商户短期内查询过、或者经常要查询的数据做缓存，实在不行就干脆实时备份，两分钟同步一次数据到专用数据库供商户查询，以避免硬件资源占用。甚至……大多数支付公司都会对查询范围跨度和历史事件进行限制，比如最多只能查一个月跨度内，不超过24个月前的数据……以避免服务挂掉。
一个可能得不能再可能的场景，请大家深刻理解里面每个角色做了什么，获取了哪些信息：
某日阳光灿烂，支付宝用户小明在淘宝上看中了暖脚器一只，价格100元。犹豫再三后小明使用支付宝网银完成了支付，支付宝显示支付成功，淘宝卖家通知他已发货，最近几日注意查收。
我们来看看这个过程中有几个相关方，分别做了什么。我语文不好，写得饶口，如果看不懂请多看几次：
小明：持卡人，消费者，淘宝和支付宝的注册会员，完成了支付动作，自己的银行账户资金减少，交易成功。
银行：收单银行，接受来自支付宝的名为“支付宝BBB”的100元订单，并引导持卡人小明支付成功，扣除小明银行卡账户余额后返回给支付宝成功通知，并告诉支付宝这笔交易在银行流水号为“银行CCC”。
支付宝：支付公司，接收到淘宝发来的订单号为“淘宝AAA”的商户订单号，并形成支付系统唯一流水号：“支付宝BBB”发往银行系统。然后获得银行回复的支付成功信息，顺带银行流水号“银行CCC”。
淘宝：我们支付公司称淘宝这类电商为商户，是支付系统的客户。淘宝向支付系统发送了一笔交易收单请求，金额为100，订单号为:“淘宝AAA”，支付系统最后反馈给淘宝这笔支付流水号为“支付BBB”。
以上流程貌似大家都达到了预期效果，但实际上仍然还有一个问题：
对支付公司（支付宝）而言，虽然银行通知了它支付成功，但资金实际还要 T+1 后结算到它银行账户，所以目前只是一个信息流，资金流还没过来。
Tips:插一句话，对支付系统内部账务来说，由于资金没有能够实时到账，所以此时小明的这笔100元交易资金并没有直接记入到系统资产类科目下的“银行存款”科目中，而是挂在“应收账款”或者“待清算科目”中。大白话就是，这100元虽然答应给我了，我也记下来了，但还没收到，我挂在那里。
对商户（淘宝）而言，虽然支付公司通知了它支付成功，他也发货了，但资金按照合同也是 T+1 到账。如果不对账确认一下，恐怕也会不安。
倒是对消费者（小明）而言：反正钱付了，你们也显示成功了，等暖脚器呀等暖脚器~
基于支付公司和商户的困惑，我们的支付结算系统需要进行两件事情：一是资金渠道对账，通称对银行帐；二是商户对账，俗称对客户帐。对客户帐又分为对公客户和对私客户，通常对公客户会对对账文件格式、对账周期、系统对接方案有特殊需求，而对私客户也就是我们一般的消费者只需要可以后台查询交易记录和支付历史流水就可以了。
我们先聊银行资金渠道对账，由于支付公司的资金真正落地在商业银行，所以资金渠道的对账显得尤为重要。
在一个银行会计日结束后，银行系统会先进行自己内部扎帐，完成无误后进行数据的清分和资金的结算，将支付公司当日应入账的资金结算到支付公司账户中。于此同时，目前多数银行已经支持直接系统对接的方式发送对账文件。
于是，在某日临晨4点，支付宝系统收到来自银行发来的前一会计日对账文件。根据数据格式解析正确后和前日支付宝的所有交易数据进行匹配，理想情况是一一匹配成功无误，然后将这些交易的对账状态勾对为“已对账”。
Tips：此时，对账完成的交易，会将该笔资金从“应收账款”或者“待清算账款”科目中移动到“银行存款”科目中，以示该交易真正资金到账。
以上太理想了，都那么理想就不要对账了。所以通常都会出一些差错，那么我总结了一下常见的差错情况：
1）支付时提交到银行后没有反馈，但对账时该交易状态为支付成功
这种情况很正常，因为我们在信息传输过程中，难免会出现掉包和信息不通畅。消费者在银行端完成了支付行为，银行的通知信息却被堵塞了，如此支付公司也不知道结果，商户也不知道结果。如果信息一直没法通知到支付公司这边，那么这条支付结果就只能在日终对账文件中体现了。这时支付公司系统需要对这笔交易进行补单操作，将交易置为成功并完成记账规则，有必要还要通知到商户。
此时的小明：估计急的跳起来了……付了钱怎么不给说支付成功呢！坑爹！
Tips：通常银行系统会开放一个支付结果查询接口。支付公司会对提交到银行但没有回复结果的交易进行间隔查询，以确保支付结果信息的实时传达。所以以上情况出现的概率已经很少了。
2）我方支付系统记录银行反馈支付成功，金额为100，银行对账金额不为100
这种情况已经不太常见了，差错不管是长款和短款都不是我们想要的结果。通常双方系统通讯都是可作为纠纷凭证的，如果银行在支付结果返回时确认是100元，对账时金额不一致，可以要求银行进行协调处理。而这笔账在支付系统中通常也会做对应的挂账处理，直到纠纷解决。
3）我方支付系统记录银行反馈支付成功，但对账文件中压根不存在
这种情况也经常见到，因为跨交易会计日的系统时间不同，所以会出现我们认为交易是23点59分完成的，银行认为是第二天凌晨0点1分完成。对于这种情况我们通常会继续挂账，直到再下一日的对账文件送达后进行对账匹配。
如果这笔交易一直没有找到，那么就和第二种情况一样，是一种短款，需要和银行追究。
以上情况针对的是一家银行资金渠道所作的流程。实际情况中，支付公司会在不同银行开立不同银行账户，用以收单结算（成本会降低），所以真实情况极有可能是：
临晨1点，工行对账文件丢过来（支行A）。
临晨1点01分，工行又丢一个文件过来（支行B）。
临晨1点15分，农行对账文件丢过来。
……
临晨5点，兴业银行文件丢过来。
……
不管什么时候，中国银行都必须通过我方业务员下载对账文件再上传的方式进行对账，所以系统接收到中行文件一般都是早上9点05分……
对系统来说，每天都要处理大量并发的对账数据，如果在交易高峰时段进行，会引起客户交互的延迟和交易的失败，这是万万行不得的。
所以通常支付公司不会用那么傻的方式处理数据，而是在一个会计日结束后，通常也是凌晨时段，将前一日交易增量备份到专用对账服务器中，在物理隔绝环境下进行统一的对账行为，杜绝硬件资源的抢占。
以上是银行资金渠道入款的对账，出款基本原理一致，不过出款渠道在实际业务过程中还有一些特别之处，由于又不是让大家亲自要建设系统，就不再赘述了。
谈完了资金渠道的对账，我们再来看看对客户帐。
前面提到了，由于资金落在银行，所以对支付公司来说，对银行帐非常重要。那么同理，由于资金落在支付公司，所以对商户来说，对支付公司账也一样重要。能否提供高品质甚至定制化的服务，是目前支付公司走差异化路线的一个主要竞争点。
Tips：之前说过，银行与支付公司之间的通讯都是可以作为纠纷凭证的。原理是对支付报文的关键信息进行密钥加签+ md5 处理，以确保往来报文“不可篡改，不可抵赖”。
同理，支付公司和商户之间也会有类似机制保证报文的可追溯性，由此我们可以知道，一旦我方支付系统通知商户支付结果，那么我们就要为此承担责任。由此我们再推断一个结论：
即便某支付订单银行方面出错导致资金未能到账，一旦我们支付系统通知商户该笔交易成功，那么根据协议该结算的资金还是要结算给这个商户。自然，我们会去追究银行的问题，把账款追回。
1）对支付系统而言，最基本的对账功能是供商户在其后台查询下载某一时间段内的支付数据文件，以供商户自己进行对账。
这个功能应该是个支付公司就有，如果没有就别混了。
2）对大多数支付系统而言，目前已经可以做到对账文件的主动投送功能。
这个功能方便了商户系统和支付系统的对接，商户的结算人员无须登录支付平台后台下载文件进行对账，省去了人工操作的麻烦和风险。
对大型支付系统而言，商户如果跨时间区域很大，反复查询该区域内的数据并下载，会对服务器造成比较大的压力。各位看官别笑，觉得查个数据怎么就有压力了。
现在比较主流的做法是把商户短期内查询过、或者经常要查询的数据做缓存，实在不行就干脆实时备份，两分钟同步一次数据到专用数据库供商户查询，以避免硬件资源占用。甚至……大多数支付公司都会对查询范围跨度和历史事件进行限制，比如最多只能查一个月跨度内，不超过24个月前的数据……以避免服务挂掉。
延伸阅读：
支付系统对账算法优化方案（指的是对客户帐）
4.5.我们作为商户如何接入
我们自家新开发一个 App 如何接入支付解决方案呢？
此问题涉及如下几方面：
1 移动支付厂商的选型
1.1 支付渠道
由于是 App，采用的支付方式主要大致有如下几种方式：
a App SDK
支持银行卡支付（借记卡、信用卡）、账户支付、快捷支付等。
支付宝、微信支付、银联在线等主流的第三方支付都提供了对应的解决方案。
b WAP/HTML5
与 App SDK 类似，但微信支付目前不开放给第三方的手机网页版。
像信用卡无磁无密支付（ePOS/MOTOPay）、代扣等由于只对实名行业开放，且商家需要资质较好，一般行业应该不适用。
1.2 增值服务的考察
对普通商户而言，在选择第三方支付厂商时候，除了考虑支付渠道、交易手续费外，还需要重点考虑第三方支付提供的其他服务，主要包括如下一些方面：
a 结算周期、结算手续费，
b 提现/退款接口，
c 分账/代付（委托结算）等结算服务：或者叫分润。例如对代理商按照自定义规则对交易进行分账并批量代付到指定的银行账号（对公、对私）。
一般而言，支付宝、财付通（微信支付）、银联在线支付对分账/代付支持较弱，而像快钱/汇付/易宝之类独立第三方支付，在结算服务商策略相对灵活、产品解决方案也相对完善。
综上所述，建议结合自己业务模式，从支付渠道+增值服务两方面对主流第三方支付厂商进行对比，选择最适合自身的厂商。
2 与第三方支付平台对接问题
此问题主要涉及如下两方面：
2.1 平台虚拟账户资金流转问题
简单说来，你自己平台有一套虚拟账户体系，第三方平台也有一套虚拟账户体系，实际资金存放在银行的账户体系中（第三方支付在银行设立的备付金账户中）。你自己平台的账户体系和第三方支付的账户体系、第三方支付虚拟账户体系与银行账户体系间都只涉及信息流转（电子货币），实际的资金流转只发生在银行的账户体系内。
你作为商户接入第三方支付时候，第三方支付会在其平台为你方设立单独的商户虚拟账户（会有多个账户，包括结算账户、现金账户、信用账户等账户类型），你方平台的收单备付金（待结算资金）存放在结算账户中。商户自身也可以通过在线支付等方式对现金账户进行充值，充值金额存放在现金账户中，这样可以解决你所提到的提现资金预存问题。
当然如果你方交易量大（每日待结算资金量大），也可以和第三方支付探讨通过轧差方式。
2.2 提现
对第三方支付而言，影响提现服务因素包括时效性、费率等。
在时效性上一般分为实时、准实时、T+n。大部分情况下，除支付宝、财付通基于提升自己用户体验的考虑支持实时、准实时提现外，一般第三方支付对接入商户及接入商户用户的提现请求都采用 T+1 到账方式：在 T+1 与商户完成结算后，通过批量代付功能完成对应商家用户的提现请求。
1 移动支付厂商的选型
1.1 支付渠道
由于是 App，采用的支付方式主要大致有如下几种方式：
a App SDK
支持银行卡支付（借记卡、信用卡）、账户支付、快捷支付等。
支付宝、微信支付、银联在线等主流的第三方支付都提供了对应的解决方案。
b WAP/HTML5
与 App SDK 类似，但微信支付目前不开放给第三方的手机网页版。
像信用卡无磁无密支付（ePOS/MOTOPay）、代扣等由于只对实名行业开放，且商家需要资质较好，一般行业应该不适用。
1.2 增值服务的考察
对普通商户而言，在选择第三方支付厂商时候，除了考虑支付渠道、交易手续费外，还需要重点考虑第三方支付提供的其他服务，主要包括如下一些方面：
a 结算周期、结算手续费，
b 提现/退款接口，
c 分账/代付（委托结算）等结算服务：或者叫分润。例如对代理商按照自定义规则对交易进行分账并批量代付到指定的银行账号（对公、对私）。
一般而言，支付宝、财付通（微信支付）、银联在线支付对分账/代付支持较弱，而像快钱/汇付/易宝之类独立第三方支付，在结算服务商策略相对灵活、产品解决方案也相对完善。
综上所述，建议结合自己业务模式，从支付渠道+增值服务两方面对主流第三方支付厂商进行对比，选择最适合自身的厂商。
2 与第三方支付平台对接问题
此问题主要涉及如下两方面：
2.1 平台虚拟账户资金流转问题
简单说来，你自己平台有一套虚拟账户体系，第三方平台也有一套虚拟账户体系，实际资金存放在银行的账户体系中（第三方支付在银行设立的备付金账户中）。你自己平台的账户体系和第三方支付的账户体系、第三方支付虚拟账户体系与银行账户体系间都只涉及信息流转（电子货币），实际的资金流转只发生在银行的账户体系内。
你作为商户接入第三方支付时候，第三方支付会在其平台为你方设立单独的商户虚拟账户（会有多个账户，包括结算账户、现金账户、信用账户等账户类型），你方平台的收单备付金（待结算资金）存放在结算账户中。商户自身也可以通过在线支付等方式对现金账户进行充值，充值金额存放在现金账户中，这样可以解决你所提到的提现资金预存问题。
当然如果你方交易量大（每日待结算资金量大），也可以和第三方支付探讨通过轧差方式。
2.2 提现
对第三方支付而言，影响提现服务因素包括时效性、费率等。
在时效性上一般分为实时、准实时、T+n。大部分情况下，除支付宝、财付通基于提升自己用户体验的考虑支持实时、准实时提现外，一般第三方支付对接入商户及接入商户用户的提现请求都采用 T+1 到账方式：在 T+1 与商户完成结算后，通过批量代付功能完成对应商家用户的提现请求。
4.6.预付费卡牌照与第三方支付牌照有什么区别
第三方支付牌照包括：网络支付、预付卡的发行与受理、银行卡收单，其中网络支付又分为：货币汇兑、互联网支付、移动电话支付、固定电话支付、数字电视支付几种。
预付费卡的发行和受理是分开的，原则上不允许支付机构同时拥有预付费卡发行+银行卡收单牌照，但可以为预付费卡受理+银行卡收单。
支付机构发行预付卡的，应当提供预付卡的受理服务。
具体请参看：
非金融机构支付服务管理办法（人民银行令〔2010〕第2号）
央行公布非金融机构支付服务管理办法实施细则
预付费卡的发行和受理是分开的，原则上不允许支付机构同时拥有预付费卡发行+银行卡收单牌照，但可以为预付费卡受理+银行卡收单。
支付机构发行预付卡的，应当提供预付卡的受理服务。
具体请参看：
非金融机构支付服务管理办法（人民银行令〔2010〕第2号）
央行公布非金融机构支付服务管理办法实施细则
4.7.大宗交易电商网站如何接入
比如众美联的 B2B 云采购就属于大宗交易电商网站。
1）账户支付
账户支付有几种形态：
a）电商网站自己的账户体系，用户通过第三方支付对网站自有账户充值后再进行支付。
b）直接使用第三方支付的账户体系（与电商账户不绑定），用户充值是充值到第三方支付账户中并支付（注意与快捷支付的区别）。
c）与第三方支付的账户体系同步，此种情况较少采用，除非合作关系较为紧密。
像 C2C、B2B 平台常用的担保支付之类也可以归为账户支付范畴。
一般应用在适合比较重视账户体系建设的网站，支付金额没有限制（取决于充值的金额）。
2）快捷支付
用户在第三方支付账户体系中：
第一步认证授权：经过实名认证后，绑定银行卡
第二步消费：在第三方支付收银台以第三方支付账户登录，下行短信后，输入验证码及交易密码，完成支付。
也有在商户侧绑定授权及完成支付的（例如银联的绑定支付/快捷支付，但只针对有信用的品牌大商户）。
一般应用在电商网站及移动端，且需要第三方支付的账户体系认同度高，用户愿意绑定。支付金额有限制。
3）网关支付
就是典型的在线支付。一般的在线支付对额度会有限制，但基本上能够满足大部分场景的需要。
普通在线支付 B2C、B2B 网关是有交易限额限制。对需要大额支付的商家，大部分的第三方支付网关支付还提供 B2B 大额支付的接口，配合企业网银/个人网银，基本上能够做到无限额支付。一般 B2B 大额支付只提供了 PC 端功能（主要受限于企业网银）。
4）代收、代付
与商户签署代收、代付协议后，直接从用户银行卡扣钱。
一般支付额度较大，应用在信任关系比较紧密的上下游商家间。
5）信用支付
在 B2B 经常会针对信用好的商户进行授信，根据其信用度授予一定额度，因此会有所谓的信用支付概念。
针对以上几种支付形态，还会有一些组合，例如账户余额+网关支付，信用支付+账户余额，一般叫组合支付。
具体使用一种或多种支付方式，需要根据公司业务形态来确定。
另外如果公司交易量大的话，从降低成本等角度考虑，一般会在交易平台前端自建一个类支付的平台，主要用于接入多家支付公司，各家支付公司支付通道路由、统一对账等，另外还会适度接入一些直连银行（注：通过银企直连接口）。
（出处14）
参考资料：
1，2015，知乎匿名用户，http://www.zhihu.com/question/20661663/answer/54953390；
3，2014，知乎人一男，http://www.zhihu.com/question/23637354/answer/27195260；
4，2014，知乎陈昊宁，http://www.zhihu.com/question/21536576/answer/33305417；
5，2014，知乎Peng Xu，http://www.zhihu.com/question/20543686/answer/23258914；
7，2015，知乎灰色细胞，http://www.zhihu.com/question/34352468/answer/59508897；
10，2014，知乎天顺，http://www.zhihu.com/question/20091391/answer/15591658；
11，2015，知乎梁川，http://www.zhihu.com/question/34843113/answer/60199150；
12，2015，知乎梁川，http://www.zhihu.com/question/33006376/answer/55845326；
13，2015，知乎梁川，http://www.zhihu.com/question/32251333/answer/55320358；
14，2015，知乎梁川，http://www.zhihu.com/question/31759219/answer/53188831；
15，2015，知乎梁川，http://www.zhihu.com/question/27445035/answer/47586760；
-EOF-