支付基本上是很多产品都必须的一个模块，大家最熟悉的应该就是微信和支付宝支付了，不过更多的可能还是停留在直接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）

原文地址：http://www.cnblogs.com/osscoder/p/6708222.html
.NET社区新闻，深度好文，微信中搜索dotNET跨平台或扫描二维码关注