支付渠道插件：管理员只需填写表单即可使用 / Payment channel plugin: 进行配置,不需要集成

go-admin 没有支付渠道机制,人们仍然需要一个。支付宝、微信支付和PayPal都占用了相同的位置,今天每个需要一个的项目都自己编写了集成代码,每个提供商都有自己的代码。我将把这个作为标准:管理员打开支付设置,选择一个渠道,粘贴商户 ID 和提供商提供的密钥,保存,然后订单就开始支付。没有代码,没有重建,没有重新部署。它应该是一个可选的插件,因为许多 go-admin 用户从来不需要支付,也不应该携带一个。这意味着大部分工作都在提供商的 API 之外。调用这些 API 是最简单的部分。围绕它的机制就是功能: **参数是数据,不是 YAML。**如果键存储在 `settings.yml` 中,那么"配置它"意味着在服务器上编辑一个文件并重新启动,并且我们已经构建了一个开发人员功能,穿着一个管理员功能的外衣。它们应该存储在一个表中,就像 `sys_config` 已经工作一样,这样一个渠道就可以在运行系统中开启。 **每个渠道都声明它需要什么。**支付宝需要应用 ID、应用私钥和平台公钥;微信支付需要商户 ID、API 密钥和证书;PayPal 又需要其他东西。如果一个渠道声明了自己的参数列表,则设置表格将从该列表生成,添加第四个渠道并不意味着要修改用户界面。 **凭证不是普通配置。**在静态存储时加密,永远不记录,一旦保存,则面板会报告值已设置,而不是显示它。一个商户密钥以明文形式存储在配置表中,任何具有数据库连接或配置导出的用户都可以读取它,这比该功能的价值要高得多。 **回调 URL 必须稳定且按渠道分配。**商户只需将一个 URL 粘贴到提供商的控制面板中一次,然后再也不需要考虑它。它不能在我们重新组织路由时移动。然后,支付代码中总是会出现问题,值得在任何人写代码之前说一下: **回调多次到达。**这是正常操作,不是边缘情况,因此必须两次处理才不能将两次付款视为同一付款。它还出现了错误顺序,因此一个晚期的 `pending` 不能覆盖已记录的 `paid`。签名在任何东西触及数据库之前都会被检查。订单表需要一个商户订单号的唯一键,在本仓库中,这意味着包含软删除标记: `(merchant_order_no, deleted_at)`。一个可为空的标记无法做到这一点 - `NULL` 不等于 `NULL` ,因此 MySQL 将为一个付款保留两个活动行。这就是 #863 中 `common.ModelTime` 发生变化的原因。我会设计为同时使用两个渠道,而不是一个,即使只实现一个。写一个接口来对应一个提供商,然后稍后添加第二个,就是如何在太晚的时候才发现接口是该提供商的 API,但字段名已被更改的原因。如果有人构建了一个他们满意的支付渠道抽象,请说出来 - 我宁愿复制一个形状,而不是自己写代码。