Ступенчатая политика подтверждений: ждём по сумме платежа

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

Что решает политика подтверждений?

Политика подтверждений — это правило, которое превращает сырое событие сети в подтверждённый результат платежа. В зависимости от сети политика может учитывать глубину блока, сигнал финальности протокола или другие текущие данные. Paymos объединяет выбранную сеть с суммой платежа и текущими условиями блокчейна, а затем передаёт состояние счёта и отправляет вебхук. Магазину не нужно знать внутреннее требование, чтобы безопасно исполнить заказ.

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

Почему безопасное ожидание зависит от суммы?

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

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

Как ступенчатая политика выглядит на практике?

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

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

Для бизнеса правило простое: исполнять заказ только после подтверждённого результата. Любое учебное число объясняет механику, но не описывает рабочие параметры Paymos. В руководстве по подтверждениям разобрано, почему одинаковое число блоков не означает одинаковую безопасность в разных сетях.

Как финальность протокола влияет на политику?

Сеть с доказательством доли может давать сигнал финальности, а не опираться только на наблюдаемую глубину блока. Например, Ethereum организует финальность через контрольные точки Casper FFG. Такой сигнал является частью модели консенсуса выбранной сети, но не даёт магазину способ воспроизвести политику Paymos. Процессор всё равно оценивает сеть, сумму платежа и текущие условия вместе.

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

Поэтому одна сеть не означает одно постоянное правило магазина. Интеграция должна опираться на переданное состояние платежа, а не воспроизводить внутренние требования.

Почему политика должна учитывать изменения сети?

Поведение сети меняется вместе с механизмом консенсуса и обновлениями протокола. Обновление Fermi в BSC и Heimdall v2 в Polygon показывают, почему значения из статьи нельзя закреплять в коде магазина. Толкование работы сети должно оставаться внутри текущей политики процессора.

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

Когда фиксированное число подтверждений — правильное решение?

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

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

Как Paymos меняет требования к подтверждению?

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

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

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