feat: balance top-up

[pplulee]

Allow users to top up the balance. #2392

A new type topup is added to Order Model. The type will be checked and passed to the invoice when processing the order. processProductOrder and processTopupOrder are used in OrderController to deal with different types of orders.

Because the invoice has no type field so it is stored in the content. It is troublesome to judge the invoice type based on the content, which causes the issue that users can top up with balance. This needs to be checked.

As the same as product packs, the top-up order will be activated in Cron; however, it is strange that users must wait for the top-up to be activated. It would be better if top-up orders could be activated in real time.

The entire process works fine after simple testing.

Known issues:

• [x] Users can top-up by balance
• [x] Add type to invoice? Not sure if it is required.
• [x] Real-time activation

[pplulee]

Implement combined payments by updating invoice prices. The invoice with top-up items only cannot paid by the balance.

It would be better if the bill could record how much money was paid using the balance.

In addition, I optimized the scheduled task process, checking expired orders first and then activating new orders to achieve simultaneous expiration and reactivation. Activation in the different cycles may cause service interruption.

[AutisticShark]

For the invoice type tho, your solution will cause performance issues when it comes to batch-processing invoices in the future, I will add an additional column to the invoice table to indicate the type of invoice, and an index to improve query performance. Here is an example.

`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '账单ID',
`type` varchar(255) NOT NULL DEFAULT 'product' COMMENT '类型',
`user_id` bigint(20) unsigned DEFAULT 0 COMMENT '归属用户ID',
...
KEY `id` (`id`),
KEY `type` (`type`),
KEY `user_id` (`user_id`),

[AutisticShark]

Just to let you know that 2024.1 will be released soon, this PR might not be included in that due to the changes made to the fundamentals of the billing system, ping me when this PR is ready for merge, and I will do the code review ASAP.

[pplulee]

I've updated to use invoice type as an identifier. The programme will activate the order when the payment is completed. @M1Screw

However, when testing the combined payment, I found that payments made with the balance do not calculate the reward.

These features need to be tested further, so there is no rush to update them.

[AutisticShark]

I found that payments made with the balance do not calculate the reward

That's by design, only the amount paid via the payment gateway will be used to calculate the payback total(invite reward).

[pplulee]

I found that payments made with the balance do not calculate the reward

That's by design, only the amount paid via the payment gateway will be used to calculate the payback total(invite reward).

Okay, that sounds fine.

[AutisticShark]

Your PR actually missing some important logic, for example, invoice content is not updated after a partial payment, an order that has a partially paid invoice shouldn't be able to be canceled by admin, and there should be different redirect behavior when the user is partially paid the invoice with balance and fully paid with balance. But don't worry, I will push a patch to fix those issues.

de50dc76dbfd0c8bc0600df5d64014e9d42a1b40 this commit, however, needs to be reverted and put in a separate PR. I understand that paying for a top-up invoice and the balance is not updated immediately would be very confusing for the end user, however, putting order activation logic inside the payment gateway abstract class is also a really bad idea.

I can see many design flaws in the current order activation process, however, to change that we will need a systematic approach and make sure everything is properly refactored instead of doing band-aid work everywhere.