GoBTC PayはWooCommerceに導入できる？条件・決済経路・注意点を解説

GoBTC Pay for WooCommerceは、WooCommerceの購入画面にBitcoin（BTC）決済を追加する無料プラグインです。独自に決済機能を開発せず導入できる一方、「インストールすればすぐ安全に運用できる」仕組みではありません。加盟店登録とKYB、API鍵、HTTPS、Webhook、BTC現物受取後の会計、手動返金まで準備する必要があります。

特に重要なのは、GoBTC内ウォレットの即時受付と、通常のBTCウォレットからのオンチェーン決済を分けて考えることです。後者は原則1承認まで注文が保留されます。また、2026年10月25日時点で公式ディレクトリ上の有効インストール数は10未満であり、公開直後のプラグインとして慎重な検証が必要です。

この記事では、調査時点の公式資料を中心に、導入条件、2つの決済経路、設定手順、Webhook障害への備え、返金・個人情報・税務の注意点を順に解説します。

先に結論：GoBTC Payを導入できる店舗・見送る店舗

• 向いている店舗：BTC現物での受取・記帳ができ、実BTCの少額試験、Webhook監視、手動返金を担当者付きで運用できる店舗
• 条件付きで検討できる店舗：定期購入・予約注文をBTC対象外にし、通常ウォレットの1承認待ちを出荷フローへ組み込める店舗
• 現時点で見送る店舗：自動返金や自動課金が必須、mainnetでの試験を承認できない、障害時に注文とオンチェーン入金を照合できない店舗
• 最低限必要な体制：技術担当、受注・返金担当、会計担当の責任範囲を決め、カードなど別の決済手段を残す

判断材料は、加盟店手数料0.2%だけではありません。2026年10月25日時点の有効インストール数が10未満であること、通常ウォレットは原則1承認待ちであること、返金が新規BTC送金になること、定期購入・予約注文に対応しないことを先に受け入れられるか確認してください。

GoBTC PayのWooCommerceプラグインとは

GoBTC Pay for WooCommerceは、WordPress上のEC機能であるWooCommerceに、GoBTC Payを通じたBTC決済を組み込む決済ゲートウェイです。購入者が支払方法としてBitcoinを選び、提示された条件に従って送金すると、外部サービスから届く決済結果をプラグインがWooCommerceの注文へ反映します。

ここで「プラグイン」と「決済サービス」は分けて理解しましょう。プラグインはストアとGoBTC Payをつなぐ部品です。支払いの生成、状態確認、Webhook通知などは外部サービスとの連携を前提とします。そのため、WordPress内だけで処理が完結するわけではなく、GoBTC Pay側の登録・審査・稼働状況も運用条件に含まれます。

WooCommerceの支払方法にBitcoinを追加する公式プラグイン

本記事でいう「公式プラグイン」とは、GoBTC Pay名義で提供され、WordPress.org公式ディレクトリに掲載された配布物という意味です。無料で通常のWooCommerceチェックアウトへBTCを追加できますが、「WordPress.org掲載」は店舗環境での安全性や将来の無事故を保証する認証ではありません。提供主体と掲載場所の意味を、運用保証と混同しないでください。

加盟店には、対応するWordPress・PHP環境の維持、秘密API鍵の管理、Webhookの監視、入金と注文の照合が残ります。商品を渡すタイミングや返金手順も店舗側で決める必要があります。導入可否は「管理画面で有効化できたか」ではなく、障害や例外を含めて注文を処理できるかで判断します。

公開直後で有効インストール数は10未満

調査時点の公式ディレクトリでは、必要環境はWordPress 6.0以上、PHP 8.1以上で、最終更新は2026年10月21日のv1.1.4、有効インストール数は10未満と表示されています。公開されたばかりで、広範な店舗運用の蓄積を確認できる段階ではありません。

この数字だけで品質を断定できませんが、長期運用実績が豊富ともいえません。WordPress.orgの自動審査にも範囲があるため、本番前に更新履歴、WooCommerceとの互換性、テーマや他プラグインとの競合を自店舗で検証します。参照日：2026年10月25日。

導入前に確認したい利用条件と費用

導入判断では、サーバー要件だけでなく、加盟店としてサービスを利用できるか、手数料以外にどのような費用や作業が生じるかを先に洗い出します。担当者が「技術」「審査」「経理」の三つに分けて確認すると、設定途中で止まりにくくなります。

WordPress 6.0以上・PHP 8.1以上が必要

公式配布ページが示す最低要件はWordPress 6.0以上、PHP 8.1以上です。最低版を満たすだけでなく、WooCommerce本体、テーマ、キャッシュ、セキュリティ関連プラグインとの組み合わせを検証してください。決済用のコールバックURLがキャッシュされたり、セキュリティ機能がWebhookを遮断したりすると、入金済みでも注文状態が変わらない可能性があります。

稼働前にはWordPressとWooCommerceのバックアップを取り、復元手順まで確認します。PHP更新を同時に行う場合は、BTC決済だけでなく既存の購入、メール送信、在庫減算、管理画面操作への影響もテスト対象です。複数の変更を一度に本番へ反映すると、障害原因を切り分けにくくなります。

加盟店登録ではKYBと利用地域の確認が必要

加盟店はGoBTC Pay側で法人・事業者確認に当たるKYBを完了する必要があります。利用規約には禁止業種、地域制限、サービス停止に関する条件もあるため、登録画面へ進めることだけで利用可能と判断しないでください。日本の事業者が自社の業種・法人形態・提供地域で本番利用できるかを、公開前に確認します。

確認時には、審査に必要な書類、受取ウォレット、責任者、サポート窓口を整理します。サービス側の審査や地域判断によって利用できない可能性もあるため、BTC決済を唯一の支払方法にはせず、既存の決済を残した状態で準備するほうが安全です。

加盟店手数料は0.2%

公式資料では、利用者側の手数料を0%、加盟店手数料を0.2%と説明しています。直接決済では、売上の99.8%を加盟店へ、0.2%を手数料としてオンチェーン出力で分ける構造です。これは調査時点の公表条件であり、導入時には最新の規約と管理画面表示を再確認してください。

また、加盟店手数料だけを総コストとみなさないことが大切です。BTC送金に伴うネットワーク手数料、返金時の新規送金費用、会計処理、価格変動への対応、監視や問い合わせ対応も運用コストになります。自店舗では、注文単価や返品率を踏まえ、現行決済と同じ基準で比較します。

2つの決済経路と「即時」の意味

GoBTC Payには、GoBTC内ウォレットを使う経路と、一般的なBTCウォレットからオンチェーン送金する経路があります。購入者の画面では同じBTC支払いに見えても、店舗が注文を受け付け、商品を渡せると判断するまでの流れが異なります。

確認項目	GoBTC内ウォレット	通常BTCウォレット
購入者の送金元	GoBTC内ウォレット	一般的なBTCウォレット
サービス内受付	即時反映と公式説明	オンチェーン送金を検知
オンチェーン処理	加盟店受取までの時点・処理は公開資料だけでは要確認	原則1承認を待つ
加盟店が受け取るもの	BTC現物。ただし受取時点・経路の詳細は要確認	手数料控除後のBTC現物
WooCommerce注文状態	受付結果に応じた具体的遷移は要確認	1承認まではOn hold、その後の具体的遷移は実機試験で確認
出荷可能時点	公式資料だけでは確定不可。店舗が実機試験後に決定	少なくとも1承認と注文更新を確認後

公式確認済みなのは、GoBTC内で即時受付をうたうことと、通常ウォレットが原則1承認までOn holdになることです。上表で「要確認」とした受取時点や厳密な状態遷移は公開資料だけで確定できません。店舗側の推奨運用として、実BTCの少額試験で注文メモ・取引ID・受取ウォレットを突合し、推測だけで出荷条件を決めないでください。Bitcoinの承認が必要な理由はプルーフ・オブ・ワークの解説も参考になります。

GoBTC内ウォレットは受付を即時反映

GoBTC内の支払いでは、サービス内で受付を即時に反映すると説明されています。ただし、この「即時」は購入者と加盟店の間でオンチェーン承認が完了したという意味ではありません。サービス内部で支払いを認識し、加盟店側の処理を進められる状態を指すものとして扱います。

店舗の案内文には、「即時」という言葉だけを載せず、どの経路が対象か、受付後に注文メールや画面がどう変わるかを示すと誤解を減らせます。高額商品や取り消しにくいサービスでは、サービス内受付だけで提供するか、追加確認を置くかをリスクに応じて決めます。

通常BTCウォレットは原則1承認までOn hold

一般的なBTCウォレットからの支払いはBitcoinネットワークへ送信され、原則として1承認までWooCommerce注文がOn holdになります。On holdは失敗ではなく、入金確認を待っている状態です。ネットワークの状況によって承認までの時間は一定ではないため、「必ず何分」と案内してはいけません。

購入者が送金を終えた直後に画面を閉じても、Webhookや状態確認を通じて後から注文へ反映される設計が重要です。逆に、期限後の入金、金額不足、重複送金などの例外が起きたときに、どの注文と結び付けるかを担当者が確認できるようにしておきます。

支払い経路別に出荷条件を決める

デジタル商品、物販、高額品では、取り消しや再提供の難しさが異なります。そこで「GoBTC内受付で提供する」「通常ウォレットは1承認後に出荷する」など、支払経路と商品区分を組み合わせたルールを定めます。WooCommerceの注文状態だけでなく、管理画面の注文メモ、取引ID、オンチェーン状況も確認できる手順が必要です。

担当者向け手順書には、On hold、Processing、Completedを日本語で定義し、誰がどの状態を変更できるかを書きます。購入者向けには、送金後すぐに再送金しないこと、反映を待つ場合があること、問い合わせ時に秘密鍵やシードフレーズを送らないことを案内します。

導入の流れと初期設定項目

作業は、店舗側の準備、GoBTC Pay側の加盟店設定、WordPress側の接続、Webhook試験の順に進めます。画面名は更新で変わる可能性があるため、実際の操作では最新の公式手順も併記してください。

プラグインをインストールして決済を有効化する

1. 環境確認：WordPress 6.0以上、PHP 8.1以上、WooCommerceの版とバックアップを確認します。完了条件は、復元手順を含めて検証担当者が記録した状態です。
2. インストール：WordPress管理画面の「プラグイン」→「新規追加」で「GoBTC Pay for WooCommerce」を検索し、提供者と配布ページを照合してインストール・有効化します。完了条件は、プラグイン一覧で有効と表示され、致命的エラーがない状態です。
3. 決済設定：「WooCommerce」→「設定」→「決済」からGoBTC Payを開き、加盟店側で発行した接続情報を入力して有効化します。完了条件は、保存後も設定エラーが出ず、支払方法が利用可能と表示される状態です。
4. 購入画面確認：管理者ではないテスト利用者として商品をカートへ入れ、チェックアウトでBitcoinを選びます。完了条件は、PCとスマートフォンの両方で支払案内まで進み、他の決済方法も選べる状態です。

有効化直後に本番公開せず、商品選択、住所入力、決済選択、支払い待ち、完了メール、在庫更新まで通して確認します。ゲスト購入と会員購入、スマートフォンとPCなど、実際の購入経路も分けて試します。

端末を作成して秘密API鍵とベースURLを設定する

GoBTC Pay側で加盟店用の端末を作成し、秘密API鍵、Webhook署名secret、APIベースURLなどをプラグインへ設定します。秘密API鍵はパスワードと同様に扱い、記事、チャット、画面共有、公開リポジトリへ貼り付けないでください。担当者が変わった場合や漏えいが疑われる場合に、鍵を交換できる手順も必要です。

権限は最小限にし、WordPress管理者全員が決済鍵を閲覧できる状態を避けます。設定変更を行った担当者と日時を記録し、退職者や外部制作会社のアカウントを残さないよう管理します。APIベースURLは公式指定と一致するかを確認し、見た目が似た別ドメインを入力しないようにします。

HTTPSとWebhook到達性を確認する

決済サイトはストア全体をHTTPS化し、HTTPとHTTPSが混在していないか確認します。WordPressの管理画面やCookieを保護するうえでもHTTPSは基礎です。証明書が有効でも、リバースプロキシ、WAF、メンテナンス制限、Basic認証などがWebhookを外部から到達不能にすることがあります。

Webhook URLにブラウザでアクセスできるだけでは、署名付き通知を正常処理できる証明になりません。実際のテスト決済で通知を送り、HTTP応答、WooCommerceログ、注文メモ、注文状態の変化を一つずつ照合します。CDNやWAFを使う場合は、決済通知だけを無条件で除外するのではなく、署名検証を前提に必要な通信を通す設計にします。

Webhookで支払いを注文へ正しく反映する

Webhookは、GoBTC Pay側で起きた支払い状態の変化をWooCommerceへ通知する仕組みです。作業主体を分けると混乱しません。

• プラグインが担う処理：通知の受信と注文への関連付け。HMAC-SHA256署名の検証や重複通知対策がどこまで実装済みかは、公開資料だけで断定せず、利用版のコード・公式サポート・実機試験で確認します。
• 加盟店が設定する項目：Webhook署名secret、APIベースURL、HTTPS、WAFやBasic認証を含む到達経路です。加盟店が独自受信処理を開発する場合だけ、署名検証や冪等性を自ら実装します。
• 加盟店が監視・復旧する項目：HTTP応答、配信ログ、注文メモ、長時間のOn hold、取消後の入金を確認し、不一致時はGoBTC Payの取引とオンチェーン記録を照合します。

HMAC-SHA256署名で通知を検証する

GoBTC Payの加盟店資料（2026年10月25日参照）は、WebhookをHMAC-SHA256で署名すると説明しています。署名は送信元と改ざんの有無を確かめる仕組みです。ただし、プラグインの利用者が署名検証コードを追加実装すべきだと公開資料が明記しているわけではありません。標準プラグインを使う店舗は、secretを正しく設定し、無効な通知が注文へ反映されないことを試験します。独自実装を加える開発者は、署名検証と、同じ通知が再送されても在庫・メールを重複処理しない冪等性を実装してください。

On hold・Processing・Completedを運用ルールに落とす

WooCommerceでは、On holdは支払い確認待ち、Processingは支払い済みで出荷などの処理待ち、Completedは注文処理の完了を表します。BTC決済で重要なのは、これらを単なる管理画面の色ではなく、店舗の行動と結び付けることです。

注文状態	担当者の理解	行動例
On hold	支払い確認中	原則として出荷せず、通知と入金を確認
Processing	入金確認後の処理待ち	商品の準備や提供条件を確認
Completed	店舗側の処理完了	完了記録と会計資料を保存

自動更新が動いても、商品区分によっては人の確認を残します。特に高額品、ダウンロード商品、予約枠の確保では、状態変更と提供処理が同時に走るかを検証してください。手動で状態を変えた場合は、理由と確認した取引情報を注文メモへ残します。

不達ログと取消済み注文をオンチェーン入金と照合する

調査資料では、支払期限と猶予期間の後にポーリングが止まり、Webhookが不達だと、遅れて入金された注文が取消のまま残るリスクが示されています。管理画面だけを見て「未入金」と決めると、実際にはBTCを受け取っているのに商品を提供しない、または二重請求する可能性があります。

毎日の照合作業では、WooCommerce注文、GoBTC Pay側の取引、受取ウォレットのオンチェーン入金を比較します。取消済み、On holdのまま長時間動かない、問い合わせがあった注文を優先して確認します。WooCommerceの一般的なWebhookは連続失敗で自動無効化される場合があるため、配信ログと有効状態を監視対象にします。

障害時の担当者、確認頻度、購入者への連絡文、復旧後の再処理方法まで決めておくと、焦って注文状態を変更する事故を減らせます。取引IDやアドレスを照合する際も、クリップボードの置換や別注文との取り違えに注意し、可能なら二人で確認します。

本番公開前のテストとセキュリティ対策

決済テストは表示確認だけでは足りません。正常系に加えて、支払い途中の離脱、期限後入金、Webhook遮断、重複通知、金額不足、管理画面での誤操作を試します。テスト結果は注文番号、日時、期待結果、実際の結果とともに残します。

テスト環境でも実BTCが動く前提で試験する

調査資料によると、非本番環境の試験でもBitcoin mainnetを使い、テスト支払いで実BTCが移動します。一般的なsandboxやtestnetのつもりで操作すると、取り消せない資金移動が起きます。少額、専用ウォレット、承認済みの送金手順を使い、テスト費用と残高の管理者を決めてください。

BTC送金はカード決済のようなチャージバックを前提としません。誤ったアドレスや金額で送った後に、管理画面のボタンで巻き戻すことはできません。テスト担当者には、送金先、ネットワーク、金額、手数料を送信前に読み合わせる手順を設けます。

ステージングへ本番API鍵を複製しない

本番サイトをステージングへ複製すると、データベース内のAPI鍵やサイト識別情報もコピーされることがあります。調査で示されたリスクでは、複製側からの操作が本番顧客の支払いを取り消し得ます。複製前に決済機能を無効化し、複製後は本番鍵を削除して別の鍵へ交換し、サイト識別子も再生成します。

バックアップにも秘密情報が含まれる可能性があります。保存先を限定し、暗号化、アクセス権、保管期限、削除方法を決めます。エラーログへ秘密API鍵や署名secretが出力されていないかも確認してください。サポートへログを渡す前には、秘密情報と顧客情報をマスキングします。

公式掲載を安全性の保証とみなさず監視と代替決済を用意する

公開後は更新履歴とWooCommerce互換性を定期確認し、異常な注文状態、エラー、Webhook不達を監視します。更新は検証環境で少額決済を再試験してから本番へ反映します。

資産管理の詳細はウォレットの種類と選び方と秘密鍵を安全に管理する方法へ分けて確認してください。試験送金の実務は暗号資産を安全に送金する手順にまとめています。

BTC決済が停止した場合に備え、カード、銀行振込など自店舗で利用可能な代替決済を残します。障害中はBTC決済を選べないようにし、すでに送金した購入者向けの問い合わせ窓口を明示します。復旧を急いで検証を省略せず、バックアップから戻す条件やプラグインを無効化する権限者も決めます。

返金・個人情報・対応外機能の注意点

技術的に決済できても、通常運用で返品、キャンセル、定期購入が扱えなければ店舗には合わないことがあります。販売中の商品と業務フローを一覧にし、非対応機能を別手段で補えるか確認します。

返金は加盟店が新規BTC送金として処理する

このプラグインはWooCommerce上の自動返金を扱わず、加盟店が返金先アドレスを確認して新規のBTC送金を行います。元の取引を取り消すのではありません。そのため、返金額を受注時のBTC数量にするか、日本円価格を返金時に換算するか、ネットワーク手数料をどう扱うかを規約に明記する必要があります。

返金先アドレスをメールだけで受け取り、そのまま送金するのは危険です。注文者本人の確認、アドレス形式とネットワークの確認、金額の二重承認、送金記録の保存を行います。BTC価格が変動するため、顧客との認識差を避けるには、返金計算の基準時点と通貨単位を購入前に示すことが重要です。

定期購入と予約注文には対応しない

公式配布ページでは、返金に加えて定期購入と予約注文を扱わない制約が示されています。毎月の自動課金、将来日の自動引き落とし、予約枠と決済を一体で管理する商品には、そのままでは適合しません。WooCommerce側に別の拡張機能を入れても、GoBTC Payが対応していなければ自動課金は成立しないと考えます。

対象商品だけBTC決済を非表示にする、都度購入へ変更する、既存決済を使うなどの選択肢を検討します。非対応機能を無理に手作業で補うと、請求漏れや二重請求につながるため、注文量と担当者数を踏まえて継続可能かを判断してください。

外部送信される注文情報と本人・取引データを確認する

プラグインの説明では、注文額、通貨、注文参照が外部サービスへ送られる一方、顧客名、メール、住所、カート内容は送られない設計です。ただしGoBTC Payのプライバシーポリシーでは、本人・法人確認情報、取引情報、IPなどの端末情報、制裁・分析関連データが処理対象とされています。

「顧客の個人情報は一切外部へ出ない」と広く言い切るのは不正確です。加盟店登録者の情報と、購入時に外部へ送る注文情報を分け、自社のプライバシーポリシーや委託先一覧へどう記載するかを確認します。データの処理国、保存、開示、削除に関する条件も最新文書で確認してください。

日本の店舗が導入前に決める会計・税務ルール

GoBTC PayはBTC現物受取型です。加盟店は法定通貨で確定した代金が自動入金される場合とは異なり、受け取ったBTCの価格変動、ウォレット管理、換算、売却時の記録に対応します。税務処理は事業形態や取引内容で変わり得るため、この記事だけで結論を出さず、税理士などの専門家へ自社の事実関係を伝えて確認してください。

BTC現物受取の換算時点と会計処理を決める

受注時、支払受付時、オンチェーン承認時など、業務には複数の時点があります。どの時点のどの価格情報を帳簿に使うか、手数料をどう記録するか、後でBTCを売却・送金した際の取得価額をどう追跡するかを会計方針として決めます。注文番号、取引ID、BTC数量、円換算額、レートの出所と時刻を結び付けて保存すると照合しやすくなります。暗号資産取引の記録と申告の全体像は暗号資産の確定申告ガイドも参照し、最終判断は税理士へ確認してください。

価格変動で受取後の価値が上がることも下がることもあります。BTCを保有し続けるか、一定の条件で売却するかは資金管理の判断であり、プラグイン導入とは別に承認ルールを設けます。本記事はBTC保有や売却を推奨するものではありません。

購入者側でもBTC譲渡損益が生じ得る

国税庁のFAQでは、個人が保有する暗号資産で商品を購入する行為も、暗号資産の譲渡として扱われ、損益計算の対象になり得ると説明されています。購入者にとって「BTCで払う」ことは、単に円の代わりにポイントを使うのと同じとは限りません。

店舗が購入者の税額を計算する必要があるという意味ではありませんが、支払い履歴を確認できる領収情報や取引情報を提供し、税務上の扱いについて断定的な案内をしないことが大切です。購入者には自身の取得価額や取引状況に応じて確認するよう伝えます。

鍵管理・返金規約・権限分離まで確認して導入を判断する

最後に、次の項目をすべて説明できるか確認してください。

• 環境要件・KYB・利用地域
• 2経路の出荷条件と実BTC少額試験
• API鍵・Webhook・注文照合の担当者
• 手動返金・非対応商品の扱い
• 会計方針と障害時の代替決済

一つでも未決定なら、BTC決済を直ちに全面公開する必要はありません。限定商品や検証環境で業務フローを整え、責任者が承認できる状態にしてから公開範囲を判断します。

まとめ：便利さより先に運用条件を固める

GoBTC Pay for WooCommerceは、独自開発をせずWooCommerceへBTC決済を加えられるプラグインです。一方で、GoBTC内の即時受付と通常ウォレットのオンチェーン承認は異なり、Webhookが届かなければ注文状態と入金がずれる可能性があります。

導入の要点は、プラグインを有効化することではなく、出荷条件、鍵管理、監視、照合、手動返金、会計・税務を一つの業務として設計することです。公開直後で導入実績が限定的である点も踏まえ、少額試験と代替決済を用意し、自店舗に適するかを慎重に判断してください。