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 не можна безпечно вважати звичайною файловою копією.