商户聚合支付系统设计
产品概述与整体设计本文转自:https://blog.csdn.net/think2017/article/details/79820786背景如今,网购已经渗透到人们日常生活中的方方面面,做为网购的载体,互联网电商平台发展如火如荼,支付功能做为其不可或缺的一部分,实现起来,也有各种各样的方案。根据自己有限的认知,我主观上把目前行业内的支付实现方案做以下归类:
我从开发者的角度,主要针对第二类,讲述怎么去构建商户自己的聚合支付平台,以及投产上线后所需要主意的事项,打造一套简单、稳定、高效的聚合支付平台。 整体设计一个完善的聚合支付系统,拥有支付网关、主动对账、退款网关、支付/退款状态查询等功能模块。我会以LNMP架构为基础,细分成六个章节对每一部分做尽量详细的说明。 聚合支付平台的核心,就是怎么合理的去管理接入的各种支付SDK,很多童鞋从官网下载到SDK,几乎不做任何逻辑修改,就直接放到项目的目录中使用,这样做虽然开发成本很低,但弊端颇多,首先要说的就是不易维护,各支付SDK代码结构、风格不一样,后期维护成功高;代码各自为政,没有统一的调用方法;配置分散,无法集中维护系统配置项;无法提供统一有效的日志数据等。因此,我建议首先定义一个Interface,如下图: 然后,每次接入新的支付方式的过程,其实就是实现该Interface的过程。 通常情况下,一种支付方式有一个class[将其class备注为支付类]来实现,但面对一种支付方式提供了多种支付场景,比如微信(提供了公众号支付、APP支付、扫码支付、H5支付、小程序支付、微信免密代扣等)、中国银联(提供了PC网关支付、WAP支付、APP支付、银联云闪付等),我们该怎么办,我建议针对每种不同的支付场景,都有单独的class来实现,理由如下:
那么,就有童鞋就会想到了,一个很头疼的问题,代码冗余。大部分第三方支付,虽然提供了不同支付场景,但基础接口都是一样的,只是部分参数不同,或支付流程上面的少许差别。这时候我们就要考虑好以第三方支付平台为单位来封装一个支付基类,该支付基类实现其所必须的接口调用,比如微信支付,代码如下图: 上面分别提到了 支付Interface、支付类、支付基类三个概念,它们之间的关系是怎样的,见下图 对上图做简要说明,PaymentHandlerInterface是所有支付类的接口,WechatPayment是所有微信支付类的基类,WechatAPPPayment、WechatJSAPIPayment、WechatNativePayment都是提供支付服务的支付类,都需要继承WechatPayment并实现PaymentHandlerInterface接口。同理,系统如果需要接入银联在线支付,那么就需要按照开发文档实现一个ChinaPayPayment做为银联在线支付的基类,然后分别开发出具体支付场景的支付类,比如ChinaPayAPPPayment(银联app支付)、ChinaPayWAPPayment(银联wap支付)、ChinaPayPCPayment(银联pc支付),这三个支付类需要继承ChinaPayPayment并实现PaymentHandlerInterface接口。 支付网关与异步通知设计支付网关用户下单成功后,要经过收银台发起支付流程,支付网关就是用户发起支付流程的入口地址。支付网关需要接收订单的部分数据(订单号、待支付金额、商品描述信息等)和交易数据(支付方式、交易起止时间、回调地址等)以及签名,支付网关接收到收银台的支付请求后,验证并处理支付请求数据,再根据支付方式获取支付实例(比如WechatAPPPayment对象),发起支付(执行doPay)。 支付交易流水表,以下重要字段:
支付网关设计,需要注意以下几点:
支付异步通知支付通知,是用来接收来自银行或者第三方支付平台的订单支付结果通知,分为两种,一种是同步通知(又称前台通知),一种是异步通知(又称后台通知),简单的说,商户支付系统收到支付同步通知并且支付状态为已支付,我们需要将订单支付状态修改为支付确认中,商户支付系统收到支付异步通知并且支付状态为支付成功,我们需要将订单支付状态修改为已支付。再次强调下,商户支付系统要以异步通知的结果为准。 异步通知设计,需要注意以下几点:
退款网关与退款状态查询设计背景退款业务,相对于支付业务,部分需求方(包括产品、市场的同事)认为退款业务不是那么紧急或重要。从业务角度分析,没有支付业务,用户无法支付或支付优惠活动无法开展,但没有退款功能,则不影响用户下单支付和开展优惠活动。用户申请退款,财务可登录第三方支付平台提供的商户管理系统进行人工退款操作。因此,目前应该还有许多电商平台的退款业务都是财务人工操作的,当公司订单到了一定规模,人工退款操作则是不可行的。这时候,则需要一一对接退款业务。 从系统安全角度分析,退款业务的重要性甚至比支付业务更要高,因为退款业务可以理解为是商户自己向用户付钱,如果多付,所造成的公司财务损失,几乎不可能追回。常见的风险有:订单申请了部分退款,由于各种原因造成多退的情况;系统退款由于操作人疏忽或其他原因造成不该退款的订单退款给用户的情况。以上两种情况,我身边确实有这样的案例,最大的一次损失,是一个下午,给公司造成了80多万的损失。鉴于此,在设计退款模块的童鞋,逻辑一定要缜密,不要有疏忽、漏洞等隐患。 退款网关对用户主动取消的已付款订单、或者因为库存不足、无法配送等各种原因需要撤销订单的,都需要给用户进行退款操作,退款形式有原路退款、银行转账、退余额等,目前主流的都是进行原路退款。退款网关不能有用户直接访问,订单要有退款申请与审批流程,一般是在订单管理系统控制,有订单管理系统调用退款网关,发起退款请求,聚合支付系统要对退款网关做好身份验证及安全防范。 聚合支付平台退款部分,也需要异步通知处理队列,消费队列接受来自第三方异步通知、crontab主动查询或人工查询到已退款成功的订单退款数据,将其统一处理,更新退款单状态、通知订单系统等操作。 退款交易流水表,主要字段展示
注意点
退款异步通知同支付异步通知一样,退款异步通知也建议使用队列进行解耦,收到第三方的退款通知,只需要验签和金额校验后,则将报文数据push到退款通知队列中,有后端消费进程去更新退款单的退款状态、通知订单系统的退款状态等后续处理流程。 支付/退款状态查询针对上一章节所遇到的问题,虽然主动对账可以处理掉绝大部分已支付订单被挂起的问题,但难免有漏网之鱼,没有被及时处理的订单,用户肯定不干,要投诉平台。鉴于此,我们开发人员需要给客服或者财务同事提供一个后台查询系统,用于处理客诉中这类问题的订单。该模块需要支持两点:
(编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |