Квитанция об оплате криптовалютой — это подтверждение продавцом проверенного платежа по конкретному заказу. Она должна объяснять покупателю, что оплачено, к какой покупке относится платеж и куда обратиться с вопросом. Один лишь хеш транзакции не дает этого коммерческого контекста.
В этом руководстве приведены список необходимых сведений для квитанции и структура сообщения, которую можно использовать повторно. Это рекомендуемые меры организации учета, а не утверждение о том, что Yolfi формирует скачиваемые квитанции или налоговые счета. Юридические требования к документам зависят от юрисдикции; уточните у бухгалтера, какие реквизиты и виды документов обязана предоставлять ваша компания.
Различайте счет, квитанцию и запись в блокчейне
Счет содержит требование об оплате. Квитанция подтверждает уже проверенный платеж. Запись в блокчейне фиксирует транзакцию в определенной сети. Связывайте эти документы и записи между собой, но не считайте их взаимозаменяемыми.
| Документ или запись | Что сообщает | Чего не доказывает сам по себе |
|---|---|---|
| Коммерческий счет | Кто продавец, что покупают и сколько нужно заплатить | Что покупатель уже заплатил |
| Квитанция продавца об оплате | Платеж принят в счет определенного заказа | Что соблюдены все требования к налоговым документам |
| Хеш транзакции и сведения о переводе | Перемещение актива в указанной сети | Личность клиента или то, какую покупку оплачивает перевод |
| Подтверждение исполнения заказа | Товар или доступ предоставлены | Сумму платежа или порядок налогового учета |
Объект провайдера с названием «Invoice» может иметь и техническое значение. В Yolfi API Checkout объект Invoice создается после того, как покупатель выберет поддерживаемую сеть и токен. Не считайте этот технический объект коммерческим налоговым счетом, которого требуют местные правила.
Отправляйте квитанцию после проверки платежа, а не после перенаправления
При интеграции проверяйте уведомление о платеже на своем сервере, прежде чем отмечать заказ оплаченным или отправлять квитанцию об оплате. В документации Yolfi по вебхукам событие payment.confirmed указано как основной сигнал для исполнения заказа. invoice.created означает, что оплата начата, а не что деньги уже получены.
Проверяйте подлинность события по описанной в документации процедуре проверки подписи, связывайте его с нужным заказом и обрабатывайте повторные попытки доставки без создания нескольких самостоятельных квитанций. Тестовое событие не должно приводить к выдаче настоящей квитанции об оплате. Храните уникальный номер квитанции и используйте его же при повторной отправке того же документа.
Страницы об успешной оплате в браузере, снимка экрана кошелька или ожидающего вывода с биржи недостаточно. Если доказательства еще не проверены окончательно, отправьте сообщение о статусе платежа, а не подтверждение оплаты заказа. Используйте список доказательств для службы поддержки, чтобы разобраться в ситуации, не запрашивая секретные данные кошелька.
Для платежа, проверенного вручную, зафиксируйте, кто проверил адрес получателя, актив, сеть, сумму и доказательства подтверждения. Внутренний регламент должен определять, когда этих доказательств достаточно; эта статья не устанавливает единое число подтверждений для всех блокчейнов.
Укажите достаточно сведений для определения покупки и платежа
Квитанция для клиента должна легко читаться, а технические доказательства можно приложить к ней или хранить в закрытой записи заказа. Покупателю не должно требоваться расшифровывать журнал переводов токена, чтобы узнать свою покупку.
| Поле квитанции | Рекомендуемое содержание |
|---|---|
| Реквизиты документа | Уникальный номер квитанции и дата выдачи с часовым поясом |
| Продавец и покупатель | Реквизиты компании и необходимые для этой сделки сведения о клиенте |
| Ссылка на покупку | Номер заказа или коммерческого счета и краткое описание |
| Стоимость покупки | Исходная сумма и валюта цены, отдельно от количества криптовалюты |
| Принятый платеж | Точное количество, название актива и сеть, фактически прошедшие проверку |
| Доказательства платежа | Идентификатор платежа у провайдера и соответствующий идентификатор транзакции, если он доступен |
| Распределение средств | Сумма, зачтенная в этот заказ, и любой остаток к оплате или неурегулированная переплата |
| Обращение за помощью | Установленный канал поддержки и номер квитанции, который нужно сообщить |
Для токенов храните в исходной записи проверенный идентификатор контракта или выпуска токена (mint). Один тикер не позволяет однозначно определить актив. Если в клиентском документе длинный адрес или хеш сокращен, сохраните полный идентификатор в закрытой записи с доказательствами.
Разделяйте цену заказа и принятое количество криптовалюты. Если показываете эквивалент в местной валюте, укажите основание оценки и время, соответствующие вашему учету. Не называйте каждое поступление USDC или USDT долларовым банковским зачислением и не приравнивайте количество токенов к стоимости для налоговой отчетности без пояснений.
Комиссии тоже нужно обозначать ясно. Сетевая комиссия отправителя не обязательно входит в сумму, полученную продавцом. Не придумывайте разбивку комиссий на основании разницы между балансом кошелька и итогом счета.
Используйте эту структуру сообщения с квитанцией
Ниже приведен шаблон текста, а не настоящая квитанция клиента. Заполняйте каждую строку по проверенным записям, а не просите языковую модель выдумать идентификаторы транзакций.
Платеж получен — номер квитанции: ваш уникальный номер квитанции.
Продавец и покупка: реквизиты вашей компании, номер заказа и краткое описание того, что приобрел клиент.
Платеж: проверенное количество криптовалюты и актив, сеть, а также исходная сумма заказа и валюта цены.
Зачтено в этот заказ: сумма, принятая в оплату покупки, с явным указанием остатка к оплате или переплаты, рассматриваемой отдельно.
Доказательства: идентификатор платежа и соответствующий идентификатор транзакции, а также время подтверждения платежа и выдачи квитанции с часовыми поясами.
Вопросы или исправления: обратитесь по установленному каналу поддержки и сообщите номер этой квитанции. Никогда не отправляйте закрытый ключ или фразу восстановления.
Добавляйте сведения о покупателе, регистрационные номера и другие обязательные реквизиты только в той мере, в какой этого требуют ваша деятельность и местные правила. Не размещайте адрес электронной почты клиента, его имя или сведения о покупке в общедоступных примечаниях в блокчейне.
Отправляйте квитанцию через страницу заказа с проверкой подлинности пользователя или по проверенным контактным данным клиента для этой покупки. Не открывайте полные записи заказа через незащищенную общедоступную ссылку на документ. Общедоступная транзакция тоже может раскрыть финансовую активность, если связать ее с конкретным клиентом.
Используйте доказательства транзакции, не преувеличивая их значение
Одна транзакция может содержать несколько переводов. Если один хеш охватывает несколько перемещений токенов, выделите нужный перевод во внутренних доказательствах, а не прикладывайте один и тот же хеш без уточнений к нескольким заказам.
Для токенов EVM справочник по квитанциям транзакций Ethereum описывает статус транзакции и журналы событий. Одно лишь успешное выполнение не доказывает, что ожидаемое количество токенов поступило на адрес продавца. Проверьте сведения о нужном переводе: получателем на верхнем уровне транзакции может быть контракт токена.
Если даете ссылку на общедоступные доказательства, используйте надежный обозреватель нужной сети. Просмотр публичной транзакции не должен требовать подключения кошелька, подписи или разрешения на расходование токенов. Квитанция не должна превращаться в приглашение «проверить» оплату на незнакомом сайте, запрашивающем доступ к кошельку.
Учитывайте частичные платежи и возвраты, не переписывая историю
При частичной оплате подтверждайте только проверенную и зачтенную сумму. Не отмечайте весь заказ оплаченным, пока вопрос с остатком не решен. При переплате отделяйте сумму, зачтенную в заказ, от суммы, ожидающей рассмотрения. Эти решения разобраны в руководстве по недоплатам и переплатам.
Для последующего возврата нужна отдельная связанная запись. Сохраняйте исходную квитанцию, решение о возврате и проверенные доказательства исходящего платежа; не заменяйте первоначально принятую сумму меньшим числом. Перед переводом денег на адрес из сообщения выполните процедуру проверки возврата.
Исправляйте ошибки в реквизитах через прослеживаемую процедуру корректировки. Нужны ли официальная кредит-нота, заменяющий документ или другая корректировка — вопрос бухгалтерского учета в конкретной юрисдикции. Сохраняйте связь между версиями, а не удаляйте прежние доказательства.
Роль Yolfi
Платежные ссылки Yolfi служат точкой входа для оплаты предложений с фиксированной ценой. Документация API Checkout различает многократно используемые Paylinks и создаваемые сервером Checkout Sessions для динамических заказов; отдельной сессии не требуется Paylink.
Ваша компания должна хранить описание заказа и сведения о взаимоотношениях с клиентом, а затем связывать доступные идентификаторы платежей со своим процессом выдачи квитанций. Прежде чем автоматизировать документы, проверьте, какие поля предоставляет ваш текущий процесс. Ни общедоступная страница монеты, ни эта статья не подтверждают доступность конкретного сочетания актива и сети, экспорта документов или интеграции с бухгалтерскими системами.
Для контроля в конце дня список сверки объясняет, как связать распределение средств по заказам с движениями в кошельке. Квитанции клиентов отвечают на вопрос «за что я заплатил?», а ежедневная сверка — на вопрос о полноте учета компании.
Часто задаваемые вопросы
Является ли хеш транзакции квитанцией об оплате криптовалютой?
Сам по себе — нет. Он определяет транзакцию в сети, но не устанавливает личность покупателя, описание покупки или зачет суммы в заказ. Квитанция продавца добавляет этот коммерческий контекст после проверки.
Можно ли отправить квитанцию, пока перевод ожидает выполнения?
Отправьте сообщение о статусе, а не квитанцию об оплате. Подтверждайте проверенный платеж только тогда, когда он принят согласно вашему документированному процессу подтверждения. Не обещайте, что ожидающий вывод поступит в определенное время.
Заменяет ли криптовалютная квитанция налоговый счет?
Не автоматически. Подтверждение платежа и выставление документов по требованиям закона могут решать разные задачи. Уточните у квалифицированного местного консультанта, какие сведения и документы ваша компания обязана хранить и выдавать.
Нужно ли показывать в квитанции всю историю кошелька?
Нет. Ограничьте доказательства соответствующим платежом. Храните необходимые технические сведения в закрытых записях, ограничивайте доступ и никогда не запрашивайте закрытые ключи или фразы восстановления.
Итог: подтверждайте платеж и сохраняйте контекст
Полезная квитанция связывает проверенное поступление средств с понятной покупкой, не утверждая больше, чем подтверждают доказательства. Начните с ясных инструкций по оплате, выдавайте одно прослеживаемое подтверждение на каждую запись о принятом платеже и сохраняйте связанные исправления или возвраты вместо изменения исходной продажи.
