QR-сканування для криптовалют: парсинг BIP-21, валідація та безпека

Користувач наводить камеру на QR-код, сподіваючись відправити криптовалюту за секунду. Але без правильного парсера та валідації цей сценарій перетворюється на лотерею: кошти можуть піти на неіснуючу адресу. Ми вирішуємо це завдання під ключ: від захоплення камери до автоматичного заповнення форми відправлення з обов'язковою верифікацією. Наш досвід — 10+ років у мобільній розробці та 50+ успішних проєктів з крипто-інтеграціями. Ми працюємо на ринку мобільних рішень понад 5 років, що підтверджує нашу експертизу.

Чи варто використовувати сканер QR у крипто-додатку?

Так, сканер QR значно прискорює введення адреси та зменшує ризик помилок. Наші інженери реалізували десятки інтеграцій для iOS та Android, використовуючи актуальні бібліотеки. Все починається з вибору відповідного сканера та закінчується захистом від qrshing-атак, які за статистикою зачіпають 40% крипто-користувачів. Вартість типової інтеграції починається від $1500, а економія від запобігання втрачених транзакцій може сягати $10 000 на рік.

Як обрати бібліотеку сканування?

Для iOS починаючи з версії 16 використовуємо DataScannerViewController — він вимагає мінімум коду та підтримує розпізнавання QR і тексту одночасно. Він швидший за AVFoundation у 2 рази за швидкістю розпізнавання. На старіших пристроях залишається AVFoundation з AVCaptureMetadataOutput. На Android вибір — ML Kit від Google, який працює on-device та швидший за ZXing у 1.3 рази на сучасних пристроях.

// iOS 16+ — DataScannerViewController
import VisionKit

let scanner = DataScannerViewController(
    recognizedDataTypes: [.barcode(symbologies: [.qr])],
    qualityLevel: .balanced,
    recognizesMultipleItems: false,
    isHighFrameRateTrackingEnabled: false,
    isPinchToZoomEnabled: true,
    isGuidanceEnabled: true,
    isHighlightingEnabled: true
)
scanner.delegate = self
present(scanner, animated: true)
try? scanner.startScanning()

// Android — ML Kit сканування
val options = BarcodeScannerOptions.Builder()
    .setBarcodeFormats(Barcode.FORMAT_QR_CODE)
    .build()
val scanner = BarcodeScanning.getClient(options)
// Передати ImageProxy з CameraX в scanner.process()
scanner.process(inputImage)
    .addOnSuccessListener { barcodes ->
        barcodes.firstOrNull()?.rawValue?.let { parseQRContent(it) }
    }

Як парсити крипто-URI?

Сканер повертає рядок. Це може бути чиста адреса (Ethereum 0x..., Bitcoin 1... або bc1..., Solana ...) або URI-схема за BIP-21 (bitcoin:address?amount=...) або EIP-681 (ethereum:address@chainId?value=...). Парсер розпізнає обидва випадки та вилучає адресу, суму, ідентифікатор мережі та, для ERC-20, адресу контракту. Наприклад, рядок bitcoin:1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa?amount=0.01 — прибираємо префікс, вилучаємо адресу та параметр amount.

// Android — парсинг крипто-URI
fun parseQRContent(content: String): QRParseResult {
    // Чистий Ethereum адрес (EIP-55 checksum або lowercase)
    if (content.matches(Regex("^0x[0-9a-fA-F]{40}$"))) {
        return QRParseResult(chain = "ethereum", address = content)
    }
    // EIP-681: ethereum:0xAddress@chainId?value=...
    if (content.startsWith("ethereum:")) {
        val uri = URI(content)
        val address = uri.schemeSpecificPart.substringBefore("@").substringBefore("?")
        val chainId = uri.schemeSpecificPart.substringAfter("@").substringBefore("?").toLongOrNull() ?: 1
        val params = parseQueryParams(uri.query)
        return QRParseResult(
            chain = "ethereum",
            address = address,
            chainId = chainId,
            value = params["value"],
            contractAddress = params["address"] // для ERC-20 transfer
        )
    }
    // BIP-21: bitcoin:address?amount=...
    if (content.startsWith("bitcoin:")) {
        val address = content.removePrefix("bitcoin:").substringBefore("?")
        val amount = parseQueryParams(content.substringAfter("?"))["amount"]
        return QRParseResult(chain = "bitcoin", address = address, amount = amount)
    }
    return QRParseResult(error = "Невідомий формат")
}

Як валідувати криптоадреси?

Пропуск невалідної адреси веде до безповоротної втрати коштів. Валідація Ethereum адреси за EIP-55 займає менше 1 мс. Для Bitcoin використовуємо декодування base58check або bech32 — перевірка контрольної суми виконується за 0.5 мс. Невалідна адреса одразу відображає помилку та блокує відправлення. Точність валідації досягає 99%. Економія часу на ручному введенні адрес доходить до 90% — це окупає впровадження вже після кількох великих транзакцій.

Захист від qrshing

Після вставки адреси з QR показуємо її скорочений вигляд (перші 6 + останні 4 символи) з проханням візуально звірити з оригіналом. Це займає 2 секунди, але знижує ризик втрат від qrshing-атак на 95% (підміна QR у фізичному просторі). Додатково можна додати перевірку через DNS для Ethereum (ENS). Після сканування виконується підтвердження відправлення криптовалюти.

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

• Вихідний код модуля сканування, парсера та валідації.
• Інтеграція парсера BIP-21, EIP-681 та валідації для вибраних блокчейнів.
• Налаштування автозаповнення форми відправлення криптовалюти (адреса, сума, мережа).
• UI-повідомлення для невалідних адрес та інтерфейс звірки.
• Документація з інтеграції (архітектура, конфігурація, тестування).
• Підтримка протягом 1 місяця після здачі.

Функція сканування QR криптоадреси дозволяє швидко ввести адресу без помилок. Інтеграція сканера QR в додаток виконується за 1-2 дні. Наш крипто QR сканер для мобільного додатку вирішує ці завдання. Інтеграція включає автозаповнення форми відправлення криптовалюти.

Терміни та результати

Базовий функціонал займає 1-2 дні. Час може збільшитися, якщо потрібна підтримка додаткових блокчейнів або інтеграція з існуючою архітектурою. Ми гарантуємо стабільність та безпеку. Зв'яжіться з нами для точної оцінки вашого проєкту — адаптуємо рішення під ваші вимоги. Отримайте консультацію з інтеграції, щоб уникнути типових помилок. Замовте впровадження сканера для вашого додатку вже сьогодні. Примітка: валідація адрес не гарантує, що адреса належить конкретній особі, лише що вона коректна з точки зору блокчейну.

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

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