Как проверить криптовалютный платёж, если клиент пишет: “Я оплатил, но заказ не зачислился”? Для клиента всё выглядит просто: деньги ушли из кошелька или биржи, значит товар, подписка, депозит или доступ должны появиться сразу. Для бизнеса это не один вопрос, а цепочка проверок: какая сеть использована, совпала ли сумма, найден ли TXID, сколько подтверждений получила транзакция, не истёк ли счёт и можно ли связать платёж с конкретным заказом.
Без понятного процесса такие обращения быстро превращаются в ручной хаос. Поддержка просит скриншоты, финансы ищут поступление на кошельке, разработчик проверяет webhook, клиент нервничает, а заказ остаётся в ожидании. Чем больше криптоплатежей проходит через SaaS, VPN, хостинг, маркетплейс, Telegram-бот, iGaming-платформу или магазин цифровых товаров, тем важнее заранее описать, как команда проверяет спорные операции.
Ниже — практический сценарий для поддержки, финансов и технической команды.
Сначала разделите “клиент отправил” и “заказ оплачен”
В криптовалюте важно различать несколько событий.
Клиент мог открыть счёт на странице оплаты, но ещё не отправить транзакцию. Он мог отправить транзакцию, но она пока не подтверждена сетью. Он мог отправить правильный актив, но не в той сети. Он мог отправить меньше нужной суммы. Или платёж мог прийти технически, но не сопоставиться с заказом из-за истёкшего счёта, неверного адреса, memo/tag или сбоя в обработке статуса.
Для клиента всё это часто называется одинаково: “я оплатил”. Для бизнеса это разные статусы и разные решения.
Минимальный набор статусов должен выглядеть не как один общий “pending”, а как понятная цепочка:
- счёт создан;
- ожидается транзакция;
- транзакция найдена;
- ожидаются подтверждения сети;
- оплата зачислена;
- получена недоплата;
- получена переплата;
- платёж пришёл после истечения счёта;
- выбрана неверная сеть;
- операция отправлена на ручную проверку;
- оформлен возврат или ручное зачисление.
Если такие статусы не разделены, поддержка не сможет объяснить клиенту, что именно происходит. А если спорных операций становится много, стоит отдельно разобрать причины неуспешных криптоплатежей: неверная сеть, gas, ручной ввод суммы, истёкший счёт и слабые подсказки на странице оплаты.
Какие данные запросить у клиента
Первое правило: не начинайте проверку только со скриншота. Скриншот может помочь, но он не доказывает, что платёж пришёл в нужной сети, на нужный адрес и в нужной сумме. На скриншоте может быть внутренний номер заявки биржи, скрытая комиссия, частично обрезанный адрес или статус вывода, который ещё не попал в блокчейн.
Поддержке нужны данные, которые можно проверить в платёжной системе и блокчейне:
- ID заказа, счёта, депозита или пополнения;
- email, user ID или другой идентификатор клиента;
- актив: например USDT, BTC, ETH, TRX, BNB, SOL;
- сеть: например TRON, Ethereum, BSC, Polygon, Solana;
- сумма, которую клиент должен был отправить;
- сумма, которую клиент фактически отправил;
- TXID, transaction hash или хеш транзакции;
- время отправки;
- адрес получателя;
- скриншот деталей операции как дополнительный контекст.
TXID — главный идентификатор для проверки. Его обычно можно найти в истории операций кошелька или биржи. В разных интерфейсах поле может называться TXID, Hash, Transaction Hash, Transaction ID или Details.
Клиенту можно дать короткую инструкцию:
“Откройте историю операций в кошельке или на бирже, выберите нужный вывод и пришлите TXID / Hash транзакции. Важно: нужен именно хеш в блокчейне, а не номер заявки внутри биржи.”
Шаг 1. Проверьте TXID в правильной сети
TXID нужно проверять в обозревателе той сети, в которой клиент реально отправил средства. Это особенно важно для USDT и других токенов, которые существуют в разных сетях.
USDT в TRON, Ethereum, BSC, Polygon и Solana — это не один универсальный платёжный маршрут. Для пользователя это может быть “просто USDT”, но для бизнеса это разные сети, разные адреса, разные комиссии и разные правила зачисления.
Что проверить по TXID:
- найден ли хеш в обозревателе;
- какая сеть использована;
- какой актив отправлен;
- какой адрес отправителя;
- какой адрес получателя;
- какая сумма отправлена;
- какая комиссия сети списана;
- какой статус у операции;
- сколько подтверждений у транзакции;
- нет ли ошибки контракта или отменённого вывода.
Если TXID не находится, не спешите отвечать “платежа нет”. Возможны несколько причин: клиент прислал внутренний ID биржи, транзакция ещё не отправлена в блокчейн, сеть выбрана неверно, хеш скопирован не полностью или используется не тот обозреватель.
Хороший ответ клиенту:
“Мы пока не видим транзакцию по этому хешу в сети. Пожалуйста, проверьте, что это именно TXID / Hash из блокчейна, а не внутренний номер операции на бирже. Если вывод ещё обрабатывается биржей, дождитесь появления хеша и пришлите его повторно.”
Шаг 2. Сравните сеть оплаты с сетью счёта
Одна из самых частых причин спорных криптоплатежей — неверная сеть. Например, на странице оплаты был указан USDT TRC-20, а клиент отправил USDT BEP-20. Он уверен, что оплатил USDT, но система ожидала перевод в другой сети.
В проверке нужно ответить на четыре вопроса:
- какая сеть была указана в счёте;
- в какой сети клиент реально отправил средства;
- принадлежит ли адрес получателя платёжной системе или бизнесу;
- можно ли технически восстановить, зачислить или вернуть перевод.
Нельзя обещать восстановление сразу. Иногда средства можно найти и обработать вручную. Иногда это невозможно, особенно если актив или сеть не поддерживаются, адрес не принадлежит провайдеру или перевод ушёл на несовместимый маршрут.
Чтобы снижать такие ошибки, сеть должна быть показана как часть платёжного реквизита: не просто “USDT”, а “USDT TRC-20” или “USDT ERC-20”. Если бизнес принимает USDT в нескольких сетях, полезно заранее выбрать приоритетные варианты и объяснить клиенту разницу. Подробнее это разобрано в статье про выбор сети для приёма USDT.
Шаг 3. Проверьте сумму: ожидаемая, отправленная и полученная
Даже если сеть правильная, платёж может не закрыть заказ. Например, клиент должен был отправить 100 USDT, но бизнес получил 99,5 USDT. Причина может быть в ручном вводе суммы, комиссии вывода на бирже, неверном понимании сетевой комиссии или попытке “вычесть комиссию из платежа”.
Поддержке важно говорить не “платёж не прошёл”, а показывать конкретику:
- ожидалось: 100 USDT;
- получено: 99,5 USDT;
- разница: 0,5 USDT;
- статус: недоплата;
- возможное действие: доплатить, вернуть сумму, зачислить фактически полученное на баланс или передать на ручную проверку.
Недоплата в интернет-магазине и недоплата в сервисе с внутренним балансом — разные ситуации. Для товара с фиксированной ценой заказ обычно не закрывается, пока сумма не совпала. Для хостинга, рекламного кабинета, API-кредитов или iGaming-баланса бизнес может зачислить фактически полученную сумму, если это предусмотрено правилами.
Переплата тоже требует процесса. Если клиент отправил больше, заказ может быть оплачен, но излишек нужно вернуть или зачислить на баланс. Иначе клиент вернётся с вопросом, почему списалось больше. Политику таких сценариев стоит заранее связать с правилами возврата криптовалютного платежа.
Шаг 4. Проверьте статус и подтверждения
Статус “отправлено” в кошельке клиента ещё не означает, что заказ можно зачислить. Транзакция должна попасть в сеть, получить подтверждения и пройти правила платёжной системы.
Основные статусы, которые нужно различать:
- транзакция не найдена;
- транзакция найдена, но ещё не подтверждена;
- транзакция подтверждается;
- транзакция подтверждена;
- транзакция завершилась ошибкой;
- транзакция подтверждена, но сумма не совпала;
- транзакция подтверждена, но сеть не совпала;
- транзакция подтверждена, но счёт истёк;
- транзакция подтверждена, но отправлена на ручную или AML-проверку.
Количество нужных подтверждений зависит от сети, суммы и политики провайдера. Для небольшого платежа в быстрой сети сценарий может быть коротким. Для крупного платежа бизнес может ждать больше подтверждений или отправлять операцию на дополнительную проверку.
Клиенту лучше объяснять это простым языком:
“Платёж найден в сети. Сейчас мы ждём подтверждения. После подтверждения статус заказа обновится автоматически. Пожалуйста, не отправляйте повторный платёж, пока текущая транзакция находится в обработке.”
Шаг 5. Проверьте gas и сетевую комиссию
Пользователь может иметь USDT, но не иметь TRX, ETH, BNB, SOL или другой нативной монеты для оплаты комиссии сети. Для него это выглядит нелогично: “USDT у меня есть, почему кошелёк не даёт оплатить?” Для бизнеса это превращается в брошенную оплату, недоплату или тикет в поддержку.
Проблема особенно заметна при ручных переводах. Клиент сам выбирает сеть, сам копирует адрес, сам вводит сумму и сам должен понять, какая комиссия будет списана. Чем больше ручных шагов, тем выше вероятность ошибки.
На странице оплаты стоит заранее объяснять:
- какая сеть выбрана;
- какая сумма должна прийти бизнесу;
- кто оплачивает сетевую комиссию;
- нужен ли нативный токен для gas;
- что будет, если клиент отправит меньше;
- что делать, если кошелёк не даёт подтвердить транзакцию.
Отдельно эту боль закрывает сценарий USDT без газа, где бизнес заранее думает не только о комиссии, но и о том, как пользователь проходит оплату без лишних переходов и ручных расчётов.
Шаг 6. Проверьте связь транзакции с заказом
Иногда платёж есть в блокчейне, сумма верная, сеть правильная, подтверждения есть, но заказ всё равно не зачислен. Это значит, что проблема может быть не в транзакции, а в сопоставлении платежа с заказом.
Частые причины:
- клиент отправил средства на старый адрес;
- счёт истёк до поступления оплаты;
- клиент сделал повторный перевод;
- система ожидала memo, tag или другой идентификатор;
- webhook не дошёл до сайта;
- заказ был отменён до подтверждения;
- платёж пришёл на общий адрес без invoice ID;
- внутренняя система не обновила статус.
В таких ситуациях поддержке нужен не только TXID, но и статус счёта в платёжной системе: создан, ожидает оплату, оплачен, истёк, недоплата, переплата, ручная проверка, возврат. Если таких статусов нет, каждый спорный платёж будет уходить к разработчикам.
Для продуктов с большим числом платежей это нужно проверять ещё до запуска. В статье про API для криптоплатежей отдельно разобрано, почему важны invoice ID, статусы, webhook, тестовые сценарии и логика выдачи доступа.
Шаг 7. Решите, нужна ли AML-проверка
Не каждый криптоплатёж должен уходить на ручную проверку. Но бизнесу нужен процесс для операций с повышенным риском: крупные суммы, необычное поведение клиента, подозрительные источники средств, возвраты на новый адрес, маркетплейсы, iGaming, финтех, VPN и международные цифровые сервисы.
На AML-проверку могут попадать:
- входящие средства с повышенным risk score;
- переводы, связанные с подозрительными адресами;
- повторяющиеся операции необычного размера;
- платежи, не похожие на обычное поведение клиента;
- возвраты на адрес, который отличается от исходного;
- спорные платежи после ошибочной сети или ручного восстановления.
Поддержка не должна принимать такие решения в одиночку. Нужен внутренний статус: “на проверке”, “нужны дополнительные данные”, “зачислено”, “возврат невозможен”, “передано финансовой команде”, “передано compliance”. Требования к AML, KYC, хранению данных и возвратам зависят от юрисдикции и бизнес-модели, поэтому юридические и регуляторные вопросы нужно согласовывать с профильными специалистами.
Общая логика риск-контроля раскрыта в статье про AML-проверку и безопасность криптоплатежей.
Что отвечать клиенту в типовых ситуациях
TXID не находится
“Мы пока не видим транзакцию по этому хешу в блокчейне. Пожалуйста, проверьте, что вы прислали именно TXID / Hash, а не внутренний номер заявки на вывод. Если вывод ещё обрабатывается биржей, дождитесь появления хеша в деталях операции и пришлите его повторно.”
Транзакция найдена, но не подтверждена
“Платёж найден в сети, но пока не получил нужное подтверждение. После подтверждения статус заказа обновится. Пожалуйста, не отправляйте повторный платёж, пока текущая операция находится в обработке.”
Сумма меньше ожидаемой
“Мы получили платёж, но сумма меньше суммы счёта. Ожидалось X, получено Y. Чтобы закрыть заказ, нужно доплатить разницу в той же сети или выбрать другой доступный вариант обработки: возврат, ручная проверка или зачисление фактически полученной суммы, если это предусмотрено правилами сервиса.”
Сумма больше ожидаемой
“Заказ оплачен, но сумма выше суммы счёта. Излишек может быть возвращён или зачислен на баланс, если это предусмотрено правилами сервиса. При возврате может учитываться сетевая комиссия.”
Платёж пришёл после истечения счёта
“Мы видим платёж, но он поступил после истечения срока счёта. Передали операцию на проверку. Команда определит, можно ли зачислить платёж, пересчитать заказ, вернуть сумму или зачислить её на баланс.”
Клиент отправил в неверной сети
“Платёж отправлен не в той сети, которая была указана в счёте. Мы проверим, можно ли технически обнаружить и обработать такой перевод. Возможность восстановления зависит от сети, адреса и правил провайдера, поэтому мы не можем подтвердить зачисление до завершения проверки.”
Платёж на AML-проверке
“Платёж найден, но операция отправлена на дополнительную проверку. Это не означает автоматический отказ. Нам нужно завершить внутреннюю проверку по правилам безопасности. Мы сообщим статус, как только проверка будет завершена.”
Что должно быть в админке, чтобы поддержка не зависела от разработчиков
Если поддержка каждый раз просит разработчика “посмотреть платёж”, процесс плохо масштабируется. В личном кабинете или админке должны быть видны поля, по которым можно быстро разобрать обращение.
Минимальный набор:
- ID заказа или счёта;
- статус счёта;
- ожидаемая сумма;
- фактически полученная сумма;
- актив и сеть;
- адрес назначения;
- TXID;
- число подтверждений;
- время создания счёта;
- срок действия счёта;
- причина исключения;
- AML-статус, если проверка применяется;
- решение по операции: ждать, зачислить, вернуть, запросить доплату, передать на ручную проверку.
Финансовой команде дополнительно нужны суммы после комиссии, курс конвертации, итоговый баланс, доступная сумма к выводу и история действий по спорной операции. Такой подход связан с тем, как CFO контролирует приём USDT для бизнеса: не только “деньги пришли”, а “деньги связаны с заказом, правильно учтены и готовы к выводу”.
Какие метрики отслеживать после запуска
Проверка спорных платежей не должна жить только в тикетах поддержки. Если проблемы повторяются, их нужно переводить в метрики и улучшать процесс оплаты.
Отслеживайте:
- долю платежей, которые автоматически связаны с заказом;
- долю платежей, которые потребовали ручной проверки;
- количество недоплат;
- количество переплат;
- количество платежей в неверной сети;
- количество поздних платежей;
- среднее время до зачисления;
- обращения в поддержку на 1 000 криптоплатежей;
- долю операций на AML-проверке;
- возвраты из-за ошибок оплаты.
Эти данные помогают понять, где ломается процесс: на выборе сети, на вводе суммы, на gas, на ожидании подтверждений, на webhook или в объяснении статуса клиенту. Подробнее набор показателей можно связать с метриками криптоплатежей.
Как снизить число спорных криптоплатежей
Проверять платежи важно, но ещё важнее уменьшить число ситуаций, где такая проверка нужна.
Что помогает:
- показывать актив и сеть вместе: USDT TRC-20, а не просто USDT;
- использовать QR-код или сценарий оплаты в приложении, чтобы клиент не вводил адрес и сумму вручную;
- показывать таймер действия счёта рядом с реквизитами;
- объяснять, кто оплачивает сетевую комиссию;
- предупреждать о нативной монете для gas;
- разделять статусы “транзакция найдена” и “оплата зачислена”;
- не использовать один общий статус “ожидание” для всех ошибок;
- заранее описать правила недоплаты, переплаты, позднего платежа и неверной сети;
- тестировать спорные сценарии до запуска;
- дать поддержке доступ к истории операций и статусам.
Важно считать не только комиссию провайдера, но и стоимость ручной работы. Если платёжный способ даёт низкую видимую комиссию, но создаёт много недоплат, возвратов и обращений, итоговая стоимость может быть выше ожидаемой. Поэтому стоит отдельно смотреть, как устроена сетевая комиссия в криптовалюте и как она влияет на сумму, UX и поддержку.
Как в этом помогает платёжная система
Бизнесу не обязательно строить весь процесс с нуля. Хорошая криптовалютная платёжная система должна закрывать не только “показать адрес кошелька”, но и операционную часть:
- создать счёт под конкретный заказ;
- показать актив, сеть, сумму и срок действия;
- снизить ручной ввод через QR-код или приложение;
- отследить TXID и подтверждения;
- связать транзакцию с заказом;
- показать статус в личном кабинете;
- обработать недоплату, переплату и поздний платёж;
- передать статус через API или webhook;
- поддержать AML-проверку;
- помочь с отчётностью и выводом средств.
CryptumPay можно использовать в таком сценарии как инфраструктуру для приёма криптовалюты на сайте, в приложении, Telegram-боте или другой digital-платформе. Но главный принцип остаётся тем же для любого решения: клиент должен понимать, что происходит с оплатой, а команда — видеть достаточно данных, чтобы не искать платёж вручную.
FAQ
Как проверить криптовалютный платёж по TXID?
Нужно взять TXID из истории операции в кошельке или бирже, открыть обозреватель нужной сети и проверить статус, адрес получателя, сумму, комиссию и подтверждения. Важно использовать обозреватель той сети, в которой был отправлен платёж.
Почему клиент отправил USDT, но заказ не зачислился?
Причин может быть несколько: неверная сеть, недоплата, отсутствие подтверждений, истёкший счёт, ошибка webhook, отправка на старый адрес, отсутствие memo/tag или AML-проверка. Сначала нужно проверить TXID, сеть, сумму и статус счёта.
Что делать, если клиент отправил USDT в неверной сети?
Нужно проверить, поддерживает ли провайдер эту сеть и принадлежит ли адрес получателя бизнесу или платёжной системе. Восстановление не всегда возможно, поэтому клиенту нельзя обещать зачисление до проверки.
Можно ли зачислить недоплату?
Это зависит от бизнес-модели. Для фиксированного заказа чаще нужна доплата или возврат. Для балансовых сервисов можно зачислить фактически полученную сумму, если это предусмотрено правилами.
Когда нужна AML-проверка криптоплатежа?
AML-проверка может понадобиться для крупных, нетипичных или рискованных операций, а также в нишах с повышенными требованиями к безопасности. Конкретные правила зависят от юрисдикции, бизнес-модели и политики провайдера.
