Bitcoin Payment Processor

Магазин створює замовлення, а його сервер запитує в процесора рахунок із сумою та валютою. Він зберігає зв’язок між внутрішнім номером замовлення та ідентифікатором рахунку. Клієнт отримує платіжну сторінку або QR-код, а процесор відстежує надходження. Без цього зв’язку неможливо надійно визначити, яке замовлення оплачується; саме повернення до браузера не доводить оплату. [BTCPay Server — eCommerce integration]

BTCPay Server може виводити адреси отримання з відкритих даних наявного гаманця без його приватного ключа. Це відрізняється від гарячого гаманця на сервері й від доступу до коштів вузла Lightning. Провайдер може утримувати кошти до виплати. Оцінюйте фактичне володіння ключами, дозволи та можливість виведення, а не лише назву продукту чи слово non-custodial. [BTCPay Server — General FAQ] [BitPay — Configuring settlements]

Звичайний рахунок BTCPay Server фіксує курс на обмежений час. Закінчення строку не означає, що пізніший переказ не надійде. Недоплата, переплата й запізніла оплата мають різні стани та потребують подальших процедур. Зберігайте початкову суму й застосований курс; зі зміною ціни новий запит може вимагати іншу кількість сатоші. [BTCPay Server — Invoice lifecycle]

BTCPay Server розрізняє Processing, що очікує налаштованих підтверджень, і Settled; успішні Lightning-платежі переходять у Settled без очікування блоку. Назви станів інших провайдерів не можна механічно прирівнювати: BitPay прямо попереджає, що paid не гарантує оплату. Магазину потрібне правило видачі товару для конкретного стану й способу оплати. Ручна зміна стану не створює мережевого підтвердження. [BTCPay Server — Invoice lifecycle] [BitPay — Invoice webhooks]

BTCPay перевіряє webhook за допомогою HMAC-SHA256 над початковими байтами тіла та спільним секретом. BitPay описує непідписані IPN: сповіщення є приводом запитати стан рахунку через API, а не самостійним надійним доказом. Сповіщення можуть надходити повторно. Тому інтеграція має надійно розпізнавати повторно доставлену подію та запобігати другій відправці того самого замовлення; після збою збережені стани потрібно звірити з процесором. [BTCPay Server — Webhook validation example] [BitPay — Invoice webhooks]

Підтвердження платежу клієнта може не збігатися в часі з виплатою провайдера. BitPay дозволяє налаштувати валюту розрахунку та банківський рахунок або криптовалютну адресу; зміна може потребувати схвалення. Перевіряйте доступні валюти, ліміти, строки, комісії та контроль коштів до виплати. Пряме отримання у власний гаманець не використовує автоматично цю модель виплати провайдером. [BitPay — Configuring settlements] [BTCPay Server — General FAQ]

Повернення потребує нової виплати та перевірки одержувача; воно не змінює початкову біткоїн-транзакцію. Розділяйте претензію щодо замовлення, рішення про суму повернення і фактичне відправлення грошей. Зберігайте зв’язки замовлення–рахунок–платіж, курси, комісії та повернення. Експорт звіту допомагає вести облік, але сам не розв’язує всі місцеві бухгалтерські вимоги або спір щодо доставки. Навіть підтверджений переказ сам не визначає юридичну остаточність угоди: перевіряйте претензії, можливий механізм chargeback і зобов’язання відповідно до платіжного шляху, договору та юрисдикції. [BTCPay Server — Refunds] [BTCPay Server — Reporting] [BitPay — Merchant and shopper terms]

Перевірте успішну, неповну, запізнілу й повторно сповіщену оплату, а також відновлення після збою. Надайте API-ключу лише необхідні дозволи й обмежте його відповідним магазином. Не передавайте зайві дані клієнта в метаданих. Враховуйте хостинг, оновлення, ліквідність і підтримку; безплатне програмне забезпечення не означає нульових експлуатаційних витрат. Доступність сервісу, володіння ключами й правильність інтеграції — окремі умови. [BTCPay Server — eCommerce integration] [BTCPay Server — Lightning operations]