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]