当前位置:   article > 正文

《支付系统-3交易系统》_支付交易系统

支付交易系统

本文属于ping++《支付系统》白皮书读书笔记系列。

3. 1收单网关

 收单网关主要负责吧业务系统的请求转化为支付系统的内部请求,主要是进行参数校验、权限检查等再对支付系统进行转发。

这里白皮书提到了通常是基于https和post提交的方式,但是实际可以根据公司的情况,我们就没有这一层。直接接口调用了RPC

接口定义

列举下相关的接口

服务请求接口:封装支付系统本身的能力,给外部系统进行调用。之前说的下单,支付就属于这种。

即时到账交易接口:买家付款成功钱直接到卖家账户。

担保交易接口:买家付款成功钱进入平台方账户。

结算(分账)接口:用户再支付完成后,对服务完成(如收货或者上门服务),确认订单完成,将担保金额结算给卖家。

继续支付接口:用户未支付的情况,在业务系统需要继续发起支付时调用。

退款接口:已支付交易有业务系统发起退款申请。

交易查询接口:业务系统没收到交易系统回调情况,可以来查询交易系统。

交易状态变更通知接口:包含交易信息通知业务方,以便业务方及时处理。

交易状态:交易订单状态:待付款、已付款、交易成功、交易结束、交易关闭。

关于退款:通常由于三方超时限制,需要财务人员线下处理。所以 返回失败实际意义要根据情况来衡量。

3.2 交易服务

3.2.1 交易服务的作用

  •  将支付系统的能力抽象出来,对外提供各类交易方式,如:下单、支付、修改金额、确认结算、退款、查询等标准接口。
  • 基于收付款方的交易链路抽象交易类型,以满足不同业务方各类交易长期的需求。
  • 鉴权交易、交易结果的通知。
  • 对接业务方。

3.2.2 担保收单交易

担保交易: 用户在平台下单,支付完成后,再服务完成(收货或者提供服务)后,将该笔资金结算给对应商户账户。是英语具备一定结算周期的业务,通过上面的担保收单接口及结算接口有业务方灵活控制结算账期。

当然,实际项目落地可以做的更复杂,比如及时业务方推送结算也可以是再额外约定冻结期,冻结期到了才开始真正的结算给商家。

实际上分为两个环节,下单支付跟结算。

下单环节用户支付的钱只是到了平台账户(属于临时过渡保管),这笔钱要给出去的,具体时间有业务方决定。

结算:业务方发起结算,才给收款人账户增加一条记录,以内部转账的形式把担保账户的资金,转给实际收款的商户账户。

3.2.3 即时到账交易

   即时到账与业务有关,常见的场景如会员产品购买。

 

合担保交易的区别,没有单独的结算环节,所以下单的时候,即明确相关的参数(分润参数),就是哪个用户uid,给个账户,交多少钱等。

3.2.4 充值交易

  充值交易及用户对账户余额进行充值。一版用于虚拟币或者钱包等。

书上列举两种方式:基于支付平台的账户做充值跟基于业务平台做充值。

流程

业务平台充值:充值、消费完全业务端闭环,支付只提供一种手段。

这里只介绍下较普遍的支付系统充值。虚拟账户在支付平台体系内且独立于业务系统,业务入口在业务端。接入业务平台只需要一套用户体系识别用户id。

优势:资金账户清晰、流程标准化、所有账户资金有支付系统控制、资金安全性高。

劣势:开发成本高。

3.2.5 出款交易

出款也称为提现,平台的用户基于自己账户余额进行提现。是将资金从平台的虚拟资金账户转移到外部账户的过程。

流程:

出车款交易可以 分为出款到三方账户跟到卡。针对B端的商户的提现交易记录, 最好单独用表记录,最好余额的校验工作。

  1. 出款到账户:需要做好账户信息的采集工作。主要是对接三方(微信、支付宝),优先实名认证。

2. 出款到卡:需要用户实名认证(认证四要素),还需要把支付系统存储的银行卡信息(卡bin,开户行信息、城市)做鉴权。将两者信息做校验,当然还需要三方渠道进行支持接入对应的银行卡出款渠道。

   实际在项目运营中,多数反馈的是鉴权问题,如收不到银行绑定的短信验证码,交易未明等信息。大多数需要客户自行咨询发卡行去解决。

 

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/Gausst松鼠会/article/detail/497180
推荐阅读
相关标签
  

闽ICP备14008679号