最佳实践坑 收银台

费用变更:

    2.进入收银页面了. 既然收银台不能主动调用业务系统. 那么收银台就提供一个接口,提前处理费用变更的逻辑. 即先关单来避免支付数据错误.

       最好支付宝,微信那边也提供.

    1.正常逻辑是支付前做一次 check, 费用是否变化.

提现:

    先扣费,再提现.长期处于提现中的, 需要重试下.

退款:

    先改状态,再提现.

    handler模式,很像系统组装.

     1.  商户号申请要关联公司营业执照

     2.   app 对应关联 微信商户号

     3.  支付查询,退款查询的权限一定要开.

1. 代码随着时间变迁. 模块化越来越凌乱
2. 核心非核心代码越来越混乱
3. 没有用 jvm 内轻量级消息组件,而是使用重量级 mq.
4. 统计 sql 大量使用.  应该以计数基础平台.
5. 对账利用 xml 使用. 利用对账平台,配置对应 sql 和 python 使用. 做到准时时对账和发送补偿消息.
6. 不分主子类型,导致 type 值意义差别较大. 另外增加一个 type 需要改动 n 处代码.
7. 只读操作未进行缓存和及时更新.导致数据库大量调用.
8. id 大量传递,导致数据库大量被调用.
9. 很多都不能可视化,导致客服和自身排查工作增加.
10. 重复支付通过事务来保证. 最好通过trade上的流水号来判断
11. 实体从1变成 list,没有很好的梳理各个实体之间的逻辑关系. 并列,只取其1,还是如何. 把各自独立变成接口化,list 实现.
    代扣,企业代扣等.

   12. 传递给下游的 type 字段(从三个字段 判断综合出来, payCannel,pay_type)没有保存. 后续流程都需要重新计算一遍.

   13. 一个商户号只支持一个微信 app, appId 应该是渠道入口传入的