SMS-форвардер увидел перевод. Можно ли закрывать заявку?

«Форвардер онлайн» означает только то, что какой-то компонент системы недавно ответил. Из этого ещё не следует, что он получает банковские уведомления, правильно извлекает суммы и передаёт все события. Для P2P-оператора разница становится денежной: пропущенное сообщение задерживает признание оплаты, а ошибочно разобранное способно подтвердить деньги, которых нет.

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

Между банком и заявкой несколько независимых событий

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

Любой участок способен задержаться или завершиться отдельно от соседнего. Банк зачислил деньги, но уведомление ещё не пришло. Устройство получило сообщение, но потеряло сеть. Сервер сохранил событие, но ответ не дошёл и приложение повторило отправку. Система сопоставила уведомление с заявкой, однако позже банковская выписка показала другую сумму. Эти ситуации требуют разных действий, хотя на экране клиента все выглядят как «платёж завис».

Поэтому у события сохраняются время операции, если оно достоверно доступно, время получения устройством и время серверного приёма. Время разбора и сопоставления можно учитывать отдельно. Если смешать их в одну отметку, невозможно понять, тормозит банк, устройство, сеть или собственная очередь обработки.

Прежде всего договоримся, какие данные вообще нужны

Для поиска поступления обычно полезны сумма, валюта, ограниченный идентификатор счёта, банковский референс, доступное время и тип события. Конкретный набор зависит от источника. Полный архив SMS, личные переписки, остатки посторонних счетов и коды входа не нужны для закрытия отдельной платёжной заявки.

Разрешения выдаются владельцем устройства и данных для конкретной цели и получателя информации. Доступ к уведомлениям не следует трактовать как согласие передавать всё содержимое телефона. Google Play отдельно ограничивает работу с SMS и журналами звонков; наличие технического способа чтения не означает допустимость распространения или использования приложения. Применимые требования платформы и банка проверяются до запуска.

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

Парсер может ошибиться даже на настоящем сообщении

Учебный пример уведомления содержит зачисление 12 000 и новый остаток 524 000. После изменения банковского шаблона извлечение первой подходящей суммы начинает возвращать остаток счёта вместо суммы операции. Сообщение настоящее, отправитель привычный, соединение защищено, но результат обработки финансово неверен.

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

Связка «сумма плюс ближайшее время» также недостаточна, если одновременно открыты две заявки по 12 000. Дополнительные признаки используются только в той мере, в которой источник действительно их передаёт. Если нужного референса нет, система признаёт неоднозначность. Она не придумывает его из номера заявки, чтобы завершить сопоставление.

Повторная доставка должна быть скучной

Допустим, сервер сохранил уведомление, но устройство не получило подтверждение. Повторная отправка должна вернуть ссылку на уже принятое событие, не создавая второй денежной записи. Стабильный идентификатор сообщения и сохранённое состояние доставки помогают отделить повтор от нового события. Но одинаковый текст двух уведомлений ещё не доказывает, что реальный перевод был только один.

При появлении банковских данных наблюдения объединяются вокруг фактического поступления. SMS, push и строка выписки могут относиться к одной операции. И наоборот, два отдельных банковских референса на одинаковую сумму могут подтверждать два платежа. Поэтому дедупликация канала доставки и дедупликация денежных поступлений решают разные задачи.

После восстановления связи очередь отправляется контролируемо, с сохранением исходных времён. Старые сообщения не должны выглядеть свежими платежами только потому, что сервер получил их сейчас. Часть связанных ордеров уже могла истечь или перейти на ручной разбор; их обработка должна учитывать текущее состояние и историю выданных реквизитов.

«Устройство живо» и «источник работает» проверяются отдельно

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

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

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

Измеряем результат по банку, а не по числу сообщений

Представим день со 100 подтверждёнными банковскими поступлениями. Форвардер своевременно передал уведомления о 95 из них, ещё о трёх передал поздно, а два пропустил. Восемь событий дополнительно пришли повторно. Сервер получил 106 сообщений: 98 уникальных наблюдений плюс восемь повторов.

Показатель «106 событий на 100 платежей» ничего не говорит о качестве. Полнота обнаружения в этом примере составляет 98%, своевременность относительно всех поступлений 95%. Отдельно считаются ошибки сопоставления, возраст исключений и доля операций, найденных только при сверке. Без независимого банковского набора пропущенные сообщения вообще не попадают в знаменатель и система выглядит лучше, чем работает.

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