支付业务-简单介绍-不定期更新

提现:

详解步骤:

 

用户登陆(session录入)→

 

前往提现页面(查可用金额，做页面显示与前端验证，若事先保存有银行信息，直接载入到页面)→

 

提现方法(同步处理的情况可以直接根据返回结果提示用户并跳转结果页面，推荐使用异步处理方式，   便于解决高并发的情况)(异步方法:在service实现类的方法上加@Async注解，注意需要配置开启注解  机制，用户发起提现请求时，只提交本次表单数据，简单验证字段后传给异步方法处理，直接返回|处 理中|的状态结果给用户，注意|处理中|的订单也是视为成功的，直接减去用户此次提现金额。此时保    存中间表:提现记录表，并标记本次交易处理中)注意!!!方法的执行结果要判断全面，例如在读取数据    库，访问服务器，读取文件流等业务上出现异常时，要回滚事务。尽量把每一步的日志都打印的很全  面。→

 

提现回调方法(表单提交时我们传递给银行的回调地址必须是畅通的，外网无条件无拦截器可以访问 到的。收到回调以后的业务:首先读取回调信息,通过回调的订单号查到本地记录,通过状态修改此次交 易的订单状态,并更新用户余额)注意!!!1回调方法要调试畅通,避免出现异常2确认收到回到后要银行    回执,银行收到后讲不再发送回调3回调信息中的金额要与本地数据库的金额进行比对是否一直4订单 设置标识符,处理过的订单避免重复处理→

 

查看结果(用户提现完成后,稍后查看结果)

 

注意事项

前段验证只是用来提高用户体验的,后台要判断所有数据和业务逻辑.

未知的情况一定要谨慎处理,可以在里面添加通知管理人员的业务,第一时间人工处理.

支付类的固定参数会写在配置文件或数据库里,便于维护,若是配置文件,必须是密文的.

 

代付操作,一般都是T+1处理模式,如果有定时任务执行的话,要防止被人插入数据.

数据上要有本地签名值,最好做到分库操作,生成公钥私钥进行加密.

代付的流程,走过的服务器越多,加密解密的次数越多越安全.

 

很必要的一项验证:平衡差.

用户入账和出账永远要平衡,否则出现问题.

 

不要依赖与第三方的验证,所有参数要本地自行验证,例如金额,状态是否范围内,回调是否不再发送等

保证数据一致性:

首先发起请求和接收回调传递的金额必须是一致的。

发起时我们在本地数据库记录金额，回调后进行比较，不匹配视为失败的情况。

浮点类型的精度问题是一个不可避免的问题。例如页面是元单位10。03后台是分单位1003在乘100     时会发生精度丢失，简单处理是在js上四舍五入 math。round() 标准一点使用大数字类型解决