微信支付的使用场景总结

关于微信支付的库和文章很多,但似乎都没有很好地说清楚各个接口的使用场景。这里结合之前的经验对微信支付文档做个补充。微信的文档在这里:https://pay.weixin.qq.com/wiki/doc/api/index.html

MICRO – 付款码支付

所谓的通过扫码设备扫描用户出示的付款码,类似POS的操作,只是POS机换成了扫码设备,银行卡磁条换成二维码。扫码设备在x宝就有的卖,100左右(可能更便宜),其实就是一个输入设备,付款码就是一段字符串。这个扫码设备只是做一个二维码到字符串的转换而已,所以可以支持微信、支付宝、银联或者你自己开发的支付码。

使用这个方案需要注意,有时候用户不是扫码后马上同步完成的,而是需要输入密码或者余额不足换卡(微信和支付宝都有可能产生这种情况),或者最终取消交易的。所以在扫码页面最好进行后台的轮询检查支付结果。

JSAPI – 公众号支付

其实更准确地说,是微信浏览器内支付(有别于H5支付是在用户移动设备上的浏览器)。在微信里,体验是最好。但是通常需要根据用户浏览器UA进行切换,如果是微信浏览器就用JSAPI,如果是在不在微信里,但是在手机浏览器里,就切到MWEB。

MWEB – H5支付

主要是用户在手机浏览器里支付,此时会打开用户手机里微信进行支付。

如果用户没有安装微信呢?

NATIVE – 扫码支付

商户端生成订单,然后生成对应的付款二维码,来让用户进行扫码支付。和MICRO是最常用的线下支付场景,和MICRO相比稍微麻烦一些,因为需要输入密码。但是好处是可以获得用户的授权,然后获取用户的openid或者unionid,而MICRO是不能拿到这个信息的。如果你需要根据openid追踪到系统内的用户时,这算是NATIVE的一个好处。

APP – APP支付

流程上其实和JSAPI很类似,都是获得预支付ID(prepayID)然后在APP内完成。在服务端接收付款通知,最好在APP里再进行一下确认。

WEAPP – 小程序支付

和JSAPI一样,只是支付参数(package)放的地方不同,一个是网页,一个是小程序内。

关于犯错

我们当下的教育环境,对犯错的态度和处理方式过于简单粗暴了。比如,教师们强调“书写规范”、“卷面整洁”……,稍微违犯,轻者从头来过,重者罚抄百遍。

究其原因,是我们整体社会环境对“犯错”的态度,经常所提的“学霸”其实等于“少犯错,甚至不犯错”,并用来应对各种各样的考试。如果我们的学习衡量标准只是单一的“应试”也没什么不妥。但殊不知,学习的过程远非学校中那么单一,并且每个人的学习敏感度敏感期都不尽相同,过分的“整齐划一”实际上可能扼杀了天才。比如英语的学习,有的人用眼睛看,有的人是用耳朵听,有的人是用嘴读,各有侧重点。以我的英语学习经历来看,我更倾向于“读、听”敏感,对于单词记忆来说读读就能记忆,让我写简直是浪费时间。但有的人就是“看、写”模式。 — 当然真的要学好英语还有很多其他的要素。

脱离了学校的单一学习环境后,很多“学霸”都不见得能很快适应,所以我们看到,举办各种各样的考试来去“适应”这些“学霸”,其实严格地来说这些“学霸”只是“考霸”。

真正的“学霸”是:了解自身的学习模式并利用之进行高效学习的人。而更厉害的“学霸”,会从别人的学习模式中“提取”自己可以运用的东西来学习、借鉴、总结并内化到自身的学习模式中。而老师,则应该不仅可以借鉴模式,而且能够总结出各种学习模式和适应范围并能够给学生知道的人。这才是真正的师傅、老师。

所谓老师,如果不从学生的”犯错“中去发现:为什么犯?什么错?那么就不能称为一个合格的”师者“,最多只是从事一份教师的职业而已。

但当下这样的”师者“,寥寥无几。有些人可能会说当下的体制、教师的考核方式等等,是的,有缺陷,但,你其实是有选择的,而且大多数时候,你已经做出了选择。

顺带提一下所谓”挫折教育“,这真是国人的另一个”天才产物“ — 用不犯错的方式来让孩子学习犯错。

过度的基础建设其实是向穷人征税

路是越修越多越修越好,但是貌似对老百姓来说还要花相对更多的时间。有的人会说,这不对,以前我用2小时才能到的地方,现在只需要半小时了。是的,绝对时间是短了。

但我说的是“相对更多的时间”,公共交通比起有车的人,时间差距显然是更大了。

你会说,公共交通便宜很多啊,但这个逻辑里隐含了:穷人的时间不值钱。

可是,穷人的时间效用更大。金钱的边际效用递减的,而穷人的钱可能边际效用可能还在上升的阶段。这个概念其实可以定义穷人,但效用很难量化,不太好用数据说话。但不影响产生结论。

从这里来看,其实时间还是很好的衡量物,对所有理性人来说都是一样的。

所以只要是制造了时间上的不平等,就是不公平对待。

但是,中国的事情是,表面上似乎人很重要,因为地铁站、机场里安检人员数量已经世界第一了,但考虑到其“不必要”性,其实还是“人不重要”。

貌似quora也被赶出中国大陆了

网站被封有一段时间了,最近appstore也下架了

解决微信小程序sdk在升级到php7.1后的一个问题

升级php7.1以后,来自微信官方的小程序解密代码会提示:

mcrypt_module_close deprecated

意思就是php7.1-mcrypt已经即将废弃了,不推荐使用了。

解决的办法:

1. 使用替代库:composer require phpseclib/mcrypt_compat

2. 同时删除原来的php7.1-mcrypt:apt remove php7.1-mcrypt,不删除会继续报错。

失信的成本是所有人来承担的

最近发生了一件事,总结了一下之前的一些经历。记录一下,算是对微型独立软件供应商(Micro ISV)的一个“生存”参考。

事情始末大概是这样:通过朋友介绍了一个小项目,其实就是2-3天的项目,都算不上是项目,纯粹出于帮忙的动机。毕竟鄂尔多斯地区找一个软件开发供应商比较难,之前的版本是一个河南的小伙做的,花了1万多,外加往返机票。我也就很实在的报了个价 – 6000块,因为最多也就是3天的工作量(其中还有50%的buffer)。如果不了解行情的人,可能还觉得我有点黑,没办法,这是市场决定的,不是我决定的。

我也是比较“傲娇”地要求事前一次性付清,然后开工。结果呢?这位项目负责人担心我搞不定,想要做完再付款。我和他说如果担心保障可以对公签合同,不过收费就是1万2(因为还有其他开销),可能是由于我一开始就给报了一个比较低的价格,这个时候这位项目负责人已经不能接受这个offer了。然后就是反复的电话沟通。然后当然是谈崩了(也可能是我的谈判技巧不佳)。

现在想想,如果我一开始报价1万5,然后打个八折1万2,然后先付6k,完工验收后再付6k。也许他还能接受。

但是,想法还是太naive了。如果人不爽快,后面要钱的那种感觉我可不愿意,毕竟我是个“审慎的”享乐主义者 – 绝对从一开始就避免这种尴尬和不爽。

然而,在目前鄂尔多斯地区(或者是类似的3、4线城市)这种困境确实是存在的 — 由于一些众所周知的原因,所有人的信用度都打了折,结果就是,所有人都要负担这份“成本”。

复杂度其实是降维

突发奇想(可能也没啥新奇的,也许就是无知而已)

其实代码中控制复杂度的过程就是降维,或者说把一个复杂的结构用多项式来标识,每个项就是一个类(对象),然后把他们加起来。

如果做不到这一点,那么代码的复杂度将不可控,整个系统也就越来越不可控,最终烂掉。

貌似,代码也有它的生命周期,很少有代码能够“活到”足够长的时间,而变得不可控。

想象,一个函数,里面是一大堆的ifelse语句,每个if就是一个分支,每个分支就是一个乘法,每多一个乘法就是一个新的维度。所以我们常常将函数拆分成若干个对象的组合(通常是加法)。

最可悲的事情是什么?

不是和笨蛋做事情,而是不得不为笨蛋做事。

事实是,我也是那个笨蛋。

如果笨蛋无可避免,那么要怎么和笨蛋相处?

大多数类似问题,其实都没有答案。答案在于“选择”。

如果没得选择,那么也就没有必要探讨答案,除了制造焦虑,没有益处。

不能忽视懒B的勤奋程度

在微信提供的PHPSDK开发代码里发现有一段代码,为了转换字符串,而把对象放到数组里再拿出来。

怎么能想出来的~ 用常规的方法不好吗?

能琢磨出这种办法的人,微信应该fire掉吧。话说回来,看来是完全没有code review啊。

有感。

给数据穿上裤子

最近华住又被拖库了,5亿的个人数据就这么泄漏了。感觉好卑微,原来每个人不过是一条数据。

怎么解决这个问题呢?

被“拖库”泄漏数据的原因是:敏感信息在数据库中明文存储。那么很自然的想法是:给数据“穿上裤子”,也就是进行加密。

比如:

电话号码:18633334444 变成 186aaaabbbb ,这里示范的是最简单的字符替换,这种算法也叫凯撒密码。

通过在加密中添加salt来避免太容易的解码,但貌似无济于事。

普通的凯撒加密可以容易地推算出来,即便是更加复杂的加密方式,人家已经获取到数据了,大不了费点事而已,毕竟是对称加密的。

话说回来,如果代码都已经被拖走了,貌似也没什么救了。

但是,对敏感数据进行部分加密还是有意义的,比如,不会容易被“撞库”。

另外,对于数据的提取,毕竟有时候会需要用户的联系方式进行短信营销,以前的做法(也说明了我们对用户的隐私是多么无视)是:直接从数据库里把数据导出来,然后交给短信发送供应商或者程序员通过短信发送接口进行批量发送。这么人的操作很难避免数据不外露,尤其是不靠谱的短信供应商。

所以,从运营的角度来说,也要通过流程来避免人为的数据泄漏。可以通过开发专用的“数据提取”功能来根据权限来获取敏感数据,同时记录下获取历史记录。就算追查追究法律责任时也是有据可查,光是这个“可追溯”也可以很大情况下避免人为泄漏。

顺道发现了一个很不错的关于数据加密的网站:https://www.dcode.fr/