Не создавайте второй самостоятельный платёж, пока исходный перевод Lightning находится in flight либо его результат неизвестен. Ожидание на экране, обрыв связи и истёкший таймер интерфейса ещё не означают окончательный отказ. Восстановите состояние существующей операции по её записи и payment hash, затем сопоставьте его с данными получателя. Только после этого решайте, нужна ли повторная оплата.
У одной покупки могут появиться два независимых платежа
Представим условного отправителя Ивана. Он подтвердил инвойс Lightning, увидел ожидание и потерял мобильный интернет. Получатель предложил новый счёт, но в исходной записи по-прежнему pending. Оплатив замену из другого кошелька, Иван не отменит первую операцию. Вместо устранения неопределённости появится ещё один платёж, который придётся разбирать отдельно, если исходный перевод впоследствии завершится успешно.
Поэтому важнее понять, к какой операции относится каждое действие, чем посчитать нажатия кнопки оплаты. Храните вместе исходный инвойс, идентификатор перевода в кошельке и номер заказа получателя. Новый счёт, другое приложение и повторно открытая ссылка оплаты могут менять контекст. Защита от дублей, предусмотренная в одном месте, не обязана распространяться на все остальные кошельки и новые платёжные запросы.
Устройство самого запроса разобрано в сравнении инвойса Lightning и адреса Bitcoin. Здесь речь о стадии после запуска перевода: нужно выяснить итог существующей операции. Это другая задача, чем выбор формата назначения или рекомендация попробовать маршрут с новой комиссией. Сначала сохраняется связь с исходным платежом, затем рассматривается любое следующее действие.
Смотрите на состояние всего платежа, а не отдельного сообщения
Одна попытка маршрутизации может закончиться неудачей, пока программа продолжает проводить тот же платёж. Потеря соединения, по которому приходили обновления, говорит о соединении, но не об итоге всех попыток. В обращении в поддержку разделяйте ошибку приложения, результат платежа целиком и состояние отдельной части маршрутизации. Это помогает, когда в технической истории соседствуют несколько записей, которые на первый взгляд противоречат друг другу.
Для системы на LND предусмотрен TrackPaymentV2: обновления относятся к платежу, определённому по payment hash. Среди состояний различаются in flight, успешное завершение и отказ. Пользователю не требуется становиться администратором узла: попросите оператора кошелька найти исходный платёж. Отсутствие нового уведомления само по себе не даёт основания считать, что деньги можно отправить повторно.
| Какие сведения есть | Что пока неизвестно | Действие с исходным платежом |
|---|---|---|
| Только ожидание на экране или тайм-аут соединения | Завершился ли перевод | Открыть его сохранённую запись и обновить через официальный кошелёк |
| Состояние всего платежа pending либо in flight | Успех или окончательный отказ | Отслеживать эту же операцию, не оплачивать новый инвойс |
| Неудачный маршрут внутри ещё работающего платежа | Результат остальных попыток или частей | Запросить итоговое состояние платежа целиком |
| Окончательный успешный результат | Возможно, соответствие платежа заказу | Сверить инвойс и заказ с получателем вместо повторной оплаты |
| Окончательный отказ исходного перевода | Причина и актуальность счёта | Разобрать ошибку и проверить текущий запрос перед повтором |
| Кошелёк и получатель показывают разное | Сравниваются ли одинаковые инвойс и сумма | Сопоставить payment hash и номер заказа по закрытому каналу |
Пустая история тоже не всегда устанавливает отсутствие платежа. Проверьте, не открыт ли другой профиль, не переключена ли сеть и завершено ли обновление данных. Зафиксируйте аккаунт, который реально запускал перевод. Переустановка приложения или восстановление на другом устройстве исключительно ради исчезновения ожидания может осложнить поиск. Сначала сохраните историю и воспользуйтесь поддерживаемым способом повторного подключения существующего кошелька, не удаляя исходные сведения об операции.
Срок инвойса, таймер приложения и ожидание перевода различаются
Срок действия запроса определяет, до какого момента его следует использовать для нового платежа. Это не тот же таймер, что ожидание ответа мобильным приложением, и не автоматическая отмена условий уже переданного перевода. Если инвойс успел истечь, пока на экране pending, одного этого недостаточно для вывода об отказе. Это также не доказывает, что зарезервированная сумма немедленно стала доступна для следующей оплаты.
В актуальной справке LND SendPaymentV2 прямо указано: отмена дальнейших попыток не исключает последующего успеха уже выполняющихся. Описание тайм-аута также не обещает немедленно прерывать отправленные HTLC. Это значения конкретной реализации, а не универсальная кнопка возврата. Не закрывайте каналы и не запускайте сторонние процедуры восстановления только для того, чтобы убрать надпись ожидания в интерфейсе кошелька.
Другой пример приведён в руководстве отправки Breez SDK. В описанном потоке Lightning достижение completion timeout может вернуть объект pending, а сведения о завершении поступят позднее. Это особенность данного API, без утверждения, что любой кошелёк использует Breez или Spark. Пример показывает, почему завершение ожидания вызывающей программой и окончательный результат денежной операции нельзя считать одним событием.
Запрашивайте поиск результата, а не повторную отправку
- Сохраните исходный инвойс, выбранный аккаунт, payment hash при наличии, сумму, время запуска и номер заказа получателя.
- Восстановите подключение того же кошелька и откройте подробности исходной операции. Сохраняйте изменения её состояния.
- Попросите получателя проверить именно соответствующий инвойс, а не общий баланс и не другой заказ.
- Если pending сохраняется, запросите у оператора явную проверку результата. Уточните, какие сведения подтвердят окончательный успех либо отказ.
- При успехе разбирайтесь с незачисленным заказом у получателя. При достоверном отказе сначала разберите причину и согласуйте актуальный счёт либо замену.
У операторов узлов есть отдельные способы запроса состояния. В документации Core Lightning listpays описаны сводные состояния и поиск по инвойсу или payment hash. В waitsendpay тайм-аут ожидания отделяется от окончательного результата. Эти справки нужны для разбора с ответственным специалистом. Они не предлагают обычному пользователю открывать доступ к узлу или исполнять найденную на форуме команду денежной отправки.
Обсуждая повтор, различайте поддерживаемое продолжение обработки того же платежа и создание нового обязательства по оплате. Фраза «в Lightning нельзя заплатить дважды» слишком широка для решения такой ситуации. Значение имеют формат запроса, реализация кошелька и появление нового счёта. Другое приложение автоматически не узнает, что первая программа ещё ждёт результат. Поэтому смена кошелька сама по себе не устраняет риск лишнего платежа.
Если в кошельке успех, а у получателя заказ не оплачен
Сначала сопоставьте payment hash, согласованную сумму и точный инвойс, а не только скриншоты остатков. Успешная оплата одного запроса не оплачивает другой автоматически, даже если оба выставлены для одной покупки. Попросите проверить привязку инвойса к заказу. Сохраняйте доказательство средствами кошелька и передавайте только стороне, разбирающей спор. Публиковать его в открытом обсуждении для привлечения случайных помощников не требуется.
Пример сообщения по закрытому каналу: «Исходный платёж в моём кошельке всё ещё pending. Прикладываю номер заказа, payment hash и время запуска. Проверьте, пожалуйста, именно этот инвойс и сообщите, видите ли вы завершение. Пока не сопоставим результат, замену оплачивать не буду». Если состояние изменится, дополните это обращение новыми сведениями. Несколько отдельных переписок без связи между идентификаторами затрудняют согласование результата и последующих действий.
Если в итоге согласован другой путь, сохраняйте исходный и заменяющий номера до закрытия вопроса. У обмена без регистрации своя заявка и условия принимаемого назначения, а страница Bitcoin даёт сведения об активе. Ни то ни другое не проверяет состояние вашего зависшего Lightning-платежа. Сначала выясните судьбу исходной операции, затем рассматривайте другой сервис как отдельный возможный способ перевода.
Частые вопросы
Чем поможет Lightning payment hash при зависшем переводе?
По нему стороны могут искать одну и ту же операцию вместо сравнения несвязанных скриншотов. Сам хеш не подтверждает итоговый успех и внутреннее зачисление на заказ.
Можно отправить новый Lightning payment, если старый ещё pending?
Сначала выясните окончательный результат существующего платежа. Независимая отправка создаёт ещё одну операцию, а не отменяет исходную.
Что означает Lightning invoice, если срок уже прошёл, но оплаты не видно?
Срок ограничивает использование запроса для новой оплаты, но не заменяет проверку ранее запущенного перевода. Попросите кошелёк и получателя сопоставить существующую операцию до выставления и оплаты замены.
По теме на сайте
Источники
- lightning.engineering/api-docs/api/lnd/router/track-payment-v2/
- lightning.engineering/api-docs/api/lnd/router/send-payment-v2/
- sdk-doc-spark.breez.technology/guide/send_payment.html
- docs.corelightning.org/reference/listpays
- docs.corelightning.org/reference/waitsendpay
- github.com/lightning/bolts/blob/master/11-payment-encoding.md