[发明专利]一种多平台之间数据一致性校验的方法和系统

说明书

技术领域

本发明涉及数据处理技术领域，具体涉及一种多平台之间数据一致性校验的方法和系统。

背景技术

目前，通过网银进行的电子支付的过程是，用户从商户的商品的页面进入支付页面，选择支付方式进入相应的网银页面，支付完成，返回支付页面。

当支付完成后，银行系统平台方并不会每笔立刻结算给商户，而是在一天的一个固定的时间点，把之前某个时间段(比如一个自然天)里面发生的所有成功交易的金额批量结算给商户。因此，在商户方一笔交易存在三个状态，等待交易，交易成功，清算成功。

其中，等待交易是指，用户已经选择了支付方式，跳转到网银页面，这时用户的行为已经脱离了商户方的页面，商户方是不知道的。

交易成功是指，用户在网银上完成了交易，银行方面确认后，给用户一个跳转指示，让用户的浏览器跳转回商户方的支付页面。在这个时候，往往存在一些问题，在用户在支付完成之后，网络出现了问题，或者用户正常或者异常关闭了浏览器，或者其他原因，使得商户方没有得到支付成功的信息。那么这个时候，这笔交易在银行方的状态是支付成功的，在商户方仍然是等待交易的状态，两个平台的状态是不一致的。

清算成功是指，银行系统平台在某个特定的时间点，完成了清算工作，已经把钱打给了商户的账户，商户需去获取银行系统平台的清算文件，去和支付平台中相应时间段内的交易进行核查，确认是哪些交易获得了清算，将这些已经获得清算的交易状态改为清算成功。清算成功往往是一笔交易的最终状态，这个时候商户和银行系统平台已经了解了关于该笔交易的债务关系。

商户和银行系统平台数据进行交易数据的校对，不直接采用其本身具有的交易表进行，交易表一般包括外部触发产生该交易的电子商务网站平台的交易单号、电子商务网站平台的交易发起时间，第三方支付平台的交易发起时间，第三方支付平台的交易完成时间，银行系统平台的交易完成时间，银行系统平台返回的交易单号，银行系统平台的交易金额，银行系统平台的交易状态，等等。因为交易表由于侧重的目标不一样，缺乏很多对于数据校对来说重要的属性，并且因为查询的需求不一致，交易表建立的索引也不见得对于进行数据校对很有帮助，所以，一般单独采用一组数据表来描述数据校对的工作，这个工作通常被定义为“收集”，其采用一组数据表通常被定义为收集表，一般包括第三方支付平台的交易完成时间，银行系统平台的交易完成时间，银行系统平台返回的交易单号，银行系统平台的交易金额，银行系统平台的交易状态，等等。定期将所有发生的交易收集到这组特定的数据表中，打上特定的数据校对的属性，在使用银行清算文件对其进行校对的时候，去改变这些属性。但是在实际中会存在问题，例如，在收集组成数据表时，某些交易有可能仍然处于“等待交易”的状态，而在收集组成数据表之后，用户完成了整个支付动作，这些交易变成了“交易成功”的状态，那么在和银行对账的时候，就会出现问题，因为对“等待交易”和“交易成功”的交易采取的措施是不一样的，那么必须在对账之前完成交易状态在两组表间的一致性扫平。这个扫平工作需要针对两组表在一段时间内的交易逐条进行状态比对，如果不一致，以交易表为准，改变收集表的状态。例如，在进行两组表之间数据一致性的扫平过程中，若发现交易表中银行系统平台的交易状态为“交易成功”状态，而在收集表中银行系统平台的交易状态为“等待交易”状态，此时，可以以交易表为准，将收集表中银行系统平台的交易状态更新为“交易成功“状态。这个扫平的工作会随着日交易量的变大而变得越来越缓慢，因为日交易量越大，需要检索的数据就越多。在对账完成后，需要统计出来本次对账，成功销账(清算)多少笔，还有多少笔处于“等待交易”和“交易成功”的状态。

这样通过收集表在查询总数和总金额时，由于数据量非常的大，形成了慢查询，拖累了整体对账速度。另外，完成交易状态在两组表间的一致性扫平，由于收集表非常大，导致同步时间过长。

另外，商户业务人员需要经常检查有多少笔交易已经处于“交易成功”状态，但是银行却没有清算，统计总数和总金额；还需要检查，有多少笔交易处于“等待交易”，用来计算潜在的业务流失率，这需要去检索收集表(不能检索交易表，因为，第一，交易表不具备便于该检索的索引设计；第二，交易表不容易区别哪些是已经到了清算日的，因为当天发生的交易是没有到清算日的)，这个检索的工作是非常庞大的，而且随着收集的数据量的增加，检索工作会越来越慢，并且检索会存在一定的不准确因素。

发明内容