跑腿业务和支付业务的具体实现流程

校园云项目

跑腿业务的具体业务分析

该流程适用于很多接单相关的业务场景，或多或少都可以从中得到启发；

整个流程描述：

任务发布：
- 用户在平台上发布任务，描述需要完成的任务内容，包括取件地址、送达地址、物品类型等信息。
任务接收：
- 平台将任务分配到前端合适的人员，当有配送员接收任务后准备执行。
任务执行：
- 配送员按照任务要求前往取件地址，取得物品后运送到指定的送达地址。
任务完成：
- 配送员顺利将物品送达目的地，并进行拍照取证，用户确认收到物品后，任务状态更新为已完成。
异常处理：
- 如果在任务执行过程中出现问题，用户可以发起工单请求平台处理，平台会协助解决问题并保障用户权益。
任务下架：
- 如果在一定时间内无人接受任务，或者用户不再需要该任务，用户可以选择取消任务。

对整个业务过程分析：

可以抽离出6个任务状态：

发布（初始状态），
已接收，
已提交待确认（接收任务者上传凭证后，发起任务者未确认前），
已完成（发起任务者点击确认完成任务），
异常（发起任务者发起工单），
已下架（设定时间内无人接收或者上传任务者点击下架）；

就足够包含整个业务流程；

对每个状态中牵扯到的变化再进行具体的分析处理

当派单用户发起任务后，用户的余额=原余额-任务金额~~（优先减兑换码的余额）~~，若剩余金额不足返回提示错误，若足够返回发布成功；最好全部用事务进行包裹
若任务下架时（从已发布变成已下架）（可能因为时间到设定时间或者发起人主动取消，只有发布和已接受状态能下架，其他状态不能主动下架），余额=原余额+任务余额；
若任务异常了（从已接收变成任务异常），~~钱仍在订单中~~（钱自动放入接单人的已冻结金额中），后台判谁得到，谁的可提现金额=原可提现金额+任务金额，同时接单人已冻结金额=原已冻结金额-任务金额；
若任务异常（从已提交待确认变成任务异常），钱会变成已冻结金额（接单人待提现金额=原待提现金额-任务金额&&接单人已冻结金额=原已冻结金额+任务金额），当工单被解决时，（两种情况，若后台判发起人胜，这笔钱会从接收人的已冻结移动到发起人的可提现金额，当后台判接单人胜，这笔钱会直接从接单人的已冻结转到可提现），异常解决时该任务会直接从异常转变为已完成；

若变成已完成状态，需要进行流水表的记录

当任务表状态变成已提交待确认后，用户待转入金额=原待转入金额+任务金额；等待到凌晨4点后，接单用户的待转入金额=原金额-任务金额&&接单用户的可提现余额=原余额+任务金额，更改任务状态为已完成；同时进行流水表的记录；
当发起人直接点击确认完成后，~~用户待转入金额=原金额+任务金额；等待时间12h后，待转入金额=原金额-任务金额&&接单用户的可提现余额=原余额+任务金额（不受理任务异常）；~~ -------(或，可以直接改成不等待：接单用户的可提现余额=原余额+任务金额) ，进行流水表的更新。

如果你以为这就结束了，那就太天真了，一个完整的业务逻辑，应该将所有能预料到的情况都包含在内，例如，这些方法中若一些方法的sql语句执行成功，一些失败，应该怎么处理？当多个用户同时接单，同时对数据库中状态进行修改时，应该怎么处理等。

上边这些状态最好全部用事务进行包裹，防止一些未预料到的情况或错误发生时，可以进行回滚操作；

上边这些状态或多或少都会出现高并发的情况，需要进行上锁，异步等的处理操作；

优化：

充值业务场景分析：

以微信充值为例，实际支付宝支付的整个流程差别不大；

前置条件：需要获取支付所需的前置条件：参数申请 - 通用规则 | 微信支付商户文档中心 (qq.com)，配置API key - 通用规则 | 微信支付商户文档中心 (qq.com)，下载并配置商户证书 - 通用规则 | 微信支付商户文档中心 (qq.com)待都配置完成后进入第一步开发

充值都可以分成两大步来进行分析，更容易理解：

第一步（提交充值请求）：具体来说就是，用户在前端点击下单后，先生成本地订单存储在服务器中（记录一些重要信息），然后再生成符合微信格式的订单并发送给微信官方（同时需要对本次请求头使用前置条件中的内容生成签名信息操作：具体生成过程的代码：如何生成请求签名 - 通用规则 | 微信支付商户文档中心 (qq.com)，也可以直接调用官方方法，以go为例使用 Go SDK 快速开始 - SDK&开发工具 | 微信支付服务商文档中心 (qq.com)），包含了加密的过程，最终微信服务器给我们返回一个二维码。（整个过程也是需要使用进行事务处理的，防止本地有订单远程未发送，或者远程生成了订单，但本地不存在的情况）。让我们进行官方代码刨析：简述：首先定义必要参数，建立客户端，调用客户端中native的支付方法，返回支付二维码。

【详细解释】：

cilent这个客户端方法，可能很多人并不清楚到底是什么东西，他在这些接口业务中到底是什么作用（包括支付，钉钉🤖通信，微服务架构等等都会出现这个知识），接下来就先科普一下什么是Client，通俗来说：

初始化一个客户端其实就是创建一个包含了多个方法的包，并传入一些必要的参数来配置这个客户端的过程。之后，可以直接调用这个方法体中的方法来访问客户端中封装好的方法，执行相应的操作。在微信支付的情境中，这个客户端包含了发送预支付请求、查询订单状态、退款等方法，通过初始化客户端并调用这些方法，可以方便地进行微信支付相关的操作。

第二步（处理充值请求）：wechatpay-apiv3/wechatpay-go: 微信支付 APIv3 的官方 Go Library (github.com)

这是微信官方的sdk仓库，在readme中包含了回调验签的代码示例，

整个过程包含两个步骤：

回调通知的验签与解密

使用微信支付平台证书（验签）和商户 APIv3 密钥（解密）初始化 notify.Handler
调用 handler.ParseNotifyRequest 验签，并解密报文。

具体实现：

初始化

方法一（大多数场景）：先手动注册下载器，再获取微信平台证书访问器。

适用场景：仅需要对回调通知验证签名并解密的场景。例如，基础支付的回调通知。

代码：

ctx := context.Background()
// 1. 使用 `RegisterDownloaderWithPrivateKey` 注册下载器
err := downloader.MgrInstance().RegisterDownloaderWithPrivateKey(ctx, mchPrivateKey, mchCertificateSerialNumber, mchID, mchAPIV3Key)
// 2. 获取商户号对应的微信支付平台证书访问器
certificateVisitor := downloader.MgrInstance().GetCertificateVisitor(mchID)
// 3. 使用证书访问器初始化 `notify.Handler`
handler := notify.NewNotifyHandler(mchAPIv3Key, verifiers.NewSHA256WithRSAVerifier(certificateVisitor))

验签：

transaction := new(payments.Transaction)
notifyReq, err := handler.ParseNotifyRequest(context.Background(), request, transaction)
// 如果验签未通过，或者解密失败
if err != nil {
	fmt.Println(err)
	return
}
// 处理通知内容
fmt.Println(notifyReq.Summary)
fmt.Println(transaction.TransactionId)