Сумма: 0
Количество заявок: 1
28.09.26 (включительно)
По договоренности
Идея
Задачи ИКТ
Финансовые технологии
FinTech
Мобильное приложение
При проведении платежа возможна ситуация, когда операция фактически выполнена внешним процессингом, но ответ не был получен приложением из-за сетевого сбоя. Повторная отправка запроса может привести к двойному списанию средств. Дополнительная сложность возникает, если платёжный провайдер не поддерживает механизм идемпотентности. Таймаут при первой отправке — ответ от провайдера не получен в установленное время: операция переводится в статус «неизвестно», запускается фоновая проверка статуса; пользователю не показывается ни успех, ни явная ошибка. Повторная отправка после таймаута (в том числе повторное нажатие пользователем) — система распознаёт операцию по idempotency-ключу/transaction_id и возвращает её текущий статус вместо создания новой. Обрыв связи на стороне клиента после отправки запроса, но до получения ответа — при восстановлении соединения клиент запрашивает статус по сохранённому transaction_id, а не отправляет платёж заново. Провайдер обработал платёж, но ответ не дошёл до приложения (сбой на обратном пути) — расхождение выявляется через сверку; статус в системе обновляется по её результатам, задвоения не происходит благодаря idempotency-ключу. Провайдер не поддерживает идемпотентность — перед повторной отправкой обязателен запрос статуса последней операции (если провайдер это позволяет) либо период ожидания с последующей сверкой по выписке; при отсутствии способа проверки — эскалация в ручной/полуавтоматический процесс сверки. Сбой бэкенда между записью операции в БД и отправкой запроса провайдеру — обеспечивается атомарностью этих шагов (outbox или аналог), чтобы факт отправки не терялся. Несколько параллельных попыток от одного пользователя — предотвращаются блокировкой на UI и уникальным ограничением по idempotency-ключу на сервере. Долгое отсутствие ответа сверх максимально допустимого времени ожидания — операция помечается «требует ручной проверки» и передаётся в очередь для разбора службой поддержки/оператором, а не автоматически считается ни успешной, ни неуспешной.
Снижение риска двойных списаний и финансовых потерь, повышение надёжности проведения платежей, устойчивость системы к сетевым сбоям и отказам внешних сервисов, а также повышение доверия пользователей к финансовому продукту.
Шавков Марк Викторович
Цель и описание задачи (проекта)
Разработка мобильного приложения с защищённым механизмом проведения финансовых операций, исключающим повторное списание средств при сетевых сбоях, тайм-аутах и повторной отправке запросов. Система должна корректно определять состояние операции даже при отсутствии однозначного ответа от внешнего платёжного провайдера. Идемпотентность запросов: перед первой отправкой платежа клиент формирует уникальный idempotency-ключ; любая повторная отправка с тем же ключом должна возвращать результат уже существующей операции, а не создавать новую. Единый сквозной transaction_id, передаваемый между приложением, бэкендом и (по возможности) платёжным провайдером — для однозначного сопоставления операции на всех этапах. Журнал транзакций на сервере с явными статусами: создана, отправлена провайдеру, подтверждена, отклонена, статус неизвестен (timeout), сверена. Переход между статусами и его время должны логироваться для последующего разбора инцидентов. Итоговый статус платежа определяется не по факту получения/неполучения ответа в момент запроса, а через отдельный запрос статуса (polling) или webhook/callback от провайдера — статус запроса и статус денежной операции должны быть разделены. Таймауты и retry-политика: заданные пороги ожидания ответа, ограниченное число повторов, экспоненциальный backoff; повтор допустим только с тем же idempotency-ключом. Механизм сверки (reconciliation) для провайдеров, не поддерживающих идемпотентность: проверка статуса последней операции клиента перед повторной отправкой либо периодическое сопоставление журнала транзакций с выпиской провайдера. Атомарность записи операции и её отправки провайдеру на стороне бэкенда (например, паттерн outbox), чтобы сбой между этими шагами не приводил к потере факта отправки. Блокировка повторной отправки формы платежа на UI до получения окончательного статуса операции. Уникальное ограничение (unique constraint) по idempotency-ключу на уровне БД — как последний рубеж защиты от дублей при параллельных запросах. Информирование пользователя о промежуточном/неопределённом статусе понятной формулировкой («платёж обрабатывается»), без утверждения об успехе или неуспехе до подтверждения.
Whatsapp
