Реализация маржинальной торговли в мобильном приложении биржи

Реализация маржинальной торговли в мобильном приложении биржи

Мы разрабатываем мобильные приложения для бирж с поддержкой маржинальной торговли под ключ. Маржинальная торговля — высокорисковый инструмент: пользователь вносит залог (маржу), а биржа предоставляет кредитное плечо 3x, 5x или 10x. Прибыль и убытки рассчитываются от полного объёма позиции, а не от залога. Если убыток приближается к сумме маржи — биржа принудительно закрывает позицию (liquidation). В мобильном приложении критично точно отображать эти риски в реальном времени: даже секундная задержка в обновлении цены может привести к неожиданной ликвидации. Наши инженеры с 6-летним опытом в финансовых приложениях реализуют надёжную систему управления маржой, соответствующую требованиям регуляторов и лучшим практикам безопасности. Мы гарантируем качество кода и соблюдение NDA.

Маржинальные аккаунты: Isolated и Cross

Два режима маржи с принципиально разной логикой:

Cross Margin — весь баланс маржинального счёта служит залогом для всех позиций. Одна позиция «съедает» маржу другой. Liquidation price рассчитывается для всего счёта.

Isolated Margin — каждая торговая пара имеет отдельный изолированный маржинальный кошелёк. Максимальный убыток ограничен суммой в этом кошельке. Для мобильного UX изолированная маржа проще: пользователь понимает, что теряет только то, что внёс на конкретную пару. Изолированная маржа даёт пользователю чёткое понимание максимального убытка, в отличие от Cross Margin, где одна позиция может потянуть за собой весь счёт. На практике это снижает число обращений в поддержку на 30%.

UI должен явно разграничивать эти два режима. Переключатель с кратким объяснением (тултип или bottom sheet с примером) — обязателен.

Как рассчитывается Liquidation Price?

Liquidation Price — ключевой индикатор для маржинальной позиции. Пользователь должен видеть его прямо в интерфейсе до открытия позиции.

Формула для ISOLATED LONG (упрощённая для Binance):

LiquidationPrice = EntryPrice × (1 - 1/Leverage + MaintenanceMarginRate)

Maintenance Margin Rate для большинства пар Binance: 0.5–1.5% в зависимости от тира.

// iOS — расчёт liquidation price для изолированной long-позиции
struct MarginPositionCalculator {
    static func liquidationPriceLong(
        entryPrice: Decimal,
        leverage: Int,
        maintenanceMarginRate: Decimal = 0.005
    ) -> Decimal {
        let leverageDecimal = Decimal(leverage)
        return entryPrice * (1 - 1 / leverageDecimal + maintenanceMarginRate)
    }

    static func liquidationPriceShort(
        entryPrice: Decimal,
        leverage: Int,
        maintenanceMarginRate: Decimal = 0.005
    ) -> Decimal {
        let leverageDecimal = Decimal(leverage)
        return entryPrice * (1 + 1 / leverageDecimal - maintenanceMarginRate)
    }
}

Liquidation price нужно обновлять при каждом изменении размера плеча или суммы маржи. Показывать его красным цветом с процентом расстояния от текущей цены — «Ликвидация в 14.3% от текущей».

Что такое Margin Ratio и как он сигнализирует о риске?

Margin Ratio = Обслуживаемая маржа / Капитал счёта × 100%.

• Ниже 100% — счёт в норме
• 80–100% — жёлтая зона, push-уведомление «Внесите дополнительную маржу»
• Выше 100% — принудительное закрытие позиций (liquidation)

На экране открытой позиции — прогресс-бар Margin Ratio с цветовой градацией (зелёный → жёлтый → красный). WebSocket обновляет баланс и P&L в реальном времени.

Заём и погашение

Работа с маржинальным займом — отдельный flow:

1. Заём (Borrow): пользователь указывает сумму и валюту. Биржа возвращает tranId. Интерфейс показывает доступный лимит займа, текущую процентную ставку (hourly/annual), максимально доступную сумму.

2. Погашение (Repay): сначала погашаются проценты, потом тело долга. Кнопка «Погасить всё» рассчитывает полную сумму к погашению включая начисленные проценты.

На Binance API: POST /sapi/v1/margin/loan и POST /sapi/v1/margin/repay. Ставки доступны через GET /sapi/v1/margin/interestRateHistory.

Уведомления и алерты рисков

Маржинальная торговля требует проактивных уведомлений:

• Margin Ratio > 75% → push «Приближаетесь к ликвидации на BTC/USDT»
• Маржинальный займ начислил проценты > X USDT → периодическое напоминание
• Позиция принудительно закрыта → немедленный push с суммой убытка

Firebase Cloud Messaging с high priority для уведомлений о ликвидации — APNs apns-priority: 10, FCM priority: high. Обычный priority может задержать доставку на несколько минут, что критично при маржинальной торговле.

Что входит в разработку маржинального модуля?

• Документация по интеграции с биржей (REST API + WebSocket)
• Реализация режимов Isolated и Cross Margin
• Расчёт Liquidation Price и Margin Ratio с real-time обновлением
• Интерфейс открытой позиции с PnL и прогресс-баром риска
• Push-уведомления о ликвидации и margin call
• Тестирование на исторических данных и симуляция стресс-сценариев
• Обучение команды заказчика и сопровождение после запуска

Интерфейс открытой позиции

Карточка открытой позиции должна показывать:

Mark Price (честная цена по индексу) — важно отличать от Last Price. Именно по Mark Price считается PnL и liquidation, не по Last Price.

Сроки и масштаб

Минимальный маржинальный модуль: 4–5 недель. Полноценная система с Cross/Isolated, историей займов, подробной аналитикой позиций — 2–3 месяца.

Наша команда имеет 6+ лет опыта в разработке биржевых приложений, реализовано 15+ проектов с маржинальной торговлей для клиентов из топ-100 криптобирж. Свяжитесь с нами для оценки вашего проекта. Закажите разработку модуля — получите консультацию по архитектуре.

Платежи в мобильных приложениях: 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)

Процесс и сроки

Начинаем с прояснения бизнес-модели: подписки, разовые покупки, consumables, freemium. От этого зависит архитектура. Тестирование IAP требует Sandbox-аккаунтов (Apple) и License Testers (Google) — это отдельная настройка окружения.

Sandbox Apple ведёт себя не так, как production: подписки возобновляются каждые 5 минут вместо месяца, inGracePeriod работает по-другому. Обязательно тестировать сценарии: истечение триала, отмена, billing retry, refund.

Стоимость рассчитывается индивидуально исходя из набора инструментов и сложности серверной логики. В среднем мы укладываемся в бюджет $5k–15k на типовую интеграцию, но экономия от предотвращения ошибок и churn окупает эти вложения за 2–3 месяца.

Получите консультацию по вашему проекту — свяжитесь с нами. Мы поможем выбрать оптимальную архитектуру платежей, которая пройдёт ревью сторов и не сломается при пиковых нагрузках.