<b>Синхронизация подписки с App Store и Google Play: где ломается биллинг</b>

<b>Синхронизация подписки с App Store и Google Play: где ломается биллинг</b>

Главная ошибка — считать магазин источником истины для вашей entitlements-модели. На практике у вас три независимых контура: ваш биллинг, вебхуки магазина и периодическая сверка. Если один из них отстал, пользователь уже мог получить доступ или, наоборот, потерять его без фактической причины.

Критичные поля для сопоставления: original transaction / purchase token, статус авто-продления, дата окончания, причина отмены, grace period, refund/revoke. Без них вы не отличите отложенное продление от реального churn и начнете плодить ложные блокировки. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.

Архитектурно нужны два механизма: обработка событий в режиме at-least-once и reconciliation job, который собирает расхождения по аккаунту, подписке и периоду доступа. Давайте разберем, что происходит с транзакцией в момент сетевого сплита шлюза: вебхук мог прийти, запись в вашем хранилище — нет, а повторное событие уже содержит тот же token. Если нет дедупликации и версионирования состояния, вы получите двойной grant или преждевременный revoke.

Правило простое: доступ выдается не по одному событию, а по согласованному состоянию, собранному из всех источников. Грамотно спроектированная dunning-стратегия способна спасти до 15% уходящей регулярной выручки, но только если синхронизация не превращает recovery-поток в источник revenue leakage.