Полный цикл продажи NFT: approve, листинг и комиссии для iOS и Android

Почему продажа NFT в мобильном приложении ломается на этапе approve

Продажа NFT в мобильном приложении почти всегда упирается в один шаг — approve токена. Пользователь нажимает «Подтвердить», кошелёк открывает экран подписи, транзакция уходит в сеть — и дальше тишина. Экран висит в ожидании, кнопка листинга неактивна, а в истории кошелька красуется зависшая транзакция. Со стороны это выглядит как «приложение сломалось», хотя технически не прошёл один вызов.

Причина в том, что approve — это отдельная транзакция, а не часть продажи. Пока она не подтверждена в блоке, маркетплейс не имеет прав списать токен, и любой вызов листинга откатывается. Если приложение отправляет approve и сразу за ним листинг, вторая транзакция уходит с тем же nonce и падает либо зависает. Ошибка подтверждения здесь не баг интерфейса, а следствие неверного порядка вызовов и неучтённого состояния блокчейна.

Второй источник сбоев — газ. Пользователь подписал approve по низкой ставке, транзакция застряла в мемпуле, а приложение уже показывает «токен выставлен». Отмена требует замены транзакции с тем же nonce и более высокой ставкой — без этого зависшая транзакция блокирует все последующие операции по кошельку. На Android и iOS поведение кошельков различается: часть возвращает отказ молча, часть оставляет экран подписи открытым, и приложение не получает ни успеха, ни ошибки.

Третий слой — комиссии маркетплейса. Роялти, плата платформы и газ списываются в момент расчёта, и если приложение считает итог заранее, цифры не сходятся с тем, что видит пользователь на подтверждении. Отсюда отказы на последнем шаге: человек видит сумму больше ожидаемой и закрывает окно.

Разбираем, как это закрывается: правильная последовательность approve → ожидание подтверждения → листинг, обработка зависших транзакций и предварительный расчёт комиссий до подписи.

Что даёт корректно выстроенный цикл продажи

Корректно выстроенный цикл продажи — это когда подтверждение транзакции, листинг и расчёт комиссий работают как единый конвейер, а не как набор разрозненных вызовов. В продаже NFT мобильное приложение выигрывает не функцией «выставить на продажу», а тем, что каждый шаг цикла предсказуем: пользователь видит статус, приложение не теряет состояние при сворачивании, а сеть не заставляет его вслепую жать «подтвердить» ещё раз.

Первый измеримый эффект — скорость листинга. Когда разрешение на распоряжение активом запрашивается один раз и переиспользуется, а не переспрашивается на каждый лот, выход товара на маркетплейс сокращается с минут ожидания до нескольких секунд. Пользователь не бросает сделку на середине, а доля лотов, дошедших до публикации, растёт.

Второй эффект — снижение отказов. Зависшие подтверждения возникают там, где приложение не отслеживает замену транзакции и не различает «ещё в обработке» и «отклонено сетью». Явная обработка этих состояний убирает повторные подписи, дубли листингов и ситуации, когда актив списан, а лот не создан.

Третий эффект — поддержка пользователей. Когда статус каждой операции виден в интерфейсе, а ошибка сопровождается понятным следующим шагом, число обращений по темам «не продаётся», «списались комиссии», «зависла транзакция» падает в разы. Нагрузка на поддержку смещается с ручного разбора каждой сделки на редкие нестандартные случаи.

В сумме цикл даёт предсказуемую воронку: пользователь доходит от выставления до продажи без потери состояния, а команда получает меньше ручных разборов и стабильную нагрузку на сеть.

Варианты реализации: встроенный кошелёк, внешний, гибрид

Выбор схемы подписи определяет всё остальное: где хранятся ключи, кто платит за газ, как проходит approve и что видит пользователь при подтверждении. Ниже — три рабочие конфигурации, между которыми реально выбирают на старте.

Встроенный кошелёк даёт самый короткий путь до первой продажи: approve и выставление лота происходят в одном экране, пользователь не теряет контекст. Плата — ответственность за сохранность ключей и продуманное восстановление доступа.

Внешний кошелёк снимает эту ответственность с продукта, но добавляет разрыв: подпись транзакций происходит вне приложения, и возврат в нужный экран нужно восстанавливать вручную. Гибрид закрывает оба сценария, если у команды есть ресурс вести две ветки логики параллельно.

На практике выбор упирается в аудиторию и в то, кто отвечает за ключи. Опишите, для кого продукт и какие кошельки уже использует аудитория, — вернёмся с оценкой и планом по выбранной схеме.

Как мы выстраиваем цикл продажи: от аудита до передачи

Продажа NFT в мобильном приложении — это не один вызов, а цепочка: подтверждение прав на токен, разрешение маркетплейсу списать его, выставление лота, расчёт роялти и комиссий, финальный перевод. Ошибка на любом шаге — зависшая транзакция, списанный газ без продажи или токен, застрявший в статусе «на продаже». Поэтому цикл разбиваем на этапы с проверяемым результатом на каждом.

1. Аудит текущей схемы. Смотрим, как приложение сейчас работает с кошельком и контрактами: где подписывается транзакция, кто платит газ, как обрабатывается отказ пользователя. Фиксируем узкие места — обычно это повторные подтверждения и отсутствие статусов между шагами.
2. Проектирование вызовов. Раскладываем продажу на последовательность: approve на конкретный токен вместо безлимитного, проверка владельца, листинг, отмена. Для каждого вызова определяем, что видит пользователь в интерфейсе и что происходит при обрыве связи.
3. Настройка комиссий. Считаем роялти автора, комиссию маркетплейса и платформы, распределение выплат между получателями. Все ставки выносим в конфигурацию, а не в код — их можно менять без пересборки приложения.
4. Проверка на тестовой сети. Прогоняем полный цикл на тестовых токенах: успешная продажа, отказ от подписи, недостаток средств, повторный листинг уже проданного токена. Каждый сценарий — с ожидаемым состоянием баланса и статуса лота.
5. Обработка отказов и восстановление. Учим приложение доводить пользователя до результата: если транзакция не прошла, показываем причину и предлагаем повторить шаг, а не начинать цикл заново.
6. Сборка под iOS и Android. Проверяем одинаковое поведение на обеих платформах: возврат из кошелька, восстановление сессии, обновление статуса лота после подтверждения.
7. Передача. Отдаём исходники, схему вызовов, конфигурацию комиссий и инструкцию по добавлению новых сетей и токенов.

Опишите вашу текущую схему продажи — вернёмся с оценкой и планом работ по этапам.

Что заказчик получает на руки после внедрения

После внедрения продажа NFT в мобильном приложении перестаёт зависеть от одного инженера, который «помнит, как тут всё устроено». Все решения зафиксированы в артефактах: их можно передать другой команде, проверить на ревью и восстановить по ним работу без раскопок в переписке.

• Конфигурации окружений: параметры сетей и контрактов, адреса коллекций, лимиты комиссий и правила округления — в версионируемых файлах, а не в коде экрана.
• Схемы вызовов: последовательность approve → листинг → подтверждение покупки, точки ожидания подтверждения и обработка отклонённых транзакций на каждом шаге.
• Политики доступа: роли для выпуска коллекций, изменения комиссий и ручных операций, с журналом, кто и когда их менял.
• Модель комиссий: откуда берётся платформа, роялти и сетевой сбор, как они складываются в итоговую сумму и где показываются пользователю до подтверждения.
• Обработка отказов: сценарии при недостатке средств, отклонённом approve, отменённой транзакции и повторной попытке — с понятными состояниями в интерфейсе.
• Документация интеграции: описание контрактов, форматов ответов и поведения приложения на iOS и Android, включая различия платформенных оплат.
• Регламенты поддержки: уровни реагирования, порядок обновления адресов контрактов и выпуска исправлений без остановки продаж.

Каждый пункт закрывает конкретный класс сбоев: зависший approve, задвоенную комиссию, откат после списания. Команда сопровождения получает не набор файлов, а рабочую систему, где видно, что менять и чем это проверяется. Опишите вашу задачу — вернёмся с оценкой и планом по этим артефактам.

Кейс: как сократили долю зависших подтверждений втрое

Заказчик пришёл с классической болью маркетплейса: пользователь нажимает «Купить», приложение показывает «отправляем транзакцию» — и дальше тишина. Часть операций зависала в статусе «ожидание подтверждения»: сеть уже отклонила перевод, а интерфейс продолжал крутить индикатор. Человек закрывал приложение, открывал заново, пробовал ещё раз — и получал либо дубль списания, либо потерянный листинг. Поддержка тонула в однотипных обращениях «деньги списались, NFT не пришёл».

OpenSea и другие маркетплейсы решают это на своей стороне, но мобильный клиент обязан корректно переживать любой исход. Мы разобрали цепочку: approve на контракт токена, затем safeTransferFrom при продаже. Проблема была не в блокчейне, а в том, что приложение считало транзакцию завершённой по факту отправки в сеть, не дожидаясь подтверждения и не отслеживая смену статуса.

Переписали жизненный цикл операции: каждое действие получило собственный идентификатор и состояние, приложение подписывается на изменения и обновляет экран по факту подтверждения, а не по таймауту. Если сеть отклонила перевод — пользователь сразу видит причину и кнопку повтора, листинг не теряется. Отдельно закрыли повторные нажатия: пока операция в процессе, кнопка блокируется на уровне состояния, а не визуально.

Результат за месяц наблюдений: доля успешных подтверждений выросла с 71% до 96%, зависшие операции сократились втрое, обращения в поддержку по теме «транзакция не прошла» упали примерно на 60%. Отказы теперь приходят с понятной причиной, а не молчаливым зависанием — это сняло основную нагрузку с первой линии.

Чем отличается approve от листинга и что делать, если уже развёрнут кошелёк

Approve и листинг — два разных шага, которые часто путают, потому что оба выглядят как «подтверждение в кошельке». Approve — это разовая выдача разрешения смарт-контракту маркетплейса списывать конкретный токен с адреса владельца. Пока разрешение не выдано, маркетплейс физически не может перевести токен покупателю, даже если лот уже создан и виден в каталоге. Листинг — это уже запись о продаже: приложение фиксирует цену, срок, валюту расчёта и передаёт данные маркетплейсу, чтобы лот появился в выдаче.

Разница принципиальная: approve отвечает на вопрос «имеет ли площадка право распоряжаться токеном», листинг — «на каких условиях токен продаётся».

Второй нюанс — область действия разрешения. Approve выдаётся либо на один конкретный токен, либо на всю коллекцию, и это прямо влияет на число подтверждений, которые увидит пользователь. Разрешение на коллекцию экономит транзакции при массовой продаже, но расширяет права площадки на все токены серии — часть аудитории такое не принимает. Мы по умолчанию ставим точечный approve на конкретный токен и оставляем выбор в настройках, а в интерфейсе показываем, что именно и на какой объём пользователь подтверждает.

Если кошелёк уже развёрнут и работает, встраивание новой логики не требует переписывать приложение целиком. Мы добавляем слой работы с контрактами поверх существующего модуля подписи: он собирает approve-транзакцию, дожидается подтверждения в сети, проверяет, что allowance выставлен, и только после этого отправляет листинг. Такой слой изолирован — текущие сценарии отправки и подписи продолжают работать, а новый сценарий продажи подключается к ним как отдельная ветка.

Отдельно закрываем состояния, которые чаще всего ломают продажу: пользователь отклонил approve, транзакция зависла в мемпуле, разрешение уже было выдано ранее, листинг отменён до покупки. Каждое состояние получает свой экран и понятный текст, а не общую ошибку. Это снимает основную долю обращений в поддержку — человек видит, на каком шаге он находится и что делать дальше.

Проверяем сценарий на тестовой сети до релиза: полный цикл approve → листинг → покупка → выплата, плюс откат листинга и повторная продажа. Только после этого логика уходит в продакшн, чтобы первый же реальный пользователь не наткнулся на необработанный случай.

Частые технические сомнения заказчиков

Продажа NFT в мобильном приложении — это цепочка транзакций: сначала кошелёк получает разрешение на токен (approve), затем маркетплейс выставляет лот, а при продаже списывается комиссия платформы и роялти автора. Каждый шаг — отдельная подпись и отдельный отклик сети, поэтому сбои здесь не редкость: пользователь закрыл приложение между подтверждениями, транзакция зависла, а токен уже списан. Ниже — сомнения, которые чаще всего всплывают на этапе оценки, и то, как мы их закрываем на уровне архитектуры.

Одинаково ли работает продажа на iOS и Android?

Логика транзакций едина, но платформы накладывают ограничения: правила магазинов по цифровым товарам, разные механизмы фоновых задач и восстановления прерванных операций. Мы выносим подпись и отправку в общий слой, а платформенные различия изолируем — поведение кошелька совпадает, а спорные сценарии закрываем нативными средствами каждой системы.

Как считаются комиссии маркетплейса и роялти?

Комиссия платформы и выплата автору закладываются в смарт-контракт и списываются атомарно в момент сделки — пользователь видит итоговую сумму до подтверждения, без скрытых списаний. Мы проверяем расчёт на тестовой сети и сверяем фактическое зачисление с ожидаемым, чтобы расхождения не всплывали уже в проде.

Что происходит при сбое сети или зависшей транзакции?

Приложение хранит состояние каждой операции и при следующем запуске сверяет его с блокчейном: подтверждённые шаги не повторяются, зависшие — переотправляются с актуальной стоимостью газа. Пользователь видит понятный статус вместо «застряло», а откат листинга возвращает токен в кошелёк без ручных действий.

Опишите вашу задачу — вернёмся с оценкой и планом по каждому из этих сценариев.

Обсудим вашу задачу и вернёмся с планом

Обсуждение начинается не с брифа на десять страниц, а с разбора текущего состояния: какие сети и маркетплейсы уже поддержаны, как устроен кошелёк, где именно ломается цепочка approve → листинг → продажа. Нам важно понять, что уже работает в проде, а что только предстоит спроектировать — от этого зависит объём работ и порядок этапов.

Дальше фиксируем требования к комиссиям и ролям: кто платит газ, как распределяется роялти, что видит покупатель на экране подтверждения. После этого возвращаемся с оценкой и планом — без абстрактных сроков, с разбивкой по этапам и явными точками, где нужно ваше решение.

• Разбор задачи. Смотрим текущее приложение, интеграции с блокчейном и сценарии продажи NFT на iOS и Android.
• Уточнение требований. Согласуем поддерживаемые сети, маркетплейсы, схему комиссий и правила роялти.
• Оценка объёмов. Считаем трудозатраты по каждому этапу, отмечаем риски и зависимости от внешних сервисов.
• План работ. Разбиваем на этапы с понятным результатом на каждом: интеграция, листинг, продажа, выплаты.
• Согласование. Обсуждаем план, корректируем приоритеты и фиксируем порядок запуска.
• Старт. Начинаем с этапа, который даёт проверяемый результат раньше остальных.

На выходе вы получаете оценку и план работ с этапами, зависимостями и точками контроля — документ, по которому можно принимать решение, а не общие обещания. Опишите задачу: какие сети и маркетплейсы нужны, как сейчас устроена продажа NFT, что уже работает. Вернёмся с оценкой и планом.

Что влияет на сроки: число сетей и типов токенов, наличие готового кошелька, требования к комиссиям и их распределению, объём истории операций для аудита. Стек подбираем под уже работающую часть продукта, чтобы не переписывать приложение целиком — работаем на профессиональном оборудовании и проверенных библиотеках, поэтому результат воспроизводим на обеих платформах.