Розробка мобільного додатку для крипто-заощаджень

Користувач хоче покласти USDC на депозит і отримувати 8% річних у крипті. Yield farming і стейкінг — популярні способи пасивного доходу. Насправді перед нами вибір: кастодіальна платформа з централізованим управлінням, інтеграція з DeFi-протоколом (Aave, Compound, Yearn) або ліквідіті-пули (Uniswap V3, Curve). Архітектурне рішення приймається на самому початку і визначає весь стек розробки. Ми вже реалізували проєкти за всіма трьома сценаріями — розповімо про нюанси.

Як обрати архітектуру для крипто-заощаджень?

Кастодіальна. Користувач переказує крипту на гаманець платформи, платформа керує капіталом сама. Мобільний додаток — класичний фінтех: REST API, JWT-авторизація, баланс, історія транзакцій, виведення коштів. Жодного Web3 на клієнті. Простий у розробці, потребує ліцензій та compliance.

DeFi-інтеграція. Користувач напряму взаємодіє зі смарт-контрактом через власний некастодіальний гаманець. Мобільний додаток стає інтерфейсом до протоколу. Потрібен Web3-стек: web3.swift / web3j, WalletConnect v2 для підпису транзакцій. Користувач платить gas самостійно.

Гібридна. Платформа тримає smart account (Account Abstraction / ERC-4337), користувач не взаємодіє з ключами напряму. Платформа спонсорує газ через Paymaster. Найкращий UX із трьох варіантів — користувач не знає про блокчейн.

Чому гібридний підхід кращий за кастодіальний у 2 рази за конверсією?

За нашими даними, гібридні додатки краще кастодіальних в 1.5–2 рази за конверсією в депозит. При цьому UX такий же простий. З іншого боку, DeFi-інтеграція без абстракції акаунту відлякує 70% новачків через необхідність купувати ETH для газу. Гібрид — золота середина. Наприклад, в одному проєкті користувачі економили до $0.50 на кожній транзакції завдяки спонсоруванню газу.

APY дашборд та real-time дохідність

Головний екран додатку — поточний баланс + накопичені відсотки. Накопичені відсотки потрібно оновлювати в реальному часі. Це UX-трюк: користувач бачить, як баланс зростає, поки дивиться на екран. При депозиті $10 000 щомісячний дохід при 8% APY становитиме близько $67 — ці цифри відображаються у вигляді анімованого графіка. Для порівняння, при депозиті $5 000 у Yearn USDC Vault з APY 9% щомісячний дохід становитиме близько $37.

Для DeFi-протоколів Aave V3 відсотки нараховуються безперервно через aToken — токен, баланс якого автоматично зростає. Рахуємо поточний баланс через AToken.balanceOf(userAddress), виклик кожні 30 секунд через JSON-RPC:

// Отримання актуального балансу aToken через web3.swift
class AaveBalanceService {
    let web3 = Web3(rpcURL: "https://mainnet.infura.io/v3/YOUR_KEY")

    func fetchATokenBalance(userAddress: EthereumAddress, aTokenAddress: EthereumAddress) async throws -> BigUInt {
        let contract = try web3.eth.Contract(json: aTokenABI, abiKey: nil, address: aTokenAddress)
        let result = try await contract["balanceOf"]?(userAddress).call()
        return result?["_balance"] as? BigUInt ?? 0
    }
}

На UI: баланс у USD з перерахунком за поточним курсом. Курс — WebSocket від Binance або CoinGecko з кешуванням на 15 секунд.

Стратегії дохідності та Vault

Yearn Finance-подібні продукти пропонують «стратегії» — автоматичне перекладання коштів між протоколами для максимального APY. У мобільному додатку це список вкладів із різним ризиком та дохідністю:

Impermanent Loss для LP-позицій — окремий екран з калькулятором. Користувач повинен розуміти ризики перед входом у ліквідіті-пул. Без цього ми не випускаємо додаток — це обов'язкова частина нашої роботи.

Виведення коштів та lock-up періоди

Деякі стратегії мають lock-up — кошти не можна вивести раніше визначеної дати. Це потрібно показувати явно до депозиту. На екрані виведення — прогрес-бар з часом, що залишився, та датою розблокування.

Часткове виведення — важлива функція. Користувач вказує суму виведення, додаток розраховує кількість shares для withdraw(shares, receiver, owner) за ERC-4626 стандартом:

// ERC-4626 Vault: конвертація assets → shares
const shares = await vault.convertToShares(assetsToWithdraw);
const tx = await vault.withdraw(assetsToWithdraw, userAddress, userAddress);

Push-сповіщення та аналітика

Щотижневий summary: скільки зароблено за тиждень, поточний APY. Push при значній зміні APY (>2%). Нагадування при наближенні дати розблокування.

Firebase Analytics для відстеження воронки — від реєстрації до першого депозиту. Це допомагає знаходити проблемні кроки в UX.

Безпека

Що входить у нашу роботу

Ми готуємо повний пакет deliverables:

• Технічна документація: вибір архітектури, ERD, схема інтеграції з протоколами
• Вихідний код мобільних додатків під iOS та Android з коментарями
• Серверна частина (баланси, APY, історія) на Node.js/Python
• Інтеграція з обраними DeFi-протоколами (Aave, Compound, Uniswap та ін.)
• Push-сповіщення через FCM/APNs
• Допомога з публікацією в App Store та Google Play (проходження рев'ю)
• Навчання команди замовника роботі з кодом та інфраструктурою
• Підтримка протягом 1 місяця після релізу

Ми маємо 5 років досвіду розробки DeFi-рішень та реалізували понад 20 мобільних крипто-проектів. Наш мобільний додаток крипто-заощадження — це yield farming мобільний, стейкінг додаток та DeFi інтеграція мобільна в гібридній архітектурі крипта. Вартість розробки MVP починається від $50,000, а економія на газі може сягати $0.50 на транзакції, що при 1000 транзакціях дає $500 економії. Ми гарантуємо якість коду та безпеку коштів завдяки багаторічному досвіду та сертифікованим аудитам.

Етапи та строки

1. Аналітика та вибір архітектури (1–2 тижні)
2. Проєктування та серверна частина (2–3 тижні)
3. DeFi-інтеграція (якщо потрібно) (2–4 тижні)
4. Мобільний клієнт iOS + Android (4–6 тижнів)
5. Сповіщення та KYC (1–2 тижні)
6. Аудит смарт-контрактів (1 тиждень)

8–14 тижнів залежно від архітектури. DeFi-інтеграція з кількома протоколами та Vault-стратегіями — ближче до 14 тижнів. Вартість розраховується індивідуально після аналізу вимог. Отримайте консультацію з архітектури вже сьогодні — зв'яжіться з нами, оцінимо ваш проєкт за один робочий день.

Платежі в мобільних додатках: 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 місяці.

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