统计
  • 文章总数:2351 篇
  • 评论总数:2546 条
  • 分类总数:18 个
  • 最后更新:6天前

腾讯微信支付就是一坨精粹

本文阅读需要 4 分钟
首页 观点 正文

最近项目老大让我做微信支付,于是我被迫去学习相关接口。在此吐槽一下食粹感受——本文纯粹情绪输出,如果引起舒适,请忍着。
1. 变量命名非常涨智,符合直觉
项目老大注册腾讯商户后,顺手给我一个叫 appid 的字符串

我看见 appid 第一反应是 APP 的 ID,但它不是!!!它是商户/公司的 ID!就是如此思路清奇

第二步接着看文档,说下单时需要我传输一个 openid 的字符串

我找项目老大要 openid ,对方说他没有。两人大眼瞪小眼,最后上网一查,原来openid 是用户 ID!没错,openid 是用户 ID

正常人的思路不是应该叫做 uid 或者 userid 吗???这是什么天才大脑???

2. 文档极其有序,且自相融洽
预支付时需要签名,具体来说把一大串参数进行签名算法得到一个签名字符串再插入一大串参数里

腾讯开发者文档说需要两次签名,第一次签名后需要把参数以 xml 或者 json 格式发给微信平台接口

我吭哧吭哧写完 json 格式的代码,然后接着看文档讲解第二次签名

文档接着说,第二次签名只能以 xml 格式,且第一次签名和第二次签名的格式必须一样,否则就验证不通过???

合着第一次签名支持 json 是耍我???这是什么强智文档???

3. 容错能力为无穷大,很支持调试
当你排除千难万险,把前端和后端的支付流程都写好了,你想调试?对不起 不支持

m1cxl1lp.png
是的,没错。快快开动你的小脑袋,进行脑内推演,想象力编译,直觉调试。一次写好前端和后端然后部署到服务器,此时才能知道代码逻辑成功不成功。

腾讯就这一坨精粹也好意思发布?趁早回去干老本行吧(指原创)

4. 精准报错,引导人
精准报错,当传给微信支付一大串参数,无论缺哪一个参数,返回的报错都是“缺失参数total_fee”

What the fox?why?

这个太多人夸了,不差我一个了,就不夸了

https://zhuanlan.zhihu.com/p/405837290

5. 可以形容的强智校验
当我终于完成以上所有步骤时,惊喜得发现:

签名失败!

是的,还是失败了。于是我冥思苦想,翻箱倒柜,搜肠刮肚检查所有错误,确认无误,我自己的代码确实没有任何问题。

终于在热心网友的帮助下,我才知道这个真善美的签名矫正规则:第一次传递参数的 appid 的字母 i 是小写字母,然后签名时的参数 appId 的字母 I 是大写字母

m1cxlxs0.png
我 $&%#@*+~

总结

腾讯,尤其是腾讯的技术部门,是如此的强智,如此的聪明,整个公司从上到下的技术就是一坨贯穿腾讯发展史的纯粹——

一句话总结:不仅道德没问题,而且智力没问题。


UP主创作不易,点个赞评论支持一下吧~

本文来自投稿,不代表本站立场,如若转载,请注明出处:

发表评论

V注册会员 L评论等级
R1 条回复
  1. xin语 :
    2024-09-22     Win 10 /    Chrome

    其他确实,就 OpenID 这个。。。显露了你开发经验的不足。。

    OpenID, 不是 UID.

    OpenID 是 OAuth 协议中的名词。微信授权登录协议大体上是走 OAuth2 的,这个 OpenID 虽然说可以理解为 UID,但是实际上与我们平常认知里的 UID 并不是同一个东西,亦无法反推。OpenID 在授权方也许有自己的 Mapping,对应着真实的 UID 但是只要你没有攻破对方服务器,你就永远无从得知这个对应关系。。所以 OpenID 可以做到隐藏用户真实信息的功能。。

    appid是沿用了公众号和小程序的id,openid则是鹅厂开放给你的用户id,实际上鹅厂内部的用户id可能是个closeid。互联网公司的特点就是先跑起来再说,但是用户一旦涨上去再推翻重做又不可能,于是就沉淀了一堆辣鸡设计,就像著名的js和win api一样。倒是果子就是有底气推倒重来,落后的版本就是不让用,必须让开发者来适配它。

    我和腾讯的人在很多业务上对接过。很显然,他们没有道德,所以不存在道德问题。至于智力,略低于阿甘。

没有更多评论了
    请配置好页面缩略名选项

热门文章