聚合支付-功能实现

前言
第一部分 - 商户注册和资质申请第二部分 - 对接 SAAS
第三部分 - 闪聚支付
更新

24.05.23 初始记录（商户注册&资质申请）
24.05.29 获取短信验证码
24.05.30 文件上传
24.06.02 Saas对接
24.06.04 bug新增，烦，遇到bug，进展很缓慢。

总结其实除了之前做过的内容，这个项目资料里只有一点重要：根据代码，项目中的聚合支付实现主要依靠==扫码接口的 request 中的 user-agent ==来判断浏览器类型

商户注册&资质申请

系统交互流程

商户注册的流程由商户平台应用、商户服务、SaaS 平台、验证码服务四个微服务之间进行交互完成，各微服务的职责介绍如下：

1）商户平台应用：此应用主要为商户提供业务功能，包括：商户资质申请、员工管理、门店管理等功能。

2）商户服务：提供商户管理的相关服务接口，供其它微服务调用，主要为商户平台应用提供接口服务，功能包括：商户基本信息管理、资质申请（这个功能蛮莫名其妙的，写了但是没有后续的审核操作，不知道干什么用的😥）、商户应用管理、渠道参数配置、商户员工信息管理、商户门店管理等。

3）SaaS 平台：闪聚支付项目是一个 SaaS 平台，所谓 SaaS 平台即多个用户租用平台的业务功能，这样用户即可省去软件系统开发的成本，每个商户就是一个租户，所以又称为多租户系统。 SaaS 平台提供租户管理、账号管理、权限管理、资源管理、套餐管理、系统认证授权等功业务功能。在上图商户注册的流程中，商户注册的账号等信息需要写入 SaaS 平台，由 SaaS 平台统一管理账号，分配权限，商户统一通过 SaaS 平台登录闪聚支付。

4）验证码服务：提供获取短信验证码、校验验证码的接口。商户使用手机号进行注册，平台通过校验手机验证码来确认是否本人在注册。

获取短信验证码

短信验证码为一个开源的服务，可单独开启使用。

开源 git 地址：(https://github.com/fightingape/sailing)

大致看了一下这个开源项目是根据传入的业务名称，获取配置好的 code 长度和 Service 实现。后续应该还可以加入别的实现（比如阿里云的短信服务等）

其中生成验证信息这个方法。
1.根据业务名称 + 随机 UUID 生成 key 存入 redis。这个 key 会返回给服务请求方。
2.根据配置好的 Map 获取名称对应的 len 即 code 码长度，如果传入不存在的 name，会直接报错。
3.验证服务就是根据返回给服务请求方的 key，查询 Redis 缓存是否存在，不存在返回 false，即验证码错误。

本项目中没有使用，只是简单控制台打印了一下。也可以直接在这个服务里存入 redis（因为要申请开通阿里云短信服务有点麻烦，又要多部署一个服务，而且这个功能比较简单不打算花时间开通了）。

之前有写过阿里云的短信，关联文章：

内链：[[【代码模板】阿里云接口实现短信发送]]
外链：【代码模板】阿里云接口实现短信发送

文件上传

资质申请的流程中涉及到了文件上传的功能。之前已经写过使用 Minio 作为文件服务器和用阿里云 OSS 作为文件存储两种方式。这里的上传直接把七牛云换成了 Minio。顺便整理了一下之前写过的两种方式。

文件上传：

内链：[[【代码模板】文件存储]]
外链：【代码模板】文件存储

支付参数配置

这个部分是项目的核心，之前做别的项目的时候，接触了微信支付和支付宝支付。就和这个项目中说的一样，用户只能先选择支付类型。再调用对应的接口获取支付二维码。而通过聚合支付这个平台，可以只生成一个链接，根据用户扫码，跳转不同的支付。

商户应该配置哪些第三方支付渠道的参数
服务类型是闪聚支付平台为商户提供的聚合支付服务通道，共分为线上和线下两大类：
线上支付服务通道：

手机 APP 支付
PC 网页支付
手机网页支付
小程序支付
线下支付服务通道：
收款码支付 (C 扫 B)：即商户出示付款码，用户扫收款码完成支付。
B 扫 C：即顾客出示付款码，商户扫描付款码。

系统交互流程

商户应用创建流程
商户渠道参数配置交互流程
交易服务职责：提供支付渠道参数配置、订单、发起支付、转账、退款等功能。

C 扫 B

1、为门店生成统一的支付二维码，用户扫一下二维码即可使用微信支付也可使用支付宝完成支付。

2、闪聚支付平台与微信、支付宝对接，闪聚支付作为中介，最终的支付动作（银行交易）仍通过微信、支付宝进行。

3、闪聚平台作为中介调用微信、支付宝的下单接口，完成支付。

重点：根据代码，项目中的聚合支付实现主要依靠==扫码接口的 request 中的 user-agent ==来判断浏览器类型

业务流程如下：

生成二维码的系统交互流程如下：

商户登录商户应用平台，查询门店列表
商户平台请求交易服务获取门店二维码 URL
商户平台根据 URL 生成二维码

交易服务支付入口：

顾客扫描二维码，请求交易服务支付入口
交易服务解析请求，生成支付确认页面
交易服务向服务响应支付确认页面

支付宝统一下单接口对接：

顾客输入金额，点击立即支付
请求交易服务，交易服务保存订单
交易服务调用支付渠道代理服务的支付宝下单接口
支付渠道代理服务调用支付宝的统一下单接口。
支付凭证返回

支付宝支付相关内容：

内链：[[04 聚合支付-【代码模板】支付宝支付接入]]

外链：聚合支付-【代码模板】支付宝支付接入

微信支付接口对接：

微信支付相关内容：

内链：[[05 聚合支付-【代码模板】微信支付接入]]

外链：聚合支付-【代码模板】微信支付接入

获取支付结果（RocketMQ）

完成支付后第三方支付系统提供两种方式获取支付结果：

第三方支付系统主动通知闪聚支付平台支付结果。

闪聚支付平台主动从第三方支付系统查询支付结果。

以上两种方法在实际项目中可以都用，其中第二种是必须用的，因为第一种是由第三方支付系统主动通知闪聚支付平台，当调用闪聚平台接口无法通信达到一定的次数后第三方支付系统将不再通知。

对接 SAAS

系统交互流程

商户注册时与 SAAS 的交互流程已经在商户注册模块给出。

分布式认证需求

统一认证授权分布式系统的每个服务（系统）都会有认证、授权的需求，如果每个服务都实现一套认证授权逻辑会非常冗余，考虑分布式系统共享性的特点，需要由独立的认证服务来处理系统认证授权的请求。如下图，闪聚支付平台包括：商户平台应用、运营平台应用、门户应用，每个应用都需要身份认证，闪聚支付平台统一由 UAA 认证服务完成认证。
开放认证体系考虑分布式系统开放性的特点，UAA 认证服务不仅服务于平台自身，并且对第三方系统也要提供认证，平台应提供扩展和开放的认证机制，以开放 API 的方式供第三方应用接入，一方应用（内部系统服务）和三方应用（第三方应用）均采用统一机制接入。

分布式系统认证技术方案详见下图：

流程所涉及到统一账号服务、UAA 服务、API 网关这三个组件职责如下:

1）统一账号服务：提供商户和平台运营人员的登录账号、密码、角色、权限、资源等系统级信息的管理，不包含用户业务信息。

2）统一认证服务：它承载了 OAuth2.0 接入方认证、登入用户的认证、授权以及生成令牌的职责，完成实际的用户认证、授权功能。

3） API 网关：作为系统的唯一入口，API 网关为接入方提供定制的 API 集合，它可能还具有其它职责，如身份验证、监控、负载均衡、缓存等。API 网关方式的核心要点是，所有的接入方和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。

BUG 记录

RestTemplate 使用 GET 请求，返回中文乱码

内链：[[RestTemplate使用GET请求，返回中文乱码]]

外链：RestTemplate使用GET请求，返回中文乱码

项目中访问 Swagger 地址，404（未解决）

不管怎么访问 swagger 的页面地址，都返回 404。但是直接用 apifox 的 URL 导入，是可以成功的🥴。

使用 mapstruct 转换对象，报错 Cannot find implementation for……

这个项目中是因为 User 微服务没有依赖 mapstruct。但是 swagger 中有这个依赖，他直接用了 swagger 中的依赖。网上搜索还有一种情况可能出现这个问题。

内链：[[使用mapstruct转换对象，报错Cannot find implementation for……]]

外链：使用mapstruct转换对象，报错Cannot find implementation for……

前端 JS 在 Long 长度大于 17 位时，出现精度丢失的问题

内链：[[Long长度大于17位时，精度丢失]]

外链：Long长度大于17位时，精度丢失

使用 git 提交报错：error RPC failed; HTTP 413 curl 22 The requested URL returned error 413

内链：[[使用 git 提交报错：error RPC failed; HTTP 413 curl 22 The requested URL returned error 413]]

外链：使用 git 提交报错：error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413