Merchant Adoption

地図にはBitcoin対応と載っているのに、今日の店員は支払いの始め方を知らない。そんな店なら掲載情報はあまり役立ちません。確認すべきなのは具体的な店舗、対応方法、確認日です。そのためBTC Mapは地域の協力者を頼りにし、既存の場所も繰り返し確認します。試しの購入に成功すれば、その時点で手順が機能することは分かります。何人が定期的に使うかまでは分からず、一定期間の実際の購入を調べる必要があります。 [1]

店側は、自分で鍵を管理するウォレットにbitcoinを受け取れます。鍵は資金を使う権限を与えるので、バックアップも守る必要があります。別の方法は、決済事業者に処理を任せ、対応する現地通貨で払い出してもらうことです。BitPayはその仕組みを説明しています。顧客がbitcoinで払っても、店側がその相場変動を抱え続ける必要はありません。払い出しまで誰が資金を管理し、いつ、どんな条件や制限で渡すかを確認しましょう。決済方法と保管方法は別の選択です。 [2] [3]

レジは購入と金額、支払い方法を結び付けます。BTCPay Serverはこれをinvoiceと呼び、一定時間だけ金額と為替レートを固定する支払い要求を意味します。顧客は自分の注文にいくら送ればよいか分かります。期限切れ、支払い不足、払い過ぎには個別の対応が必要です。送信前に金額、受取先、正しいネットワークを確認します。QRコードは情報をウォレットへ渡すだけで、情報の正しさや注文との対応をそれだけで保証するものではありません。 [4]

顧客が送金済みの画面を見せても、店員は店側のシステムを確認します。BTCPay ServerのProcessingは必要額が払われたものの、ブロックでの取引承認など、完了条件が残っている状態です。Settledはその条件が満たされたことを示します。Lightning決済は通常、ブロック承認を待ちません。商品の引き渡しは店の方針、決済方法、購入額に従います。手動で状態を変えてもネットワークの確認を証明しません。通常と異なる支払いは先に確かめる必要があります。 [4]

Lightning Networkは、参加者間にあらかじめ作った決済チャネルという接続を通じて素早く支払います。受け取るには接続が利用でき、インバウンド流動性、つまりチャネル経由で追加の資金を受け入れる余地が必要です。これは店がすでに持っている金額とは違います。決済ソフトを動かすコンピューターである自分のノードを運用するなら、チャネル管理と継続的な手入れが必要です。サービスは作業を簡単にできますが、店はその稼働に依存し、方式によっては資金も預けます。 [2]

選ぶ際には広告の一つの手数料だけを比べても不十分です。ネットワーク料金やサービス料のほか、適用レートと比較基準レートの差に費用が含まれることもあります。受取用の流動性、機器、保守、店員の時間も考えましょう。自己管理は制御を得ると同時に、稼働への責任も負います。簡単なサービスには制限や、事業者の停止・破綻のリスクがあり得ます。次のシフトも、障害や誤った金額への対処を含む手順を知っている必要があります。 [2] [4]

照合のため、注文、支払い、為替、手数料、事業者からの払い出しの対応を残します。BTCPay Serverはレポートを書き出せますが、それだけで地域の会計上の義務を満たす保証はありません。返金は新しい支払いで、元の取引の削除ではありません。通貨と返金額の計算方法を先に決め、顧客の受取情報を確認しましょう。BTCPayの文書化された手順では返金リンクを作るだけでは足りず、顧客が宛先を指定した後に払い出し処理が必要です。 [5] [6]

大切なのは「何か所増えたか」だけでなく、「今も払えるか、顧客はまた来るか」です。利用可能な店舗、成功した購入、繰り返し利用、支払いの問題を別々に追いましょう。期間と定義をそろえて比べ、閉店や古い情報も記録します。地域の支援と定期確認が、使える状態を保ちます。場所の数は顧客数ではなく、Bitcoinを受け付けるだけで売上やBitcoin価格の上昇が保証されるわけでもありません。 [1] [5]