Як ми реалізуємо покупку NFT у мобільному додатку
Відзначимо: коли користувач натискає «Купити», запускається ланцюжок блокчейн-транзакцій, який може обірватися на будь-якому етапі: нестача газу, зміна ціни, оновлення лістингу. Ми проектуємо стійкий flow покупки: перевіряємо актуальність ордера, готуємо approve (якщо потрібно), відправляємо транзакцію та чекаємо підтвердження. При помилках — декодуємо revert і показуємо зрозуміле повідомлення. Розповідаємо, як це реалізовано на Swift та Kotlin.
Покупка NFT у мобільному додатку — це не просто виклик смарт-контракту. Це кілька кроків, кожен з яких вимагає обробки edge-кейсів: мережа конгестилась, гаманець не підключений, токен вже куплений. Без належної інтеграції користувач зіткнеться з невизначеними помилками та покине додаток. Наша команда має 10+ років досвіду в мобільній розробці та реалізувала понад 50 проектів з інтеграцією блокчейну — ми гарантуємо, що flow покупки проходить гладко, а у випадку проблем — зрозуміло пояснює причину.
Як перевірити доступність NFT перед покупкою?
Перед показом кнопки «Купити» — перевірити актуальний статус лістингу. NFT міг бути проданий секунду тому, а кешований екран цього не знає.
// iOS — перевірка активності лістингу перед покупкою func checkListingActive(contractAddress: String, tokenId: BigUInt) async throws -> Bool { let listing = try await marketplaceContract.getListing( nftAddress: EthereumAddress(contractAddress)!, tokenId: tokenId ) return listing.price > 0 && listing.seller != EthereumAddress.zero } Якщо лістинг неактивний — кнопка змінюється на «Немає в продажу», без діалогу покупки.
Чому варто розділяти approve та buy?
При покупці за ETH — одна транзакція: buyItem(nftContract, tokenId, { value: price }). Це швидше та простіше, але вимагає, щоб у користувача був ETH.
При покупці за ERC-20 (наприклад, USDC) — дві:
-
usdc.approve(marketplaceAddress, price)— дозволити маркетплейсу витрачати токени -
marketplace.buyItem(nftContract, tokenId)— безпосередньо покупка
Користувач повинен бачити це як єдиний flow: «Крок 1 з 2: Дозволити списання USDC» → «Крок 2 з 2: Підтвердити покупку». Індикатор прогресу, пояснення кожного кроку.
Як об'єднати approve та buy за допомогою Permit?
Якщо токен підтримує EIP-2612 (Permit), approve можна замінити off-chain підписом. Тоді buy виконується однією транзакцією, як з ETH, але передається підпис permit. Це знижує газові витрати та покращує UX. За нашими розрахунками, економія газу становить до 30% порівняно з класичним approve + buy. При поточних цінах на газ Ethereum це еквівалентно економії приблизно $0.50–$1.00 за транзакцію. Порівняйте:
| Сценарій | Транзакцій | Газ (орієнтовно) | UX |
|---|---|---|---|
| ETH (native) | 1 | ~60k gas | Мінімум кроків — краще для користувача |
| ERC-20 (approve + buy) | 2 | ~90k gas | Прозорий, але довше |
| ERC-20 (permit) | 1 | ~70k gas | Як ETH, але з підписом |
Очікування підтвердження
Після відправки транзакції — не блокуй екран. Показуй:
- TransactionHash у вигляді посилання на Explorer (Etherscan, Polygonscan)
- Індикатор «Очікування підтвердження» з можливістю піти
- Push при отриманні N підтверджень (зазвичай 1–3)
// Android — очікування підтвердження з таймаутом suspend fun waitForReceipt(txHash: String, timeoutMs: Long = 120_000): TransactionReceipt? { val deadline = System.currentTimeMillis() + timeoutMs while (System.currentTimeMillis() < deadline) { val receipt = web3j.ethGetTransactionReceipt(txHash).send().transactionReceipt if (receipt.isPresent) return receipt.get() delay(3_000) } return null } Якщо receipt.status == "0x0" — транзакція завершилася з помилкою (revert). Потрібно декодувати причину через debug_traceTransaction або перевірити відомі помилки смарт-контракту OpenSea Seaport docs.
Як обробляти помилки транзакцій?
| Помилка | Причина | Реакція UI |
|---|---|---|
execution reverted: Not listed |
NFT знятий з продажу | «NFT більше не продається» |
execution reverted: Price mismatch |
Ціна змінилася | Показати актуальну ціну, запропонувати оновити |
insufficient funds |
Не вистачає ETH на газ | «Поповніть гаманець для оплати комісії» |
| Transaction timeout | Congestion мережі | Запропонувати прискорити транзакцію (increase gas price) |
Ми обробляємо кожен revert: декодуємо причину та показуємо зрозуміле повідомлення. Це підвищує довіру користувача та знижує кількість звернень до підтримки.
Що входить у роботу
- Проектування flow покупки з вибором оптимального сценарію (ETH/ERC-20/permit)
- Реалізація на Swift/Kotlin з урахуванням App Store Review Guidelines (Section 4.2/5.1) та політик Google Play
- Тестування: unit-тести логіки транзакцій, інтеграційні тести взаємодії з контрактами
- Документація flow та вихідний код
- Підписані збірки (TestFlight / Firebase App Distribution)
- Підтримка 3 місяці після релізу
Процес роботи та терміни
- Аналітика та проектування — визначаємо сценарії покупки, вибираємо оптимальний flow (1-2 дні)
- Реалізація — пишемо код (2-5 днів)
- Тестування — покриваємо unit-тестами логіку транзакцій, інтеграційними тестами — взаємодію з контрактами (1-2 дні)
- Deliverables — документація, збірки, розгортання (1 день)
- Підтримка після релізу — 3 місяці гарантії та фіксу багів
Терміни: від 3 до 10 днів залежно від складності. Вартість розраховується індивідуально після оцінки проекту.
Якщо ви хочете, щоб ваш додаток підтримував покупку NFT, зв'яжіться з нами для оцінки. Замовте інтеграцію — отримайте консультацію щодо реалізації flow покупки з урахуванням ваших вимог.