How the Balance Top-up Request System Works

The Invoice plugin turns balance top-up into a managed, controlled and verifiable process. It creates an intermediate layer between the user and the actual crediting of funds, where requests, payment methods, confirmations and administrative decisions are recorded.

The system operates in two parallel planes:

• the user creates and tracks requests;
• the administrator manages requests and payment details, confirms payments and credits the balance.

Both sides are connected by one entity — top-up request (invoice).

1. How it works from the user side

1.1. Where the request comes from

The user cannot create a request on their own.
It always originates from a payment intention in the Payments module.

The process looks like this:

1. The user initiates balance top-up through the Payments module.
2. A payment is created in the system with status new or process.
3. Instead of an automatic payment gateway, the user is redirected to the Invoice interface.
4. Invoice receives this payment and uses it as the basis for the request.

Thus, each request is tightly linked to a payment and knows:

• who it belongs to;
• what amount it was created for;
• which payment intention it is associated with.

The request amount is recalculated using an internal exchange rate coefficient, to convert the payment to the site’s currency.

1.2. Choosing a top-up method

After that, the user is taken to the payment method selection page.

They see only the methods that the administrator has enabled in the admin panel.
Each method contains:

• name;
• currency;
• wallet or payment address;
• network (if applicable);
• link to the service;
• text instructions.

The user:

1. selects one method;
2. optionally leaves a comment;
3. submits the form.

At this moment the system:

• creates a new request;
• assigns it a unique number;
• links it to the payment;
• changes the payment status to process.

1.3. What happens after creation

Immediately after creating the request:

• the administrator receives a notification;
• the user receives an email with a personal link to their request.

This link contains a security hash, calculated from the request number and user ID.
This ensures that only the owner can open the request.

1.4. Request page

Via their link, the user sees all payment details and the request status:

• number;
• amount;
• selected method;
• currency;
• wallet or address;
• network;
• instructions;
• comment;
• current status.

The actual payment happens outside the site — the user transfers money using the provided details.
After that, they return and click the button:

“I have already paid”

This changes the request status to claimed — the user officially declares that the payment has been sent.

The administrator receives a notification about this and, if the claim is correct, credits the funds to the user’s balance with one simple button click.

1.5. User’s list of requests

The user can always open the list of all their requests and see:

• numbers;
• amounts;
• selected methods;
• creation and confirmation dates;
• current statuses.

This is their log of all attempts and successful top-ups.

2. How it works from the administrator side

The administrator manages the entire system through a special Invoice panel.

2.1. List of all requests

On the main admin page, all requests are displayed with information:

• user;
• number;
• amount;
• top-up method;
• currency;
• status;
• link to the user’s request page.

For each request, the following actions are available:

• confirm payment;
• edit;
• delete.

2.2. When the user clicked “I have already paid”

When the user marks the request as paid, its status becomes claimed.

This means:

The user claims that the money has been sent, but the balance has not yet been credited.

This is the key point where the administrator makes the decision.

2.3. Payment confirmation by administrator

When the administrator clicks “Confirm”, the crediting chain starts.

The system works as follows:

Step 1.
Checks if the request has an associated payment.

Step 2.
If the request came from the user — the payment already exists.
If the request was created manually by the administrator — there is no payment yet, and one is created automatically.

Step 3.
The corresponding payment is set to status paid.

It is this step that triggers the business logic of the Payments module and actually credits the money to the user’s balance.

Step 4.
The request is marked as paid, and the payment date is recorded.

Step 5.
The user receives an email stating that their request has been confirmed and the balance has been topped up.

2.4. Manual requests from the administrator

The administrator can create requests manually, without user involvement.

They:

• select the user;
• specify the amount;
• add a comment.

Such a request initially has no payment.
But upon confirmation, the system automatically creates a payment, sets it to paid status, and credits the balance.

From an accounting perspective, this is completely equivalent to a regular user top-up.

2.5. Editing and deleting requests

While the request is not paid, the administrator can:

• change the amount;
• change the comment.

They can also completely delete the request if it is erroneous or irrelevant.

3. Managing top-up methods

A separate tab in the admin panel is dedicated to payment methods.

The administrator can:

• create new methods;
• set currency, wallet, network and instructions;
• enable and disable methods;
• manage display order.

Only enabled methods are visible to users when creating a request.

Thus, the administrator fully controls where and how users send money.

4. General philosophy of the plugin

Invoice is not a payment gateway.
It is a system of accounting, confirmation and control.

It guarantees that:

• the user will not receive balance without a formalized request;
• the administrator will not credit funds without a recorded document;
• every step is confirmed by statuses and emails;
• every payment is always linked to a specific request.

As a result:

• the user has a transparent, clear and trackable process;
• the administrator has control, audit and a decision point;
• the system has a strict connection between real money and virtual balance.