公共支付平台设计思路
2016-03-13 17:09
316 查看
公共支付平台:XX
1.支付宝+微信+银联,通过银联支付,实际也是走的支付宝提供的接口,并未和银行直接做交互。支付平台包含两方面配置(XX各系统配置+各支付系统配置)
2.首先XX:包含多个提供支付的系统(i聘+b端+校园+评测系统(内网+公网)),支付平台会配置各系统交互的xml信息(主要配置:系统的标识id,名称,订单号,md5校验码),
当系统请求平台支付接口时,根据系统id,读取xml配置,并获取信息,根据订单号查询对应的系统的订单信息,获取订单金额等信息;(从订单中提取key,根据md5加密规则对比md5校验);
3.校验成功跳转,系统内支付页面,这时,还是要重新走校验和订单信息查询流程(可能会发生篡改)。用户这时会选择支付方式,支付宝、支付宝接口各银行、微信。当用户荀泽支付方式点击
确定后,在重新走校验+根据订单查询订单信息(已经第三次校验)。根据支付方式读取对应支付xml配置,组装body\title\支付成功回调url,(支付宝接口:回调数据格式:json,支付宝包含两个回调,实时回调+轮询回调(支付宝自己的机制,可能一天回调一次,
如果回调成功,返回回调成功码,通知中断通知))(微信:回调格式为格式xml,实时回调一次,所以需要自己写服务,根据订单号轮询微信公开的订单记录,判断是否支付成功),微信和支付宝都支持回调校验,因为回调
暴露在公网,可能会被扫到,所以平台接到回调需建立回调校验(请求回调校验接口),根据校验规则判断是否是支付平台回调的。
4.注意,校验时间戳,将请求时间写入加密cookie,再次操作时,对比时间。
5.注意,支付平台传递的订单号,一定是公共支付平台定义的订单号,因为那个XX系统提供的订单号都不一致,可能不符合第三方支付平台接口。
1.支付宝+微信+银联,通过银联支付,实际也是走的支付宝提供的接口,并未和银行直接做交互。支付平台包含两方面配置(XX各系统配置+各支付系统配置)
2.首先XX:包含多个提供支付的系统(i聘+b端+校园+评测系统(内网+公网)),支付平台会配置各系统交互的xml信息(主要配置:系统的标识id,名称,订单号,md5校验码),
当系统请求平台支付接口时,根据系统id,读取xml配置,并获取信息,根据订单号查询对应的系统的订单信息,获取订单金额等信息;(从订单中提取key,根据md5加密规则对比md5校验);
3.校验成功跳转,系统内支付页面,这时,还是要重新走校验和订单信息查询流程(可能会发生篡改)。用户这时会选择支付方式,支付宝、支付宝接口各银行、微信。当用户荀泽支付方式点击
确定后,在重新走校验+根据订单查询订单信息(已经第三次校验)。根据支付方式读取对应支付xml配置,组装body\title\支付成功回调url,(支付宝接口:回调数据格式:json,支付宝包含两个回调,实时回调+轮询回调(支付宝自己的机制,可能一天回调一次,
如果回调成功,返回回调成功码,通知中断通知))(微信:回调格式为格式xml,实时回调一次,所以需要自己写服务,根据订单号轮询微信公开的订单记录,判断是否支付成功),微信和支付宝都支持回调校验,因为回调
暴露在公网,可能会被扫到,所以平台接到回调需建立回调校验(请求回调校验接口),根据校验规则判断是否是支付平台回调的。
4.注意,校验时间戳,将请求时间写入加密cookie,再次操作时,对比时间。
5.注意,支付平台传递的订单号,一定是公共支付平台定义的订单号,因为那个XX系统提供的订单号都不一致,可能不符合第三方支付平台接口。
相关文章推荐
- HDU 2073:无限的路【模拟】
- 快来给宝宝打分
- 使用javascript为网页增加夜间模式
- Pku oj 1573 Robot Motion(模拟)
- 在JDBC中使用PreparedStatement代替Statement,同时预防SQL注入
- 构建一个简单的Linux系统 MenuOs —— start_kernel到init进程(20135304刘世鹏)
- 第一周笔记
- 第一周学习感想和以往回顾
- plsa(Probabilistic Latent Semantic Analysis) 概率隐语义分析
- 第一讲: 软考中高项01_信息基础+服务管理
- c++第2次实验(循环)
- Windows系统下安装Ubuntu虚拟机
- 《Java程序设计》第二周学习总结
- IDEA社区版使用Maven + Tomcat开发Web项目
- 第一次上机实验1-2
- Git使用教程
- MySQL索引
- 20145329 吉东云《Java程序设计》第二周学习总结
- 最小生成树--kruskal
- linux用户和权限管理