Как сверять криптоплатежи с заказами, чтобы не потерять ни одной оплаты

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

Что такое сверка платежей и чем она отличается в криптовалюте

Сверка платежей — это сопоставление двух списков: того, что вы ждёте, и того, что реально пришло. Магазин ждёт 100 долларов за заказ номер 1540; на счёт приходит перевод на 100 долларов с пометкой «заказ 1540»; сверка ставит галочку. Если перевода нет или сумма другая, сверка показывает расхождение, и с ним уже разбирается человек.

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

• Нет назначения платежа. В переводе USDT по сети TRON или Ethereum негде написать «за заказ 1540». Есть только адрес получателя, сумма и номер транзакции (TXID).
• Нет имени плательщика. Адрес отправителя ничего не говорит о покупателе: он мог платить с биржи, где с одного адреса уходят переводы тысяч людей.
• Сумма приходит неточной. Покупатель округлил, биржа удержала комиссию за вывод, курс сдвинулся за время оплаты. Вместо 100 USDT приходит 99,2.
• Перевод нельзя отменить. Лишнее или ошибочное не отзовёшь через банк: возврат — это новый перевод в обратную сторону, который делаете вы.

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

Две стороны сверки: заказы и переводы

У сверки две стороны, и у каждой свой набор полей:

• База заказов — ваша система: номер заказа, сумма и валюта счёта, адрес или сумма-метка, которые вы выдали покупателю, время создания и срок, в который ждёте оплату.
• Список входящих переводов — сеть или отчёт платёжного сервиса: сеть, адрес, сумма, TXID, время и число подтверждений.

Сверка — это соединение двух списков по общему ключу. Ключей в криптовалюте четыре, и обычно их используют вместе:

• Адрес. Самый надёжный ключ, если на каждый заказ выдан свой адрес. Перевод на адрес заказа 1540 — оплата заказа 1540, что бы ни было в сумме.
• Сумма. Работает, когда адрес общий. Каждому заказу назначают чуть отличающуюся сумму: 100,013 USDT одному, 100,027 другому. У USDT в сетях TRON и Ethereum шесть знаков после запятой, так что места для таких меток хватает.
• TXID. Номер транзакции уникален во всей сети. Он ничего не говорит о заказе сам по себе, но именно по нему вы помечаете перевод как учтённый, чтобы не зачесть его дважды.
• Время. Вспомогательный ключ: перевод, пришедший за минуту до закрытия счёта, и перевод, пришедший через два часа после, — разные случаи, хотя сумма и адрес совпадают.

Как привязать перевод к заказу, если принимаете на свой кошелёк

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

• Свой адрес на каждый заказ. Кошельки с иерархией ключей (их называют HD-кошельками) умеют выдавать сколько угодно адресов из одного главного ключа. Заказ создан — адрес выдан; перевод на него не спутаешь ни с чем. Это лучший способ, но ему нужна автоматизация: вручную вести сотни адресов не выйдет.
• Своя сумма на каждый заказ. Адрес один, а к сумме добавляют копейки-метку. Способ простой, но ломается, если покупатель округлил или его биржа удержала комиссию: 100,013 превращается в 99,013, и метка теряется.
• Тег или memo в самом переводе. В некоторых сетях у перевода есть поле для короткой пометки: так устроены, например, TON и XRP. В TRON и Ethereum, где ходит больше всего USDT, такого поля нет, так что для них способ не работает.
• TXID от покупателя. После оплаты покупатель сам присылает номер транзакции, а вы находите перевод в сети и привязываете к заказу руками. Для десятка заказов в месяц этого хватает, для сотни — уже нет.

Какой бы способ вы ни выбрали, найденный перевод всё равно нужно проверить: та ли сеть, та ли монета, достаточно ли подтверждений. Что именно смотреть в обозревателе блоков и как отвечать покупателю, пока оплата не подтвердилась, — отдельный разбор о том, как проверить криптовалютный платёж по TXID, сети и статусу.

Как сверка устроена при приёме через платёжный сервис

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

• Выдаёт отдельный адрес на каждый заказ.
• Следит за сетью и считает подтверждения.
• Сообщает вашему сайту о каждой смене статуса сообщением на ваш сервер — вебхуком.

Вам остаются два действия: при создании заказа сохранить у себя пару номеров — свой номер заказа и номер, который этому заказу выдал сервис, — а при получении вебхука найти по номеру сервиса свой заказ и обновить ему статус. Эта пара и есть ключ сверки. Потерять её нельзя: уведомление «оплачено 100 USDT» приходит с номером сервиса, и без сохранённой пары его не привязать ни к чему.

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

• created — покупатель выбрал валюту и получил адрес, сервис ждёт оплату.
• pending — перевод замечен в сети и ждёт подтверждений.
• crediting — подтверждений достаточно, средства зачисляются на баланс.
• finished — платёж завершён.

Сумма, зачисленная после всех комиссий, приходит в поле income только в вебхуке статуса finished — именно её и сверяют с итогом дня. Если вебхук потерялся, состояние заказа можно запросить с сервера CryptumPay; история операций и статусы есть и в личном кабинете.

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

Расхождения, которые находит сверка, и что с ними делать

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

• Недоплата. Пришло 99,2 USDT вместо 100. Заказ не оплачен полностью, но и деньги не чужие. Решение зависит от размера разницы: мелкую можно простить, на заметную — попросить доплатить.
• Переплата. Пришло 105 USDT вместо 100. Заказ оплачен, а лишние 5 USDT нужно либо вернуть, либо зачесть покупателю на будущее, и в обоих случаях — записать.
• Перевод после закрытия счёта. Счёт на оплату жил полчаса, покупатель отправил деньги через час. Деньги на адресе, а заказ уже отменён, и сверка видит перевод без пары.
• Два перевода на один заказ. Покупатель нажал «отправить» дважды. Один перевод закрывает заказ, второй — переплата целиком.
• Перевод есть, заказа нет. Деньги пришли на адрес, к которому не привязан ни один заказ, или в сети, которую вы не принимаете. Такие переводы ищет сама сверка: без неё они лежали бы на кошельке незамеченными.
• Заказ есть, перевода нет. Покупатель мог просто передумать, и тогда заказ закрывается по сроку. Но если он уверяет, что заплатил, перевод нужно искать по TXID.

Разбирать недоплату и переплату руками не обязательно: если у платёжного сервиса есть допуск по сумме, мелкую разницу он закрывает сам. У CryptumPay допуск в процентах задаёт сам продавец: если разница укладывается в него, платёж подтверждается без вопросов; если недоплата больше допуска, окно оплаты само просит покупателя доплатить, и на это у него есть до двух попыток. Переплату покупатель запрашивает назад из того же окна оплаты, и возврат делает CryptumPay, а не вы вручную.

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

Сверка сумм: почему у одного заказа три разных числа

Самая частая путаница в сверке криптоплатежей — не адреса, а суммы. У одного заказа их оказывается три, и все три верные:

• Сумма счёта. То, что вы выставили покупателю: 100 долларов или 9 000 рублей. Это число живёт в вашей базе заказов и в бухгалтерии.
• Сумма перевода. То, что ушло из кошелька покупателя: 100,4 USDT или 0,0011 BTC по курсу на момент оплаты. Это число живёт в сети, и именно его видит обозреватель блоков.
• Сумма зачисления. То, что реально легло на ваш баланс после сетевой комиссии и комиссии сервиса: 99,4 USDT. Это число живёт в отчёте сервиса или на вашем кошельке.

Сверять заказ нужно со второй суммой: она отвечает на вопрос «заплатил ли покупатель». Третью сумму сверяют уже не с заказом, а с итогом дня: сколько всего должно было лечь на баланс после комиссий и сколько легло. Если хранить только одно из трёх чисел, через месяц не получится объяснить ни бухгалтеру, ни себе, куда делись 0,6 USDT с каждого заказа.

У CryptumPay сумму счёта выставляют в одной из обычных валют — долларах, евро, рублях, тенге, юанях и ещё девяти, — и это только валюта номинала. Какой бы монетой ни заплатил покупатель, при поступлении она сразу конвертируется в USDT, и платёж зачисляется на USDT-баланс продавца. Комиссия CryptumPay — 1 % за успешный платёж, на больших объёмах от 0,5 %, и её можно переложить на покупателя. Сумма, зачисленная после всех комиссий, приходит в поле income вебхука finished, так что третье число у вас есть в момент завершения платежа, а не в конце месяца.

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

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

Сверка, которую делают «когда накопится», превращается в разбор полугодовой кучи. Рабочий ритм — раз в день, и у процедуры пять шагов:

1. Выгрузить переводы за день. Из личного кабинета платёжного сервиса или из кошелька: сеть, адрес, сумма, TXID, время, статус. Если сервис шлёт вебхуки, этот список у вас уже накопился на сервере.
2. Выгрузить заказы за тот же день. Из своей системы: номер, сумма счёта, выданный адрес или сумма-метка, статус, время.
3. Соединить два списка по ключу. По адресу или номеру заказа — автоматически, скриптом или формулой в таблице. Каждую найденную пару пометить TXID, чтобы перевод не был зачтён второй раз.
4. Разобрать остаток. Всё, что осталось без пары, — это список расхождений из прошлого раздела. По каждому принять решение и записать его: доплата, возврат, зачёт, ожидание.
5. Закрыть день. Сложить суммы зачислений и сравнить с движением баланса за день. Сошлось — день закрыт; не сошлось — искать перевод, которого нет в выгрузке.

Чтобы потом не восстанавливать платёж по памяти, от каждого стоит хранить четыре группы полей:

• Идентификаторы: номер заказа и TXID.
• Маршрут: сеть и адрес, на который пришёл перевод.
• Деньги: сумма перевода в монете, сумма зачисления, курс и сумма в валюте счёта на момент оплаты.
• Время: дата и время перевода.

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

Коротко

• В криптопереводе нет назначения платежа, поэтому заказ помечают заранее: отдельным адресом, суммой-меткой или, где сеть позволяет, тегом.
• Сверка — это соединение двух списков (заказы и переводы) по ключу и разбор того, что осталось без пары.
• Платёжный сервис делает за вас первую половину: выдаёт адрес, следит за сетью и сообщает статус вебхуком; ваша задача — хранить пару номеров заказа, свой и сервиса, и верить статусу с сервера, а не странице «спасибо».
• У каждого заказа три суммы: счёт, перевод, зачисление. С заказом сверяют перевод, с итогом дня — зачисление.
• Ритм — раз в день, и остаток без пары важнее галочек.

Вопросы и ответы

Как проверить, что USDT действительно поступил, если покупатель говорит, что оплатил?

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

Можно ли выгрузить криптоплатежи в 1С?

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

Есть ли готовые библиотеки на Python, чтобы проверять поступления самому?

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

Что делать, если перевод пришёл, а заказа под него нет?

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

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

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

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