I have never heard of shopNC, but I can give you some ideas on cashback.

Cashback: After the user completes the order, a certain amount of cash will be returned.
Cashback can be one-level cashback or multi-level cashback;

First level rebate:
That is, only one level is returned; the price of a product is 100 yuan, and the cashback ratio is 10%; at this time, user A recommends B to purchase this product; the process is:

B Place an order---> B Pay 100 yuan---> B Receive the goods---> Complete the order---> Enter the cashback function (100 * 10% = 10). At this time, It doesn't matter whether the 10 yuan is given to B or A. But only to one person, that is: either to B or to A;

Second level rebate:
Same purchasing process. After B completes the order, part of the 10 yuan will be returned to B and part to A. As for how much A and B are returned, there must be a ratio. For example: 7:3, then B gets 7 yuan and A gets 3 yuan;

Multi-level rebate:
Same as the second-level rebate. However, there is generally a fixed number of layers, such as: below 3 layers. If there are multiple layers, be careful to make the product a pyramid scheme;

With the above ideas, the program is relatively simple to implement. The cashback function can be triggered after the user completes the payment or when the user completes the order. It is recommended to trigger after completing the order.
Because the user has just finished paying and may cancel the order and other actions.

Represented in pseudo code:

function back($orderid)
{
    $order = 数据库查到此订单信息

    // 根据 $order 中的订单总金额、返现比例 算出 返现金额
    $back_money = ....

    // 根据系统定的规则算出这些钱给谁
    if( 一级返回，并给 B )
        更新 数据库里 B 的账号余额

     elseif 多级返
        调用多级返的函数
}

function more_back($money, $orderid, $userid)
{
    // 先把多层返回的比例取出，并算出最底层用户的返现
    $user_money = ....

    // 更新用户账号里的余额

    // 算出当前用户的上层用户，然后回调一次即可
    more_back()
}

....After the order is completed, call the back function

The above is pseudo code. In actual practice, it must be carefully controlled to prevent calculation errors, especially when there are multiple layers of cashback;

I have never done it, I can only explain it based on this
Rebate is a marketing tool, so formulate a corresponding SKU product marketing strategy. Of course, this strategy is formulated by the merchant, and formulating the strategy requires a lot of strict logic to limit it. For example, limit the rebate amount ratio to prevent order fraud. Since it is a commission rebate, the rebate person information parameters must be included in the product details page URL and the product parameters submitted to the shopping cart. When the order is generated, the product information and rebate information will be submitted Go to the backend. At that time, you need to verify the product and whether there is a rebate for the product. After the verification is completed, the relevant rebate information will be saved into the database (this data table field must be the product id, the current price of the product, the rebate recipient information, the rebate amount, and the marketing Strategy id, status). The user's refund action will occur from the order generation to the final status of the order, so the rebate behavior must be established when the order is completed and the transaction is successful (the rebate status is converted to success)
Rebate for the rebate person The amount is settled every month (through scheduled tasks, the rebate information is placed in the queue for slow calculation), and all calculation data is fed back to the merchant for the rebate person to view.
At the beginning of the settlement day, the rebate person obtains the merchant Transfer the funds (this may require a very detailed process, such as whether the funds are transferred directly to the merchant's account, or the user has put the rebate money into a temporary account during checkout)