BTCPay Server — свободный платёжный процессор с лицензией MIT, который можно запускать на своей инсталляции или у стороннего хостера. Проект предоставляет программу, а не универсальный кастодиальный счёт или арбитраж споров с продавцом. Доверие зависит от фактического соединения сервера, кошелька и платёжных сервисов.
Продавец связывает кассу или интернет-магазин со счётом и выбранным способом приёма. BTCPay Server создаёт on-chain адреса и Lightning-запросы, отслеживает платежи и показывает счета. В него также входят кассовые и благотворительные приложения и интерфейсы интеграции. Открытый код позволяет проверять и изменять программу, но сам не подтверждает безопасность конкретной установки. [BTCPay Server — Source repository]
Существующий on-chain кошелёк можно подключить расширенным публичным ключом: сервер выводит адреса получения без его закрытого ключа. Горячий кошелёк на сервере имеет другую модель риска. Разрешения узла Lightning тоже могут позволять распоряжаться его средствами. Разделяйте ключи получения, подписи и администрирования; слово self-hosted само не определяет, кто может потратить деньги. [BTCPay Server — Wallet setup] [BTCPay Server — General FAQ]
Сторонний хостер обслуживает сервер, а пользователь может получать прямо в собственный кошелёк. Это не устраняет доверие: вредоносный или взломанный сервер способен подменить публичный ключ и перенаправить будущие платежи. Уже полученные монеты в своём кошельке и новые отображаемые реквизиты — разные вещи. Проверяйте поступления также независимо от кассы. Такая же атака возможна на взломанной собственной инсталляции; хостер влияет и на доступность с приватностью. [BTCPay Server — Third-party hosting risks]
Магазин задаёт валюту, источник курса, срок действия и необходимые подтверждения. Processing у on-chain платежа ожидает настроенного условия; Settled означает его выполнение. Успешному Lightning-платежу не нужно ждать блока. Обрабатывайте недоплаты, переплаты, поздние поступления и ручные изменения состояния, которые не создают сетевых подтверждений. Пересчёт цены в биткоин — не продажа за фиат: конверсионный плагин или провайдер добавляет свои комиссии и требования доверия. [BTCPay Server — Invoice lifecycle] [BTCPay Server — Store rates and policies] [BTCPay Server — General FAQ]
Интернет-магазин должен сохранять связь заказа с идентификатором счёта. Greenfield API позволяет ограничить разрешения нужным магазином; не давайте ключу лишнего доступа. Проверяйте webhook по документации и обрабатывайте повторное событие без второй отправки. Возврат клиента на страницу благодарности сам не доказывает оплату. После сбоя сверяйте местный учёт с фактическими состояниями счетов и платежей. [BTCPay Server — eCommerce integration]
Свой узел требует доступности, управления каналами и входящей ликвидности. Сервис ликвидности, swap или кастодиальный кошелёк решают разные части задачи и не представляют одну модель. В кастодиальном сервисе контроль средств остаётся у провайдера; у других вариантов нужно проверить конкретные разрешения и риски. Логотип BTCPay Server не гарантирует успеха каждого платежа или нулевых комиссий. [BTCPay Server — Lightning options]
Сохраняйте копии данных магазинов, счетов, конфигурации и нужных данных кошельков согласно развёртыванию; seed не заменяет базу заказов. Документация Docker требует проверить восстановление копии. Старое состояние канала Lightning при неправильном восстановлении может привести к потере средств. Плановая миграция с корректной остановкой исходного узла отличается от аварийного восстановления; после запуска замены не запускайте исходную копию того же узла. Процедура должна соответствовать используемому backend. [BTCPay Server — Backup and restore]
Планируйте обновления, защиту доступа администратора, открытые сетевые интерфейсы, мониторинг доступности и проверенные копии. Хостинг, оборудование, сетевые комиссии, ликвидность и поддержка могут стоить денег, даже если программа не берёт процент с каждого платежа. Ограничивайте сохранённые данные клиентов. Возвраты и споры о доставке решает продавец, а не разработчики проекта; экспорт счетов не гарантирует выполнения всех бухгалтерских обязанностей. [BTCPay Server — Maintenance] [BTCPay Server — General FAQ] [BTCPay Server — eCommerce integration]
Сбой кассы не означает потерю уже полученных монет
В условном магазине сервер знает лишь публичные данные внешнего кошелька. При отказе хостинга уже полученные on-chain монеты остаются под контролем его ключей, но касса может перестать создавать счета или сообщать о платежах. Оператор восстанавливает сервис, проверяет настройки приёма и сверяет заказы с кошельком. Пример не относится к горячему кошельку на потерянном сервере или устаревшему состоянию каналов Lightning.
Для полной картины прочитайте эту статью вместе с Bitcoin Payment Processor, Bitcoin Point of Sale, Самостоятельное хранение, Lightning Network, Merchant Adoption, Bitcoin. На эту статью также ссылаются Bitcoin Coffee, Bitcoin Payment Processor, Bitcoin Point of Sale, Bitcoin Donations.
01Означает ли BTCPay Server автоматически самостоятельное хранение?+
Нет. Это определяют подключённый кошелёк, Lightning-сервис и реальные разрешения. Приём во внешний кошелёк только через публичный ключ отличается от горячего кошелька на чужом сервере или кастодиального backend. Кроме того, нужно доверять правильности отображаемых реквизитов.
02Достаточно ли копии seed для восстановления?+
Seed может восстановить соответствующий on-chain кошелёк, но не автоматически счета, настройки магазинов и состояния каналов Lightning. У этих частей свои копии и процедуры. Восстановление надо проверить; устаревшую копию активного узла Lightning нельзя безопасно считать обычной копией файлов.