Начните с ограничений на сервере: проверяйте частоту запросов и доступный бюджет до отправки звонка через API. Чтобы контролировать расходы на Flash Call, свяжите повторные попытки с текущим запросом на вход, установите предел затрат и предусмотрите остановку отправок. Одной блокировки кнопки на сайте недостаточно: запросы можно отправлять в обход формы. Ниже разберём, какие правила передать разработчику, как учитывать расходы и что показать клиенту, если лимит уже сработал. Эти меры подходят и небольшому интернет-магазину, и сервису с личными кабинетами.
Почему запросов на Flash Call становится слишком много?
Клиент нажимает «Получить код» повторно, когда звонок задерживается или форма не объясняет, что делать дальше. Отдельный источник запросов — автоматические обращения к серверу. Если каждый такой запрос сразу запускает вызов, интерфейс сайта уже не контролирует отправки.
В одном из вариантов Flash Call приложение считывает номер входящего вызова из системного журнала, извлекает код из последних цифр и отправляет его на сервер для проверки. Это описание конкретного сценария, а не обязательное поведение любого сайта или приложения (источник: SP Telecom). Поэтому сначала уточните, как устроена ваша интеграция: кто создаёт код, кто его проверяет и какой запрос запускает новый звонок.
Для разбора расходов разделите события: клиент попросил код, сервер разрешил отправку, провайдер принял запрос, клиент завершил вход. Запрос к вашей форме и платное событие у провайдера могут учитываться по-разному. Основание для списания нужно проверить в условиях подключения.
Посмотрите и на причины повторных попыток. Если человек не понимает, где взять код, ограничение расходов лишь остановит новые звонки, но не поможет войти. Для такой проверки пригодится разбор причин, по которым клиенты не проходят верификацию через Flash Call.
Какие ограничения поставить до отправки звонка?
Попросите разработчика собрать все проверки в одном серверном обработчике. Он должен решать, разрешена ли отправка, прежде чем обращаться к API провайдера. Кнопка с обратным отсчётом остаётся подсказкой для клиента; сервер проверяет ограничения независимо от неё.
- Ограничьте частоту запросов на один номер. Приводите номер к единому формату, чтобы пробелы и разные способы записи не обходили правило.
- Проверяйте частоту обращений из одной сессии и с одного сетевого адреса. Учитывайте, что общая сеть бывает у нескольких клиентов, поэтому одного такого признака недостаточно для жёсткой блокировки.
- Установите общий предел отправок для проекта. Он нужен на случай, когда запросы идут с разных адресов и на разные номера.
- Задайте бюджет в BYN на выбранный период. Если расчёты с провайдером идут в другой валюте, заранее определите правило пересчёта и запас до предела.
- Добавьте ручной выключатель новых отправок. Ответственный сотрудник должен знать, где его найти и что увидят клиенты после отключения.
Пороговые значения выбирайте по собственным обращениям: посмотрите, как часто клиенту действительно нужен повторный вызов и когда запросы идут плотнее обычного. Универсального безопасного интервала для всех проектов нет. Отдельно проверьте ситуацию, когда несколько запросов приходят одновременно: проверка лимита и учёт новой попытки должны проходить как одна операция, иначе каждый запрос успеет получить разрешение.
Как учитывать бюджет и не оплачивать случайные повторы?
До запуска решите, как сервер учитывает запрос, по которому ещё нет окончательного ответа провайдера. Практический вариант — резервировать расчётную стоимость перед отправкой, а затем сверять её с фактическим статусом и условиями тарифа. Пока судьба запроса неизвестна, резерв остаётся занятым. Иначе очередь одновременных отправок обойдёт денежный предел.
Расчётную стоимость берите из условий своего подключения, включая платежи, которые относятся к отправке. Точный жёсткий предел расходов возможен только с учётом правил списания и задержек в отчётности провайдера. Внутренний счётчик сайта сам по себе не заменяет сверку с его данными.
Для повторов используйте идентификатор операции. Если браузер повторно отправил тот же запрос, сервер должен найти текущую попытку, а не автоматически создавать новую. Поддержку такого механизма на стороне провайдера уточните в документации API. Например, справочный центр Плюсофон описывает отдельный метод отправки Flash-вызова с генерацией пин-кода, но из этого описания нельзя сделать вывод, что повторный вызов метода не создаст новую отправку (источник: справочный центр Плюсофон).
Тайм-аут тоже требует отдельного правила. Если сервер не дождался ответа, это ещё не означает, что провайдер не принял запрос. Сначала уточните статус доступным способом. Повторную отправку разрешайте по заранее заданному сценарию, чтобы временная потеря связи не запускала цепочку вызовов.
Проверьте и вход в нескольких вкладках: повторное действие пользователя может создать ещё одну попытку и сделать предыдущий код непригодным. Подробности этого сценария разобраны в статье о том, почему код Flash Call не подходит при входе в двух вкладках.
Что показать клиенту, когда лимит сработал?
Разделите сообщения для клиента и сведения для сотрудника. Клиенту нужны причина задержки на понятном языке и доступное действие. Сотруднику — правило, которое остановило запрос, состояние бюджета и ответ провайдера. Технические подробности защиты в форме входа не нужны.
При слишком частых попытках покажите, когда можно запросить звонок снова. Если уже есть активная попытка, оставьте доступным ввод кода и объясните, из какого звонка его взять. Когда отправки остановлены для всего проекта, уберите обещание скорого вызова: оно провоцирует новые нажатия.
Резервный способ подтверждения нужен на случай проблем с доставкой. В обзоре New-Tel описаны блокировки Flash Call со стороны операторов и рекомендация иметь альтернативу для верификации (источник: New-Tel). Однако резервный канал тоже требует ограничений: если после отказа Flash Call система без проверки отправляет другое платное сообщение или звонок, расходы продолжаются.
Включайте резервный способ после проверки его доступности и бюджета. Не запускайте несколько каналов одновременно только потому, что клиент ещё не ввёл код. Сценарий, который не предусматривает доставку звонка, лучше проверить отдельно от сценария, где звонок пришёл, но человек не завершил вход.
При подборе API-интеграции для flashcall.by эти правила стоит включить в техническое задание вместе с самим подтверждением номера. На сайте заявлены авторизация по звонку и подбор решения под проект; конкретные лимиты, статусы и порядок остановки отправок нужно согласовать для своей схемы подключения (источник: Flashcall.by).
Типичные ошибки при ограничении расходов
- Блокируют только кнопку. Прямой запрос к серверу обходит интерфейс, поэтому повторную проверку ставят перед обращением к API.
- Считают только успешные входы. Для бюджета сверяют события, за которые провайдер списывает деньги, даже если клиент не завершил авторизацию.
- Разрешают повтор после любого тайм-аута. Сначала выясняют судьбу предыдущего запроса и сохраняют связь с текущей попыткой входа.
- Проверяют лимит отдельно от учёта отправки. При одновременных запросах это оставляет возможность превысить предел; проверку и резервирование объединяют в одну операцию.
- Останавливают Flash Call, но оставляют резервный канал без контроля. Для него тоже задают предел расходов и правило отключения.
Работу ограничений проверьте тестовыми сценариями: повторным нажатием, входом в нескольких вкладках и отсутствием ответа от провайдера. Результат проверки должен быть виден в событиях сервера: какая попытка получила разрешение, какая остановилась и почему. Начните сейчас с одного действия на две минуты: отправьте разработчику вопрос «Проверяет ли сервер общий лимит расходов до каждого обращения к API Flash Call?».
