Как работает система заявок на пополнение баланса

Плагин Invoice превращает пополнение баланса в управляемый, контролируемый и проверяемый процесс. Он создаёт промежуточный уровень между пользователем и реальным зачислением денег, в котором фиксируются заявки, способы оплаты, подтверждения и административные решения.

Ручное пополнение баланса через заявку на оплату электронных кошельков или криптовалюты. Управление статусами в админке и зачисление на баланс.

Система работает в двух параллельных плоскостях:

• пользователь создаёт и отслеживает заявки;
• администратор управляет заявками и платёжными реквизитами, подтверждает оплаты и зачисляет баланс.

Обе стороны связаны одной сущностью — заявкой на пополнение (invoice).

1. Как это работает со стороны пользователя

1.1. Откуда появляется заявка

Пользователь не может создать заявку сам по себе.
Она всегда рождается из платёжного намерения в модуле Payments.

Процесс выглядит так:

1. Пользователь инициирует пополнение баланса через модуль Payments.
2. В системе создаётся платёж со статусом new или process.
3. Вместо автоматического платёжного шлюза пользователь переходит в интерфейс Invoice.
4. Invoice получает этот платёж и использует его как основу для заявки.

Таким образом, каждая заявка жёстко связана с платежом и знает:

• кому она принадлежит;
• на какую сумму создана;
• с каким платёжным намерением связана.

Сумма заявки пересчитывается через внутренний коэффициент курса, чтобы привести платёж к валюте сайта.

1.2. Выбор способа пополнения

После этого пользователь попадает на страницу выбора способа оплаты.

Он видит только те способы, которые администратор включил в админ-панели.
Каждый способ содержит:

• название;
• валюту;
• кошелёк или платёжный адрес;
• сеть (если используется);
• ссылку на сервис;
• текстовые инструкции.

Пользователь:

1. выбирает один способ;
2. при необходимости оставляет комментарий;
3. отправляет форму.

В этот момент система:

• создаёт новую заявку;
• присваивает ей уникальный номер;
• связывает её с платежом;
• переводит платёж в статус process.

1.3. Что происходит после создания

Сразу после создания заявки:

• администратор получает уведомление;
• пользователь получает письмо с персональной ссылкой на свою заявку.

Эта ссылка содержит защитный хэш, который рассчитывается из номера заявки и идентификатора пользователя.
Это гарантирует, что заявку может открыть только её владелец.

1.4. Страница заявки

По своей ссылке пользователь видит все платёжные реквизиты и состояние заявки:

• номер;
• сумму;
• выбранный способ;
• валюту;
• кошелёк или адрес;
• сеть;
• инструкции;
• комментарий;
• текущий статус.

Фактическая оплата происходит вне сайта — пользователь переводит деньги по указанным реквизитам.
После этого он возвращается и нажимает кнопку:

«Я уже оплатил»

Это переводит заявку в статус claimed — пользователь официально заявляет, что платёж отправлен.

Администратор получает уведомление об этом и если утверждение верно - выполняет зачисление средств на баланс пользователя, одним простым нажатием кнопки.

1.5. Список заявок пользователя

Пользователь всегда может открыть список всех своих заявок и видеть:

• номера;
• суммы;
• выбранные способы;
• даты создания и подтверждения;
• текущие статусы.

Это его журнал всех попыток и успешных пополнений.

2. Как это работает со стороны администратора

Администратор управляет всей системой через специальную панель Invoice.

2.1. Список всех заявок

На главной странице админки отображаются все заявки с информацией:

• пользователь;
• номер;
• сумма;
• способ пополнения;
• валюта;
• статус;
• ссылка на пользовательскую страницу заявки.

Для каждой заявки доступны действия:

• подтвердить оплату;
• редактировать;
• удалить.

2.2. Когда пользователь нажал «Я оплатил»

Когда пользователь помечает заявку как оплаченную, её статус становится claimed.

Это означает:

Пользователь утверждает, что деньги отправлены, но баланс ещё не зачислен.

Это ключевая точка, где решение принимает администратор.

2.3. Подтверждение оплаты администратором

Когда администратор нажимает «Подтвердить», запускается цепочка зачисления.

Система действует следующим образом:

Шаг 1.
Проверяется, есть ли у заявки связанный платёж.

Шаг 2.
Если заявка пришла от пользователя — платёж уже существует.
Если заявка была создана администратором вручную — платёжа ещё нет, и он создаётся автоматически.

Шаг 3.
Для соответствующего платежа устанавливается статус paid.

Именно этот шаг запускает бизнес-логику модуля Payments и реально зачисляет деньги пользователю на баланс.

Шаг 4.
Заявка помечается как paid, фиксируется дата оплаты.

Шаг 5.
Пользователь получает письмо о том, что его заявка подтверждена и баланс пополнен.

2.4. Ручные заявки от администратора

Администратор может создавать заявки сам, без участия пользователя.

Он:

• выбирает пользователя;
• указывает сумму;
• добавляет комментарий.

Такая заявка изначально не имеет платежа.
Но при её подтверждении система автоматически создаёт платёж, переводит его в статус paid и зачисляет баланс.

С точки зрения учёта это абсолютно эквивалентно обычному пользовательскому пополнению.

2.5. Редактирование и удаление заявок

Пока заявка не оплачена, администратор может:

• изменить сумму;
• изменить комментарий.

Он также может полностью удалить заявку, если она ошибочна или неактуальна.

3. Управление способами пополнения

Отдельная вкладка админки посвящена способам оплаты.

Администратор может:

• создавать новые способы;
• задавать валюту, кошелёк, сеть и инструкции;
• включать и отключать способы;
• управлять порядком отображения.

Только включённые способы видны пользователям при создании заявки.

Таким образом, администратор полностью контролирует, куда и как пользователи отправляют деньги.

4. Общая философия плагина

Invoice — это не платёжный шлюз.
Это система учёта, подтверждения и контроля.

Она гарантирует, что:

• пользователь не получит баланс без оформленной заявки;
• администратор не зачислит деньги без зафиксированного документа;
• каждый шаг подтверждён статусами и письмами;
• каждый платёж всегда связан с конкретной заявкой.

В результате:

• у пользователя есть прозрачный, понятный и отслеживаемый процесс;
• у администратора есть контроль, аудит и точка принятия решения;
• у системы есть жёсткая связка между реальными деньгами и виртуальным балансом.