玩具级应用的收款方案

在我开发的应用中，对于需要付费授权的功能，我实践了以下本地OCR校验支付凭证的付费授权方案，一定程度上实现了自动收款，现分享出来供大家参考。

本地OCR校验微信支付凭证的纯前端应用收款方案

1. 系统显示微信收款码图片，用户使用微信扫码付款。
2. 用户扫码支付后上传微信支付凭证截图。
3. 系统使用完全本地运行的 OCR 识别支付截图。核验收款人，支付金额、付款时间、支付单号的完整性和合法性。
4. 核验成功后，系统根据支付金额，按相应金额的授权方案激活授权。
5. 如果核对失败，则回退到手动方式：用户添加作者微信，发送支付凭证，作者确认后生成授权码发送给用户。此时需弹出添加微信的提示。文案：支付凭证核验未通过，请确认重新上传，或添加作者微信，提供支付凭证，获取授权码
   • 如果 OCR 加载成功，但匹配失败，则核验失败原因写成英文编码，避免被人轻易识破而进行伪造。
6. 整个过程都要假设用户会产生疑虑，或遇到问题，所以界面上需要有 Popover，引导用户加作者微信获取激活码授权。

主要限制和风险点

1. OCR 的加载、识别不稳定。这意味着终究需要人工通道来兜底，作者需要投入少量个人时间处理人工审核。这在我是可以接受的，毕竟本身就有用户需要咨询使用问题，我也需要了解用户反馈。
2. OCR 模型文件较大，受限于带宽，加载时间较长，可能体验较差。缓解方式是：加载模型时提示：系统核验中，首次预计需2~3分钟，请耐心等待，请不要关闭页面
3. 需要引导用户找到正确的支付凭证页面。许多用户不知道什么是微信支付凭证，只知道发送付款后的截图。这需要提供示例截图，明确告诉用户：需要截取哪一个页面，减少无效截图上传。 1 支付凭证可能被滥用。一张有效的支付凭证，实际上可以被传播使用，遍地开花。应对方法主要是对授权时间做限制。授权方案最长为付款成功后的 24 小时，这样可避免授权码被大面积传播。当然也可要求用户支付时填入设备标识码，核验时同时核验设备标识码，但支付凭证里的设备标识码同样也可造假，并会引入更多复杂度。根本上，对授权时长进行限制，是最值得做的。
4. 支付凭证可伪造。不对接微信支付，理论上就是没办法真正对支付凭证进行校验的，因为客户端获取不到真实的交易信息。这就意味着用户上传的支付凭证是完全可伪造的。但实际情况是，大部分用户远远没有那么聪明（很多用户非常欠缺阅读文字和解决问题的能力，使用应用过程中的任何一步都可能会把他卡死，更不用说设法绕过收费系统了），至少新用户大概率是会需要实际支付的，况且本身就是玩具级的应用，如果付款流程的漏洞成为了一个值得担心的问题，那说明生意真正做大了，那就不是这个阶段考虑的问题了。因故此问题不用纠结。

方案总结

这是一套适合个人独立开发者、小体量工具应用、零开发后端支付对接能力下的低成本付费授权方案，完全绕开微信支付商户开户、后端服务，依靠前端 OCR + 人工兜底快速跑通付费闭环。本方案优点是零接入成本、快速上线，但是存在一定的业务安全风险和合规风险，适合小流量下使用，但不适合规模化商用。