最后更新于 .

其实想跟大家分享这套支付系统的架构已经很久了,今天总算有时间写出来了。

先说说这套系统的需求由来吧:

  1. 笔者公司的游戏产品已经有几款了,每次上各种渠道都是要搭配不同的计费方式,并且每开发游戏都要重复一遍痛苦的接入sdk流程
  2. 游戏的支付需要出各种报表以及统计,每个游戏单独去做对人力的消耗巨大

基于以上几点,我这边设计了统一支付系统。

这个系列一共会分两篇文章,分别对应系统的v1版和v2版,我们这一篇先从v1起介绍。

在仔细分析了国内的大多数支付sdk之后,我们梳理出游戏的支付流程大体可以实现为两类:

  • 第三方sdk服务器进行支付结果通知
  • 第三方sdk客户端直接返回支付结果通知,没有服务器支付结果通知。

对于调用方而言,这两种方式各有好处。

  • 第一种方式更加安全,但是支付调用的时间相对较长
  • 第二种方式速度更快,但是很容易被不怀好意的人破解。参见之前的文章:google支付接口被刷以及解决方案

接下来,我们来看一下我这边设计的统一支付流程。

客户端:

1

服务器端:

2

简单解释一下:

  • 每次支付开始,都要让服务器生成一个订单作为此次支付的记录,订单的id即为 bill_id。订单有4中状态:订单生成,支付失败,支付成功,发货成功。
  • pay_server即为统一支付系统的服务器端,考虑到调用量和方便调试,使用了简单的http协议+json+sign的方式

对于服务器内部,唯一麻烦的一点是,《等待pay_server支付结果通知》这个接口。因为这个http请求需要支持挂起,在第三方支付服务器通知了pay_server之后,pay_server 根据通知里面透传的bill_id 将订单状态修改后,再给客户端结果。

由于我们后端是用python实现的,所以用django+gevent的实现还是蛮简单的,示例代码如下:

if bill_id in bill_to_result:
    result = bill_to_result[bill_id]
else:
    result = AsyncResult()
    bill_to_result[bill_id] = result

try:
    ret, error = result.get(timeout=config.BILL_RESULT_TIMEOUT)
except gevent.Timeout:
    logger.error('result wait timeout. bill_id: %s', bill_id)
    return jsonify(
        ret=config.RET_WAIT_BILL_RESULT_TIMEOUT,
        msg=u'超时没有返回'
    )
except:
    logger.fatal('exc occur. bill_id: %s', bill_id, exc_info=True)
    return jsonify(
        ret=config.RET_SERVER_BUSY,
        msg=u'服务器繁忙'
    )
else:
    logger.error('notify result succ. bill_id: %s', bill.id)

    return jsonify(
        ret=ret,
        error=error,
        sign=make_sign(secret, request.path, bill.id)
    )
finally:
    if bill_to_result.get(bill_id) == result:
        bill_to_result.pop(bill_id, None)

当收到第三方支付服务器的结果通知时,添加如下代码即可:

def notify_bill_result(bill_id, ret, error):
    result = bill_to_result.get(bill_id)
    if result:
        result.set((ret, error))

再来看一下支付存储需要的字段是哪些: 

class Bill(models.Model):
    userid = models.CharField(max_length=64)
    # 支付物品唯一ID
    item_id = models.CharField(max_length=255)
    source = models.CharField(max_length=32)
    # 渠道,类似 CN_91 这种
    channel = models.CharField(max_length=64, null=True, blank=True)
    create_time = models.DateTimeField(default=datetime.datetime.now)
    state = models.IntegerField(default=config.BILL_STATE_INIT, choices=[
        (config.BILL_STATE_INIT, u'订单生成'),
        (config.BILL_STATE_FAIL, u'支付失败'),
        (config.BILL_STATE_SUCC, u'支付成功'),
        (config.BILL_STATE_DELIVERED, u'发货成功'),
    ])
    bill_type = models.IntegerField(choices=config.BILL_TYPE_CHOICES)
    # 只有当是储值类型的会生效
    lz_amt = models.FloatField(null=True, blank=True)
    # 币种
    lz_cur = models.CharField(max_length=64, null=True, blank=True)
    # 兑换的内部游戏币
    lz_coin = models.IntegerField(null=True, blank=True)
    # 会被透传的信息
    passinfo = models.TextField(null=True, blank=True, default='')
    # 系统 android/ios
    os = models.CharField(max_length=16)
    # 应用的版本
    app_version = models.IntegerField(null=True, blank=True)
    # sdk的版本
    sdk_version = models.IntegerField(null=True, blank=True)
    # 如果是映射的用户,比如平安这种
    map_userid = models.CharField(max_length=255, null=True, blank=True)
    # 不可以用dict(),默认参数的问题一定要牢记
    extra = jsonfield.JSONField(default=dict, null=True)

需要注意的是extra字段,客户端可以将金额,描述等字段都放入其中。

 

整个支付的流程大体就是这样了,还需要多聊一点的是关于客户端支付sdk封装的问题。

目前是封装了一个统一支付sdk,将所有第三方sdk需要的参数传入,并根据传入的bill_type来启动对应的支付方式。

这样做的好处是:

  • 只要调通一种支付方式,基本所有的支付都调试通过了

而缺点是:

  • 依赖的第三方sdk太多,难以定制只使用几个sdk的版本
  • 第三方sdk之间非常容易出现冲突
  • 支持新的sdk非常麻烦,很容易影响其他支付

所以其实比较下来,这种客户端sdk的封装方式实际是比较差劲的,所以才会有了接下来的v2版本,升级的具体内容将会再下篇介绍。

Pingbacks

Pingbacks已关闭。

评论

暂无评论

发表评论