Как мы реализуем покупку 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 покупки с учётом ваших требований.