495 / 736PAY·PROC

Bitcoin Payment Processor

Процессор биткоин-платежей

Клиент платит биткоином, но магазину ещё нужно понять, какой заказ оплачен, верна ли сумма и когда отправлять товар. Bitcoin Payment Processor связывает эти шаги. Под одним названием могут скрываться собственная программа и сервис, выплаты от которого продавец должен ждать.

Bitcoin Payment Processor — программа или сервис, создающий платёжные запросы, отслеживающий поступления и связывающий их с заказами. Он помогает выполнять продажи и сохранять записи. Он не устанавливает правила сети Bitcoin и не обязательно хранит деньги клиентов: контроль ключей и порядок выплат зависят от конкретной схемы.

Представим покупателя, заказывающего книгу онлайн. Магазин просит процессор создать invoice — платёжный запрос с суммой и валютой — и сохраняет его идентификатор рядом с номером заказа. Покупатель открывает платёжную страницу или сканирует QR-код и платит. Сохранённая связь показывает, к какой покупке относятся деньги. Без неё одного факта поступления биткоина куда-либо недостаточно. Возврат на страницу «Спасибо за заказ» тоже не доказывает, что магазин получил оплату. [1]

BTCPay Server может создавать адреса получения из публичных данных существующего кошелька без закрытых ключей, позволяющих тратить деньги. Это отличается от горячего кошелька с ключами на сервере или доступа к средствам узла Lightning для быстрых платежей. В сервисе провайдер может контролировать деньги до выплаты. Поэтому одного обозначения non-custodial, то есть без передачи ключей провайдеру, недостаточно. Проверяйте реальные права, кто может отправить средства и требуется ли чужое согласие, чтобы их получить. [2] [6]

Цена книги может быть указана в обычной валюте, хотя покупатель отправляет биткоин. BTCPay Server фиксирует сумму и курс в запросе на ограниченное время. Истечение срока не мешает более позднему переводу поступить; магазин должен правильно его обработать. То же относится к недоплатам и переплатам. Исходная сумма и курс остаются в учёте для сверки. Новый запрос при другом курсе может требовать иное количество сатоши, мельчайших единиц биткоина, даже если цена книги не изменилась. [3]

В BTCPay Server Processing означает, что запрошенная сумма оплачена, но условия завершения ещё не выполнены, например не хватает подтверждений транзакции в блоках. Settled означает, что условия выполнены; платежи Lightning обычно не ждут подтверждения в блоке. Другие сервисы определяют свои статусы. BitPay прямо предупреждает: paid не гарантирует оплату. Правило отправки должно соответствовать документации выбранного сервиса и способу платежа. Ручная отметка «оплачено» не заменяет проверку реального поступления. [3] [5]

Процессор сообщает об изменениях через webhook — автоматическое сообщение между серверами. Магазин проверяет его происхождение и содержимое. В BTCPay HMAC-SHA256 вычисляют из исходных байтов сообщения и общего секрета: это код аутентификации, а не подтверждение сети Bitcoin. BitPay не подписывает уведомление IPN; оно лишь запускает проверку настоящего статуса через API, интерфейс взаимодействия программ. Сообщение может прийти снова. Магазин фиксирует выполнение заказа, чтобы не отправить его повторно. После сбоя сохранённые статусы сверяют с процессором. [4] [5]

Получение платежа клиента и выплата от сервиса — разные события. BitPay позволяет выбрать поддерживаемую валюту расчёта и банковский счёт или криптовалютный адрес; изменения могут требовать одобрения. Продавец также проверяет сроки, лимиты, комиссии и контроль средств до выплаты. При прямом поступлении в собственный кошелёк такого промежуточного шага может не быть. Система продаж должна различать эти схемы, чтобы слово «оплачено» не создавало ложного представления об уже доступных деньгах. [6] [2]

Возврат денег не стирает исходную транзакцию Bitcoin. Магазин сначала рассматривает запрос, определяет сумму и валюту, проверяет получателя и организует новый платёж. Ссылка для запроса возврата ещё не означает, что деньги отправлены. В учёте остаются заказ, платёжный запрос, поступление, курс, комиссии и возврат. Экспортированные отчёты помогают бухгалтеру, но сами не выполняют все местные требования. Подтверждение сети также не разрешает спор о доставке и не отменяет договорные или законные обязанности при рассмотрении претензий. [7] [8] [10]

Одной удачной пробной покупки перед запуском мало. Проверяют недоплату, запоздалый платёж, повторные уведомления и восстановление после сбоя. API-ключ — учётные данные программы для доступа: ему дают только необходимые права для нужного магазина. Дополнительные сведения не должны включать лишние персональные данные. Собственная эксплуатация требует хостинга, обновлений и поддержки; Lightning также требует управления ликвидностью, то есть средствами и доступным пространством в каналах для платежей. Бесплатная программа не означает бесплатную эксплуатацию. Доступность, защита ключей и правильное подключение магазина проверяются отдельно. [1] [9]

Пример · PAY·PROC

Оплаченная книга и повторное сообщение

Магазин связывает платёжный запрос с заказом OBJ-101. Проверив оплату и выполнив условия отправки, он отправляет книгу и фиксирует исполнение. Позже то же уведомление приходит снова. Система узнаёт выполненный заказ и не создаёт ещё одну посылку. Простого открытия страницы благодарности для отправки было бы недостаточно.

Для полной картины прочитайте эту статью вместе с BTCPay Server, Bitcoin Point of Sale, Merchant Adoption, Lightning Network, Bitcoin. На эту статью также ссылаются Оплата биткоином в Alza, Merchant Adoption, BTCPay Server, Bitcoin Point of Sale.

01Нужно ли доверять биткоин процессору?

Не всегда. Программа может отслеживать поступления в ваш кошелёк без ключей для расходования. Горячий кошелёк на сервере, доступ к узлу Lightning или сервис с последующей выплатой предполагают другие условия. Оценивайте реальный контроль денег и права, а не только надпись non-custodial.

02Можно ли отправлять товар сразу после возврата клиента в магазин?

Нет. Возврат в браузере — лишь действие на странице. Магазину нужен проверенный статус конкретного платежа и правило выполнения заказа для этого способа оплаты. Повторные сообщения о том же платеже тоже не должны запускать повторные отправки.

DOC · 001BTCPay Server — eCommerce integrationДокументация DOC · 002BTCPay Server — General FAQДокументация DOC · 003BTCPay Server — Invoice lifecycleДокументация DOC · 004BTCPay Server — Webhook validation exampleДокументация DOC · 005BitPay — Invoice webhooksДокументация DOC · 006BitPay — Configuring settlementsДокументация DOC · 007BTCPay Server — RefundsДокументация DOC · 008BTCPay Server — ReportingДокументация DOC · 009BTCPay Server — Lightning operationsДокументация DOC · 010BitPay — Merchant and shopper termsПервичный источник
Обновлено: Сначала источники · Не является инвестиционной рекомендацией