今天的一段励志对白：
：1000元流水咱俩分9毛8，是这么回事吧？
：是。
：朱哥，咱要一分一分赚钱。
Archives for : 在路上
走分账的一个必要前提是降低商户的微信手续费率。只有降低费率，才好意思向商家分账。
2021-7-6 更新：
成功从 0.6% 降低到 0.2%
添加了第一个特约商户，但是发现服务商“行业合作”开放的行业太少，没有合适的选择。
之后又发现服务商“点金计划”只能在 h5 实现，不支持小程序场景。
两条路都不通，只能另辟他径，比如走分账。
折腾三天，终于搞定 component_verify_ticket，捉急。
没想到写小程序还有机会写 php，主要是两方面：
两天写下来，调用云函数走通了，快速注册还要研究下。
顺便学了点 php，比较蛋疼的是：js 不用写分号，php 要写分号。
一不小心就 500，查半天发现没写分号。
1
连续看了三天文档资料，主要是第三方平台、服务商平台、 微信支付服务商，顺便把云开发文档又重新详细看了一遍，有不少更新。
之前对分账概念不是很理解，所以把服务商分账也看了一下，这个和服务商技术服务费是两个概念。
2
服务商的技术服务费有点不太好理解，反复看了又看，社区里查了很久，理清了。
有两种技术服务费：基础服务技术服务费、行业服务技术服务费。
基础服务技术服务费，只能是线下交易场景的订单才会被计算进去，包括：
- 刷卡支付
- 公众号支付场景，扫一扫渠道来源
- 小程序支付场景，扫一扫渠道来源
- 扫码支付
- 人脸支付
行业服务技术服务费，包括全量交易但不包括 APP 支付及 H5 支付。需要在服务商后台的“行业合作报名”申请。
3
普通商户号不能绑定成为服务商的特约商户号，需要在服务商后台重新申请子商户号（即特约商户）。同一个主体可以申请无数个商户号。
昨天土豆发给我几条群聊记录，原来是车友群忽然有人问我为啥退群了。
于是我托土豆带了个话回去：
专心创业，事成之日再回去发个大红包。
事实上，除了车友群比较分心，炒股也比较分心。
最近渐渐想明白，就算真的从股市中赚到了钱，那也仅仅只是积累了财富。单纯积累财富真的有很大意义吗？为什么不把时间花在既能让自己赚钱又能帮助别人赚钱的事情上呢？
不过罗杰建议我删除 App 就行了，好股票可以留着做时间的朋友。
看了下，手里剩的就三个，航发动力、通威股份、海尔智家。
我信了罗杰，删光四个炒股 App，富途、同花顺、华盛通、选股宝，取关了所有相关的公众号，待我提到创业的第一桶金，再回来看看，对比下哪边赚的比例高。
我是去年 6 月开户的，正好一年，正式入市是 11 月，算起来也认真玩了 7 个月，做了些笔记，还真学到一些东西。
谨此纪念。
全网发布通过审核。
1
第一次遇到的坑，是客户支付时，正好进来个电话，支付成功了，但是我们这边没有收到返回信息，因为当时网断了。
解决方案：使用云函数异步接收订单结果。
2
不料又遇到一个坑，突然出现两笔一模一样的订单号。两笔都标记成功了，但其实只有一笔支付成功。
头一次出现这情况，没有复现。
解决方案：把防止二次提交优化一下，做得更加严谨，并且支付的异步回调函数获取订单改成倒序，按订单号查询最新的一条，做二次防范。
3
以为这样应该没问题了，哪曾想，又出问题了，有一笔订单没支付成功，但是被标记成功了。原因是 wx.requestPayment 这个接口的 success 只是通信成功，而不是支付成功（文档害人，注释上写支付成功）。
最终解决方案总结：
- 小程序端发起支付，创建一个未支付订单；
- 通信成功后跳转到支付结果页，这一步前端不做 status 的修改，而是让回调的云函数根据支付结果去修改订单 status；
- 跳转到支付结果页先检查订单 status，如果是未支付状态，则请求 CloudPay.queryOrder 接口，查询支付结果，修改订单 status。
这样就把修改订单 status 的操作统一交给后端，前端只负责展示。这个流程也符合文档里给出的最佳实践。
这个问题主要是体现在微信结算技术服务费的时候，需要开 6 个点的增值税发票，小规模公司只能开 1 个点的发票。
我们讨论下来是这样：先注册小规模，后续达到了申请技术服务费的标准，先用 1 个点的发票尝试，如果申请不成功，再升级成一般纳税人去申请服务费。
这样比较节约前期的记账成本，一般纳税人的记账费比小规模高一倍，但其实前期没必要注册一般纳税人，因为没收入或者收入很少。从小规模升级成一般纳税人只要几天时间，当月生效。
