做业务有个绕不开的业务逻辑，就是支付。这里总结一个基础的支付电商逻辑闭环流程，完成支付基础体系的实现。这里假定我们要实现的是一个独立的电商平台上允许用户在平台充值，其他的类似多多购物或者淘宝购物的流程逻辑。

数据表结构的逻辑设计。这里复盘一个开发的产品订单系统。

   数据逻辑上，首先我们需要有个基础的商品表（一般包括商品id+名字+描述+所属店铺+各种关联图片）其他的一些自定义属性（是否允许参团  是否推荐购买，排序，标签之类的，是否允许上架）。这是商品的基础表。Product数据表

   然后围绕基础表，品类表是关联商品表的，我们需要设置对应的品类价格，品类的标题，品类的描述，主要设置允许售出数量，不同的品类数量是不同的，包括是否卖光,，品类的排序，品类的详细图片（和产品本身图片不同，这个是每个套餐的产品图片）。Package数据表

在一般情况下，商品表+品类表，已经可以确定用户购买的商品，但是如果商品规格是随着基础属性不断变化增加的，我们还需要属性商品属性表。属性分类1级属性（大类） 2级属性（归属1级属性），属性的附加价格，每次用户勾选其中一个属性，都会导致价格变动，每个大类属性下面只能勾选一个小类。ProductAttr数据表。

通过三张表，可以实现商品展示+商品套餐+商品额外属性价格叠加的商品购买效果。

订单逻辑的梳理:
参数过滤第一步。有必填空参数，直接跳出。
    首先检查商品或者商品套餐是否已经下架（下架就无法再次下单了），

第二，检查商品的库存是否超标了，超标就无法再下单

第三检查用户是否有权限购买，需要调用权限相关的逻辑身份检测，主要防止一些优惠订单被反复购买，可能限定了购买一次又或者用户是黑名单。

第四，计算商品的价格，其中还涉及到商品的优惠券核销计算，所以其实订单里面需要原始价格，优惠券价格，最终支付价格三个信息。

第五 将订单信息记录到订单系统表，完成下单逻辑

第六:将用户的该优惠券设置为使用状态。如果有其他逻辑，也一并处理，比如用户设置为店铺关注的客户，或者标记为活跃客户。
    第七，下单成功之后，将订单号返回出去。

小结下流程——产品

此处逻辑，完成了订单的生成逻辑。下一步就开始走支付逻辑。前端拿到订单号之后，跳入各大支付平台的支付接口处。
   向服务器端发送订单号+身份认证token+支付方式的选择。如果选择余额支付，由于不涉及到外部支付系统，直接查询当前该用户是否有足够余额，付款完成的同时，将订单也一起完成。基本订单类型的都需要事物逻辑，关于事物，后面专门拓展。
   查询订单，主要是查询未支付的订单，超时/取消/或者并发类的订单直接拦截掉。

根据我们自己的订单号，生成相关参数，按照指定格式生成其他平台的支付格式（如果是WX 则会生成微信格式， ZFB生成zfb格式，苹果生成苹果支付格式）

付款完成后，支付成功方会向我们的回调。回调的本质是服务器端根据它运行的结果调用我们预先写好的API。

至此，我们完成了我们支付项目的第二部分逻辑，主要是唤醒第三方的支付，并让我们在支付平台的账号收到对应款项，然后收到款项之后，向我们的服务器发送已收到款的信息。

回调逻辑:

根据我们自己发给服务器的本地交易号，查询到对应的订单，然后将第三方的交易流水号还有交易信息在本地进行更改。同时将订单的状态变更成已收到款，收到款项后，就是走我们后续的发货逻辑或者店铺里面核销逻辑。

  回调的第三方一般传回的参数除了本地发过去的订单号（本地的唯一性），还会传token  交易订单号。
 这样就完成了一个下单——发起支付——完成支付的整个流程，基本上电商的最重要的逻辑就是收款，收不到款，其他的都是白干。所以要做独立开发，必须对支付业务流程有清晰的认识。

将整个流程整理成一张图：

• 业务的下单逻辑
  • 产品是否还在
  • 产品是否超过库存
  • 购买权限检测
  • 价格系列核算
  • 完成下单逻辑
  • 扣除商品库存/优惠券锁定/状态标志
  • 返回订单号，给其他逻辑调用
• 发起支付逻辑
  • 检查下单时候订单号信息
  • 检查该订单是否允许继续支付
    • 是否超时需要关闭
    • 商品是否已经不允许下单
    • 系统已经锁定不再支持支付
  • 调用第三方支付模块生成支付跳转
    • 配置回调链接
    • 配置发起模式
  • 等待客户端完成支付
    • 这一步基本都是第三方SDK完成
• 支付成功后回调
  • 校验回调拿到的信息
  • 更改订单状态变更为完成支付
  • 处理完成支付后的逻辑（发货\核销之类操作）