Как предотвратить криптоплатежи не в той сети: регламент действий для продавца

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

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

Подтвержденная транзакция не означает, что платеж принят

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

Для обычного платежа проверьте все следующие поля:

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

Основные виды инцидентов

Клиенты часто называют любую ошибку «не той сетью». Сначала установите факты и только потом выбирайте способ решения.

Не считайте знакомый тикер достаточным доказательством того, что актив выбран правильно. Circle описывает USDC как цифровой доллар, выпускаемый в нескольких блокчейнах, а Tether публикует актуальный список протоколов, поддерживающих токены Tether. Списки эмитентов не определяют, что поддерживает Yolfi, ваш кошелек или ваша компания. Предлагайте только те сочетания актива и сети, которые отображаются в действующих настройках Yolfi.

Предотвратите ошибку до подтверждения в кошельке

Надежная защита от выбора неправильной сети начинается на странице оплаты, а не в службе поддержки.

Считайте актив и сеть единым способом оплаты

Не называйте вариант просто «USDC» или «USDT». Везде используйте составное обозначение, например «USDC в [выбранной сети]»: при выборе, на экране проверки, в инструкциях рядом с QR-кодом, при переходе в кошелек, в квитанции, обращениях в поддержку и выгрузках для сверки.

В руководстве по приему USDC и руководстве по приему USDT объясняется, почему выбор сети является частью способа оплаты. В открытых инструкциях указывайте только сочетания, которые доступны в текущем процессе оплаты, а не все сети, в которых эмитент когда-либо выпускал токен.

Повторите важные сведения перед подтверждением

До того как пользователь подтвердит транзакцию в кошельке, покажите:

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

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

Сократите число лишних вариантов

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

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

Соберите пакет сведений об инциденте

Сразу запросите всю необходимую информацию. Повторные запросы затягивают разбирательство и подталкивают клиента к непроверенным способам решения.

Что нужно запросить у клиента

• URL платежной ссылки или идентификатор платежа;
• номер заказа, счета или учетной записи;
• хеш транзакции и ссылку на обозреватель блокчейна, если она есть;
• актив и сумму, которые, по словам клиента, он отправил;
• фактически выбранную сеть;
• адрес кошелька отправителя;
• примерное время перевода.

Данные со стороны продавца

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

Снимок экрана может быть изменен, устареть или относиться к другой сети. Используйте его, чтобы найти транзакцию, а затем проверьте ее самостоятельно.

Проверьте перевод в правильном обозревателе блокчейна

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

1. Откройте надежный обозреватель фактически использованной сети.
2. Выполните поиск по полному хешу транзакции. Не доверяйте видимому тексту ссылки: проверьте домен обозревателя по внутреннему регламенту.
3. Установите статус транзакции: ожидает подтверждения, выполнена успешно, завершилась ошибкой, была удалена или заменена.
4. Посимвольно сверьте адреса отправителя и назначения.
5. Проверьте переведенный актив. Для токена проверяйте контракт или адрес выпуска, а не только тикер.
6. Проверьте необработанную сумму токенов в событии перевода. Отдельно установите точность токена по официальному контракту или адресу выпуска либо по надежным метаданным обозревателя.
7. Зафиксируйте блок, время, текущее число подтверждений или статус окончательности и важные журналы событий.
8. Сравните каждое поле с первоначальным платежным запросом.
9. Проверьте расчетный кошелек или данные системы наблюдения за кошельком в этой же сети.
10. Выполните поиск во внутренних записях и убедитесь, что хеш еще не был распознан или учтен в другом месте.

Краткое руководство Circle по переводу USDC в EVM-сетях показывает отдельные этапы: выбор сети, отправку перевода, получение хеша и проверку в обозревателе. В нем также указано, что отправителю нужен нативный токен этой сети для оплаты комиссии за газ. Это лишь пример механики перевода, а не список сочетаний, доступных в вашей учетной записи Yolfi.

Используйте дерево решений и не обещайте возврат

Проходите этапы по порядку.

1. Есть ли действительная транзакция в заявленной сети?

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

2. Совпадают ли сеть, актив, адрес назначения, сумма и требования к подтверждению?

• Да: обработайте платеж обычным способом с защитой от повторного исполнения заказа.
• Нет: передайте его на разбор исключений. Не отмечайте заказ как оплаченный вручную только потому, что средства куда-то поступили.

3. Контролирует ли продавец адрес назначения в фактически использованной сети?

• Это не установлено: не утверждайте, что средства получены или их можно вернуть. Передайте вопрос владельцу кошелька или кастодиальной организации, отвечающей за этот адрес.
• Да: убедитесь, что именно этот актив находится по данному адресу и им можно безопасно распорядиться в соответствии с вашими правилами работы с кошельками, безопасностью, учетом и нормативными требованиями. Контроль адреса еще не означает, что первоначальный заказ оплачен правильно.
• Нет: объясните, что ваша компания не может перемещать средства с адреса, который она не контролирует. В справочном разделе Ethereum.org указано, что транзакции Ethereum не могут быть отменены центральным оператором; если адрес контролирует известный сервис, обратиться следует в его службу поддержки.

4. Одобрен ли способ исправления?

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

Никогда не говорите, что средства «всегда потеряны» или что их «всегда можно вернуть». MetaMask описывает распространенный случай в EVM, когда тот же адрес кошелька может быть доступен в другой EVM-совместимой сети, но также приводит случаи без гарантии возврата. Эти рекомендации не доказывают, что продавец, биржа, смарт-контракт, мультиподписной кошелек или платежная система смогут получить доступ к конкретному переводу либо вернуть его.

Безопасно создавайте ссылки для повторной оплаты

Если первоначальный запрос нельзя признать оплаченным, а правила допускают еще одну попытку, создайте новую платежную ссылку Yolfi. Не изменяйте историю и не предлагайте клиенту просто «попробовать еще раз».

Повторный запрос должен:

1. сохранять тот же номер заказа или счета;
2. получать новый уникальный идентификатор платежа;
3. указывать точные актив, сеть, сумму и адрес назначения из текущего процесса оплаты;
4. обозначать предыдущий запрос как замененный или находящийся на проверке;
5. объяснять, что первоначальная транзакция остается отдельным инцидентом;
6. предупреждать клиента, что оплачивать обе ссылки не нужно;
7. сохранять установленный срок действия;
8. передавать оба запроса на проверку дублирования до исполнения заказа.

Не просите клиента отправить неотслеживаемую доплату, повторить перевод на адрес из переписки или переключить сеть после отправки, будто это переместит первоначальные средства.

Исключите повторную оплату и двойное исполнение заказа

Транзакция с задержкой может подтвердиться уже после создания повторного запроса. Клиент также может отправить средства дважды, пока ждет ответа поддержки. Предусмотрите оба случая.

Используйте один номер заказа на уровне компании и несколько неизменяемых попыток оплаты. Применяйте следующие правила:

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

Если оба перевода выполнены успешно, не удаляйте один из них, не засчитывайте его незаметно в счет другой покупки и не отправляйте средства автоматически на адрес из нового сообщения в поддержку. Заблокируйте повторное исполнение заказа и следуйте установленным правилам зачета или возврата.

Установите правила поддержки и безопасности для продавца

Подготовьте для первой линии поддержки готовый сценарий и четкие условия передачи обращения специалистам.

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

Используйте, например, такую формулировку:

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

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

Yolfi — это некастодиальный сервис: платежи поступают в настроенный кошелек продавца, а не хранятся у Yolfi. Поэтому особенно важны правильная настройка кошелька, подтвержденный контроль доступа и внутренний порядок действий продавца при инцидентах.

Контрольный список продавца при инциденте

До начала приема платежей

• Показывайте актив и сеть вместе на каждом этапе.
• Включайте только сочетания, доступные в текущих настройках Yolfi.
• Проверяйте каждый расчетный адрес и идентификатор токена.
• Полностью проверяйте каждый включенный маршрут оплаты.
• Установите правила подтверждения, обработки несоответствий и повторных платежей, возврата средств и передачи обращений специалистам.
• Обучите поддержку никогда не запрашивать секретные данные кошелька.

При поступлении сообщения об инциденте

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

Частые вопросы

Может ли транзакция быть подтверждена, а платеж остаться неоплаченным?

Да. Подтверждение доказывает, что сеть обработала транзакцию. Чтобы признать платеж, необходимо также сверить запрошенные сеть, актив, адрес назначения, сумму и номер, а также убедиться в соблюдении требований продавца к подтверждению.

Возвращает или перемещает ли средства переключение сети в кошельке?

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

Нужно ли сразу просить клиента заплатить еще раз?

Нет. Сначала определите, ожидает ли первоначальная транзакция подтверждения, завершилась ли она ошибкой, выполнена ли успешно или не соответствует запросу. Если еще одна попытка одобрена, создайте новый связанный платежный запрос и включите проверку дублирования для обеих попыток.

Может ли Yolfi вернуть платеж, отправленный не в той сети?

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

Что делать, если клиент выбрал правильную сеть, но отправил не тот токен?

Рассматривайте это как ошибку в валюте. Проверьте контракт или адрес выпуска токена, сумму, адрес назначения и поступление в кошелек, а затем следуйте установленному порядку обработки исключений, а не отмечайте заказ как оплаченный.

Что делать, если транзакция все еще ожидает подтверждения?

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

Достаточно ли снимка экрана, чтобы одобрить исполнение заказа?

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

Заключение

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

Начните с сочетаний, показанных в действующих настройках Yolfi, протестируйте их и дайте поддержке единое дерево решений. Если нужна еще одна попытка, создайте связанный повторный запрос, а не придумывайте порядок действий в переписке. Цель — распознать правильный платеж, исполнить заказ один раз и документировать каждое решение по исключениям.