Реорганизация цепочки и подтверждённый платёж

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

Для бизнеса вопрос ровно один. Может ли заказ, который вы уже отгрузили, оказаться неоплаченным? В Paymos — нет: подтверждённый платёж остаётся зачисленным мерчанту, а недостачу платформа записывает на свои счета как убыток от реорганизации.

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

Что реорганизация делает с платежом?

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

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

Может ли пропасть платёж, который Paymos уже подтвердил?

Подтверждение — может, зачисление — нет. Paymos подтверждает платёж раньше финальности протокола, на глубине, выбранной по сети и сумме. Это осознанный выбор в пользу скорости оплаты: ждать абсолютной финальности в каждой сети означало бы сделать часть платежей неприемлемо медленными на странице оплаты. У выбора есть цена, и её стоит называть прямо — блок уже подтверждённого платежа изредка может оказаться отброшенным.

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

Кто несёт этот убыток?

Его несёт платформа. Решение подтвердить платёж на такой-то глубине, в такой-то сети, для такой-то суммы принимает процессор — ради того, чтобы плательщик не ждал. Когда решение оказывается неверным, средств действительно нет, и разрыв должен лечь на чей-то баланс. Положить его на мерчанта означало бы поставить ответственность бизнеса в зависимость от чужой оценки риска: её делал не он и увидеть её он не может.

Это политика, а не закон природы. И спросить о ней стоит у любого процессора, прямым текстом: когда вы подтверждаете раньше финальности, а цепочка с вами не соглашается — чей баланс двигается? Там, где над этим не думали, ответа не будет. Там, где думали, назовут счёт.

Как бизнес узнаёт, что это случилось?

На платёжных каналах — вебхуком. payment_channel.deposit.reorged — одно из трёх событий депозита, рядом с confirming и confirmed, и приходит по той же подписке. Список событий и их значения собраны в справочнике по вебхукам.

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

Что должна делать система заказов?

Как правило — ничего нового. Порядок в вашей системе уже такой, какой нужен: заказ не оплачен, затем подтверждён, затем исполнен. Реорганизация не добавляет к этому четвёртого состояния — баланс не меняется, сводить нечего.

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

Почему запись о переводе не удаляют?

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

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

Когда считается, что блок действительно исчез?

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

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

Ниже финализированной высоты автоматики нет. Если реорганизация всё-таки уходит туда, её не сводят на ходу — сканирование этой сети останавливают. Нарушение правил протокола не разбирают без человека.

Что будет, если транзакция вернётся в цепочку?

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

Баланс мерчанта не двигается: он не двигался и в первый раз. На один платёж приходится одно зачисление, и оно остаётся одним, что бы за это время ни сделала цепочка. Ради этого вся конструкция и устроена так.

Как проверить свой обработчик заранее?

Симулировать событие в песочнице. Симуляция депозита принимает стадию, и reorged — одна из трёх, вместе с confirming и confirmed. Параметры вызова описаны в симуляции депозита канала.

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