Сколько подтверждений ждать бизнесу при приёме крипты

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

Что доказывает подтверждение?

Подтверждение показывает, что сеть приняла транзакцию в свою историю и продолжила строить или подтверждать эту историю. Однако разные блокчейны приходят к расчёту по-разному. В сетях proof-of-work накапливается выполненная работа, в proof-of-stake участвуют голоса валидаторов, а некоторые механизмы консенсуса передают отдельный сигнал окончательности. Для бизнеса важен практический вопрос: достиг ли платёж достаточной надёжности, чтобы выдать товар, открыть доступ или начать услугу. Включение транзакции — ранний этап, а окончательность — более сильный результат. Если считать их одним и тем же, заказ можно выполнить раньше, чем сеть даст нужную уверенность.

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

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

Как должна работать политика с учётом сети?

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

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

Блокчейны используют разные правила консенсуса, наборы валидаторов и способы определения основной истории. В одних сетях приложение наблюдает, как цепочка продолжается, в других получает отдельное сообщение об окончательности блока. Эти механизмы нельзя сводить к одной межсетевой таблице с числами и сроками. Такая таблица быстро устареет и превратит справочную характеристику сети в постоянное обещание Paymos. Устройство Ethereum, TRON, BNB Chain, Polygon и других сетей описано в их официальной документации. Для реального платежа бизнесу нужно следовать состоянию счёта, рассчитанному для выбранной сети, суммы и текущих условий.

Что ломается при одном фиксированном правиле?

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

Что должна делать интеграция во время ожидания?

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

Что происходит при изменении недавней истории?

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