支付基本上是很多产品都必须的一个模块,大家最熟悉的应该就是微信和支付宝支付了,不过更多的可能还是停留在直接sdk的调用上,甚至和业务系统高度耦合,网上也存在各种解决方案,但大多形式各异,东拼西凑而成。所以这里我介绍下OSS.PayCenter开源跨平台支付组件 及其框架设计。并对常用支付模式进行一个全面介绍,方便大家开发以及跨平台使用。这篇文章主要围绕以下几个模块:
1. 微信和支付宝对比
2. 支付模式介绍
3. OSS.PayCenter框架设计
4. 调用示例
5. 注意事项
一. 微信和支付宝对比
这两者现在已经占领了移动支付的90%市场,支付形式也都大抵相同,只是在实现细节上略微不同。这里之所以要专门对比,是因为有些接口的不同在后边的框架的设计中也会有所影响。主要集中在以下几个方面:
1. 支付方式上:
a. 支付宝多了一个声波支付
b. 手机端H5支付方式中, 微信只支持微信内部浏览器
c. 微信用户扫码方式中除了正常下单返回支付二维码,还提提供了回调下单模式(即扫描的二维码并不是支付二维码,而是商品二维码,微信会回调商户指定地址才真实下单)
2. 接口安全
a. 微信不同接口安全等级不一样,涉及付款等接口加密相对简单(MD5,SHA1),涉及到退款,发送红包等接口需要使用双向证书验证
b. 支付宝所有接口统一使用RSA加密验证,需要公私钥验证。
3. 接口协议
a. 微信使用的xml协议,所有参数基本都在同一层级。
b. 支付宝使用json协议,核心参数放在biz_content字段中。
二. 支付模式介绍
1. 完整支付的流程
随着时间的发展,线上线下的支付场景都已经比较完善,各支付平台虽然接口不同,但是两者在业务流程都有着相似之处。这里我用一个流程图来展示核心的业务流程(线上线下主要是指在用户在线下单还是线下商户辅助下单):
以上流程图将线上和线下集中支付形式做了一个概要的说明,两个支付平台在具体的细节上可能或有略微不同,不过基本上都在这个流程范围之内。
注:其中微信的扫码支付中,除了正常的返回支付二维码支付,还可以直接扫描商品二维码,通过微信后台回调商家接口,在回调中完成支付请求,唤起客户端支付。
2. 支付方式介绍
首先:线上支付
1). 用户扫码支付
这个一般应用在在线PC网站支付中,用户在商户系统下单后,选择自己方便的支付平台,由商户系统向支付平台发起支付请求,返回对应的支付二维码,完成支付。(微信提供两种形式,其中可以直接扫描商品二维码,回调处理,这个可以方便应用在线下活动推广中,由微信后台间接帮助完成下单。
2). 手机端支付
这个一般应用在H5站点或者app中,商户系统下单后后台直接发起下单请求,唤起手机支付平台客户端,完成支付。(微信的H5支付只能在微信内部浏览器中唤起。
其次:线下支付,这个主要集中在超市,商场等。常见的如:
1). 商户发起扫码支付
这个基本在餐饮,超市,商场等。客流量较大,服务员需要快速完成收付操作,商户后台下单后直接扫码。如果用户扫码在多人同时操作时容易出现错单错误等问题
2). 声波支付(支付宝)
这个一般出现自动贩售机,或者聚会相互付款等,不需要用户扫来扫去,按住开关就可发现周边设备。暂时只有支付提供
3. 支付结果及后续处理
上述介绍了支付主要流程,线上支付时由于是客户端同步返回支付结果,且是在页面直接跳转完成,所以这个支付结果不能作为实际的支付结果,以防止前端的恶意攻击或者支付平台内部处理异常导致的支付失败。 正确的支付结果需要以后台的异步通知为准。
如果当前订单在一定时间内一直未支付,建议调用取消支付请求订单接口,以防止后续出现错误支付或者订单支付异常问题。
三. OSS.PayCenter框架设计
1. 框架流程
了解了以上的几种支付方式之后,那么具体的调用什么接口其实已经比较清晰了,那么我们纵向的来看一下接口调用的流程。如果把一个请求当做一个生命周期,以发起一个POST请求为例,在OSS.PayCenter中主要流程如下:
在这个框架中,分为两个部分:
下层为基类,完成 签名=》内容协议格式化=》请求=》响应内容协议格式化=》全局错误处理。其中提供了两个基本请求方法,PostApiAsync-为当前请求签名,封装xml内容调用网络请求。 RestCommonAsync-执行当前请求,并对结果格式化和全局错误处理。
上层为子类,具体各个接口名称和对应的请求内容参数。(注:退款,付款在单独的子类中,和其他接口做了物理隔离)
2. 框架介绍
当前项目都基于.Net标准库项目,也就是说同步支持.Net Framework和.Net Core,每个项目中都会有SysTools文件夹,主要存放当前类库的辅助类。
1). 基础配置
两个类库中最底层基类中,都提供了DefaultConfig 静态属性,可以方便在程序全局入口中就设置好对应的支付平台配置信息。
同时如果你存在多租户情况,可以在具体的接口类构造函数中传入不同租户支付平台配置信息。
2). 命名规则
当前项目中主要接口都已经实现完毕,但是如果你需要自己重新实现,或者个别特殊未实现的接口,可以参照各个子类的实现
实体的命名规则: 平台名称+动作名称 + 接口名称 +Req/Resp (如微信下单接口:WxAddPayUniOrderReq),实体都会继承至对应的BaseReq/BaseResp,具体可参见源码。
在当前的框架中,分为OSS.PayCenter.WX(微信)和OSS.PayCenter.ZFB(支付宝)两个项目,两者在接口协议,和参数格式上都完全不同,所以对应底层基类细节也会有所不同,详情请阅读具体代码。
四. 调用示例
这里以支付宝回调结果解析为例:
这个示例展示了主要个三个步骤,当前仅仅是解析回调结果,没有发起网络请求,下边再给出一个发起支付请求的示例:
凡是涉及到网络请求的接口都会返回一个异步Task对象,如果需要同步使用,使用.WaitResult()扩展方法即可,这个我在OSS.Http文章中已经介绍。
五. 注意事项
1. 在微信项目中同时提供有发送红包,企业付款,代金券等接口,详情可参见具体类。
2. 由于.net standard类库当前还并不是十分完整,有两个地方需要注意一下。(下个月.net standard 2.0版本发布后估计应该会完善了)
a。在wx项目中使用到了请求的双向证书绑定,.net core 和.net frameword中已经实现,标准库中暂时还没有,所以在微信配置实体中我公开了一个SetCertificata属性,调用时只需要如下赋值即可:
config.SetCertificata = (handler, cert) =>
{
handler.ServerCertificateCustomValidationCallback =
(msg, c, chain, sslErrors) => true;
handler.ClientCertificates.Add(cert);
};
b. 支付宝的加解密使用的RSA,本身提供的方法依赖于Windows系统的“crypt32.dll”和“advapi32.dll”两个组件,所以我重写了整个签名加密模块,隔离系统的依赖。但是在当前标准库版本下RSACryptoServiceProvider类内部的linux平台版本依然没有具体实现,也就是说支付宝当前项目可以运行windows系统中.net core下,linux下暂时不可以,看2.0版本更新情况如何吧。
如果你还有其他问题,欢迎关注公众号(OSSCoder)
原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/industrynews/255589.html