Спершу визначте точний тип підтвердження, а вже потім дійте
Насамперед потрібно зрозуміти, що саме означає «підтверджено». Криптоплатіж може бути підтверджений у блокчейні, зарахований платформою або просто відображатися в історії гаманця після синхронізації. Це три різні події, і вони дають різні варіанти дій.
Якщо транзакція має підтвердження в мережі, блокчейн уже її прийняв. Якщо платіж видно лише в біржі або кастодіальному застосунку, платформа ще може контролювати етап зарахування, а отже, підтримка, ймовірно, зможе допомогти. Якщо він відображається лише в історії одного гаманця, можливо, ви бачите локальний запис, а не завершений переказ. Ця різниця дуже важлива, коли ви намагаєтеся зрозуміти, як виправити криптоплатіж у неправильній мережі.
Спочатку перевірте блокчейн-оглядач. Один хеш транзакції скаже більше, ніж три скриншоти. Подивіться на назву мережі, висоту блоку та адресу отримувача і не припускайте, що підпис у застосунку правильний лише тому, що він виглядає акуратно.
Один невеликий, але показовий приклад: користувач бачить у гаманці статус «підтверджено» й думає, що кошти втрачено назавжди. Це не завжди так. Іноді гаманець просто показує переказ на адресу, яка існує в кількох мережах, а справжня проблема в тому, що застосунок отримувача відстежує лише одну з них.
Зіставте кошти з тим середовищем, куди вони були надіслані
Далі з’ясуйте, куди саме потрапив платіж. Чи прийшов він у гаманець із самостійним зберіганням, на депозитну адресу біржі, у смартконтракт чи на акаунт кастодіального застосунку? У кожного з цих варіантів свій шлях відновлення і своя сторона, яка контролює ключі.
Гаманець із самостійним зберіганням означає, що сторона-отримувач сама контролює свої ключі відновлення. Депозитна адреса біржі означає, що платформа може контролювати акаунт, але не саму блокчейн-адресу, на яку надійшов депозит. Смартконтракт може зберігати токени за правилами, які не збігаються зі звичайною поведінкою гаманця. Кастодіальний застосунок може показувати баланс навіть тоді, коли переказ у мережі лежить в окремій адресі гаманця «за лаштунками».
Уважно перевірте пункт призначення. Якщо платіж пішов на адресу, яка належить вам, проблема може бути лише у відображенні. Якщо він потрапив на депозитну адресу біржі, якою ви не керуєте, ваш реалістичний шлях — лише підтримка платформи. Якщо кошти потрапили в контракт, подальший розвиток визначає код контракту, а це рідко буває швидким виправленням.
Одна практична перевірка тут дуже допомагає: порівняйте адресу в оглядачі з адресою в застосунку отримувача. Якщо цифри збігаються, але актив не видно, ви не шукаєте зниклий переказ. Ви перевіряєте невідповідність мережі або проблему з підтримкою активу.
Перевірте, чи підтримує сторона-отримувач цей актив у цій мережі
Платформа-отримувач може підтримувати токен, але не в тій мережі, яку було використано. У багатьох випадках саме це і є проблемою. Гаманець може показувати ту саму адресу в кількох блокчейнах, але за замовчуванням у застосунку може бути активною лише одна мережа.
Поставте собі два запитання. По-перше, чи підтримує сторона-отримувач сам актив? По-друге, чи підтримує вона цей актив саме в тій мережі, якою його було надіслано? Якщо відповідь на друге запитання — ні, баланс може бути невидимим, а не втраченим. Саме в таких випадках люди часто пишуть, що не видно криптопереказ у гаманці.
Деякі застосунки приховують баланси, доки не буде додано правильну мережу. Деякі біржі розпізнають депозити лише в певних блокчейнах. Деякі гаманці можуть показати токен після ручного додавання контракту, тоді як інші просто не можуть цього зробити. Баланс, який здається відсутнім, може бути на місці, але «захований» за мережевим налаштуванням, яке користувач ще не увімкнув.
Ось чому одна й та сама ситуація може завершитися двома дуже різними способами. В одному випадку співробітник підтримки вмикає правильну мережу — і кошти з’являються. В іншому сторона-отримувач ніколи не підтримувала цей блокчейн, тож платіж лежить у мережі, яку застосунок не читає. Різниця тут не косметична, і саме тому запит на кшталт криптовалюту надіслано в неправильній мережі що робити має починатися з перевірки підтримки активу.
Зберіть точні дані транзакції для ескалації
Перш ніж звертатися до будь-кого, зберіть усі дані про транзакцію в одному місці. Вам потрібні хеш tx, адреса відправника, адреса отримувача, контракт токена, назва мережі, час, сума та скриншоти зі статусом «confirmed». Не надсилайте лише частину цього списку й не сподівайтеся, що підтримка сама заповнить прогалини.
Використовуйте запис в оглядачі як головне джерело правди. Скриншот із гаманця корисний, але хеш важливіший. Платформа-отримувач зазвичай спершу попросить хеш, потім мережу, далі адресу призначення, а інколи й точну суму аж до останньої одиниці.
Зберігайте докази в охайному вигляді. Скриншот із неправильною назвою мережі може зіпсувати весь день. Скопійований хеш із однією пропущеною літерою може завести підтримку в глухий кут. Якщо у вас є і вигляд гаманця, і вигляд із оглядача, збережіть обидва.
Також корисно зазначити, чи однаковий формат адреси в відправника й отримувача в різних мережах. Багато адрес виглядають однаково в кількох блокчейнах, і саме тому проблема з неправильною мережею взагалі виникає. Вирішальним фактором є мережа, а не форма адреси.
Звертайтеся до платформи-отримувача як до кейсу невідповідності мережі, а не як до загального запиту на повернення коштів
Відкрийте правильний канал підтримки. Не пишіть «запит на повернення коштів», якщо проблема насправді в невідповідності мережі. Скажіть, що платіж був підтверджений у неправильній мережі, і вам потрібна перевірка випадку network mismatch. Таке формулювання дає підтримці кращу відправну точку й позбавляє типового перекидання відповідальності, коли вас просять тричі переповісти ті самі факти.
Якщо ви маєте справу з платформою, у першому повідомленні додайте хеш, мережу, актив, адресу призначення та час. Попросіть про один із трьох варіантів: зарахування, імпорт активу або ручний перегляд для відновлення. Це реалістичні шляхи, якщо сторона-отримувач ще може щось зробити.
Якщо можливо, використовуйте один тикет підтримки. Кілька тикетів можуть розірвати історію звернення і ускладнити відстеження проблеми. Один чіткий кейс легше ескалювати, ніж п’ять коротких повідомлень, у кожному з яких не вистачає назви мережі.
Тут важливий і тон. Ставте факти, а не емоції. «Переказ підтвердився в Polygon замість Ethereum» звучить краще, ніж «ваша система загубила мої кошти». З першою фразою підтримка може працювати. З другою зазвичай мало що можна зробити.
Вирішіть, чи можливе самостійне відновлення
Деякі випадки можна виправити без підтримки, але таких ситуацій небагато. Якщо ви контролюєте той самий гаманець і актив існує в неправильній мережі, ви можете імпортувати цей гаманець у застосунок, сумісний із потрібною мережею, додати токен вручну або змінити RPC/мережеві налаштування, щоб баланс з’явився.
Це працює лише тоді, коли сторона-отримувач — це ваш власний гаманець або застосунок, де ви керуєте ключами. Якщо кошти були відправлені на депозитну адресу біржі, до кастодіального застосунку або в смартконтракт, самостійного відновлення може не існувати. Блокчейну байдуже, що помилка була випадковою.
Ручне додавання токена — поширене рішення, коли актив є, але він прихований. Ви вводите правильну адресу контракту, кількість знаків після коми та мережу — і гаманець показує баланс. Неправильні дані контракту можуть лише погіршити ситуацію, тому перевіряйте кожне поле за офіційним джерелом токена.
Якщо вам потрібен ширший підхід, який допоможе уникати таких помилок у майбутньому, дивіться як новачкам почати приймати криптовалюту. Стаття присвячена налаштуванню, але той самий принцип допомагає і тут: знайте, які мережі ви насправді підтримуєте, ще до того, як надійде переказ.
Уникайте дій, які можуть ускладнити відновлення
Не надсилайте платіж ще раз, якщо цього не попросить підтримка. Другий переказ може створити проблему дублювання, і тепер вам доведеться пояснювати вже два хеші замість одного. Це поганий обмін.
Не експериментуйте з випадковими bridge-інструментами, поки чекаєте. Бридж — не рятувальний трос за замовчуванням, а невдалий крок може перемістити актив ще в одне місце, яке підтримка не зможе швидко перевірити. Один ризикований клік може перетворити відновлювану невідповідність на хаос.
Не взаємодійте зі смартконтрактом, якщо не знаєте точно, навіщо це робите. У деяких контрактів є кроки для отримання, кроки для виведення або правила обгортання токенів, які виглядають безпечно, аж поки не заблокують баланс ще сильніше. Якщо ви не створювали цей контракт, ставтеся до нього обережно.
І ніколи не діліться seed-фразою. Жодному співробітнику підтримки вона не потрібна. Жодному «фахівцю з відновлення» теж. Якщо хтось просить seed-фразу, щоб допомогти з платіжкою в неправильній мережі, завершіть чат.
Сформуйте очікування і підготуйте запасний план
Підтримка може допомогти, а може й ні. Якщо платформа-отримувач не контролює адресу призначення, не підтримує цю мережу або не може безпечно імпортувати актив, відповідь може бути негативною. Це наслідок, а не оцінка.
Повністю задокументуйте втрату, перш ніж рухатися далі. Збережіть хеш, скриншоти, номер тикета та будь-яку відповідь підтримки. Якщо отримувач контролює ключі відновлення, запитайте, чи можливий ручний імпорт. Якщо ні, це потрібно знати якнайшвидше, а не після тижня очікування.
Після цього вирішіть, чи виправдовує сума звернення до професійних сервісів з відновлення. Для невеликого переказу комісії можуть перевищити вартість. Для великого переказу обережний аналіз від людини, яка розуміє мережу й середовище отримувача, може бути вартий уваги, але лише після перевірки її особи та процесу.
Якщо ви керуєте сайтом або магазином і хочете не допускати, щоб клієнти потрапляли в таку ситуацію, допомагає більш охайне налаштування. Такі самі звички важливі, коли ви налаштовуєте приймання криптодепозитів, адже чітка політика щодо мереж зменшує кількість звернень у підтримку ще до їх появи.
Ще один момент: якщо сторона-отримувач — це платіжний провайдер або шлюз, вам може знадобитися технічна підтримка, а не звичайна служба роботи з клієнтами. У такому разі шлях для розробників часто є найшвидшим, саме тому посилання на кшталт документація для розробників, API криптоплатіжного шлюзу може бути важливим, коли кейс включає логи API, записи webhook або правила генерації адрес.
Для WordPress-магазинів плагін оформлення замовлення теж може бути частиною проблеми. Якщо ви використовуєте плагін, який за замовчуванням відстежує не ту мережу, перевірте налаштування й протестуйте невеликий переказ. Інструкція на кшталт приймати криптоплатежі у WordPress корисна тут, бо вибір мережі має бути в конфігурації магазину, а не в здогадах після надходження платежу.
Коли мерчанту потрібно пояснити різницю між підтримуваною мережею та видимим балансом, формулювання має значення. Платформа, яка є некостодіальний криптоплатіжний шлюз VAT, обробляє записи інакше, ніж кастодіальна, і ця відмінність може визначати, що підтримка здатна відновити, а що ні.
Якщо проблема виникла в нішевому сценарії — запит на платіж, депозит для бронювання або інтеграція для розробників — відповідь часто зводиться до точного маршруту, яким пройшла транзакція. Платіж у неправильній мережі не виправляється надією. Його виправляють, коли визначають блокчейн, зіставляють адресу призначення і звертаються до тієї сторони, яка ще може виконати потрібну дію.
Коментарі