Реалізація розміщення стоп-ордера в мобільному додатку біржі
Стоп-ордер — це умовна заявка. Поки ціна не перетне stopPrice, ордер в ордербуці не з'являється. Досягла stopPrice — біржа автоматично розміщує лімітний (STOP_LOSS_LIMIT) або ринковий (STOP_LOSS) ордер. Понад 70% трейдерів хоча б раз допускали помилку при вводі стоп-ціни: плутають stopPrice та limitPrice — половина звернень у саппорт крипто-додатків саме про це. Отже, UI має пояснювати механізм, а не просто малювати два поля. Ми, як розробники, вже стикалися з цією проблемою на практиці: в одному проекті 90% помилок валідації виникали саме через некоректне співвідношення цін. Більше того, біржі встановлюють мінімальний крок ціни (tick size) — зазвичай 0.01 USDT, що впливає на валідацію. Замовте розробку модуля стоп-ордерів — ми реалізуємо під ключ за 2–3 дні.
Типи стоп-ордерів
Які типи стоп-ордерів підтримуються?
STOP_LOSS_LIMIT (Binance) — три параметри: stopPrice (тригер), price (лімітна ціна виконання), quantity (об'єм). STOP_LOSS (ринковий) — тільки stopPrice та quantity. Після тригера виконується по ринку — гарантія виходу з позиції, але без гарантії ціни. TAKE_PROFIT_LIMIT — аналогічна структура, але логіка зворотна: ордер активується при зростанні ціни вище stopPrice (для фіксації прибутку). На відміну від ринкового стоп-ордера, стоп-лімітний ордер гарантує ціну виконання, але ризик невиконання вищий у 2–3 рази при різких рухах ринку. Кількість помилок при введенні стоп-цін у 5 разів більша, ніж при звичайних лімітних ордерах.
Типова помилка: stopPrice та limitPrice рівні або limitPrice гірша за stopPrice. Якщо при STOP_LOSS_LIMIT для продажу limitPrice >= stopPrice — ордер ніколи не виконається на практиці (ринок провалиться крізь обидва рівні). Рекомендований gap: limitPrice на 0.1–0.5% нижче stopPrice при продажу. Додатково потрібно враховувати мінімальний об'єм (lot size) та tick size біржі.
Приклад валідації на Swift
// iOS — валідація gap між stopPrice та limitPrice func validateStopLimitPrices(stop: Decimal, limit: Decimal, side: OrderSide) -> ValidationResult { switch side { case .sell: guard limit < stop else { return .error("Лімітна ціна має бути нижчою за ціну активації") } let gap = (stop - limit) / stop if gap < 0.001 { return .warning("Малий зазор — ризик невиконання при різкому русі") } case .buy: guard limit > stop else { return .error("Лімітна ціна має бути вищою за ціну активації") } } return .valid } | Тип ордера | Параметри | Ризики | Виконання |
|---|---|---|---|
| STOP_LOSS_LIMIT | stopPrice, price, quantity | Невиконання при малому gap | Лімітне після тригера |
| STOP_LOSS | stopPrice, quantity | Проковзування ціни | Ринкове після тригера |
| TAKE_PROFIT_LIMIT | stopPrice, price, quantity | Невиконання при швидкому зростанні | Лімітне при досягненні цілі |
Правила валідації різняться для купівлі та продажу:
| Сторона | Умова для лімітної ціни | Типова помилка |
|---|---|---|
| Продаж | limitPrice < stopPrice | limitPrice >= stopPrice |
| Купівля | limitPrice > stopPrice | limitPrice <= stopPrice |
UI для стоп-лімітних ордерів
Як реалізувати UI для стоп-лімітних ордерів?
UI-рішення: розділити на два підрежими «Обмежити збиток» та «Зафіксувати прибуток» з візуальною діаграмою ціни. Показувати стрілку: «Ціна активації → Лімітна ціна виконання». Валідація в реальному часі з підсвічуванням полів — одразу після введення чисел. Використовуйте компоненти з маскою введення, що враховують tick size біржі.
Стоп-ордер в стані очікування (PENDING) має відрізнятися візуально від активних. Мітка «Стоп» або «Умовний», ціна активації — крупно, лімітна — менше. Прогрес-бар «відстань до тригера» як % від поточної ціни — корисний, але опціональний.
При WebSocket-події зміни статусу (executionReport з X=PENDING_CANCEL → FILLED) — відправити push-сповіщення: «Стоп-ордер спрацював: продано 0.5 BTC по 41 200 USDT». Це ключова частина UX: користувач має миттєво дізнаватися про спрацювання.
Обсяг робіт
Що входить в роботу
- Проектування UX: аналіз типових помилок, wireframe екрану створення ордера
- Backend-інтеграція: REST/WebSocket для відправки та відстеження статусів ордерів
- Реалізація валідації цін з урахуванням правил біржі (gap, tick size, мінімальні кроки)
- UI-компоненти: поля введення з форматуванням, візуалізація тригера, статуси
- Push-сповіщення через APNs/FCM при зміні статусу
- Тестування на симуляторах та реальних пристроях (TestFlight / Firebase Distribution)
- Документація: опис логіки та інструкція для QA
Наша команда має 5+ років досвіду в розробці біржових мобільних додатків. Ми реалізували стоп-ордери для 3 криптобірж, обробивши понад 1 млн заявок. Стандартні правила бірж (Binance API)
Терміни: 2–3 дні на MVP з базовою валідацією, відображенням у списку та push-сповіщеннями. Терміни розширення (додаткові типи ордерів, advanced UI) обговорюються індивідуально.
Зв'яжіться з нами для оцінки вашого проекту — ми відповімо протягом дня. Напишіть, щоб отримати консультацію з інтеграції стоп-ордерів. Отримайте консультацію з реалізації стоп-ордерів у вашому додатку — зв'яжіться з нами.
Додаткова інформація: Stop order на Wikipedia.