Для partial payment в XRP Ledger проверяйте подтверждённые метаданные и фактический delivered_amount. Amount в API v1 либо DeliverMax в API v2 может обозначать максимум, а не поступившую величину. Поэтому успешная транзакция с большой указанной суммой ещё не даёт основания зачислять её целиком или возвращать якобы возникшую переплату.
Ошибка возникает в учёте, а не в записи сети
Частичные платежи — штатная возможность XRPL. При подходящих условиях операция может завершиться с меньшим получением. Возможность обмана появляется, если человек или интеграция записывает максимальную сумму как фактическое поступление. Настоящий хеш и успешный результат не исправляют такую ошибку учёта. Проверять нужно смысл конкретной величины, а не только существование операции.
В официальном разборе partial payments это различие разобрано отдельно. Сам флаг частичного платежа не доказывает мошенничество. Но и объяснение отправителя не заменяет проверку реального результата у получателя. Сначала установите содержание записи, затем решайте, закрывает ли поступление ожидаемый перевод и какие действия с ним допустимы.
Прямой перевод XRP в XRP не поддерживает этот механизм. Межвалютные операции, в которых XRP является одной из сторон, устроены иначе. Поэтому заголовок про частичные платежи XRP не означает, что любой обычный перевод нативной монеты способен через этот флаг незаметно доставить меньше. Разбирайте тип платежа и путь актива, а не распространяйте предупреждение на все случаи.
Каждому полю соответствует свой вопрос
| Поле или признак | Что проверяет | Типичная ошибка |
|---|---|---|
| Destination и tag | Назначение перевода | Сверить лишь знакомое имя аккаунта |
| Amount / DeliverMax | Поручение или максимум с учётом типа платежа | Всегда принимать число за поступление |
| DeliverMin, когда применим | Указанный минимум частичной доставки | Считать его обязательным в каждой операции |
| SendMax | Предельный расход отправителя | Принимать его за зачисление получателя |
| TransactionResult | Исполнение по правилам транзакции | Приравнять успех к заявленной сумме |
| Признак validated | Результат в подтверждённом реестре | Учесть предварительное наблюдение как окончательное |
| meta.delivered_amount | Фактическое поступление | Подставить вместо него желаемый максимум |
| Идентичность актива и единицы | Какую величину получили | Сложить разные активы или разряды |
В справке Payment объясняется переименование: API v1 использует Amount, API v2 — DeliverMax. Новое название яснее показывает ограничение сверху. Однако старый интерфейс или сводка обозревателя могут сохранять привычную подпись. Выясните, какое значение выводится под ней, вместо доверия одному заголовку «Сумма» на экране.
Получите окончательную запись независимо от отправителя
Откройте надёжный обозреватель или документированную запись принимающего приложения самостоятельно. Сверьте сеть, хеш и полный адрес назначения. Метод tx позволяет получить сведения об операции. При чтении результата важно сохранить метаданные и признак подтверждения, а не свести весь ответ к одному крупному числу.
Для выпущенного токена сравните валютный код и эмитента. Знакомое обозначение само по себе не определяет актив, который ожидался по заказу. Единицы также должны совпадать: нативная монета и токен могут иметь разные формы представления величины. Неподписанное целое число на пересланном изображении плохо подходит для изменения внутреннего баланса. Сверяйте его с исходной записью в нужном формате.
Если фактическое поле отсутствует, не читается или содержит unavailable, нельзя для удобства подставлять DeliverMax. В справке метаданных описаны исторические частичные платежи, где для определения результата требуется анализ изменённых записей реестра. Если вы не можете его выполнить, передайте случай специалисту. Недоступный ответ API оставляет проверку открытой, а не превращает запрошенную сумму в полученную.
Разберите вымышленную просьбу вернуть переплату
Предположим, по внутренней записи ожидались 80 единиц токена конкретного эмитента. Отправитель показывает успешную операцию с максимумом 800, но подтверждённый delivered_amount вашему получателю равен 0,8. Это учебные числа, а не инструкция атаки и не реальный случай. Подтверждённое поступление здесь 0,8; оснований зачислять 800 из этих сведений нет.
Если контрагент просит вернуть разницу, не считайте возврат от заявленного максимума. Сначала установите, что действительно получено, не учтено ли поступление ранее и положен ли возврат по вашему процессу. Маленький настоящий перевод не создаёт обязанности отправлять значительно больше из остальных средств. Отдельно зафиксируйте решение о корректировке и фактическую запись, на которую оно опирается.
Добросовестный частичный перевод может просто не закрыть ожидаемое поступление. Формулируйте ответ предметно: запись показывает такой актив и такую доставленную величину; первоначальное обязательство рассматривается отдельно. Сам механизм не доказывает обман, как и уверенная просьба вернуть переплату не доказывает её наличие. Не торопитесь с обвинениями и не подменяйте проверку доверительной перепиской.
Настройте приём так, чтобы суммы было трудно перепутать
- До просмотра платежа запишите ожидаемый актив, эмитента при необходимости, сумму, адрес и требование к метке.
- Найдите операцию независимым надёжным способом и проверьте подтверждённый результат.
- Сверьте фактический delivered_amount, правильный актив и единицы с ожидаемым поступлением.
- Оставьте неоднозначную запись неучтённой до выяснения; не заменяйте отсутствующие сведения максимумом.
- Убедитесь, что это поступление не использовалось ранее, до зачисления или рассмотрения возврата.
- Сохраните сетевую запись и отдельное обоснование изменения внутреннего счёта.
Разработчику приёма недостаточно испытания с одним успешным обычным платежом. Проверьте частичную доставку, недоступные метаданные, разные версии API и повторное предъявление того же получения. На экране ручного разбора фактическая сумма должна читаться без догадок. Сотрудник не должен вычислять её по желаемому максимуму из текста отправителя.
Базовая проверка хеша помогает найти запись сети. Метка депозита решает другой вопрос: правильная маршрутизация не доказывает заявленное количество. Перед обменом без регистрации соблюдайте инструкции конкретной заявки. Наличие функции XRPL не означает поддержку сервисом любой формы платежа.
Частые вопросы
Любой partial payment XRP означает мошенничество?
Нет, это штатная возможность для подходящих типов платежей. Опасна подмена фактического получения заявленным максимумом при зачислении или рассмотрении возврата.
Какую сумму смотреть у успешного частичного платежа?
Проверяйте delivered_amount в метаданных вместе с активом, получателем и подтверждением реестра. Успех не даёт основания вместо этого брать Amount или DeliverMax.
Бывает ли прямой перевод XRP в XRP частичным?
Для прямых XRP-to-XRP платежей этот механизм недоступен. Межвалютная операция с участием XRP — отдельный сценарий, поэтому важен реальный тип перевода.