转载第三方支付平台相关-支付对账

Posted 2020-08-16 笨鸟居士的博客

参考页面：

http://www.cnblogs.com/leefreeman/p/4043959.html

 

首先交易的流程（商家角度）：

1：浏览商品、下单； 
2：支付，用户将货款划到支付平台； 
3：支付平台通知商家支付成功； 
4：卖家收到支付通知，进行发货； 
5：用户收到货物，验货完成，通知支付平台； 
6：支付平台将货款划到商家账户。

涉及到银行的支付流程（支付平台角度）：

1：浏览商品、下单； 
2：支付，用户将银行账户信息提交给支付平台，支付平台连接银行支付网关，请求将买家账户的资金划至支付平台银行开的账户。 
3：银行返回结果给支付平台，支付平台通知卖家支付成功 
4：卖家收到支付通知，进行发货； 
5：用户收到货物，验货完成，通知支付平台； 
6：支付平台将货款划到商家账户。

还要涉及一个支付平台与银行对账的流程：

支付平台与银行：用户的支付实际是将自己银行账户的钱划到支付平台的银行账户上（实际上支付平台在多家银行都有自己的账户），同时在支付平台做好记录。
但银行实际划账是T+1，也就是说此时虽然支付成功了，但是支付平台的银行账户余额上并没有增加资金，在第二天银行结算完成后，支付平台银行账户的资金才到账。
也就是说在此时，只有信息流的产生，没有资金流的产生。而这笔资金信息，在支付平台上也会特别标记，比如记为“应收款”，待实际划款后才记为“已收款”。

常见对账问题有：

1、信息流中没有对应的应收款记录，而对账文件中有记录。

    也就是说支付平台，不知道自己收到款了，但支付平台银行账户上实际确实多了款项。这种情况是由于支付请求到达银行后，银行处理完成，
但银行通知支付平台环节出现问题（可能是网络原因等），导致支付平台没有收到支付成功的通知，所以在支付平台上没有记录。
但因为银行处理完成，在结算的时候仍然会将此款项划入了支付平台银行账户，所以对账文件中存在记录。
针对这种情况，可以考虑对账后将信息填补上，并且后续通知商户继续发货。对于用户而言，他的支付状态可能一直待支付，但他实际支付成功，可能会电话投诉，
客服做好合理的解释并提供必要帮助。

2、信息流中存在应收款记录，而对账文件中不存在。

    也就是说支付平台认为应该收款，但实际银行账户并未受到款项。这种情况通常是由于支付平台和银行系统系统时间不同，
比如一笔交易在支付平台上是23:59分完成的，但银行系统认为是在00:01完成的，所以在银行当日的对账文件中就不存在此款项记录，而会在第二天的对账文件中体现。
针对这种情况，因为并不会影响用户支付流程，所以在拿到第二天的对账文件时做处理就行了。

支付平台和商家也有对账的需求：

因为商家的资金存在支付平台的账户上，而发货由商家做。商家就得核对每天的货款是否和自己支付平台上的账户金额对的起来。
通常的做法是支付平台提供一个商家系统，商家可以在系统中查询下载一段时间内的账户信息，然后和自己的货款信息对账。

支付安全

支付平台通常面临的安全问题，包括：

1、用户密码被盗；

2、钓鱼网站诱导用户骗取资金；

3、用户银行卡信息泄露；

4、网络传输数据被截取；

 针对以上问题的方案：

针对第一种情况，大部分支付平台会设置两个密码，即登录密码和支付密码，登录密码和支付密码严格要求不能相同，如果你两个密码都被盗了怎么办？
一般支付平台在支付时要求你安装数字证书，数字证书和某台电脑是绑定的，没有安装数字证书的电脑不能完成支付。
而新安装数字证书必须通过手机短信进行验证。纳尼？手机也丢了，那就只有打110了。

钓鱼网站就是域名和界面都和真实的支付平台网站非常相似的网站，用户误认为是真实网站而输入了自己的账户信息支付，导致资金转到了非法账户。
防止钓鱼网站，支付平台可以与浏览器厂商合作，比如输入类似域名的网站时警告用户该网站可能存在风险，而正确域名的网站则提醒用户该网站是安全可靠的。

用户银行卡信息被泄露，一般在支付时还会有手机短信验证进一步保证安全，另外在交易风险监控方面也可以做一些事情，例如限制一张银行卡当日的最大交易量。
如果交易量超过设定阀值，则交易失败，另外发送短信给用户提示账户存在风险。

由于支付的过程相关的支付信息、账户信息都会在网络上传输，为了保证数据在传输过程中的安全，
一般会采用SSL协议（Secure Socket Layer即安全套接层）或SET协议(Secure Electonic Transcation 即安全电子交易协议)来进行传输，
他可以实现数据的加密，并且提供认证服务和保证数据完整性。具体的技术细节有机会在慢慢分析。

SSL和SET协议的对比分析

安全套接层（SSL）和安全电子交易（SET）是两种重要的通信协议，每一种都提供了通过Internet进行支付的手段。
但是，两者之中谁将领导未来呢？SET将立刻替换SSL吗？SET会因其复杂性而消亡吗？SSL真的能完全满足电子商务的需要吗？
我们可以从以下几点对比作管中一窥： 

SSL提供了两台机器间的安全连接。支付系统经常通过在SSL连接上传输信用卡卡号的方式来构建，在线银行和其他金融系统也常常构建在SSL之上。
虽然基于SSL的信用卡支付方式促进了电子商务的发展，但如果想要电子商务得以成功地广泛开展的话，必须采用更先进的支付系统。
SSL被广泛应用的原因在于它被大部分Web浏览器和Web服务器所内置，比较容易被应用。 

SET和SSL除了都采用RSA公钥算法以外，二者在其他技术方面没有任何相似之处。而RSA在二者中也被用来实现不同的安全目标。 

SET是一种基于消息流的协议，它主要由MasterCard和Visa以及其他一些业界主流厂商设计发布，用来保证公共网络上银行卡支付交易的安全性。
SET已经在国际上被大量实验性地使用并经受了考验，但大多数在Internet上购的消费者并没有真正使用SET。 

SET是一个非常复杂的协议，因为它非常详细而准确地反映了卡交易各方之间存在的各种关系。
SET还定义了加密信息的格式和完成一笔卡支付交易过程中各方传输信息的规则。
事实上，SET远远不止是一个技术方面的协议，它还说明了每一方所持有的数字证书的合法含义，希望得到数字证书以及响应信息的各方应有的动作，
与一笔交易紧密相关的责任分担。

小结：

上面的文章主要从支付平台的流程出发，简单分析了支付平台中典型的业务细节，以及在支付安全上采用的方法，这些业务流程都是比较典型的流程，某些支付平台可能会有所差异或者包含很多其他的业务，需要真实的去了解。