最近近半年时间，都在做公司的自有商城，由于开始的时候，设计的不是很合理，导致后来代码比较杂乱，业务流程交叉，很是郁闷。。。所以抽时间做个小总结，本人小菜，高手请略过。。。。
1.支付
1.1 支付
a)接收商品信息和用户信息
b)生成订单
c)向支付系统提交支付
d)支付成功，插入支付表，向第三方下单，接收下单结果，下单成功，更新订单表为成功；下单失败，退款
e)支付失败，插入支付表，更新订单表状态为：失败
1.2 退款
a)加载订单表，支付表和接口配置表
b)判断订单表状态，成功或者在途状态的订单，可以退款，其他状态的订单不做退款处理。
c)向支付系统提交退款交易
d)根据退款结果，插入支付表记录，然后更新订单表状态为已退款。
2.游戏点卡
a)向用户展示商品数据
b)接收用户提交的购买信息。
c)对用户提交的信息进行验证，包括商品单价、总价、数量等等，对非法信息进行记录，并决绝该次请求。
d)合法交易，转到支付页面，进行支付。
e)接收第三方的交易结果的通知，根据结果，如果成功，更新订单状态为成功，如果 失败，进行退款。
f)定时查询订单为在途状态的交易，向第三方提起查询请求，根据结果，如果成功，更新订单状态为成功，如果 失败，进行退款。
***注意***
c步骤，一定不要相信用户提交的数据，都要严格进行验证。
e和f步骤，有可能几乎同时执行，这时候，先执行的那个，首先把订单状态改为“修改中”。因为两个流程在修改 时都会读取订单状态，只能修改“在途”状态的订单。这样就避免出现重复退款的可能。
3.点券（天猫，京东）
点券的业务和点卡的相似，重点注意要验证用户提交的信息的合法性。
两种点券实验了两种不同的下单方式。
a)当用户在前台页面选择要购买的商品数量，点击提交的时候，后台自动锁定相应数量的商品，用户完成支付后，完成出库。后台开启一个线程去查询用户放弃的商品，解锁。（缺点：效率低； 优点：保证提交后一定有货）
b)用户可直接购买任意数量的商品，在商品出库的时候，如果商品数量不足，提示用户“库存不足”。（缺点：体 验不好； 优点：效率高）
4.总结
注意验证数据合法性。
原文地址：http://blog.csdn.net/Mchange/article/details/19918625