支付系统的长短款

今天我们就说一个必须要处理的一种异常：长短款。

不要误会，这个长短款不是裙子的也不是裤子的长短款样式，而是支付业务对账出现的一种差异表现。

网上有很多关于长短款的定义，我觉得特混乱视听，有的人从会计学出发，什么应收款项，实收款项...有人从支付角度，有的人从银行角度，总之可能你说的“长”，是别人理解的“短”，你说的“短”，恰好是人家的“长”，最后的局面是“鸡同鸭讲”。

>我们先看一下角色，无非三种：业务方、三方支付、银联网联。

业务方调用三方支付，三方支付对接银联或者网联。

一般的调用过程是这样的：

业务方发起一笔入金请求，生成入金单，状态为初始态；

三方支付调用银联网联方，如果成功，异步通知业务方：入金成功；

业务方收单回调通知，将订单修改为入金成功；

当然了，上面是最普通的流程，还有的是异步通知+主动查询机制，如果业务方没有收到三方支付通知，则会主动调用三方的支付订单查询接口，根据结果来进行订单状态修改。

你也许会觉得，为什么三方支付没有直接返回业务方支付成功或者失败结果，而是异步通知和查询机制，首先是因为三方支付也会调用银联或者网联，他也不知道结果，所以只能异步通知了。

有没有实时返回结果的三方支付，有，自己垫资，无需调用银联网联的那种。

从上面的流程中，我们可以看到，不管是站在业务方，还是三方支付方，都会有订单的生成以及状态流转处理，业务方有业务方的订单；三方支付有三方支付的订单；当然了银联的业务订单；

而还有一个概念，切日或日切。

我们正常生活中，以24:00点为标准，过了就是下一天了，对于各支付以及上下游系统，也会有切日的处理，不过很多不是以24点，有的23点，有的22点，原来支付公司能直接对接各银行时，那可开眼了，切日的时间没几个一样的。

说切日就像说一个问题：对于不同的角色，同一笔订单，业务方可以归为为今天，三方支付可能属于明天的订单，切日，不能小看他，能带来很多意想不到的问题。

其实我们支付请求后的主动查询也是对账的一种表现，而更多的是日终的一次对账，很多银行、银联、网联真正为准的是日终对账文件，不管白天的业务订单状态变化如何，一切以日终的批处理文件为准；

所以不管是业务方还是三方支付，都会有一个必须经过的环节：日终对账。

对的是什么，是订单。

业务方拿着支付订单，找三方支付要日终文件，我们要核对一下；

三方支付拿着订单，找银行银联要日终文件，我们也要核对一下；

最终的结果，订单的核对无非几种结果：订单一一对应，没有任何问题，大家皆大欢喜；

最常见的结果：出现不一致的结果，我有，你没有；或者我没有订单，你反而有。

这里就引入了长款和短款，下面只是举例子，至于你们系统怎么理解的长款短款自己定义。

（1）支付长款：银行或者支付机构钱多了就是长款，即金额差错时，订单金额<对账文件金融，或者单边帐，订单无，对账文件有。

（2）支付短款：银行或者支付机构少钱了就是短款，即金额差错时，订单金额>对账文件金额，或者单边帐，订单有，对账文件无。

其实长款和短款也要分两种情况：

一是对账的时候订单和资金对账文件都有，金额差异造成长款和短款；

二是对账的时候订单和资金对账文件一边有一边无，即所谓的单边帐造成的长短款。

第一种情况很少遇到，一般情况下支付联机时实际支付金融和联机银行回显金额不相等，订单就支付失败了，也不会拿去对资金账。如果联机时两边金额是相等的，而在T+1对账时对出金额差异，这一般就是银行的问题了。

第二种情况，先说短款，T+1对账时，对出订单有对账文件无，一般不会立即出短款，而是先标记为“存疑”，因为有的银行会在T+2时提供对账文件。待T+2的对账文件来了，再把之前存疑的订单拿来对。万一到了设定了时间点，还是订单存疑的话，那么就要确认为短款了。

再说长款，T+1对账时对出订单无支付文件有时，这会立即出长款的。这时候要进行补单的操作，所谓补单即通过支付流水关联全局的订单，关联到了，将订单的支付状态改为支付成功，更新银行回写时间等等。如果没关联到，确实没有订单，那么要线下找银行去处理了。

这里只是最简单的处理方式。