Bitcoin Point of Sale

Сотрудник выбирает кофе или вводит цену и проверяет валюту, чаевые и итог. BTCPay Server, например, предлагает каталог, корзину или цифровую клавиатуру. Затем создаётся invoice — запрос оплаты, связанный с конкретной покупкой. Эта связь позволяет впоследствии узнать, за что пришли деньги. Перезагрузка экрана не должна добавлять ещё один проданный кофе. Заказ и его платёжная запись должны оставаться доступными для проверки. [1] [2]

Кофейня может назначать цену в чешских кронах, а касса переводит её в биткоин по выбранному источнику курса. Перед отправкой клиент должен видеть сумму и срок действия, проверить получателя и платёжную сеть. BOLT 11 — формат запроса Lightning. Он содержит хеш платежа, криптографический отпечаток, связанный с доказательством оплаты, и срок действия; сумма может быть не задана. Поэтому сканирования недостаточно: для покупки проверяют реально запрошенную сумму. Цена в кронах сама по себе не означает поступления крон на банковский счёт кофейни. [3] [4]

QR-код передаёт платёжные данные, а не доказательство получения денег. Снимок экрана клиента не заменяет проверку со стороны кофейни. В BTCPay Server Processing означает полностью оплаченный запрос, для которого ещё не выполнены условия завершения, например нужные подтверждения в блоках. Settled обозначает их выполнение. Есть и ручная отметка, но она не создаёт настоящего платежа или подтверждения. Успешная оплата Lightning обычно не ждёт блока. Товар выдают по проверенному поступлению и правилам магазина, а не по цвету чужого экрана. [2]

Касса может принимать в собственный кошелёк продавца или использовать сервис, хранящий деньги за него. Важны приватные ключи для расходования, разрешения и условия вывода, а не логотип Bitcoin. Публичных данных кошелька может хватать для создания адресов получения. Но взломанная касса всё равно способна показать адрес злоумышленника для будущих платежей. Поэтому кассиру не нужны все права администратора: продавать кофе — не то же самое, что менять получателя или одобрять возврат. [5] [6] [7]

Lightning передаёт платежи через соединённые платёжные каналы. Собственный узел, то есть участвующая в сети программа, должен быть доступен и иметь входящую ликвидность: место в каналах для приёма средств. Сервис может взять часть работы на себя, но меняет расходы и круг доверия. Отсутствие маршрута или ликвидности не означает успешной оплаты. До попытки другим способом кассир проверяет результат первой, чтобы за один кофе не заплатили дважды. [7] [4]

Планшет может потерять интернет, сервер — перестать отвечать, а курс — не загрузиться. Тогда касса может не создать запрос или не проверить поступление. Напечатанный QR остаётся читаемым, но это не доказывает работоспособности системы. Нужен согласованный порядок: запасное подключение, отложенная продажа или последующий поиск платежа. Сам сбой не доказывает отсутствие оплаты. Недоплаты, переплаты и платежи после срока рассматривают отдельно; ручная правка записи не переписывает историю сети. [2] [3]

Вернуть деньги означает провести другой платёж, связанный с исходной покупкой. Нужно согласовать сумму и валюту, проверить назначение и получить одобрение уполномоченного сотрудника. BTCPay Server, например, отделяет создание запроса возврата от отправки выплаты. Ссылка для клиента ещё не означает, что деньги получены. Персонал различает подготовленный запрос, ожидающую выплату и завершённый возврат; исходный перевод остаётся в истории. [8]

В конце смены сверяют заказы, поступления, комиссии, возвраты и возможные выплаты поставщика. BTCPay Server экспортирует платежи, проданные товары и движения on-chain кошелька, работающего непосредственно с цепочкой Bitcoin. Отчёты помогают учёту, но сами не выполняют всех местных бухгалтерских и налоговых требований. До запуска отработайте обычную продажу, сбой и восстановление. Ограничьте доступ к данным клиентов и учтите затраты на оборудование, связь и обслуживание. [9] [1] [6]