😀 Самое опасное при пополнении средств и зачислении пользователю — это не отсутствие примечания, а то, что примечание принимают за удостоверение личности (ID).
В моём руководстве по сканированию пополнения Moonlight для @Dusk я заметил две почти соседние фразы.
В документации memo возвращается в шестнадцатеричном виде и относится к «незаслуживающим доверия данным маршрутизации», которые сначала нужно проверить по формату.
Далее напоминание ещё прямее: никогда не использовать memo как идемпотентный ключ. Единственное, что действительно должно быть уникальным, — это ID транзакции Dusk.
Именно это различие определяет, что система зачисления считает фактом. memo лишь говорит системе подсказку «возможно, кому нужно передать»; транзакционный ID отвечает на вопрос «обрабатывались ли эти деньги уже». Если платформа смешает эти вещи, удобная для фронтенда пометка будет ошибочно принята за бухгалтерскую запись на стороне бэкенда.
Плохой сценарий — когда две операции пополнения несут одинаковый, отсутствующий или имеющий сбой формат memo. Если система дедуплицирует по примечанию, можно пропустить одну запись; если же напрямую относить по нему, можно отправить аномальный запрос не в тот аккаунт. Пользователь увидит, что пополнение долго не зачисляется, а команда операций будет снова и снова сверять финансы, логи и работу с клиентами.
Проблема не в том, что в примечаниях $DUSK есть дизайн-ошибка — проблема в том, хочет ли интегратор признать, что маршрутизирующая информация по своей природе нуждается в проверке. В документации для @Dusk уже задано направление: неизвестные или недействительные метаданные должны попадать на ручную повторную проверку, а не тихо отбрасываться. Стоит проверять именно то, заложит ли подключающая сторона это правило в продукт и покажет ли пользователю, что он сейчас находится в процессе ручной верификации. #dusk