Это происходит, когда пользователь нажал «Оплатить», деньги списались, а доступ не открылся. Поддержка ловит тикеты, аналитика показывает обрыв воронки, а команда спорит: виноват клиент или сервер. Платежи — единственная зона, где ошибка стоит денег прямо сейчас, и поэтому сюда нельзя приносить код «на глаз». Дальше — самое интересное.

Продолжение ниже: конкретика. Сторы диктуют правила — IAP и подписки обязаны идти через StoreKit и Play Billing, web checkout допустим только там, где это легально и где вы реально контролируете релиз. Команды чаще выбирают инструмент по моде, а не по риску сценария, и упираются в комиссию, grace-периоды и billing retry уже после релиза.

А теперь важная часть — инсайт. Платёж считается завершённым только после серверного подтверждения: finish transaction и вебхуки с идемпотентностью важнее красивого экрана оплаты. Мало кто об этом знает, потому что в демо всё зелёное: покупка проходит по happy-path, а падает на плохой сети, повторной доставке вебхука или восстановлении покупок на новом устройстве.

Вывод: надёжный платежный контур — это не экран paywall, а контракт между клиентом, стором и сервером с fail-path, метриками и планом отката. Всё это разобрано в курсе «Платежи в мобильных приложениях»: IAP против web checkout, серверная валидация, анти-фрод и восстановление покупок. Первый модуль бесплатно. Подписывайся на канал, чтобы не пропустить следующее.