今天做了最后的测试,顺便发现一些细节上的问题。在此整理和记录一下。
总的架构:微信官方合作服务商小微商户接入,后端通过Bmob管理数据,阿里云计算函数提供对外接口。

后端工作流程:

流程图

调用时,阿里云计算函数调用相关资源后,统一返回JSON格式:

{
   "status": 3,       // 状态码,0为成功,其它为失败
   "msg": "正在维护",  // 失败时才有的提示
   "qrcode_url": "https://xxxx.png",  // 成功时返回所需的信息
} 
系统原理:
  • 四个参数(order_id, money, title, about)经过验证才能得到二维码图片地址
  • 同一商户订单号,支付成功前可多次请求,每次都创建新平台订单号,返回新的二维码
  • 同一商户订单号,如支付成功则会返回已支付
  • 支付成功后,才会发送异步通知,即出现在后端数据库里
  • 退款后更改后端数据库里相应商户订单那一条,statue为3即可
  • 商户订单号是universal唯一的,后端数据库里存在商户订单号&&statu为1,证明支付有效。
申请时的about参数:

用户唯一ID&类型代码(应用唯一编码或捐赠编码)&money数额

例:122121212&DON&1000
代表:id为122121212的用户,捐赠,10元
后端接口会检查最后的数额和money是否一致,不一致的话返回错误
之后会加一条&190611这个当天的日期
到时候查询时按照格式即可确认是否成功付款过

例:122121212&DRT&1
代表:id为122121212的用户,DRT滴雨项目,一个月会员
后端接口会检查最后的月数和对应money是否一致,不一致的话返回错误
之后会加一条&190611这个当天的日期
最终进入数据库的就是:用户&项目&月数&开始日期
然后会在一个新表中,以用户id为唯一键,更新这条数据的相应字段

总结

之所以如此麻烦,是因为要考虑一个假设:通过抓包、中间人欺骗等,客户端所有访问都可能是公开的,无论是接口还是参数。当用户数量上升到一定程度时,非法尝试的可能就成了必然,因此必须保证逻辑上没有漏洞。比如要远程验证订单的金额和实际支付是否一致,而不是相信用户提交的表单。以前某些微信小程序就犯这种错误,导致我不时在朋友圈看到某人吃一分钱的外卖……

后端数据库主要是两个表,一个以订单号为唯一键,记录和更新所有支付成功的订单;另一个以用户ID为唯一键,记录和更新所有的账户信息。查询支付状态,盯账单时走前一个,各种应用来查询账号是否在会员状态时走后一个。两个表同步更新。

到这里基本可以上线使用了。安全、稳定、统一。也是以后所有收费的基础。虽然麻烦,但是从头搭建的好处就是,确保可控,确保合适。测试完毕之后,下一步就是去打造产品了。