Bitcoin Payment Processor は支払い要求を作成し、受け取った支払いを注文に照合して記録を支援します。自分で運用する方式とサービスとして利用する方式があります。Bitcoin のコンセンサス規則ではなく、プロセッサーという名称だけでは誰が資金を管理するかは分かりません。
店舗が注文を作成し、そのサーバーが金額と通貨を指定してプロセッサーに請求書を要求します。内部の注文番号と請求書 ID の対応を保存します。顧客は支払いページまたは QR コードを受け取り、プロセッサーが入金を監視します。この対応がなければ、どの注文に対する支払いかを確実に判断できません。ブラウザーに戻るだけでは支払いの証明になりません。 [BTCPay Server — eCommerce integration]
BTCPay Server は既存ウォレットの公開データから、秘密鍵を使わずに受取アドレスを導出できます。これはサーバーに保存されたホットウォレットや、Lightning ノードの資金へのアクセスとは異なります。事業者が払い出しまで資金を保有する場合もあります。製品名や non-custodial という言葉だけでなく、実際の鍵の保有、権限、引き出し能力を評価してください。 [BTCPay Server — General FAQ] [BitPay — Configuring settlements]
通常の BTCPay Server の請求書は、一定時間だけ換算レートを固定します。期限切れでも、その後の送金が到着しなくなるわけではありません。支払不足、過払い、遅延払いには異なる状態があり、それぞれ後続の処理が必要です。元の金額と使用レートを保存してください。価格が変わると、新しく発行した要求の satoshi 数は同じとは限りません。 [BTCPay Server — Invoice lifecycle]
BTCPay Server は設定した承認を待つ Processing と Settled を区別します。成功した Lightning 支払いはブロックを待たずに Settled になります。他の事業者の状態名を機械的に同一視できません。BitPay は paid が支払い保証ではないと明示しています。店舗には具体的な状態と支払い方法に応じた商品引き渡し規則が必要です。状態を手動変更してもネットワーク承認は生まれません。 [BTCPay Server — Invoice lifecycle] [BitPay — Invoice webhooks]
BTCPay は本文の元のバイト列と共有シークレットに対する HMAC-SHA256 を使って webhook を検証します。BitPay が説明する IPN は未署名です。通知は API で請求書の状態を問い合わせるきっかけであり、それ自体は信頼できる証拠ではありません。通知は繰り返し届くことがあります。そのため統合処理は再配信されたイベントを確実に認識し、同じ注文の二度目の発送を防ぐ必要があります。障害後は保存した状態をプロセッサーと照合します。 [BTCPay Server — Webhook validation example] [BitPay — Invoice webhooks]
顧客の支払い確認と事業者からの払い出しは同時とは限りません。BitPay では精算通貨と銀行口座または暗号資産アドレスを設定でき、変更に承認が必要な場合があります。利用可能な通貨、限度額、時期、手数料、払い出しまでの資金管理者を確認してください。自分のウォレットへの直接入金は、この事業者による払い出し方式を自動的に採用するものではありません。 [BitPay — Configuring settlements] [BTCPay Server — General FAQ]
返金には別の払い出しと受取人の確認が必要で、元のビットコイン取引を書き換えるものではありません。注文に関する苦情、返金額の決定、実際の送金を分けて扱ってください。注文・請求書・支払いの対応、換算レート、手数料、返金を記録します。レポートのエクスポートは記録に役立ちますが、それだけで地域のあらゆる会計義務や商品配送の紛争が解決するわけではありません。 送金が承認されても、それだけで取引の法的な最終性は決まりません。支払い経路、契約、法域に応じて、苦情処理、利用可能な chargeback の仕組み、義務を確認してください。 [BTCPay Server — Refunds] [BTCPay Server — Reporting] [BitPay — Merchant and shopper terms]
成功した支払い、不足した支払い、遅延した支払い、繰り返し通知された支払いと、障害からの復旧を試してください。API キーには必要最小限の権限だけを与え、対象店舗に限定します。メタデータに不要な顧客情報を送らないでください。ホスティング、更新、流動性、サポートを見込みます。無料のソフトウェアでも運用費用はゼロではありません。サービスの可用性、鍵の保管、統合の正確さは別々の条件です。 [BTCPay Server — eCommerce integration] [BTCPay Server — Lightning operations]
同じ通知は新たな購入ではない
仮想的な統合例では、注文 OBJ-101 に請求書 ID が保存されています。精算を検証すると、システムは発送を一度だけ作成します。その後、同じイベントの重複通知が届いても、履行済みの注文に関連付けるだけで新たな発送は作成しません。お礼ページの表示だけで、この状態遷移が起きてはいけません。
理解を深めるには、この項目とあわせて次もお読みください BTCPay Server, Bitcoin Point of Sale, Merchant Adoption, Lightning Network, Bitcoin. 次の項目からも参照されています Alza Bitcoin payments, Merchant Adoption, BTCPay Server, Bitcoin Point of Sale.
01どの決済プロセッサーも私のビットコインを保管しますか？+
いいえ。要求の作成と自分のウォレットへの入金監視だけを行う仕組みもあれば、払い出しまで資金を管理する仕組みもあります。同じソフトウェアでも異なるウォレット方式を使えます。重要なのは鍵、権限、実際の資金の流れであり、プロセッサーという名称だけではありません。
02顧客が支払いページから戻ったら商品を発送できますか？+
戻っただけでは不十分です。店舗はそのプロセッサーの手順で該当する請求書と状態を検証する必要があります。通知は文書に従って検証し、再配信によって再び履行されてはいけません。商品の引き渡しは、選択した支払い確認の条件に従います。