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]