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