前提条件:先不考虑数据量。
财务流水里面有充值、提现、下单(就是订单那块)。帐户余额也涉及到冻结(例如在提现的时候)。
订单支付方式有帐户余额、在线支付。
本人现在是以单表的形式记录流水的,表如下:
id:流水号
time:发生时间
price:金额(有+跟-)
type:充值、提现、下单
pay_name:支付名称(支付宝或微信)
pay_detail:第三方支付接口返回的信息(如对方的流水号等)
status:状态(0表示未生效,1表示生效。例如发起一条充值操作,但尚未充值成功则用0表示)
========================================================================
简单记录如下:
ID price type
1 +100 充值
2 -50 下单(使用帐户余额下单)
现在有个问题,例如给订单付款的时候用户选择了在线支付,那么是直接跳到第三方支付去的,这个流水记录应该怎么写?
先+再-还是直接-?假如直接-的话帐户余额就对不上了。
现在就是卡在这里,或有其他更好的做法?例如分表什么的
财务流水里面有充值、提现、下单(就是订单那块)。帐户余额也涉及到冻结(例如在提现的时候)。
订单支付方式有帐户余额、在线支付。
本人现在是以单表的形式记录流水的,表如下:
id:流水号
time:发生时间
price:金额(有+跟-)
type:充值、提现、下单
pay_name:支付名称(支付宝或微信)
pay_detail:第三方支付接口返回的信息(如对方的流水号等)
status:状态(0表示未生效,1表示生效。例如发起一条充值操作,但尚未充值成功则用0表示)
========================================================================
简单记录如下:
ID price type
1 +100 充值
2 -50 下单(使用帐户余额下单)
现在有个问题,例如给订单付款的时候用户选择了在线支付,那么是直接跳到第三方支付去的,这个流水记录应该怎么写?
先+再-还是直接-?假如直接-的话帐户余额就对不上了。
现在就是卡在这里,或有其他更好的做法?例如分表什么的
解决方案
20
假如是真实的业务场景,建议分表,外部接口(三方支付)存到另一张表,原因是三方支付的在你公司没有现金流,所以不应该属于账户流水。
或可以在本表增加标记字段,用来区分支付方式,当然金额就不用标记+- ,统计对账的时候注意区分就好了
或可以在本表增加标记字段,用来区分支付方式,当然金额就不用标记+- ,统计对账的时候注意区分就好了
20
可以先添加一条status=0的记录,三方支付成功返回之后置成1
20
可以加标记列,在线支付标记为不变更余额
也可以把在线支付变成两条流水,一条为在线支付充值,+账户余额,第2条支付,-账户余额
也可以把在线支付变成两条流水,一条为在线支付充值,+账户余额,第2条支付,-账户余额
20
为什么不参考一下大众点评,或 支付宝 中的处理方式? 同样他们也实现了由 支付宝余额支付,还是由银行支付。
其实这个本身不是技术问题。相似于财务怎么样记录制作会计分录的原则。 在业务定下之后,软件开发则是通过不同的方法选择来保证这些业务规则的实现。 例如可以参考微软的 petshot中的订单处理中的策略模式实现同步/异步的订单处理策略。
其实这个本身不是技术问题。相似于财务怎么样记录制作会计分录的原则。 在业务定下之后,软件开发则是通过不同的方法选择来保证这些业务规则的实现。 例如可以参考微软的 petshot中的订单处理中的策略模式实现同步/异步的订单处理策略。
10
你应该把业务分为充值和购买两种来考虑
充值就是增加账户余额,购买就是减少账户余额
跳第三方支付的实际流程是先充值到账户余额,成功后再从账户余额里扣减
两个业务的流水日志分在两个表记录,互不影响
充值就是增加账户余额,购买就是减少账户余额
跳第三方支付的实际流程是先充值到账户余额,成功后再从账户余额里扣减
两个业务的流水日志分在两个表记录,互不影响
10
这类开源商城做支付业务,还需要检查模块以及安全性。