Merchant Adoption

地図への掲載や連携の発表は、店員が今日支払いを受け付けられる証拠にはなりません。具体的な店舗、対応方式、確認日を特定します。BTC Map は継続的な再確認と地域貢献者への支援を説明しています。受付が動作しても常連客の証明にはならず、一定期間の実際の利用データが必要です。 [BTC Map — Verification and local maintenance]

店舗が自ら鍵を管理する場合、資金を自分のウォレットで受け取り、その安全に責任を持ちます。事業者は支払いを処理し、合意した選択肢に応じて現地通貨へ換えられます。BitPay はこのような精算を文書化しています。つまり顧客がビットコインで払っても店舗が長期保有するとは限りません。払い出し前の資金管理者、制限、条件を確認します。 [BTCPay Server — Lightning options and custody] [BitPay — Configuring settlements]

レジは注文を金額、通貨、支払い要求に結び付けます。BTCPay Server の通常の請求書は一定時間レートを固定します。そのため期限後の支払い、不足、超過は個別処理が必要です。送信前に金額、ネットワーク、受取人が一致していなければなりません。注文との関連がない QR コードだけでは明確な照合に不十分です。 [BTCPay Server — Invoice lifecycle]

顧客のスクリーンショットは受領確認ではありません。店員は自分のシステムで状態を調べます。BTCPay Server は設定した承認を待つ Processing と Settled を区別し、成功した Lightning 支払いは直ちに Settled になります。手動で付けた状態は新たなネットワーク上の証拠ではありません。商品引き渡しの規則では支払い方式と注文額を考慮します。 [BTCPay Server — Invoice lifecycle]

Lightning Network はレジでの素早い支払いを助けますが、利用可能な接続と受領能力が必要です。自分のノードではチャネルと入金側流動性の管理が求められます。サービスに任せればその運営に依存し、モデルによっては資金の保管にも依存します。ウォレット残高だけでは十分な入金側流動性を証明できません。 [BTCPay Server — Lightning options and custody]

単一の広告料率だけでなく、ネットワーク手数料、サービス料、為替スプレッド、流動性費用、機器の運用費を比べます。店員の教育、障害や例外的な支払いへの対応も含めます。自主管理は制御権を得られますが保守が必要で、簡単なサービスには制限や事業者リスクが加わる場合があります。店員の交代後も支払い方法を使える状態にします。 [BTCPay Server — Lightning options and custody] [BTCPay Server — Invoice lifecycle]

注文ごとに支払いとの関連、適用レート、手数料、後続の精算を保存します。BTCPay Server は支払いレポートを出力できますが、出力だけで地域の会計義務を満たすとは決まりません。返金は別の支払いであり、元の取引の書き換えではありません。返金通貨と金額計算を事前に定め、受取人情報を確認します。文書化された BTCPay の手順でも、その後の払い出し処理が必要です。 [BTCPay Server — Reporting] [BTCPay Server — Refunds]

稼働店舗、成功した購入、反復利用、決済時の問題を別々に追跡します。同じ期間と定義を比較し、閉店や古いデータも記録します。地域の支援と継続確認はサービス維持を助けます。追加店舗数は顧客数ではなく、決済受付だけで売上増やビットコイン価格上昇が保証されるわけでもありません。 [BTC Map — Verification and local maintenance] [BTCPay Server — Reporting]