电商交易背景知识合集第一季

现如今手机 App 接入支付宝和微信支付即可，早年间 PC 端还得通过与银联商务对接，接入银联在线支付。但这是什么东西？unionpay，chinapay，银联在线支付，银联在线，这又是什么鬼？

据说银联自己人都不一定能搞清楚这些东西的历史渊源。

 

首先，这是中国银联的官方网站：www.unionpay.com，现在是银联总公司办公室打理。它是这么介绍自己的：

银联，是2002年国内80多家金融机构共同出资组建的股份制金融机构，其本身定位是银行卡组织。

他对国内商业银行的银行卡制定了统一的标准，凡是商业银行按照银联标准发卡，这些卡就能够进入银联的清分网络。

原本两家银行数据假使是互相独立的，银联制定规范前，工行的 ATM 机没法受理华夏银行卡的提现。在银联介入后，由于卡信息规范得到了统一，工行 ATM 机能够读懂华夏银行卡内的磁条信息。更重要的是，工行可以通过银联的网络查询到华夏借记卡中的余额，并受理用户的提现需求。用户在提现后，根据银联的清分数据，华夏银行会在规定账期内将资金结算给工行。

银联在这个过程中，不参与交易和收单，不负责出款，仅仅负责信息传递并产生清分数据，赚的是“信息费”。这和其他著名卡组织的功能基本相同，制定标准、打通发卡行、负责清分信息。 

为了可以更好地解释支付结算系统对账过程，我们先把业务从头到尾串起来描述一下场景，帮助大家理解：
一个可能得不能再可能的场景，请大家深刻理解里面每个角色做了什么，获取了哪些信息：
某日阳光灿烂，支付宝用户小明在淘宝上看中了暖脚器一只，价格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个月前的数据……以避免服务挂掉。