Реалізація маржинальної торгівлі в мобільному додатку біржі

Реалізація маржинальної торгівлі в мобільному додатку біржі

Ми розробляємо мобільні додатки для бірж з підтримкою маржинальної торгівлі під ключ. Маржинальна торгівля — високоризиковий інструмент: користувач вносить заставу (маржу), а біржа надає кредитне плече 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»
• Маржинальна позика нарахувала відсотки > 10 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 місяці. Економія клієнтів становить в середньому 25% на комісіях завдяки оптимізації маржі. Наш модуль обробляє до 1000 запитів на секунду без затримок — у 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 та зовнішнім платіжним шлюзом?

Якщо додаток продає цифровий контент або підписки — Apple та Google вимагають використовувати їхні платіжні системи. Обійти це неможливо: порушення правил 3.1.1 App Store або Google Play Developer Policy призводить до видалення додатку. Фізичні товари та послуги, що надаються офлайн, — інша історія.

In-App Purchase: дві платформи, два різних API

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: платний (безкоштовно до певного рівня MRR, далі відсоток від доходу), не підходить для дуже складних flow з кількома storefront-ами або кастомними bundle-ами. Однак для типового SaaS-додатку економія на власній розробці є значною — інтеграція окупається швидко.

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.

Як налаштувати тестове середовище для платежів?

Вартість розраховується індивідуально виходячи з набору інструментів та складності серверної логіки. У середньому ми вкладаємося в бюджет, який обговорюється окремо, але економія від запобігання помилок та churn окупає ці вкладення за 2–3 місяці.

Отримайте консультацію по вашому проєкту — зв'яжіться з нами. Ми допоможемо обрати оптимальну архітектуру платежів, яка пройде рев'ю сторів та не зламається при пікових навантаженнях.