Незачисленный депозит jetton иногда связан с отсутствующим уведомлением, хотя токены дошли до токен-кошелька сервиса. В стандартной схеме forward_ton_amount задаёт нативную сумму для сообщения transfer_notification; при нуле уведомление не отправляется. Сначала проверьте поступление и цепочку сообщений, затем уточните у получателя порядок разбора. Повторная отправка не является первой диагностикой такого случая.
Разделите движение токена и уведомление
Токеновая часть меняет баланс jetton-кошелька получателя. Уведомление — отдельное сообщение владельцу или сервисному аккаунту. Автоматический учёт может ожидать именно его, чтобы распознать поступление и отнести к заявке. Когда сообщения нет, ожидаемый сигнал обработки отсутствует, но само движение токенов от этого не становится вымышленным. Установите каждое событие самостоятельно.
В стандарте jetton количество токенов отделено от forward_ton_amount; прямо указано, что при нуле уведомление не отправляется. Поэтому успешная отметка раннего этапа не отвечает на весь вопрос зачисления. Прикреплённую нативную монету также нельзя читать как количество полученных жетонов. Названия и единицы этих значений имеют значение при разборе.
Однако по такому объяснению нельзя угадывать реализацию конкретного сервиса. Приём бывает устроен иначе. В руководстве обработки jetton рассматривается процесс на основе уведомлений и рекомендуется совместимая отправка. Требование этого процесса нельзя превращать в универсальное утверждение, что любой перевод без уведомления вообще не доставил токены. Проверяйте фактический остаток и правила получателя.
Составьте цепочку с отдельной строкой для каждого события
| Этап или поле | Что сохранить | На какой вопрос отвечает |
|---|---|---|
| Ожидаемый master | Идентификатор легитимного актива | Переводился ли нужный jetton |
| Принимающий токен-кошелёк | Проверенную связь с владельцем сервиса и master | Дошёл ли токен до нужного контракта |
| Количество jetton | Фактическое токеновое поступление | Сколько единиц доставлено |
| forward_ton_amount | Нативное значение для пересылки | Запрашивалось ли уведомление этой схемы |
| transfer_notification | Наличие, отправителя и результат сообщения | Получен ли ожидаемый сигнал |
| forward_payload | Данные привязки, требуемые сервисом | Можно ли отнести депозит к заявке |
| Внутренняя запись сервиса | Его учёт поступления | Зачислен ли проверенный перевод этому заказу |
В надёжном обозревателе проходите по дереву сообщений, не ограничиваясь сводкой отправителя. Официальная инструкция предлагает проверять принимающее исполнение и итоговое состояние. Сохраните ошибки и возвратные сообщения. Запрошенное уведомление и действительно доставленное уведомление — не одно свидетельство. Если направление видно, но исполнение не завершилось, это нужно прямо указать в обращении.
Ненулевое значение не равно всему бюджету операции
Пересылаемая нативная сумма играет другую роль, чем количество jetton. Для выполнения также нужно достаточное нативное обеспечение обработки и необходимых действий контрактов. Маленькое значение из технического примера нельзя подставить вместо полной оценки отправки. Обратное тоже верно: увеличение постороннего поля комиссии не доказывает, что кошелёк правильно включил уведомление в инструкцию.
Получатель может публиковать требования, которые поддерживаемый кошелёк обычно выполняет сам. Следуйте им через официальный способ отправки. Если приложение показывает расширенные параметры, сначала уточните единицы и действие каждого. Не меняйте сырое содержимое по совету из комментария лишь из-за слова TON в названии поля. Хорошая инструкция должна объяснять, к какой части перевода относится настройка.
Комментарий депозита — ещё один самостоятельный элемент. Доставленное уведомление без нужных данных заказа может не дать выполнить привязку. Текст в заметке кошелька не доказывает, что он оказался в ожидаемом forward_payload. Сохраните исходные требования и сравните их с реальным сообщением. Скриншот предварительного экрана помогает вспомнить намерение, но не заменяет итоговое содержимое отправки.
Сравните два вымышленных депозита
Представим «Осину» и «Кедр»: оба должны передать сервису по 20 единиц одного проверенного jetton. У «Осины» токеновое получение есть, но пересылаемая сумма равна нулю и уведомления нет. У «Кедра» уведомление присутствует, однако номер заказа не соответствует ожидаемому. Оба случая могут выглядеть как незачисленный внутренний баланс, но требуют разных проверок.
Для «Осины» вопрос — способен ли получатель распознать уже состоявшееся поступление по своим правилам. Для «Кедра» исследуются привязка и реальные данные сообщения. Ни один пример не исправляется предположением, что ещё один перевод на 20 решит проблему. Он может создать второе незачисленное получение или повторный платёж. Это учебное сравнение, не описание реальных клиентов.
Отправка нативной монеты позже не редактирует исходную jetton-инструкцию. Она создаёт другую операцию и автоматически не восстанавливает пропущенное сообщение с прежним контекстом. Если проверенный сервис предлагает восстановление, получите его условия по официальному каналу. Неожиданная просьба пополнить адрес сама по себе не подтверждает подлинность процедуры. Сопоставьте её с ответом настоящего получателя.
Задайте поддержке конкретный вопрос об учёте
- Сохраните номер заказа, исходную отправку, ожидаемый master и адрес владельца-получателя.
- Сначала проверьте связь принимающего токен-кошелька и фактическое поступление.
- Найдите уведомление, его пересылаемую сумму и ошибки. Отсутствие сообщения отметьте явно.
- Сравните данные привязки с первоначальными инструкциями.
- Спросите официальный сервис, распознаёт ли он это поступление и каков поддерживаемый процесс разбора.
- Учитывайте возможную стоимость и новое действие отдельно от доказательств. Не отправляйте повторно до выяснения учёта первой суммы.
Полезное обращение сообщает о проверенном токеновом поступлении, содержит ссылку на цепочку и указывает отсутствие либо ошибку уведомления. Оно не сводится к требованию доверять зелёной надписи отправителя. Получатель сможет разделить исполнение сети, требование к сообщению и внутреннюю привязку. Ручной возврат, зачисление и сроки обещать за него нельзя: это его процесс и зона контроля.
Отдельный вопрос маршрутизации разобран в материале об USDT TON и комментарии. Порядок обмена описывает сервисный этап заявки. При обмене без регистрации следуйте конкретным выданным инструкциям. Протокольный разбор не раскрывает и не удостоверяет внутренний мониторинг определённого заказа. Установите, что доставлено, до решения о новом переводе.
Частые вопросы
Для чего нужен jetton transfer notification?
Это отдельное сообщение, которое принимающее приложение может использовать для распознавания и обработки поступления. Наличие и успешную доставку проверяют отдельно от движения токена.
Сумма TON при jetton transfer равна количеству токена?
Нет, forward_ton_amount относится к нативному значению для уведомления. Количество jetton и полный бюджет обработки — самостоятельные величины.
Повторный jetton transfer исправит незачисленный депозит?
Автоматически нет: он создаст новый перевод вместо изменения первого. Сначала попросите официального получателя установить учёт уже доставленной суммы.