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]
Кава, оплачений телефон і від’єднаний планшет
У прикладі замовлення POS-497 покупець показує успішну оплату, коли планшет працівника втрачає зв’язок. Працівник не створює відразу другий запит і не позначає покупку неоплаченою. Він відновлює з’єднання, знаходить початкову invoice й порівнює суму з фактичним надходженням. За результатом завершує продаж або розбирається з новою спробою. Усі записи залишаються біля того самого замовлення, щоб ні платіж, ні продаж не порахували двічі.
Для повної картини прочитайте також Merchant Adoption, BTCPay Server, Bitcoin Payment Processor, BOLT 11, Підтвердження, Bitcoin. На цю статтю також посилаються Merchant Adoption, Bitcoin Payment Processor, BTCPay Server, BTC Map.
01Чи достатньо QR на прилавку?+
Код передає дані, але сам не визначає, чи надійшли гроші та якої покупки вони стосуються. Працівникам потрібні надійна перевірка й порядок дій для неправильної суми, простроченого запиту або втрати зв’язку.
02Чи означає Lightning, що кав’ярня сама тримає кошти?+
Не автоматично. Вона може мати власний вузол або сервіс з іншим розподілом прав, зокрема зберіганням у постачальника. Перевірте, хто контролює ключі й баланс, хто забезпечує приймання та за яких умов кав’ярня може вивести кошти.