Синхронизация подписок с App Store и Google Play: где теряются деньги

Синхронизация подписок с App Store и Google Play: где теряются деньги

Главная ошибка — считать магазин источником истины. В реальности ваш billing должен вести собственный state machine: trial, active, grace, paused, canceled, expired, refunded. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.

Критические события, которые нужно нормализовать:
— initial purchase и renewal;
— cancel, pause, resume;
— billing retry, grace period;
— refund, chargeback, revoke.
Каждое событие должно приходить с корреляционным ключом, попадать в журнал и обрабатываться повторно без двойного начисления. Без этого любая ретрай-логика магазина превращается в источник revenue leakage. 🔧

Слабое место — асинхронность. Магазин может уже считать подписку активной, а ваш сервис — отключенной, или наоборот. Поэтому статус доступа надо вычислять не по одному webhook, а по совокупности: событие, период действия, последняя успешная валидация receipt/token, окно grace и история отмен. Давайте разберем, что происходит с транзакцией в момент сетевого сплита шлюза: если нет надежного reconcile-процесса, вы получите расхождение между access control и бухгалтерским учетом.

Хорошая схема: входящие события складываются в immutable ledger, затем отдельный reconcilation-job сверяет магазин, локальный state и платежный журнал. Все конфликты отправляйте в manual review, а не в «автоматическое восстановление». Грамотно спроектированная dunning-стратегия способна спасти до 15% уходящей регулярной выручки.

Практика простая: не давайте магазину управлять вашей логикой доступа напрямую; управляйте ею сами через строгую модель состояний, ретраи с дедупликацией и регулярную сверку.