...
| Предупреждение |
|---|
Перед сменой состояния модуля с "рабочего" на "тестовый" необходимо убедиться, что в данный момент нет транзакций. Также необходимо решить вопрос с транзакциями со статусом "В обработке". После смены режима все ранее необработанные транзакции при обработке получат статус текущего режима! То есть, если транзакция начата как "тестовая", а запрос о подтверждении пришёл после смены режима на "рабочий", то она будет считаться проведённой в рабочем режиме, и наоборот. Платежи в договор в любом режиме добавляются одинаково. |
Рекуррентный платёж
Поддерживается возможность периодических платежей. Пользователь при оплате может указать, что платёж периодический
| Блок кода | ||
|---|---|---|
| ||
# Рекуррентный платёж (если настроек нет, то запрещено)
# Минимальная сумма рекуррентных платежей
assist.RecurringMinAmount=1.00
# Максимальная сумма рекуррентных платежей
assist.RecurringMaxAmount=666.66
# Периодичность рекуррентных платежей в днях (31 - magic number, означает месяц вне зависимости от кол-ва дней)
assist.RecurringPeriod=31
# Дин.класс вызывается перед попыткой рекуррентного платежа (имплементация ru.bitel.bgbilling.modules.assist.server.RecurringRequest). Подразумевается, что можно сменить там сумму.
assist.recurring.request.class=ru.bitel.bgbilling.modules.assist.AssistRecurringRequest
# Комментарий. Данный параметр передается в ASSIST при рекуррентных платежах и отображается в выписках по операциям. (доступны только эти два макроса)
assist.OrderCommentRecurring=Рекуррентная оплата по договору ${contract} (${contract_comment}) |
Есть возможность ручной инициации платежа (см. в договоре на модуле assist внизу). Для работы должна быть настроена задача ежедневная.
Этот таск не смотрит на деньги, нехватку, подписку, абонку, блокировку. Всё это должно делаться в упомянутом дин.коде, который нужно написать под свои требования. "Делаться" только одно по сути: вычисление суммы, которую сейчас надо заплатить. По умолчанию поведение следующее: каждые N (из конфига) дней платится сумма S (заявленная юзером при подключении платежа) до достижения максимальной даты D (задаётся юзером при подключении платежа согласно сроку своей карты). С технической точки зрения: при этом платёж происходит точно также, как если бы человек сам платил из личного кабинета: сначала создаётся заказ, который сначала "в обработке", потом отправляется запрос в ассист, если он одобряется, то через некоторое время в тот же самый экзекутер приходит оповещение, заказ отмечается оплаченным, на договор добавляется платёж на эту сумму.