Проверяйте metadata, а не заявленный максимум

  • Для входящей Payment используйте delivered_amount из metadata; Amount/DeliverMax не является фактически полученной суммой.
  • Проверяйте validated ledger, Destination, tag, currency и issuer до внутреннего зачисления.
  • Если delivered_amount недоступен для очень старой операции, баланс восстанавливают по AffectedNodes, а не подставляют Amount.
Три суммы, которые нельзя смешивать
ПолеРольМожно ли по нему зачислять
DeliverMax или Amount в API v1Максимум, который платёж пытается доставитьНет, если не проверена metadata
SendMaxМаксимум актива, который согласен потратить отправительНет: валюта и issuer могут отличаться от результата
metadata.delivered_amountФактически доставленный актив и количествоДа, после проверки validated result и получателя
DeliverMinМинимально допустимый результат для partial pathНет: это условие исполнения, а не отдельный receipt
Три суммы, которые нельзя смешивать
Поле
DeliverMax или Amount в API v1
Роль
Максимум, который платёж пытается доставить
Можно ли по нему зачислять
Нет, если не проверена metadata
Поле
SendMax
Роль
Максимум актива, который согласен потратить отправитель
Можно ли по нему зачислять
Нет: валюта и issuer могут отличаться от результата
Поле
metadata.delivered_amount
Роль
Фактически доставленный актив и количество
Можно ли по нему зачислять
Да, после проверки validated result и получателя
Поле
DeliverMin
Роль
Минимально допустимый результат для partial path
Можно ли по нему зачислять
Нет: это условие исполнения, а не отдельный receipt

Сначала закрепляют сеть, получателя и идентичность актива

Сохраните transaction hash, network, validated ledger index/hash и полный ответ метода tx или transaction_entry. Затем сверьте TransactionType=Payment, Destination и, если используется hosted account, DestinationTag. Для issued token нужны одновременно currency и issuer: одинаковый код валюты у разных issuer не обозначает один актив. Такой пакет дополняет обычную проверку перевода криптовалюты, но не заменяет внутренний ID заказа или клиента.

Флаг разрешает доставить меньше заданного предела

При tfPartialPayment поле DeliverMax, которое в API v1 называлось Amount, задаёт верхний предел результата. Путь может закончиться любой положительной доставленной суммой либо значением не ниже DeliverMin, если он указан, и не превысить SendMax с учётом конвертации и issuer transfer fee. Поэтому нельзя вычислять остаток простым вычитанием Fee: сетевой transaction cost в XRP, path conversion и fee issued asset относятся к разным слоям.

Direct XRP-to-XRP Payment не может быть partial, но cross-currency путь с XRP или issued tokens может. Отсутствие флага не отменяет проверку delivered_amount: официальная документация рекомендует использовать это поле для входящих Payment, а не строить две разные ветки зачисления по одному только tfPartialPayment.

Decision tool связывает metadata с внутренним зачислением

Проверка одной операции

  1. 1
    Закрепите validated ledger

    Не используйте tentative/open result. Сохраните hash, ledger index, TransactionResult и ответ целиком.

  2. 2
    Проверьте адресацию

    Destination должен быть точным custody address; DestinationTag — точным клиентским или инвойсным идентификатором, если он требовался.

  3. 3
    Прочитайте delivered_amount

    Сверьте value, currency и issuer. Для XRP значение выражено в drops; issued amount представлен отдельным объектом.

  4. 4
    Сопоставьте условия

    Сравните фактический результат с ожидаемой суммой и допустимым отклонением; не дополняйте разницу значением из DeliverMax.

  5. 5
    Закройте off-chain слой

    Свяжите chain evidence с order/deposit ID и журналом зачисления. Платёж в ledger и запись сервиса — два разных факта.

Результат и безопасное действие
НаблюдениеВыводДействие
Validated + delivered_amount совпадает с активом, суммой, Destination и tagOn-chain часть подтвержденаСверить и записать внутреннее зачисление
tesSUCCESS, но delivered_amount меньше инвойсаДоставлен частичный платёжНе закрывать инвойс автоматически; применить опубликованное правило недоплаты
Issuer или currency не совпалиПолучен другой issued assetНе оценивать его по похожему тикеру; остановить credit
Destination правильный, tag отсутствует или неверенСредства могли попасть в общий custody accountИспользовать официальный memo/tag recovery без повторной отправки
Нет validated результатаФинальный on-chain факт отсутствуетНе кредитовать и перепроверить другим endpoint
Результат и безопасное действие
Наблюдение
Validated + delivered_amount совпадает с активом, суммой, Destination и tag
Вывод
On-chain часть подтверждена
Действие
Сверить и записать внутреннее зачисление
Наблюдение
tesSUCCESS, но delivered_amount меньше инвойса
Вывод
Доставлен частичный платёж
Действие
Не закрывать инвойс автоматически; применить опубликованное правило недоплаты
Наблюдение
Issuer или currency не совпали
Вывод
Получен другой issued asset
Действие
Не оценивать его по похожему тикеру; остановить credit
Наблюдение
Destination правильный, tag отсутствует или неверен
Вывод
Средства могли попасть в общий custody account
Действие
Использовать официальный memo/tag recovery без повторной отправки
Наблюдение
Нет validated результата
Вывод
Финальный on-chain факт отсутствует
Действие
Не кредитовать и перепроверить другим endpoint

Если DestinationTag потерян, не нужно отправлять вторую сумму для «активации». Сохраните hash и metadata, а затем используйте процедуру восстановления memo или destination tag у конкретного получателя. Его внутренняя политика, сроки и требование доказать владельца аккаунта не определяются XRPL protocol.

Старое unavailable восстанавливают по изменениям ledger

Для partial payments, включённых до 20 января 2014 года, delivered_amount может быть строкой unavailable. Это исключение не разрешает подставить DeliverMax. Фактическое изменение восстанавливают по AffectedNodes и trust-line balances, учитывая сторону issuer и распределение по нескольким RippleState entries. Современный платёж с неожиданно отсутствующим полем — повод остановить автоматическое зачисление и проверить схему ответа/endpoint.

Validated ledger защищает вывод от последующей перестановки open state, но не доказывает полноту off-chain истории. Граница finality и подтверждений важна для повторной проверки через независимый endpoint; screenshot explorer без raw metadata недостаточен для расследования.

При расхождении сохраняют evidence и останавливают автоматический credit

Stop-сигналы

  • сервис читает Amount/DeliverMax и игнорирует metadata.delivered_amount;
  • один currency code считается достаточной идентичностью без issuer;
  • tesSUCCESS автоматически закрывает инвойс независимо от суммы и tag;
  • explorer показывает только formatted value, а raw response и ledger context недоступны;
  • для возврата или зачисления просят seed, private key либо новый тестовый платёж;
  • поддержка предлагает изменить или удалить уже validated transaction.

Финальный отчёт должен содержать network, transaction hash, validated ledger, TransactionResult, Destination/tag, delivered amount с currency+issuer, ожидаемую сумму и точный off-chain record. Проверка freeze или clawback токена XRPL — отдельный вопрос эмитентского контроля и не объясняет величину конкретного Partial Payment без его metadata.

Источники

Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.

  1. XRPL Docs — Partial Payments XRP Ledger · Проверено 23 августа 2026 г. в 20:02 GMT+5
  2. XRPL Protocol — Payment XRP Ledger · Проверено 23 августа 2026 г. в 20:02 GMT+5
  3. XRPL Protocol — Transaction Metadata XRP Ledger · Проверено 23 августа 2026 г. в 20:02 GMT+5
  4. XRPL Docs — Look Up Transaction Results XRP Ledger · Проверено 23 августа 2026 г. в 20:02 GMT+5
Материал носит информационный характер и не является индивидуальной рекомендацией. Криптоактивы связаны с риском волатильности, технических сбоев, хищения и полной потери средств.