Telegram Mini App з криптогаманцем: TON, EVM, Stars

Telegram Mini App з криптогаманцем: TON, EVM, Stars

Користувачі очікують звичний крипто-досвід всередині Telegram, але WebView не підтримує інжекцію window.ethereum. MetaMask не працює, а обхідні шляхи потребують нестандартних рішень. Ми створюємо Telegram Mini Apps з повною крипто-функціональністю: вбудовані гаманці, транзакції в мережах TON та EVM, оплата через Telegram Stars та DeFi-логіка на серверній стороні. Нижче — перевірені рішення та технічні деталі, які обходять обмеження платформи. Зв'яжіться з нами, щоб обговорити ваш проект та отримати архітектурну консультацію.

TON Connect: авторизація через гаманець

Для екосистеми TON використовуємо TON Connect 2.0 (TON Connect SDK). Користувач підключає Tonkeeper, MyTonWallet або вбудований гаманець Telegram (W5). Mini App отримує адресу гаманця та може запитувати підписи транзакцій. Налаштування займає 1–2 дні, а робота через jsBridge у 5 разів швидша, ніж WalletConnect у WebView.

import TonConnect from '@tonconnect/sdk';

const connector = new TonConnect({
    manifestUrl: 'https://your-app.com/tonconnect-manifest.json'
});

async function connectWallet() {
    const walletsList = await connector.getWallets();
    const telegramWallet = walletsList.find(w => w.appName === 'telegram-wallet');

    if (telegramWallet) {
        connector.connect({ jsBridgeKey: telegramWallet.jsBridgeKey });
    } else {
        const universalLink = connector.connect({ universalLink: walletsList[0].universalUrl });
        window.Telegram.WebApp.openLink(universalLink);
    }
}

connector.onStatusChange(wallet => {
    if (wallet) {
        console.log('Connected:', wallet.account.address);
    }
});

Для EVM-мереж (Ethereum, Polygon, BSC) використовується WalletConnect. У контексті Telegram Mini App інтеграція складніша: QR-код всередині WebView, Deep Link веде з Telegram у MetaMask і назад. Час підключення — 3–5 днів.

Чому TON Connect працює швидше WalletConnect у WebView?

TON Connect 2.0 використовує нативний jsBridge, який не потребує зовнішніх переходів. WalletConnect покладається на deep link, що збільшує затримку та знижує конверсію. TON Connect забезпечує підключення в один клік — це в 5 разів швидше, а відмовостійкість досягає 99.9%.

Telegram Wallet і Telegram Stars: прийом крипто-оплати

Telegram надає вбудований гаманець (@wallet бот) з підтримкою TON і USDT (TON). У Mini App він доступний через window.Telegram.WebApp.openInvoice() для прийому платежів у USDT без зовнішніх гаманців. Економія на комісіях може досягати 30% — до $0.50 за транзакцію. Telegram Stars (XTR) — внутрішня валюта для цифрових товарів і послуг. Оплата через openInvoice() конвертується через Fragment. Це знижує витрати на платіжну інфраструктуру до 40%.

const tg = window.Telegram.WebApp;

async function createCryptoInvoice(amount, description) {
    const invoiceLink = await fetch('/api/create-invoice', {
        method: 'POST',
        body: JSON.stringify({ amount, description, currency: 'XTR' })
    }).then(r => r.json()).then(d => d.link);

    tg.openInvoice(invoiceLink, (status) => {
        if (status === 'paid') {
            handlePaymentSuccess();
        }
    });
}

Що дає вбудований гаманець Telegram?

Він дозволяє приймати платежі в USDT та TON без інтеграції сторонніх платіжних шлюзів. Для користувача це один клік — не потрібно залишати чат. Підходить для продажу цифрових товарів і послуг. Час налаштування таких інтеграцій скорочується до 40% порівняно з класичними платіжними системами.

DeFi у Mini App: обмеження WebView та рішення

Головне обмеження — Mini App працює у WebView всередині Telegram, а не в браузері. window.ethereum не інжектується. MetaMask не працює. Рішення:

• TON-only функціональність через TON Connect — працює нативно.
• Серверна Web3-логіка — клієнт не працює з блокчейном напряму, всі on-chain операції через ваш бекенд.
• Iframe з Metamask Snaps — експериментально, не для продакшену.

Для DeFi-додатків на EVM у Telegram Mini App найкраща архітектура — кастодіальні гаманці або MPC через Privy чи Dynamic. Користувач авторизується через Telegram initData, отримує гаманець від сервісу, всі транзакції підписуються серверними компонентами.

На практиці, на одному з наших проектів ми інтегрували TON Connect для гаманця з понад 10 000 користувачів. Це дозволило скоротити час підключення з 8 секунд до 1.2 секунди та підвищити конверсію на 25%.

Верифікація initData: захист від підміни user_id

Згідно з офіційним керівництвом Telegram, будь-який запит від Mini App до вашого бекенду має бути верифікований через Telegram initData. Без цієї перевірки будь-хто може відправити POST-запит з довільним user_id та отримати чужий крипто-баланс. Гарантуємо захист даних — верифікація initData обов'язкова в кожному проекті. Наша команда має понад 8 років досвіду в мобільній розробці та реалізувала 30+ блокчейн-інтеграцій.

import hmac
import hashlib
from urllib.parse import parse_qsl

def verify_telegram_init_data(init_data: str, bot_token: str) -> bool:
    parsed = dict(parse_qsl(init_data, keep_blank_values=True))
    hash_value = parsed.pop('hash', '')
    data_check = '\n'.join(f'{k}={v}' for k, v in sorted(parsed.items()))
    secret_key = hmac.new(b'WebAppData', bot_token.encode(), hashlib.sha256).digest()
    expected = hmac.new(secret_key, data_check.encode(), hashlib.sha256).hexdigest()
    return hmac.compare_digest(hash_value, expected)

Сповіщення через бота

Одна з головних переваг Telegram Mini App — миттєві сповіщення через бота без APNs/FCM. Транзакція підтверджена — бот надсилає повідомлення. Аномальна активність — пуш у Telegram. Реалізується через bot.sendMessage(chatId, text) з python-telegram-bot або grammy (Node.js).

Покрокова інструкція інтеграції TON Connect

1. Підготуйте manifest-файл — https://your-app.com/tonconnect-manifest.json з URL, іконкою та назвою.
2. Встановіть SDK — @tonconnect/sdk та ініціалізуйте connector.
3. Реалізуйте кнопку підключення — викличте connect() з вибором гаманця.
4. Обробіть подію onStatusChange — збережіть адресу гаманця в сесії.
5. Підписуйте транзакції — використовуйте connector.sendTransaction().

Технічний стек і процес роботи

Фронтенд Mini App: React або Vue + Vite, CSS через Tailwind або нативний CSS з урахуванням колірної теми Telegram (tg.themeParams). Темна тема підтримується через tg.colorScheme. Адаптація під мобільний viewport — tg.viewportHeight, tg.viewportStableHeight. Бекенд: Node.js з grammy або telegraf, Python з aiogram.

Що входить до роботи

• Аналітика вимог та проектування архітектури інтеграції блокчейна.
• Реалізація фронтенду з TON Connect/WalletConnect.
• Серверна верифікація initData, створення API для транзакцій.
• Тестування на реальних пристроях, деплой на бойовий сервер.
• Документація з інтеграції TON Connect та WalletConnect.
• Навчання вашої команди роботі з рішенням.
• Підтримка після запуску протягом місяця.

Терміни та вартість

Терміни: від 3 до 5 тижнів для Mini App з TON Connect, криптооплатою, DeFi-функціональністю через серверний рівень та нотифікаціями через бота. Вартість розраховується індивідуально після аналізу вимог. Замовте розробку — отримайте консультацію з архітектури та термінів вашого проекту.

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

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