Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

微信支付多商户相关设计讨论 #3

Closed
gdlcf88 opened this issue May 15, 2020 · 8 comments
Closed

微信支付多商户相关设计讨论 #3

gdlcf88 opened this issue May 15, 2020 · 8 comments
Assignees
Labels
discussion enhancement New feature or request

Comments

@gdlcf88
Copy link
Member

gdlcf88 commented May 15, 2020

  • 所有的商户(AppId)应有注册机制
  • 支付结果通知接口、退款通知接口,应在路由上传入AppId,从注册的商户配置中匹配,用于进行签名验证,验证不通过的请求将不会传交给handler

@GameBelial 你怎么看?

@gdlcf88
Copy link
Member Author

gdlcf88 commented May 18, 2020

支付结果通知接口、退款通知接口,应在路由上传入AppId

已了解,微信调用回调地址时会传入appid参数。

@gdlcf88
Copy link
Member Author

gdlcf88 commented May 23, 2020

所有的商户(AppId)应有注册机制

注册机制是为了提供足够信息进行签名验证,也可考虑设计成可替换的验证器

@real-zony
Copy link
Member

@gdlcf88 考虑使用单独的表存储,存储在 ISettingManager 限制很多,性能也有不少问题。

@gdlcf88
Copy link
Member Author

gdlcf88 commented Jun 7, 2020

是否考虑使用setting,在全局、租户级别提供“商户配置”,并且允许开发者对此配置器进行重写或替换,从而实现更复杂场景?

@real-zony real-zony self-assigned this Jun 23, 2020
@real-zony real-zony added enhancement New feature or request discussion labels Jun 23, 2020
@gdlcf88
Copy link
Member Author

gdlcf88 commented Jun 25, 2020

可考虑:

  • 主动请求微信时:默认从setting中获取配置,支持手动临时覆盖默认配置
  • 接收微信回调时:从商户注册表中读取配置,目前用于签名验证

@gdlcf88
Copy link
Member Author

gdlcf88 commented Jun 27, 2020

@gdlcf88 考虑使用单独的表存储,存储在 ISettingManager 限制很多,性能也有不少问题。

我们的框架模块最好不设计实体,保持轻量

@mentianyi
Copy link

你们的工作太棒了,加油.

@real-zony real-zony added this to the 1.8.2 milestone Dec 29, 2021
@gdlcf88 gdlcf88 removed this from the 1.8.2 milestone Jan 7, 2023
@gdlcf88 gdlcf88 closed this as completed Jan 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants