请问，微信支付的v3-javasdk部分是实习生在维护么？ about wechatpay-java

[oldbotman]

这里方便留个wx么？我们想了解下你具体的诉求

[Linindoo]

错误描述

基本没有体现什么面向对象的**，所有的request,rep连接口都没有 其次有些用法非常无语，比如notify的时候，要传requestbody进sdk解密，但是回调类型又写在解密前的字符串里面，很多吧，感觉怎么用怎么别扭，我一下午。 要不然发外包把这个sdk整一下吧，不然咱这小公司什么时候上v3啊。

重现bug的步骤

1

预期行为

1

导致错误的代码片段

@PostMapping("/notify/{tenantCode}")
    public String wxPayNotify(@PathVariable String tenantCode, @RequestBody String body, HttpServletRequest request){
        BaseContextHandler.setTenant(tenantCode);
        Notification notification = JSONUtil.toBean(body,Notification.class);

        RequestParam requestParam = new RequestParam
                .Builder()
                .serialNumber(request.getHeader("Wechatpay-Serial"))
                .nonce(request.getHeader("Wechatpay-Nonce"))
                .signature(request.getHeader("Wechatpay-Signatur"))
                .signType(request.getHeader("Wechatpay-Signature-Type"))
                .body(body)
                .build();

        // 根据type做出多种结果处理
        return payService.parseOrderNotifyResultV3(requestParam,notification.getResource().getOriginalType());
    }

### 操作系统

macos

### Java 版本

1.8

### wechatpay-java 版本

21

### 其他信息

1

鄙人附议，不过感觉更像是外包做的，JsapiService这种难道就不能抽象吗？服务商支付模块定义一个，商户支付模块也定义一个，然后它们就名字相同，其他没有任何关系，相同的model每个模块里面都定义一个，不能抽象就算了，类名就别定义成一样的啊，其他类似的问题比比皆是，真是服了

[xy-peng]

首先对SDK的不便表示抱歉。我们在很多方面没有做好。也希望开发者多提意见。

基本没有体现什么面向对象的**，所有的request,rep连接口都没有

简单解释一下。wechatpay-java 有一个设计目标是可扩展，所以将 HttpClient/HttpRequest/HttpResponse 抽象出来了。这样的好处，举个例子，我们就能够提供 Apache-HttpClient 扩展，以便于使用 Apache-HttpClient 而不是 OkHttp 的商户系统整合。

而业务 API 对应的 Request/Response 的定义就非常简单：只包含纯业务数据，能被 JSON 库序列化反序列化。我想 @huihui-hb 你说的 request/rep 是它们。它们确实是没有统一定义接口的，可能也不需要。如果在哪些方面给你造成了不便，希望你能说明具体的场景。

其次有些用法非常无语，比如notify的时候，要传requestbody进sdk解密，但是回调类型又写在解密前的字符串里面，很多吧，感觉怎么用怎么别扭，我一下午。

这一点确实是 SDK 的功能缺失。我们的导向是希望商户能使用不同的服务或 endpoint 接受不同的回调通知。但是确实不满足多业务回调以及 webhook 的场景。我想提供一个两步解析的方法，请 @huihui-hb 看看是否满足你的需求。

  NotificationObject object = parser.parse(requestParam);
  if (object.event_type == "TRANSACTION.SUCCESS") {
      Transaction transaction = object.getResource(Transaction.class);
      // do what you want
  }

[xy-peng]

鄙人附议，不过感觉更像是外包做的，JsapiService这种难道就不能抽象吗？服务商支付模块定义一个，商户支付模块也定义一个，然后它们就名字相同，其他没有任何关系，相同的model每个模块里面都定义一个，不能抽象就算了，类名就别定义成一样的啊，其他类似的问题比比皆是，真是服了

SDK 的实现思路，跟我们把 V2 的统一下单拆分成不同的接口，是一脉相承的。不同接口的契约是不一样的。随着业务持续迭代，久而久之，混在一起容易变成“大泥团”。这是我们不希望看到的。

至于类名是一样的。我也感受到有的方面不方便，比如智能补全时无法一眼识别。但是包名是不一样的。你们会把不同支付的代码写在一起吗？ @Linindoo

另外，“比比皆是”能否麻烦你多列几条？我们很希望有更多的反馈意见。

[huihui-hb]

鄙人附议，不过感觉更像是外包做的，JsapiService这种难道就不能抽象吗？服务商支付模块定义一个，商户支付模块也定义一个，然后它们就名字相同，其他没有任何关系，相同的model每个模块里面都定义一个，不能抽象就算了，类名就别定义成一样的啊，其他类似的问题比比皆是，真是服了

SDK 的实现思路，跟我们把 V2 的统一下单拆分成不同的接口，是一脉相承的。不同接口的契约是不一样的。随着业务持续迭代，久而久之，混在一起容易变成“大泥团”。这是我们不希望看到的。

至于类名是一样的。我也感受到有的方面不方便，比如智能补全时无法一眼识别。但是包名是不一样的。你们会把不同支付的代码写在一起吗？ @Linindoo

另外，“比比皆是”能否麻烦你多列几条？我们很希望有更多的反馈意见。

从使用者的角度来讲，你们这个SDK基本没把事情变简单，真写代码的时候让我觉得非常难受。

先把接口定好，jsapiService的参数和返回定好，再去做实现，以后你们更新的时候只要更新实现就行了。你觉得封装接口以后变复杂，我不认为，因为支付这部分主要业务是比较固定的，api上就表达出来了，即使后续增加了分账或者是优惠券活动，都是参数问题而已，我觉得你们这么干，是纯粹的意识形态，是一定要说明你和weixin-java-pay这种包的区别吧。

你现在等于整了一堆POJO让我们自己玩，嗯确实你是把文档都转成model了，另外也封装了鉴权部分，不过我们是写代码的，不是研究sdk的，其实主要是想他省事就好了。

Development Kit ，肯定是要封装的， 如果你改名成wechat-pay-core，我觉得比较合适一些，我也能不会失望到跑到github来表达。

[huihui-hb]

而业务 API 对应的 Request/Response 的定义就非常简单：只包含纯业务数据，能被 JSON 库序列化反序列化。我想 @huihui-hb 你说的 request/rep 是它们。它们确实是没有统一定义接口的，可能也不需要。如果在哪些方面给你造成了不便，希望你能说明具体的场景。

我觉得他们需要定义成统一接口，因为他们的操作基本一致。不过我刚刚才发现你是分了不同的Servic(js h5 app)。也许是我昨天的理解有问题，你们是要把所有的操作都区分开，反正我昨天下午在引入sdk后写代码时，超级无语。

[xiaodaweic]

太难用了，研究半天，我都不知道怎么下手，哭晕在厕所。能否把参数整合一下，每个接口的参数都不一样，前置条件参数说明和接口要的参数对不上号，都被参数整晕车了。

[xy-peng]

太难用了，研究半天，我都不知道怎么下手，哭晕在厕所。能否把参数整合一下，每个接口的参数都不一样，前置条件参数说明和接口要的参数对不上号，都被参数整晕车了。

你是指 前置条件 和 Config 构造时要求的参数对不上吗？

[franciszhang]

xy-peng

如果有多个支付服务商或商户，接收回调数据后，apiV3Key和cert要用怎么区分，serialNumber吗

[xy-peng]

如果有多个支付服务商或商户，接收回调数据后，apiV3Key和cert要用怎么区分，serialNumber吗

我们建议，不同的商户/服务商，使用不同的回调地址区分，再使用证书验签。

[JanYork]

复议，既然是SDK，那就要一切从简，一切都需要围绕传入参数，SDK内方法返回结果，这样的模式为主，既然用到了SDK，那便是要寻求简便，文档含糊不清，SDK混乱，开发时很多不必要麻烦，腾讯云就做的很好，他将整个SDK初始化一个服务对象，将对象丢入IOC，基本上完成所有的事情，只需要调用对应方法，传入对应参数，微信支付的验签解密这些，完全可以融合起来，而非单独的抛出几个对象Verifier，PrivateKey，CloseableHttpClient，虽然使用起来基本上很方便了，但是我更希望官方可以让SDK更加内聚化，更加便捷，使用更方便，另外我希望SDK有一份详细的文档，而不是让开发者在大海捞针，最好可以提供一份与SDK'版本保持对应的已实现需要的功能的Demo，也方便接入拷贝代码。

[JanYork]

这个SDK确实是太差了，整个架构思路混乱，很多地方很不符合实际，比如Amount这个类，total居然是整型，不允许小数，难道人民币已经贬值到不需要角和分了吗？？？

对滴，基本的业务逻辑业务需求都有些不对劲，但是还是比以往要方便很多了。

[FreeJay0223]

这个SDK确实是太差了，整个架构思路混乱，很多地方很不符合实际，比如Amount这个类，total居然是整型，不允许小数，难道人民币已经贬值到不需要角和分了吗？？？

人家total的单位本来就是分

[huihui-hb]

xy-peng

如果有多个支付服务商或商户，接收回调数据后，apiV3Key和cert要用怎么区分，serialNumber吗

你可以在回调路径上加上不同商户的标识，我这里用的比如 /{tenantCode}/notify解决了这个问题