如何模块化设计出款系统(一)

6 评论 7813 浏览 66 收藏 6 分钟

出款系统可以分为这几个主要模块:应用层、服务层、业务层、核心交易层、渠道网关层。

和收款业务相对,出款业务是支付业务的另一个重要板块。

出款业务是指,从支付机构的角度来看,资金方向是流出的,从支付机构的客户备付金账户付款到用户/商户的账户,最常见的业务类型包括:个人提现、商户结算、商户代发等。

那么应该如何设计出款系统?出款系统包括哪些模块呢?

一、设计思想

首先先来思考一个问题,在做出款系统设计的时候,应该从哪些角度进行分析?

我们经常说,产品设计时,应当从使用者的角度去思考使用者的需求是什么?在做出款产品设计时也是一样的道理。

那么出款系统的使用者有哪些?其实不仅仅有普通用户,还有不同角色的使用者,包括:

用户:

包括个人用户和商家用户。对于用户来说核心诉求是,快速、简便发起提现/代付/结算请求;资金快速到账。另外,对于个人用户和商户用户来说,都需要能随时了解交易进展和准确、尽快得知最终交易结果;如果交易失败,需要了解具体的失败原因以便更正后能成功提现/代付/结算。

财务:

对于财务来说,核心诉求是,有足够的资金用于当前出款交易;资金安全,避免出现多付款的情况;对于差错交易进行后续差错处理,保证账务无误。

通道运营:

对于通道运营的同学来说,核心诉求是,提高通道的出款成功率,同时降低成本。

风控:

风控同学的核心诉求是,根据发起交易的设备号,使用适当强度方式的校验用户身份;能对达到一定风险值的用户进行出款交易拦截。

因此,在整个出款系统的设计中,需要综合考虑不同角色的诉求进行产品设计。

二、出款系统涉及哪些模块?

我将出款系统分为5个层:应用层、服务层、业务层、核心交易层、渠道网关层。

具体包括以下模块:

出款应用层:

负责面向商户或用户,是出款服务的最前端入口。

出款服务层:

负责与外部应用层进行交互,并对调用方的基本信息进行校验。

这一层对应生成出款请求号-request id。

出款业务层:

负责处理与业务相关的流程。不同的业务类型,如个人提现和商户结算,在流程处理上会有差异,因此需要根据不同业务进行处理。这也是为什么需要拆分出款业务层和出款核心层的原因之一。

这一层对应生成出款订单号-order id。

出款核心层:

负责处理核心出款交易流程,这部分流程和前端业务没有关系,可以理解为是各出款业务最终都必经的主流程。包括出款资金审核、出款对账、出款差错处理等模块。

这一层对应生成出款交易单-transaction id。

渠道网关:

负责连接支付机构出款系统和外部通道。接收内部出款系统的外发渠道请求,包括交易请求和交易结果查询请求等,组装报文后外发到外部通道。T+1日获取通道提供的对账文件。

这一层对应生成渠道流水号-channel id。

整体订单流转流程为:

1. 用户或商户每次发起出款请求,都会对应生成一个request id,即出款请求号;

2. 流到出款业务层之后,一个request id对应生成一个order id, 即出款订单号;

3. 流到出款核心层后生成transaction id,即出款交易单。当原交易因通道异常导致交易失败而重发交易时,一个订单会对应多个交易单;

4. 流到渠道网关后生成channel id,即渠道流水号,一个transaction id对应一个channel id。

在出款系统内部,需要同时关注订单、交易单和渠道流水信息;而用户或商户在前端看到的信息则是订单层面的信息。在产品设计的时候需要注意,用户希望看到的是什么信息,那么订单层面需要将信息进行一定的处理后再面向用户展示。

后面的篇章将按照层级结构分别介绍,每个层级的每个模块扮演的角色是什么?在设计时分别需要考虑哪些因素?

 

本文由 @Rebecca 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 通俗易懂思路清晰,给作者点赞!

    来自北京 回复
  2. 为什么要产生三个id?

    回复
    1. 以购物为例,我猜是文中的几个ID可以这样理解:你点击了付款按钮会产生一个request id,这个ID对电商平台运营人员非常有用;当你核对好地址、商品信息后点击立刻支付会产生一个order id,这个ID对运营、客服、用户都有用;付款成功后商家后台会产生一个transaction id表明付款成功,这个ID对于查询付款订单比较有用,防止hack订单;channel id 可能是用来区分电商产品不同渠道,比如app、网站、小程序、代理等等,这个对营销人员可能比较有用。

      来自上海 回复
    2. 首先非常感谢你的提问~~

      出款的整个交互流程涉及四方:外部调用方–》出款系统–》渠道网关系统–》外部渠道。

      request id :一般是外部调用方传进来的。这个号在调用方那是唯一的,可用于外部调用方和出款系统进行订单核对。

      order id :是出款系统内部订单唯一性的标识。为什么不以request id为准呢,因为request id是外部调用方传进来的,当有多个调用方使用你的出款服务,碰巧其中两个调用方在同一天内送进来两个一样的request id时,你就无法分清楚了。所以内部的唯一性肯定要用自己内部生成的订单号来保证。

      transaction id :这个也是出款系统内部生成的号,和order id不同的是,order id是业务层生成的,对应的是与业务相关的订单信息,例如用户提现和商户代付是两个不同的业务。 transaction id 是交易核心层生成的,对应的是交易信息。而当渠道异常导致交易失败时,可以将第一笔交易置失败,再重发一笔新的交易。因此,一个order id可对应多个transaction id ,给前端用户返回的信息其实是order id层面的。

      channel id:这个是渠道网关系统生成的号,称为渠道流水号。渠道网关系统和出款系统是两个独立的系统,每一笔transaction 请求时,渠道网关都会对应生成自己的唯一的渠道流水号。这个号也是渠道网关系统与外部渠道之间交互的唯一性编号。

      总结一下:
      request id、order id 、channel id 是为了四方交互时,保证各方内部唯一性而产生的编号。
      而transaction id 的产生,主要是因为它和order id需要承担出款系统内不同的分工。

      文章中讲到的各个层级都分别扮演不同的角色,后续篇章会逐个具体分析。

      来自广东 回复
  3. 嗯,确实,如果再补充一下,为什么这样做就更好了。现在的支付系统比较标准化,但是很多人都知道要这样做,确不知道为什么要这样做。

    来自北京 回复
    1. 非常感谢你的建议,我对于这个问题的理解已经补充在上面那位同学的提问中。

      来自广东 回复