Skip to content

Latest commit

 

History

History
172 lines (124 loc) · 6.77 KB

记录支付平台开发.md

File metadata and controls

172 lines (124 loc) · 6.77 KB

整理硬盘找出来的, 当时这个项目基本是个人完成的 耗时7-8个月(实际代码时间应该小于1月) 当然 写文档 花了不少时间 数据库文档 然后 设计流程 应用接入的api文档 .... 这个项目已经上线并在无人值守稳定运行

这是当时项目过程中碰到进度和方案记录的一个版本 这个文档里面 下面列举的问题 后面全都解决了

呵呵 异步任务后来用的rabbitmq 然后消费的过程中 涉及一些自己的 任务调度策略

这里安全方面为什么用 rsa 还要加 用户自主密码呢 防止接入方证书泄露 当时改证书来不及 他们可以直接改个接入密码 继续维持线上运行 然后再有时间 完成证书替换

XX钱包财务流程:

用户接入流程:
	1. 注册 XX公共平台[XX开放用户,XX钱包]接入账号
	2. 等待审核
	3. 审核通过后 会得到 client_id, client_secret
	4. 使用 client_id 和 client_secret 可以按照文档进行用户接入了
	5. 可以参考用户接入 demo[php]
	
	如果进一步要使用 XX钱包 :
	1. 申请企业认证
	2. 设置接入密码[充值订单密码 + 提现订单密码 + 交易订单密码]
	3. 上传生成的 rsa 公匙证书
	4. 等待审核
	5. 审核通过 会邮件给你 XX钱包公匙
	6. 参考文档进行财务接入




数据安全方案:

--------------- 发送数据的情况 ----------------------
1. 接入方(生成一对RSA密钥[私钥自己保存/公钥上传XX钱包]):
	a. 获取 token
	b. 用户使用私钥对发出数据+相关密码(充值订单密码 + 提现订单密码 + 交易订单密码)进行签名
	c. token + 数据 + 签名 post 到XX钱包

2. XX钱包方(一对RSA密匙[公开XX钱包公钥])
	a. 检测接入放权限 都没问题后
	b. 对要发送给接入放的数据根据类型 + 接入配置里用户设置的密码(充值订单密码 + 提现订单密码 + 交易订单密码) 使用XX钱包私钥进行签名
	c. 数据 + 签名 返回(回调时是post)给用户

--------------- 接收数据的情况 ----------------------
1. 接入方
	a. 使用XX公匙 对收到的数据包+自己设置的相关密码 进行签名验证


2. XX钱包方
	a. 验证用户token
	b. 根据类型对数据进行完整性检测
	c. 验证接入应用权限
	d. 使用接入方公钥 对用户post的数据 + 应用接入设置的相关密码 进行签名验证
	e. 验证财务相关用户权限
	
	

说明: 接入方接入是 要求设置 【充值订单密码, 提现订单密码, 交易订单密码】这些会参与数据签名验证 但是不会在数据传输中提现
     接入方保存: 自己设置的接入密码, 接入方自己生成的私钥, XX钱包的公钥
     XX钱包保存: 接入方设置的接入密码,XX钱包私钥,接入方上传的公钥





A. 应用财务接入方
----------------------------------------
1. 获取token接入令牌
2. post 充值/提现/支付 数据 并使用私钥+相关密码 签名
3. 获取实时返回(订单查询/预充值订单[比喻快钱的提交form]/余额支付)
4. 异步交易等待服务器回调通知
	a. 验证XX钱包数据签名
	b. 对数据进行处理(充值/支付/提现)


B. XX钱包方(每个接入引用下有N个用户,每个应用的的财务及用户数据相互隔离)
----------------------------------------
1. 检测令牌
2. 检测主要参数是否缺失
2. 检测用户接入配置(用户财务权限/用户财务风控)
	a. 应用已经接入 但此用户是第一次使用财务的情况
3. 验证数据包签名
4. 对数据进行处理(充值/提现/支付)
	a. 生成XX钱包处理订单
	b. 对数据签名提交支付通道处理
	c. 等待支付通道实时返回 或 异步回调 结果
5. 实时返回受理结果
6. 对异步处理任务加入异步回调队列
7. 异步服务回调接入放


C. 支付通道方
----------------------------------------
1. 受理XX钱包数据(充值[支付]/打款[提现])
2. 验证XX钱包接入数据签名
3. 实时返回数据(订单查询/预下单等接口。。。)
4. 回调XX钱包接入(支付/提现/退款申请)




------------------------------------------------------------------------------------
预想太美好 现实要做和注意的东西太多 
参考: https://beecloud.cn/doc/?index=0 这个成熟的四房支付 2(10年开发经验)-20 左右人在做
创业者 以前清华然后美国博士 google硅谷回来创业 (第一个版本用了9个月)

我们定的1个月时间,左右出支付/提现/交易api (貌似他们比我们只多了京东支付,然后我们多了汇款充值)
------------------------------------------------------------------------------------



XX钱包充值订单状态:
------------------------------------------------------------
0 充值订单创建完成等待支付
1 等待用户支付(XX钱包已经想支付方返回支付相关内容 等待用户进行支付)
2 支付通道处于等待用户支付
3 支付通道到账, (支付通道回调XX钱包 或者XX钱包异步向支付通道查询到账)XX钱包到账
4 回调第四方完成(交易完成)
5 交易关闭( 1. XX钱包订单超时关闭 2 支付通道那边关了 3 用户发起关闭)
6 --- 发生退款 -- 退款订单状态


XX钱包交易订单状态:(等待。。。)
------------------------------------------------------------


XX钱包提现订单状态:(等待。。。)
------------------------------------------------------------




还可能会有问题的东西
-----------------------------------------------------------
1. 流水到底怎么搞 未定下来(按我想的来)
2. 充值订单状态 拆成三个 发生退款的 状态未定下来(还未抓退款订单数据包[流程太长未测试])
3. 每个支付订单查询返回结果
	a. 订单在支付通道方不存在的情况
	b. 订单在支付通道存在但未支付的情况
	c. 订单已支付的情况
		c1. 银行未回调我们
		c2. 银行已经回调我们,我们已经入账
		c3. 我们未回调接入方
		c4. 我们回调接入放,单对方未正确回执
		c5. 回调地四方失败
	d. 订单发生退款的情况
		d1. 退款完成
		d2. 发起退款申请 等待通道处理
		d3. 退款失败
	e. 订单关闭
		e1. 订单超时关闭
		e2. 订单在支付通道长时间未处理(支付通道自动关闭)
		e3. 接入方主动对未支付完成的订单发起关闭

4. 支付通道查询订单需要归一的数据
	a. 支付金额
	b. 支付完成时间(未付款的订单可能没有)
	c. 支付状态
	d. 此笔交易的手续费(有的接口是没有的 要自己算)
	e. 在支付方的订单号(并不是所有接口都可能有)
		e1. 微信支付 未支付之前没有订单号 只有预支付订单号
		e2. 快钱只能查询交易成功的订单

5. 有的支付通道对查询有限制 但是未在文档明确说明限制条件(我说的就是垃圾X联) 这叫一个 菊花疼