Организатор крупного фестиваля сталкивается с дилеммой: до события нужно максимизировать продажи билетов, а во время — обеспечить навигацию, нетворкинг и лайв-обновления для тысяч участников. Мы создаём event-приложения, которые работают в обоих режимах без компромиссов. Наш опыт включает проекты для конференций, музыкальных фестивалей и спортивных мероприятий — каждый со своей спецификой.
Event-приложение живёт в двух режимах: до события (афиша, покупка билетов, ожидание) и во время (расписание, навигация, нетворкинг). Технически это разные наборы требований, и распространённая ошибка — делать их одинаково. До события критична конверсия покупки. Во время — offline-first, скорость и real-time обновления расписания.
Покупка билетов
Экран события: описание, спикеры, программа, остаток мест, кнопка «Купить». Выбор типа билета (General, VIP, Online) → корзина → checkout. Для событий с ограниченными местами — счётчик в реальном времени через WebSocket или polling. Если за секунду до покупки места закончились — 409 Conflict, внятное сообщение.
Сезонный абонемент / многодневный фестиваль — один заказ на несколько дат. Групповая покупка: пользователь покупает 4 билета, указывает email каждого участника — каждый получает свой QR.
Платёжный флоу — критичен. Apple Pay и Google Pay для минимизации трений. Сохранённая карта для повторных покупок. Stripe, Checkout.com или региональный эквайер — конверсия повышается на 15–20%.
Почему real-time синхронизация расписания критична?
На фестивале расписание меняется каждые 10 минут: спикер заболел, сессия перенесена. Если приложение показывает устаревшие данные, участники теряют доверие. WebSocket-обновления и push-уведомления решают эту проблему. На клиенте мы используем scheduleSessions как Observable/Stream — при изменении данных UI перерисовывается без полной перезагрузки.
QR-регистрация при входе
QR-код билета: JWT с ticketId, eventId, userId, exp (экспирация). Подписан серверным ключом. При сканировании на входе: проверка подписи → проверка exp → отметка билета как использованного (redemption flag в БД).
Защита от передачи скриншота билета: анимированный QR (обновляется каждые 30 секунд с новым iat) — стандарт для крупных фестивалей. Без сети — принимаем последний загруженный код с проверкой offline-кэша использованных билетов на устройстве волонтёра.
Приложение для волонтёров-сканеров — отдельный target или отдельное приложение. Сканирование через AVFoundation / ML Kit. Звуковой и вибро-сигнал при успешном / ошибочном сканировании — важно в шумной толпе.
Расписание и программа
Многозальное расписание — горизонтальная ось времени, вертикальная — залы/сцены. UICollectionViewCompositionalLayout или кастомный Canvas. Пересекающиеся сессии отображаются параллельно.
Персонализированное расписание: пользователь отмечает «Хочу посетить» — сессии добавляются в личную программу. Конфликты («в 15:00 у вас два события одновременно») — предупреждение.
Real-time изменения: спикер заболел, сессия перенесена. WebSocket-обновление расписания, push-уведомление подписавшимся. На клиенте: scheduleSessions как Observ/Stream — при обновлении UI перерисовывается без reload.
Offline: расписание кэшируется при первой загрузке. На фестивале нет интернета у трети участников — приложение должно работать. Core Data / Room / Isar с фоновой синхронизацией при наличии сети.
Как обеспечить offline-работу на фестивале?
Офлайн-режим — базовая потребность для event-приложений. Мы кэшируем расписание, карту мероприятия и QR-билеты на устройстве. Синхронизация происходит в фоне: при появлении сети данные обновляются, а изменения конфликтов разрешаются через last-write-wins. Для нетворкинга используем Bluetooth proximity, который не требует интернета.
Нетворкинг
Профиль участника: имя, компания, роль, фото, ссылки. Видимость — настраивается (все / только по запросу / скрыт).
«Найти людей рядом» — Bluetooth proximity через CoreBluetooth (iOS) / Nearby Connections API (Android). Proximity-radius ~10 метров. При обнаружении другого участника с включённым нетворкингом — всплывающий banner «Рядом: Иван Петров, CTO в Acme Corp».
Визитка: NFC-обмен (NFCNDEFReaderSession iOS / NfcAdapter Android) — участники прикладывают телефоны, обмениваются профилями. QR-визитка как fallback.
Чат: личные сообщения между участниками, групповые каналы по темам. Stream Chat или SendBird — готовые SDK с push-уведомлениями.
Интерактивность для участников
Live Q&A: участники задают вопросы спикеру через приложение, голосуют за вопросы других. На экране организатора — список вопросов по рейтингу в реальном времени. WebSocket для синхронизации голосов.
Опросы: спикер запускает опрос → участники отвечают → результаты в реальном времени на слайде. Готовые решения (Mentimeter API) или кастомная реализация через WebSocket.
Стек и сравнение платформ
React Native — популярный выбор для event-приложений: кроссплатформа, быстрый старт, достаточная производительность для расписания и чатов. Zustand или Redux Toolkit для стейта расписания. react-native-vision-camera для QR-сканирования.
Flutter — аналогичный выбор, но с более высокой производительностью анимаций. Нативный Swift + Kotlin — если нужны Bluetooth proximity, NFC-обмен визитками и максимальная производительность живого расписания.
| Платформа |
Производительность |
Срок разработки |
Сообщество |
| React Native |
Высокая |
Быстрый |
Крупное |
| Flutter |
Высокая |
Средний |
Растущее |
| Native (Swift/Kotlin) |
Максимальная |
Долгий |
Зрелое |
Что включает разработка event-приложения?
| Компонент |
Описание |
| Аналитика и UX |
Интервью с организаторами, прототипирование |
| Фронтенд |
iOS (Swift) + Android (Kotlin) или кроссплатформа |
| Бэкенд |
Node.js / Go, PostgreSQL, Redis |
| Платежи |
Apple Pay, Google Pay, Stripe / Checkout.com |
| QR-система |
JWT, анимированные QR, офлайн-проверка |
| Публикация |
App Store, Google Play, TestFlight |
| Тестирование |
Пилотное мероприятие, нагрузочное |
| Документация |
API docs, руководство для волонтёров |
Процесс работы
Проектирование афиши и checkout → QR-система и приложение для волонтёров → расписание с offline-поддержкой → нетворкинг → интерактивность → тестирование на реальном событии (pilot run) → публикация.
Ориентиры по срокам
MVP (афиша, покупка билетов, QR-вход, расписание): 4–7 недель. Полноценное event-приложение с нетворкингом, live Q&A, Bluetooth proximity и мультиплатформенным сканером: 2–4 месяца. Стоимость — после анализа требований.
Мы на рынке более 5 лет, реализовали 15+ event-приложений для конференций, фестивалей и спортивных событий. Закажите разработку event-приложения сегодня — мы предложим оптимальное решение. Свяжитесь с нами для предварительной оценки вашего проекта.
Платежи в мобильных приложениях: In-App Purchase, StoreKit 2, Google Billing, Stripe, RevenueCat
В каждом нашем проекте по монетизации приложения мы балансируем между политиками App Store и Google Play, требованиями PCI DSS и логикой верификации покупок на бэкенде. Неправильно сделанная система платежей — это не просто баг, это финансовые потери и возможный бан приложения. За 7 лет мы разобрали более 50 кейсов интеграции платёжных SDK — от простой Stripe-формы до распределённого биллинга с собственными серверными вебхуками.
In-App Purchase: две платформы, два разных API
Если приложение продаёт цифровой контент или подписки — Apple и Google требуют использовать их платёжные системы. Обойти это нельзя: нарушение правил 3.1.1 App Store или Google Play Developer Policy приводит к удалению приложения. Физические товары и сервисы, оказываемые офлайн, — другая история.
StoreKit 2 (iOS 15+)
StoreKit 2 — полная переработка исходного StoreKit с async/await API. Product.products(for:), product.purchase(), Transaction.currentEntitlements — читаемо и предсказуемо по сравнению с очередью транзакций через SKPaymentTransactionObserver.
Самое важное изменение: транзакции в StoreKit 2 подписаны JWS (JSON Web Signature) и верифицируются локально без серверного roundtrip. Transaction.verificationResult возвращает .verified(Transaction) или .unverified(Transaction, VerificationError). Это не значит, что сервер не нужен — он нужен для хранения статуса подписки, но локальная верификация убирает задержку при старте.
StoreKit.AppTransaction — верификация самого факта загрузки приложения из App Store. Нужна для приложений с платным скачиванием или бессрочными покупками, не подписками.
Сложное место в StoreKit 2 — обработка renewalState для подписок: .subscribed, .expired, .inBillingRetryPeriod, .inGracePeriod, .revoked. Состояние inGracePeriod означает, что Apple пытается возобновить оплату (до 16 дней) — в это время нужно продолжать давать доступ. Не обработаешь — потеряешь лояльных пользователей, у которых временно не прошла карта. По опыту, около 5% подписок попадают в billing retry, и автоматическое восстановление доступа возвращает до 80% из них.
Google Play Billing Library (v6+)
Google Billing — сложнее StoreKit по количеству сценариев. BillingClient с PurchasesUpdatedListener, queryProductDetailsAsync, launchBillingFlow, queryPurchasesAsync — обязательно вызывать при каждом старте приложения, не полагаться на PurchasesUpdatedListener как единственный источник правды.
Подтверждение покупки: acknowledgePurchase() для non-consumables и подписок, consumePurchase() для consumables. Если не вызвать acknowledge в течение 3 дней — Google автоматически сделает возврат. Это гарантированная потеря денег, если забыть про acknowledge на бэкенде после верификации.
ProductDetails с SubscriptionOfferDetails — в Billing v5+ структура оферт усложнилась: один продукт может иметь несколько basePlanId и offerId (пробный период, скидка для новых пользователей, retention-оффер). BillingFlowParams.SubscriptionUpdateParams для апгрейда/даунгрейда подписки с prorationMode.
Почему серверная верификация обязательна?
Никогда не доверяйте только клиентскому коду при разблокировке платного контента. Клиентская верификация обходится модификацией приложения.
Для IAP минимальная схема: приложение получает receiptData (iOS) или purchaseToken (Android), отправляет на бэкенд, бэкенд верифицирует через Apple App Store Server API / Google Play Developer API, сохраняет статус в БД, отдаёт ответ клиенту. RevenueCat делает это за вас — но если у вас кастомный бэкенд, нужно реализовать самостоятельно.
Webhook-и важнее, чем кажется. Пользователь может отменить подписку через настройки телефона, не через приложение — приложение не получит об этом событие в реальном времени. Только webhook от Apple/Google (или RevenueCat) позволяет своевременно обновить статус. Мы используем проверку подписи входящих запросов через Apple's signedPayload и Google's DeveloperNotification.
Как RevenueCat упрощает интеграцию?
Поддерживать StoreKit 2 и Google Billing одновременно, с учётом промо-кодов, оферт, восстановления покупок и серверной верификации — это несколько месяцев разработки. RevenueCat закрывает большую часть этого слоя.
RevenueCat — не просто SDK для платежей. Это:
- Единый API для iOS и Android (и Stripe для веба)
- Серверная верификация и хранение статусов подписок
- Webhooks на события (покупка, возобновление, отмена, billing issue)
- Аналитика по когортам, MRR, churn
- A/B тестирование оферт через Experiments
Purchases.configure(withAPIKey:) при старте, Purchases.shared.getCustomerInfo() для получения текущих entitlements — минимальный интегрируемый слой. Purchases.shared.purchase(package:) вместо прямого вызова StoreKit/Billing.
В документации RevenueCat сказано: «RevenueCat handles receipt validation on the server side, reducing client-side complexity and preventing fraudulent purchases.»
Ограничения RevenueCat: платный (бесплатно до $2.5k MRR, дальше процент от дохода), не подходит для очень сложных flow с несколькими storefront-ами или кастомными bundle-ами. Однако для типового SaaS-приложения экономия на собственной разработке составляет $15–30 тыс. — интеграция окупается за 2 месяца.
Stripe в мобильных приложениях
Stripe — для оплаты физических товаров, услуг, B2B-платежей где IAP не требуется политикой платформы.
Stripe iOS SDK и Android SDK — PaymentSheet для готового UI оплаты, PaymentSheetFlowController для кастомного UI с сохранёнными картами. Payment Intent создаётся на сервере, client secret передаётся в приложение — карточные данные никогда не проходят через ваш сервер, только через Stripe.
Apple Pay и Google Pay через Stripe: PKPaymentRequest (iOS) и GooglePayLauncher (Android) уже интегрированы в Stripe SDK. Конверсия у Apple Pay даёт в 1.3–2 раза выше результат, чем формы с ручным вводом карты — это цифры, которые мы подтвердили на десятке проектов.
Сохранённые карты через SetupIntent + Customer API — пользователь платит в один тап при повторном визите. Compliance: PCI DSS SAQ A — самый лёгкий уровень compliance, потому что Stripe Tokenization убирает нужду хранить карточные данные на своей стороне. Согласно PCI DSS, передача токенов освобождает от необходимости сертификации уровня 1.
3DS2 (Strong Customer Authentication) — обязателен для платежей в ЕС по PSD2. Stripe обрабатывает автоматически через PaymentIntent.confirmPayment, но нужно корректно обработать .requiresAction статус и вернуть пользователя в нужный экран после аутентификации.
Что входит в работу (deliverables)
| Документация/Артефакт |
Содержание |
| Архитектурная схема биллинга |
Диаграмма потоков: клиент → SDK → сервер → store/webhook |
| Интеграция SDK |
Подключение и конфигурация StoreKit 2, Google Billing, RevenueCat или Stripe |
| Серверная верификация |
Реализация эндпоинтов и обработка webhook (Apple/Google/RevenueCat) |
| Тестовый стенд |
Sandbox Apple, License Testers Google, Stripe Test Mode |
| Документация по запуску |
Описание ключей, provisioning profiles, TestFlight |
| Обучение команды |
Сессия по поддержке платёжного модуля |
Процесс и сроки
Начинаем с прояснения бизнес-модели: подписки, разовые покупки, consumables, freemium. От этого зависит архитектура. Тестирование IAP требует Sandbox-аккаунтов (Apple) и License Testers (Google) — это отдельная настройка окружения.
Sandbox Apple ведёт себя не так, как production: подписки возобновляются каждые 5 минут вместо месяца, inGracePeriod работает по-другому. Обязательно тестировать сценарии: истечение триала, отмена, billing retry, refund.
| Сценарий |
Инструмент |
Время реализации |
| Подписки iOS + Android |
StoreKit 2 + Google Billing + RevenueCat |
2–3 недели |
| Подписки с кастомным бэкендом |
StoreKit 2 + Google Billing + собственный webhook |
4–6 недель |
| Оплата картой (физические товары) |
Stripe PaymentSheet |
1–2 недели |
| Apple Pay / Google Pay |
Stripe или нативные SDK |
+ 3–5 дней |
| Полный платёжный стек |
Всё вышеперечисленное |
6–10 недель |
Развернуть типичные ошибки при интеграции
- Забыли вызвать
acknowledgePurchase() на Android — деньги возвращаются через 3 дня.
- Не обработали
inGracePeriod — лояльные пользователи блокируются без доступа.
- Положились только на Pushtokens при восстановлении подписок — пропускаете state обновления.
- Использовали production-ключи в TestFlight — срабатывают реальные списания.
Стоимость рассчитывается индивидуально исходя из набора инструментов и сложности серверной логики. В среднем мы укладываемся в бюджет $5k–15k на типовую интеграцию, но экономия от предотвращения ошибок и churn окупает эти вложения за 2–3 месяца.
Получите консультацию по вашему проекту — свяжитесь с нами. Мы поможем выбрать оптимальную архитектуру платежей, которая пройдёт ревью сторов и не сломается при пиковых нагрузках.
