费用变更:
2.进入收银页面了. 既然收银台不能主动调用业务系统. 那么收银台就提供一个接口,提前处理费用变更的逻辑. 即先关单来避免支付数据错误.
最好支付宝,微信那边也提供.
1.正常逻辑是支付前做一次 check, 费用是否变化.
提现:
先扣费,再提现.长期处于提现中的, 需要重试下.
退款:
先改状态,再提现.
handler模式,很像系统组装.
1. 商户号申请要关联公司营业执照
2. app 对应关联 微信商户号
3. 支付查询,退款查询的权限一定要开.
- 代码随着时间变迁. 模块化越来越凌乱
- 核心非核心代码越来越混乱
- 没有用 jvm 内轻量级消息组件,而是使用重量级 mq.
- 统计 sql 大量使用. 应该以计数基础平台.
- 对账利用 xml 使用. 利用对账平台,配置对应 sql 和 python 使用. 做到准时时对账和发送补偿消息.
- 不分主子类型,导致 type 值意义差别较大. 另外增加一个 type 需要改动 n 处代码.
- 只读操作未进行缓存和及时更新.导致数据库大量调用.
- id 大量传递,导致数据库大量被调用.
- 很多都不能可视化,导致客服和自身排查工作增加.
- 重复支付通过事务来保证. 最好通过trade上的流水号来判断
- 实体从1变成 list,没有很好的梳理各个实体之间的逻辑关系. 并列,只取其1,还是如何. 把各自独立变成接口化,list 实现.
代扣,企业代扣等.
12. 传递给下游的 type 字段(从三个字段 判断综合出来, payCannel,pay_type)没有保存. 后续流程都需要重新计算一遍.
13. 一个商户号只支持一个微信 app, appId 应该是渠道入口传入的
转播
