# От обнаруженной транзакции до сверенного заказа: подтверждения и реорганизации | SwissOctet Insights https://swissoctet.com/ru/insights/confirmations-reorgs-order-reconciliation/ SwissOctet / Аналитика / Криптоплатежи Криптоплатежи Продвинутый · 4 мин чтения От обнаруженной транзакции до сверенного заказа: подтверждения и реорганизации Проектируйте состояния платежа на основе проверенных данных цепочки, явных правил приёма и однозначной привязки к заказу, а не заявления браузера о том, что средства отправлены. От редакции SwissOctet Сохранить руководство Скопировать ссылку НА ЭТОЙ СТРАНИЦЕ 01 Отделяйте событие цепочки от события заказа 02 Используйте правила уверенности для конкретной цепочки 03 Проверяйте фактическое содержимое перевода 04 Делайте привязку к заказу однозначной 05 Определите состояния, допускающие поздние и изменяющиеся данные 06 Делайте повторные попытки безопасными и наблюдаемыми 07 Знайте, что ещё нужно заказу в ожидании Ваш практический чек-лист Источники и дополнительное чтение Назад в библиотеку ПРЯМОЙ ОТВЕТ Обнаружение транзакции, подтверждение в сети, привязка к заказу и предоставление услуги — это отдельные шаги. Проверьте правильную сеть, актив, получателя и сумму; применяйте документированную политику приёмки; сделайте сверку идемпотентной. Ссылка на транзакцию, скриншот или кнопка в браузере сами по себе не могут подтвердить, что конкретный заказ был оплачен. 01 Отделяйте событие цепочки от события заказа Кошелёк, сообщающий, что перевод был отправлен, даёт свидетельство о собственном действии, а не полное решение о платеже. Принимающий бэкенд должен наблюдать предполагаемую сеть, проверить фактический перевод и связать его с заказом. Только после этого заказ может применить свою политику приёмки. Предоставление инфраструктуры — это ещё один операционный шаг после приёмки платежа. Сохраняйте эти переходы явными как в коде, так и в языке общения с клиентом. Экран может показывать ожидание, обнаружение или подтверждение, не называя заказ оплаченным. Не позволяйте браузеру передавать принятую сумму или перезаписывать авторитетный статус. Храните созданное сервером предложение и его инструкции, чтобы последующую сверку можно было оценивать относительно исходного заказа, а не меняющейся корзины. 02 Используйте правила уверенности для конкретной цепочки Разные сети описывают достоверность транзакции по-разному. Руководство для разработчиков Bitcoin объясняет, как узлы выбирают цепь с наибольшим накопленным доказательством работы и как могут возникать конкурирующие блоки. Поэтому транзакция, увиденная недавно, требует политики в отношении глубины подтверждения и возможных изменений цепи. Не существует единого числа подтверждений, подходящего для любого актива и коммерческого риска. Документация Ethereum о доказательстве доли объясняет финальность контрольных точек, а Solana описывает состояния обязательств processed, confirmed и finalized. Не переводите эти термины небрежно в одно универсальное число блоков. Фиксируйте правило, специфичное для сети, источник информации и поведение в условиях неопределённости. Оператор должен определять пороги приёмки исходя из риска платежа и поставки, а не копировать число из несвязанного процесса оформления заказа. 03 Проверяйте фактическое содержимое перевода Определите получателя, актив и сумму в правильной сети. Платежи в токенах требуют идентичности предполагаемого токена, а не просто успешной транзакции на адрес. Проверьте успешность выполнения и доказательство перевода в соответствии с моделью цепи. Разбирайте целочисленные суммы с правильной точностью актива, а не доверяйте форматированному десятичному значению, переданному браузером. Платёжная инструкция должна оставаться привязанной к своему исходному маршруту. Перевод в другой сети, другой токен с тем же символом или несвязанная ссылка на транзакцию не должны её удовлетворять. Запись о проверке должна объяснять, что было проверено, и сохранять доказательства, необходимые для пересмотра решения. Это руководство описывает общие принципы сверки платежей, а не конкретную реализацию сервиса. 04 Делайте привязку к заказу однозначной Фиксированные адреса получения могут принимать несколько заказов с похожими суммами. Наличие совпадающего перевода не доказывает, какому клиенту или заказу следует зачислить платёж. Определите метод привязки до приёма реальных платежей и предусмотрите обработку коллизий. Предоставленная пользователем ссылка на транзакцию всё равно требует проверки, что тот же перевод не был ранее отнесён к другому заказу. Представьте два счёта на одну и ту же сумму по одному маршруту в перекрывающемся окне. Наблюдатель видит один перевод. Автоматически помечать оба как оплаченные неправильно; выбрать один без достаточных доказательств тоже небезопасно. Оставляйте перевод нераспределённым или на проверке, пока политика оператора не позволит установить допустимую привязку. Неоднозначное совпадение — это состояние, которое нужно обработать, а не повод выдумывать определённость. 05 Определите состояния, допускающие поздние и изменяющиеся данные Платёжный процесс выигрывает от небольшого набора чётких состояний, где доказательства из цепи отделены от решения принять заказ. Эта иллюстративная таблица объясняет возможные этапы, а не описывает названия статусов конкретного сервиса. У каждого перехода должна быть проверенная причина, а приёмка платежа должна оставаться отдельной от предоставления инфраструктуры. Учитывайте поздние, частичные и избыточные переводы, истечение срока предложения и временную недоступность данных цепи. Истечение срока не заставляет реальный перевод исчезнуть. Поздний платёж может потребовать проверки, а не автоматической приёмки или отклонения. Если ранее наблюдавшееся событие цепи изменилось, переоцените состояние согласно документированной политике, а не считайте каждое уведомление наблюдателя необратимой истиной. Иллюстративное состояние Значение Следующее решение Ожидание Нет проверенного подходящего перевода Продолжать наблюдение за действительным счётом Обнаружено Обнаружен релевантный перевод Проверить достоверность цепи и привязку Подтверждение Правило приёмки ещё не выполнено Наблюдать, пока политика не позволит принять решение Проверка Поздние, частичные или неоднозначные доказательства Урегулировать согласно политике оператора Принято Проверенный и сверенный платёж Перейти к отдельному процессу предоставления услуги 06 Делайте повторные попытки безопасными и наблюдаемыми Наблюдатели и задачи сверки будут повторять попытки после прерванных соединений или перезапусков процесса. Используйте стабильный идентификатор перевода, например цепь и соответствующий идентификатор транзакции или перевода, чтобы предотвратить дублирующиеся зачисления. Сохраняйте ход выполнения и решения, чтобы одно и то же событие можно было обработать повторно без предоставления второй услуги или изменения принятого предложения. Отличайте неизвестный результат от неудачной операции. Если нижестоящий запрос завершается по тайм-ауту, проверьте его авторитетный результат перед повторной отправкой. Ведите долговременные записи о принятых и неопределённых действиях. Ограничьте доступ к токенам заказа и внутренним доказательствам, сохраняя достаточно информации для расследования спорного платежа. Надёжность здесь — это воспроизводимые решения, а не плавная анимация при оформлении заказа. 07 Знайте, что ещё нужно заказу в ожидании Заказ может оставаться в ожидании, потому что перевод не был обнаружен, требуемая достоверность цепи не достигнута или его привязка к счёту требует проверки. Сохраните счёт и публичную ссылку на транзакцию, проверьте указанные правила приёмки и используйте предусмотренный для заказа процесс обращения за помощью. Задержка обновления статуса сама по себе не является причиной отправлять ещё один платёж. Следуйте инструкциям и проверенному статусу для фактического заказа. Подтверждение оплаты должно обозначать приёмку сверенного перевода, тогда как предоставление услуги имеет отдельный статус. Не включайте приватные токены доступа и секреты кошелька в запросы о помощи. ПРЕВРАТИТЕ ЭТО В ДЕЙСТВИЕ Ваш практический чек-лист. ✓ Сохраняйте неизменяемое предложение, созданное сервером. ✓ Проверьте цепь, получателя, актив и целочисленную сумму. ✓ Документируйте правила приёмки, специфичные для цепи. ✓ Обрабатывайте коллизии фиксированных адресов без догадок. ✓ Предотвращайте дублирующиеся зачисления и небезопасные повторные отправки. ✓ Тестируйте случаи поздних, частичных переводов, неверного маршрута и изменившихся доказательств. Скачать чек-лист ЧАСТЫЕ ВОПРОСЫ Детали, которые важны. Достаточно ли хеша транзакции для подтверждения оплаты? + Нет. Проверьте перевод в предполагаемой цепи, его полезную нагрузку и достоверность, затем установите, что он принадлежит заказу и ещё не был зачислен. Могут ли все сети использовать один и тот же порог подтверждения? + Нет. Сети предоставляют разные модели достоверности и финальности. Оператор должен определить и протестировать политику приёмки, подходящую для каждого маршрута. Означает ли подтверждённая оплата, что сервер предоставлен? + Нет. Приёмка платежа и предоставление услуги — это отдельные события процесса. Сообщайте статус предоставления из его собственного авторитетного процесса. ОСНОВНЫЕ ИСТОЧНИКИ Перейдите к источнику. Эти источники поддерживают технические концепции в этом руководстве. Следуйте актуальной документации, прежде чем менять производственную систему. Руководство для разработчиков Bitcoin: поведение блокчейна developer.bitcoin.org Ethereum: доказательство доли и финальность ethereum.org Solana: фиксация состояния RPC solana.com Редакционное руководство от SwissOctet. Примеры иллюстративны. Спецификации услуг, доступные опции и договорные условия необходимо проверять отдельно. СВЯЖИТЕ ЗНАНИЯ Связанная инфраструктура. Vector VPS Швейцария Metal Hyper Швейцария Veil Onion Швейцария СОХРАНЯЙТЕ НИТЬ Ваши следующие заметки. Изучите все руководства ЗАМЕТКА / 01 + Облако и VPS Основа Как выбрать VPS, не гадая Превратите идею приложения в полезный бюджет ресурсов, затем сравните CPU, память, хранилище и передачу вместе. 4 мин чтения Читать руководство ЗАМЕТКА / 02 + Криптоплатежи Основа Криптооформление заказа и пределы приватности платежей Разберитесь в пути актива, сети и подтверждения и защитите информацию, которая связывает ваш проект с платежом. 4 мин чтения Читать руководство ЗАМЕТКА / 03 + Криптоплатежи Основа Выберите актив и сеть перед подготовкой криптоплатежа Рассматривайте платёжный маршрут как полную пару «актив и сеть», затем проверьте инструкции счёта, идентичность токена и доставленную сумму перед авторизацией перевода. 4 мин чтения Читать руководство