二、功能实现
线下扫码返现工具功能的实现紧张分为三个：二维码的天生、APP页面的参数通报、返现功能的实现。
1. 二维码的天生
二维码的天生，从前端看用户只有两个动作，输入手机号，天生二维码。但是后端却相对繁芜的多，详细流程如下：
录入手机号手机号正则校验，如果校验成功，进入下一步；如果校验失落败，提示用户重新输入精确手机号根据精确的手机号调用干系接口，返回对应的用户账户账户校验，如果接口返回账户，进入下一步；如果接口没有返回账户，提示用户无对应账号新建数据表，将对应的用户账户写进该数据表里（白名单）将用户账号添加到APP的页面链接的URL中（记用户账户的参数为recommenderid）根据页面的链接，天生对应的二维码小结：在前端天生二维码的过程中，后端做了很多用户看不出来的操作，包括数据的校验、接口的调用、数据表的天生、APP干系参数的拼接等。这些操为难刁难于全体项目闭环的实现都很主要，短缺任何一步都会影响全体功能的实现。
2. APP页面参数的通报APP产品首页的URL中带入参数recommenderidAPP产品sku详情页带入参数recommenderid订单填写页带入参数recommanderid订单天生的时候 订单表增加参数recomanderid
小结：APP各级页面参数的通报，是为了在订单天生的时候可以记录到推举人的账户信息，从而在之后的返现环节可以成功的把返现的钱打到推举人的账户上。
3. 返现功能的实现
以上，我们完成了二维码的天生和APP页面参数的通报，接下来就要讲讲全体扫码返现闭环中最主要的返现功能的实现过程了。如下图所示，返现紧张有以下8个步骤，大略的流程示意图如下所示。
1. 每隔N小时轮询N小时内已支付的订单
2. 判断该订单表里的字段recommenderid是否空，如果非空，解释该订单可能源自扫码订单，进行下一步；如果字段recommenderid为空，则解释该订单来源不是扫码订单，返现流程结束。
3. 判断订单号对应的返现关联表里面的返现状态，如果返现关联表里面的返现状态是已返现，解释该订单已经返现，结束返现流程；如果返现关联表里面的返现状态是未返现，则实行下一步。
4. 判断recommenderid是否在白名单里（白名单在二维码天生环节天生，由于APP链接首页二维码的天生是通过URL拼接参数的办法实现，以是有可能别的入口也会带入相同的参数，因此须要用返现白名单做一个二次校验，以确保recommenderid是我们自己创建的）。如果存在，则进行下一步；如果不存在，则结束返现流程。
5. 判断recommenderid是否在黑名单里（黑名单的浸染是删除某些刷单的推举者，此处的刷单是指在扫码的渠道下单的用户，支付成功返现后又取消订单的行为），如果存在，结束返现流程；如果不存在，进入下一步。
6. 根据干系的业务规则，配置返现金额
7. 调用返现接口，传入紧张参数订单号、recommenderid、返现金额等
8. 根据接口返回的结果，修正返现关联表的返现状态。如果返现成功，则变动返现关联表中的返现状态为返现成功；如果返现失落败，则变动返现关联表中的返现状态为返现失落败。
总结
从前端看，一个天生二维码的页面，输入手机号，点击天生二维码，用户扫码下单、支付成功就结束了，但是后端却做了很多事情。
在一个完全的返现流程中，包括二维码的天生、参数的落地、返现功能的实现三个大的步骤。
在全体流程中，做了多次校验和判断和接口的调用。每一个校验、判断、接口调用，都会影响整体返现闭环的功能实现。前端一个小小的功能，都须要后端一个完全的闭环流程的支撑。末了，本文从实战的角度先容了详细的后端项目经历，希望能够和大家一起学习进步。
本文由 @我是范甘迪 原创发布于大家都是产品经理。未经容许，禁止转载
题图来自 Unsplash ，基于 CC0 协议
