缴费业务的一般流程和差异

缴费业务的一般流程和差异

从终端来看：最糙的流程是这样：
1.终端调用后台的查询个人缴费计划（grycx接口），后台返回给终端一个欠缴信息
2.终端可以点击缴费，然后输入银行卡密码，后台返回给一个缴费结果给终端
说白了，这里就是两个请求-响应
第一个是确认请求，第二个是缴费请求；只有第一个了确认了，才执行第二个缴费；
第一个确认请求到达后台后，后台做了什么？
后台接收到这个请求之后，去调用X软的一个接口（个人应缴查询）
在个人应缴查询接口把欠费信息返回到后台后，后台把该结果处理一下，返回给终端；
一般后台做的事情是：
1.接收终端请求获取参数，
2.将参数组装成javabean，发送给本地数据库事务处理接口，得到返回结果并处理成理想的结果，
3.将这个理想的结果发送给终端
这里后台做的事情：
1.接收终端请求获取参数，
2.将参数组装成报文，发送给东软个人应缴查询接口，接收返回结果并处理成理想的结果，
3.将这个理想结果发送给终端
所以说，第二步做的事情变了；
第二个缴费请求到达后台之后，后台做了什么？
1.接受终端的请求获取参数
2.将参数组装成报文，将报文发送给第三方支付平台，接收返回结果并处理成理想的结果
3.将这个理想结果发送给终端

所以后台的处理流程都是一样的：
1.接收请求，获取参数
2.根据参数组装javabean或者报文，将javabean或者报文发送给对应的接口，接收返回结果，处理成理想结果
3.将理想结果发送给终端
区别在于第二步，是组装javabean,还是报文，组装json报文还是金融报文而已
这里要注意的问题是：
是不是第三方支付平台缴费成功了，就一定可以返回了呢？
不是的，
即使第三方支付平台缴费成功了，还得去通知另外一个平台，
让另外一个平台也做相应的处理，如果他们处理失败了，我们也只能去调用支付平台的接口，
去撤销缴费，从而让缴费金额原路返回；
这样做是确保多个涉及的平台的缴费记录的一致性，
如果不一致，那问题就严重了；
管理平台作为一个中游，为了实现上游和下游的交互，一直在做的工作是：
接收数据，处理数据，发送数据；接收数据，处理数据，发送数据；
中游完全就是一个数据流！