How to implement virtual currency on the site?

Question

Web development

Good afternoon! The essence of the question is as follows: there is a site on which it is necessary to implement virtual currency programmatically, that is, when registering, the user receives a certain number of "points", which he can later buy using payment systems, the Payeer level, and so on.
Where do you need to start and how to correctly write algorithms without errors to create this function?
Code examples are not needed, the main thing for me is to understand the whole essence of the algorithm and how to do it correctly.
Website backend - php.
Thanks a lot!

Answer 1

it can be primitive - the user has a " wallet " where the amount of money changes depending on the operation
can be normal - by analogy with accounting " each operation changes 2 accounts, for example , receipt is written + to wallet + to received purchase - to wallet and + to purchases total balance = 0 wallet + purchases = received or wallet + purchases + withdrawn + blocked = received + affiliate program

Answer 2

You add the "purse" entity, which will contain the final value of the amount (0 by default);
You add the "operation" entity, which will reflect the receipt and expenditure of bonus points;
With any movement of points, you change the amount in the wallet.
To track movements, it makes sense to create a separate table.
id, user_id, sum, type, status, comments, source, date_create, date_confirm where:
Actually, when registering a user, you make a movement with the receipt of bonuses;
Then you change the data for the wallet;
Then you write any movement to the table and change the state of the wallet.
In the simplest case, you can do it right through one class, but this is not very comme il faut.

Answer 3

How to organize the balance of funds in your account?

Answer 4

I strongly recommend that ALL wallet operations that should be indivisible (atomic) be implemented as third-party methods and work only with them, the simplest example is stored procedures in a database.
In this case, in principle, you will not have glitches with the final balance (which should ideally be zero, and third-party receipts should be made through special accounts with a negative deposit, or introduce the concept of a loan, i.e. two balances - the deposit balance and the amount credit and both numbers are only positive).
Log everything! ideally, the log should be machine-readable, allowing you to play the history of operations on a snapshot, incl. from the very beginning of the life of the base, it will save you a lot of nerves when you debug the algorithm or solve problems that have arisen due to hardware problems.