Bitcoin Point of Sale — кассовый интерфейс для очных продаж: рассчитывает стоимость покупки, создаёт платёжный запрос, сопоставляет полученный платёж и сохраняет запись. Он может работать на телефоне, планшете или терминале; внешний вид устройства не определяет, кто контролирует монеты.
Сотрудник выбирает товары или вводит сумму, проверяет валюту, чаевые и итог. BTCPay Server предлагает каталог, корзину и цифровую клавиатуру. Каждая покупка должна отслеживаться через заказ и счёт; повторное открытие экрана не должно создавать вторую запись продажи. [BTCPay Server — Point of Sale app] [BTCPay Server — Invoice lifecycle]
Цена в местной валюте пересчитывается по настроенному источнику курса; касса должна показывать ожидаемую сумму биткоина и срок действия предложения. BOLT 11 содержит данные счёта Lightning, включая хеш платежа и срок действия; сумма может быть необязательной. Для конкретной покупки нужно проверить фактическую сумму, сеть и получателя. Пересчёт цены не означает продажу биткоина за фиат. [BTCPay Server — Store rates and policies] [Lightning BOLTs — Invoice protocol]
QR-код лишь передаёт платёжные данные. Снимок экрана покупателя не заменяет статус в системе продавца. В BTCPay Server статус Processing ждёт выбранных on-chain подтверждений; Settled означает выполнение правил, но может быть установлен вручную. Успешный платёж Lightning не ждёт подтверждения блока. Поэтому выдача товара основывается на проверенном платеже, а не только на цвете экрана. [BTCPay Server — Invoice lifecycle]
Один и тот же планшет может направлять поступления в собственный кошелёк или использовать кастодиального поставщика. Важны ключи, разрешения и условия выплат, а не логотип Bitcoin. Даже получение через открытый ключ не исключает подмену будущего адреса взломанной кассой или сервером. Отделите права кассира от изменения получателя, управления кошельком и утверждения возвратов. [BTCPay Server — Wallet setup] [BTCPay Server — Third-party hosting risks] [BTCPay Server — Lightning setup]
Собственный узел Lightning требует эксплуатации, каналов и входящей ликвидности. Поставщик может взять часть работы на себя, но меняет расходы и доверие. Ошибка маршрутизации или нехватка ликвидности — не успешный платёж. Перед переходом на другой способ оплаты сотрудник проверяет результат первоначальной попытки, чтобы избежать двух платежей за одну покупку. [BTCPay Server — Lightning setup] [Lightning BOLTs — Invoice protocol]
Недоступность интернета, бэкенда или источника курса может помешать новому запросу либо проверке поступления. Код на экране или бумаге может оставаться читаемым без актуального статуса. Порядок работы должен определять резервное подключение, отсрочку продажи и последующий поиск платежа. Недоплаты, переплаты и платежи после истечения срока рассматривайте отдельно; ручная смена статуса не меняет историю сети. [BTCPay Server — Invoice lifecycle] [BTCPay Server — Store rates and policies]
Возврат средств требует связи с исходной покупкой, согласованных суммы и валюты, проверенного назначения и разрешения уполномоченного лица. BTCPay Server отделяет создание запроса на возврат от отправки выплаты. Исходный перевод не стирается. Сотрудник должен различать созданный запрос, ожидающую выплату и действительно завершённый возврат. [BTCPay Server — Refund workflow]
В конце смены сверяйте заказы, полученные платежи, комиссии, возвраты и возможные выплаты поставщика. BTCPay Server экспортирует отчёты о платежах, проданных товарах и on-chain кошельке; сам экспорт не гарантирует соблюдения местных бухгалтерских и налоговых требований. Проверьте действия персонала, сбои и восстановление, ограничьте доступ к данным покупателей и учитывайте расходы на устройства, подключение и эксплуатацию. [BTCPay Server — Reporting] [BTCPay Server — Point of Sale app] [BTCPay Server — Third-party hosting risks]
Два экрана, одна покупка
В учебном заказе POS-497 покупатель показывает успешный платёж, но планшет сотрудника теряет соединение. Сотрудник не отмечает покупку автоматически как неоплаченную и не создаёт сразу второй запрос. Он восстанавливает соединение, находит исходный счёт и проверяет сумму и фактический статус поступления. Только после этого решает выдать товар или повторить попытку и записывает результат в тот же заказ.
Для полной картины прочитайте эту статью вместе с Merchant Adoption, BTCPay Server, Bitcoin Payment Processor, BOLT 11, Подтверждение, Bitcoin. На эту статью также ссылаются Merchant Adoption, Bitcoin Payment Processor, BTCPay Server, BTC Map.
01Достаточно ли QR-кода на кассе?+
Код передаёт платёжные данные, но сам не проверяет поступление и не сопоставляет платёж с покупкой. Кассе нужны достоверный статус платежа и порядок действий при неверной сумме, истечении срока и отсутствии соединения.
02Всегда ли платёж через Lightning означает самостоятельное хранение продавцом?+
Нет. Касса может использовать собственный узел, другую модель сервиса или кастодиального поставщика. Проверьте, кто контролирует ключи и баланс, кто обеспечивает приём и на каких условиях можно вывести средства.