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コードだけあれば十分ですか？+
コードは支払情報を伝えますが、それ自体で入金を検証したり購入と照合したりはしません。信頼できる支払状態と、金額誤り、有効期限切れ、接続障害への対応手順が必要です。
02Lightning 決済なら必ず店舗の自己管理になりますか？+
いいえ。自前ノード、別のサービス方式、カストディ事業者のいずれも使えます。誰が鍵と残高を管理し、誰が受取を担い、どの条件で資金を引き出せるかを確認してください。