谈谈异常（一）
业务对账和资金对账的本质及原理我们已经谈得差不多了，现在就来谈谈业务过程中的异常处理。
可以毫不夸张地说，异常占据了我们设计思考产品的八成精力，如果没有异常，系统设计会相当简单。
先谈谈支付单据处理过程中的异常。
一笔支付指令，从业务场景报送业务单据，到形成支付指令，再完成账务驱动，回执业务场景，整个链路节点众多，任何一个环节出问题都会导致异常的发生。
假设一个最粗粒度支付平台的领域关系是这样的（支付公司内部我们看他黑盒好了，实际上即便是支付公司内部会根据实际情况再划分业务架构域，有各自的职能和单据）：
淘宝（创建交易单据）向支付宝发起支付请求==》支付宝创建支付单据向工商银行发起支付请求==》工行银行执行收单及账务操作，回执支付宝==》支付宝更新单据状态同步，执行账务操作，回执淘宝==》淘宝变更交易单据状态，推进后续流程。
简单来说就是：
taobao①==》alipay②==》bank③==>alipay④==>taobao
我们有时候（很低概率）会遇到这种情况：
在网站上使用支付宝买了东西，明明银行扣款成功了，但是商户的订单状态还是等待支付——客户开始不停打电话进来咨询到底怎么回事，客满开始焦头烂额。
这就是一个最典型的掉单场景，多数是在3,4环节发生了信息的丢失（因为银行已经扣款了，所以1和2肯定已经消息抵达并处理）。
这种异常每天都会让我们的客户焦急万分，也曾经让支付公司头疼不已，但所幸现在已经不再是什么大问题了。
在银行端，通常银行都会开出“交易状态查询”服务接口，当支付系统发现一笔交易没有得到回执，或者返回的回执无法确定支付结果时，我们可以主动通过此服务接口，以订单号作为查询条件进行状态查询，以弥补回执丢失带来的问题。通常99%的掉单问题，都可以通过这个方式来解决。
即便还留有1%的用户，无法通过掉单查询来恢复状态，我们在日终的时候还是可以通过业务对账的方式来进行单据状态的确认……但这样其实用户体验已经比较糟糕了。
复习一下，业务单据状态的确认，有三种方式：回执消息，掉单查询恢复以及业务对账。
这样，我们由于白天的交易而产生的与银行机构之间的债权债务关系就明确了，下回接着说。
