
BNB Chainで暗号資産決済を受け付ける方法:事業者向けガイド
BNB Chainで暗号資産決済を受け付けるには、ウォレットアドレスを公開するだけでは不十分です。信頼できる事業者向けの決済フローでは、ネットワークと資産を指定し、正しい金額を提示して、送金を検知し、適切な決済状態になるまで待ったうえで、二重に商品やサービスを提供することなく、その決済を1件の注文に関連付ける必要があります。
BNB Smart Chainのメインネットは、チェーンIDが56のEVM互換ネットワークです。ネイティブ資産のBNBはガス代の支払いに使われます。多くのウォレット利用者にとって使い慣れたEVM設計である一方、決済時には重大なリスクも生じます。同じように見える0xアドレスがEthereumをはじめとする複数のネットワークに存在するためです。顧客が有効なアドレスへ実在するトークンを送っても、その注文に対して誤ったチェーンを使用する可能性があります。
本ガイドでは、トークンコントラクト、承認、Webhook、返金、会計上のリスクを管理しながら、BNB ChainでBNB、USDT、その他の対応資産による決済を受け付ける方法を解説します。どの組み合わせも案内を始める前に、ログイン済みの実運用設定画面に対象のトークンとネットワークが正確に表示されていることを確認してください。公開されているYolfiのBNB Chainページでは利用可能な製品機能を紹介していますが、公開ページや自動生成ページがあるだけでは、すべてのアカウントであらゆる資産が有効になっている証明にはなりません。
BNB Chain決済で特定すべき情報
BNB Smart ChainはBSCとも呼ばれ、BNB Chainエコシステム内のスマートコントラクト対応ネットワークです。公式のBNB Smart Chainドキュメントでは分散型アプリケーション向けの基盤として説明され、公式のBSC概要にはEVM互換性と、ガス代におけるBNBの役割が記載されています。
事業者が発行する決済リクエストには、次の情報が必要です。
| 項目 | 顧客と事業者のシステムが把握すべき内容 |
|---|---|
| ネットワーク | Ethereumや別のEVMチェーンではなく、BNB Smart Chainメインネット |
| チェーンID | BNB Smart Chainメインネットは56 |
| 資産 | ネイティブBNB、または対応する正確なトークン |
| トークンコントラクト | トークンで支払う場合に受け付けるBEP-20コントラクト |
| 送金先 | この決済経路用に設定された、事業者が管理するアドレス |
| 金額 | 見積もりまたは請求書の方針に基づく正確な請求額 |
| 参照情報 | 注文、請求書、顧客、または決済リクエストの識別子 |
| 状態 | 作成済み、処理待ち、承認済み、期限切れ、不一致、その他の定義済み状態 |
ネットワークと資産を組み合わせて、1つの決済手段として扱います。「USDT」だけでは情報が足りず、「BNB Chain上のUSDT」なら実際の操作に使えます。「この0xアドレスに送金してください」という案内も、EVM形式のアドレスだけでは利用すべきチェーンをウォレットに伝えられないため不十分です。
BNB Chainが適しているケース
顧客がすでにBNB Chain上でBNBやステーブルコインを保有している、普段使う取引所からBNB Chainへ出金できる、対応ウォレットを使っている、といった場合はBNB Chainを試す価値があります。暗号資産を日常的に使う顧客向けのSaaSプラン、デジタル商品、制作会社などの請求書、有料コミュニティ、そのほかのオンライン商品に適しています。EVM互換の開発ツール、BEP-20対応、ブロックエクスプローラーでの確認、比較的抑えられる可能性がある取引コストが導入を後押ししますが、手数料が固定されるわけではありません。
高速または安価だと紹介されているという理由だけで選んではいけません。顧客が別のネットワークに資金を保有している場合、支払い前に取引所からの出金やブリッジが必要になることがあります。その分、費用、時間、リスクが増えます。また、ネットワークの状況やウォレットの見積もりも変動します。
通常、最適な決済ネットワークとは、顧客がすでに利用しており、事業者が最初から最後まで対応できるネットワークです。需要が明確でない場合は、ステーブルコイン決済に最適なブロックチェーンのガイドを参考に、顧客の保有資産、ガス代、ウォレットへのアクセス、資金管理、問い合わせ対応の負担を比較してください。
BNBとステーブルコインのどちらを選ぶか
最初に決めるべき運用上の事項は、BNB Chain上のどの資産を受け付けるかです。
ネイティブBNBを受け付ける
BNB決済は、BNB Smart Chain上ですでにBNBを保有している顧客や、意図的にBNB建てで価格を設定する事業者に適しています。この決済フローでBNBには2つの役割があります。購入代金として使えるほか、ネットワーク手数料の支払いにも使われます。
法定通貨建ての商品では、見積もりの作成から支払いまでの間に必要なBNB数量が変動することがあります。適切な決済ページでは、正確な数量を計算し、基準とした為替レートと時刻を記録し、必要に応じて有効期限を表示します。また、支払いが遅れた場合、請求額に足りない場合、または超過した場合の対応も定めます。
古いBNB見積もりを無期限に再利用しないでください。購入代金とガス代は分けて扱います。ウォレットでは、請求額から手数料を差し引くのではなく、別途ガス代を支払えるだけのBNBが必要です。
USDTなどのステーブルコインを受け付ける
米ドルを基準とするステーブルコインを使うと、米ドル建ての請求書を分かりやすくできます。たとえばUSDTなら、BNBの価格が動くたびに表示価格を変更する必要がありません。USDT決済を受け付ける方法では、同じティッカーの資産が複数のネットワークに存在する仕組みを解説しています。
ただし、ステーブルコインにも発行体、価格連動の乖離、コントラクト、規制、ネットワーク、ウォレット、流動性に関するリスクがあります。トークンシンボルだけではコントラクトを特定できず、ウォレットにはよく似た偽トークンが表示される場合もあります。
Yolfiの公開BNB Chainページでは現在、ネイティブBNB、USDC、USDT、その他の主要なステーブルコインを紹介しています。これは製品の参考情報として扱い、実際に利用できる選択肢はログイン済みの設定画面で確認してください。技術的には任意のトークンをアドレスへ送れるからといって、「すべてのBEP-20トークンに対応」と案内してはいけません。
BNBとステーブルコインの比較
| 判断項目 | BNB | USDTまたはその他の対応ステーブルコイン |
|---|---|---|
| 価格設定 | 法定通貨建ての注文は見積もり後の価格変動の影響を受ける | 基準通貨建ての商品では通常、価格を分かりやすくしやすい |
| 顧客側の要件 | 支払いとガス代の両方にBNBが必要 | 対象トークンに加え、ガス代用のBNBが必要 |
| 識別方法 | BNB Smart Chainのネイティブ資産 | BNB Smart Chain上の正確なBEP-20コントラクト |
| 見積もり方針 | 有効期限とレートの取り扱いが特に重要 | 金額は単純になりやすいが、支払期限後のルールは必要 |
| 資金管理 | BNBを保有するか換金するかを決める | 発行体、コントラクト、流動性、会計処理を確認する |
まず、顧客から最も要望の多い決済経路から始めてください。資産を追加するたびに、価格設定、トークンの検証、例外処理、返金、照合の業務が増えます。
トークンを有効にする前にBEP-20コントラクトを理解する
BEP-20は、BNB Smart Chainで一般的に使われるトークン規格です。決済業務で重要な識別子は、トークン名、ブランド表示、ティッカーではなく、コントラクトアドレスです。
検索結果、心当たりのないメッセージ、ウォレット内検索、出所不明のトークン一覧からコントラクトをコピーしてはいけません。発行体が提供する最新の一次情報と、ログイン済みの決済設定画面に表示される資産の両方で確認してください。対象の決済経路について発行体が信頼できる識別子を公開していない場合、推測して作り出してはいけません。
BEP-20資産を有効にする前に、次の手順を実施します。
- 実運用中の事業者向け設定画面にある、正確なトークンとBNB Chainの選択肢を記録する。
- トークン発行体の公式情報からコントラクトを取得する。
- 対応コントラクトと1文字ずつ照合する。
- 信頼できるコントラクト情報またはブロックエクスプローラーのデータで、小数点以下の桁数と送金表示を確認する。
- 顧客が実際に使う経路で少額決済を行う。
- 決済記録がそのコントラクトを正確に認識することを確認する。
- 異なるトークンや類似トークンが送られた場合の問い合わせ対応を文書化する。
未対応のコントラクトによる送金が事業者のアドレスに届いても、有効な支払いとは限りません。例外確認の対象にしてください。想定したティッカーやおおよその米ドル価値が表示されているという理由だけで、注文に自動で入金を反映してはいけません。
BNBのガス代を明確に説明する
通常のBNB Smart Chain取引では、ガス代としてBNBが必要です。BEP-20決済も同様です。請求額を満たすUSDTを保有していても、そのネットワーク上のBNBがウォレットになければ送金できないことがあります。
次の金額は分けて示してください。
- 事業者が受け取るべき金額
- ウォレットが見積もるBNB建てのネットワーク手数料
- 決済ページで開示する、決済事業者または販売事業者による別途の料金
80 USDTを請求する場合は、80 USDTを送金し、送信元ウォレットにガス代として十分なBNBを残すよう顧客へ案内してください。BNB建ての手数料をUSDTの請求額から差し引くよう指示してはいけません。
単に「BNBが必要です」ではなく、「ガス代にはBNB Smart Chain上のBNBが必要です」と説明します。別のネットワークや商品に関連付けられた残高は、BSCのガス代に使えない場合があります。手数料の恒久的な目安や承認時間を保証する表現は避けてください。決済条件もリスク管理方針も変わる可能性があります。
BNB Chain決済の導入方法
1. 実運用中のトークンとネットワークの選択肢を確認する
ログイン済みの事業者向け設定画面を開き、提供予定のBNB Chainとの組み合わせをすべて記録します。設定ページだけでなく、顧客が実際に見る決済画面も確認してください。BNB、USDT、USDC、その他の資産が表示されない場合、その決済経路を案内してはいけません。
有効にする選択肢ごとに、表示名、ネットワーク、必要な場合はコントラクト、決済先アドレス、運用責任者を記録します。アカウントや製品の変更後には、これらの情報を再確認してください。
2. 事業者が管理するウォレットを設定する
社内方針に沿って管理できる、BNB Smart Chain対応の決済先ウォレットを使用します。公開前に、送金先が正しいことを独立した方法で確認してください。次の事項を定めます。
- 決済先アドレスを閲覧または変更できる担当者
- 秘密鍵や署名用端末の保護方法とバックアップ方法
- リスクの高い変更や返金に2人目の承認者が必要かどうか
- アドレス変更の記録方法とテスト方法
- 承認済みの出金取引に必要なBNBを資金管理部門が確保する方法
- BNB Chain上の残高を、他チェーン上の類似資産と財務上区別する方法
Yolfiは、BNB Chain決済を、資金が事業者のウォレットへ直接送られる非カストディ型の仕組みとして説明しています。直接決済により、決済事業者からの出金手順は不要になりますが、鍵の管理、ウォレットへのアクセス、返金、資金管理は事業者の責任となります。
3. 決済リンクか組み込み型の決済ページを選ぶ
決済リンクは、試験導入、請求書、コンサルティング業務、個別注文、手作業で提供する商品やサービスに最も早く導入できる方法です。決済ページを全面的に組み込まなくても、送金額と決済の参照情報を設定できます。Yolfiの公開BNBページでも、BNB決済リンクとウォレットへの直接決済を紹介しています。
組み込み型の決済ページは、承認後にアカウント作成、ファイル配信、クレジット付与、注文更新、利用期間の延長を自動で行う場合に適しています。少なくとも次の情報を保持してください。
- 社内の注文IDと顧客ID
- 商品、数量、基準通貨での価格
- 請求した資産、ネットワーク、トークンコントラクト
- 送金先と暗号資産の正確な数量
- 該当する場合は、見積もりレート、作成時刻、有効期限
- 決済リクエストID、状態、トランザクションハッシュ
- 商品・サービスの提供記録と返金記録
Yolfiの公開BNB Chainページでは現在、決済リンク、継続決済、決済イベント、Webhook、ウォレットへの直接決済を紹介しています。継続請求が製品に適している場合は、暗号資産によるサブスクリプションを確認したうえで、ログイン済みの決済フローで利用可能なBNB Chain資産を正確に確認してください。継続決済だからといって、ウォレットから自動的に引き落とされるとは限りません。実際の実装に合わせて、更新通知、支払期間、猶予期間、解約、アクセス変更、重複イベントの処理を定めてください。
4. ネットワークの選択を見落とせないようにする
資産、金額、QRコード、ウォレット操作のそばに、「BNB Smart Chain」または「BNB Chain」と繰り返し表示します。ウォレットの設定や技術的なヘルプにはチェーンID 56も記載しますが、顧客が数字だけを頼りにしなくても済むようにしてください。
分かりやすい決済画面の文言例は次のとおりです。
- 「BNB Smart Chainで80 USDTを送金してください。」
- 「BNB Smart Chainメインネットのみを使用してください(チェーンID:56)。」
- 「ネットワーク手数料には、BNB Smart Chain上のBNBが必要です。」
- 「このトークンをEthereumや別のネットワークから送らないでください。」
複数のネットワークを提供する場合は、ウォレットを開く前に明示的な選択を求めます。トークンシンボルしか表示しないまま、BNB Chainを自動選択してはいけません。暗号資産を誤ったネットワークへ送る事故を防ぐ方法では、決済画面での予防策と事故発生時に必要な証拠を詳しく解説しています。
5. 顧客の決済フロー全体をテストする
顧客が実際に使う端末、ウォレットへの遷移方法、決済ページを使って、少額の実取引を行います。次の点を確認してください。
- 決済ページにトークンとBNB Chainの両方が表示される。
- ウォレットがメインネットのチェーンID
56を使用する。 - 送金先と請求額が一致する。
- トークン決済で想定したBEP-20コントラクトが使われる。
- BNBのガス代が別に表示される。
- 送信直後に商品やサービスを提供せず、処理待ちの状態になる。
- 適切な承認済み状態が注文システムに届く。
- Webhookが繰り返し配信されても、提供処理が重複しない。
- 経理担当者が決済先ウォレットとブロックエクスプローラーで入金を確認できる。
- 管理された返金手順が正しく機能する。
ウォレット、トークン、決済ページのコード、Webhookの送信先、承認方針、提供処理のロジックを変更した後は、テストを繰り返してください。
二重提供を防ぎながら決済を確認する
トランザクションハッシュは確認を始める手掛かりであり、商品を発送してよいという許可ではありません。取引は処理待ちのままになる、失敗する、誤ったチェーンを使う、類似トークンを送る、金額が違う、またはすでに別の注文へ割り当てられている可能性があります。
事業者が支払いを受け入れる際は、次の条件を満たす必要があります。
- BNB Smart Chainメインネット、チェーンID
56である。 - 請求したネイティブ資産または正確なBEP-20コントラクトである。
- 設定済みの送金先である。
- 注文方針で求める金額である。
- 決済システムで必要とされる承認状態に達している。
- その取引が別の注文へ割り当てられていない。
- その注文の商品やサービスがまだ提供されていない。
決済フローが示す承認済み状態と、注文金額や提供リスクに応じた追加の管理策を使ってください。すべての支払いについて、一律の承認回数、所要秒数、または覆らない確定時点を約束してはいけません。
Webhookでは、連携仕様に定められた真正性の確認方法に従います。イベントID、決済リクエストID、トランザクションハッシュ、状態、処理結果を保存してください。連携仕様に従ってイベントの受信確認または再試行を行い、提供処理は冪等にします。
冪等性とは、同じイベントを繰り返し受信しても、一度だけ受信した場合と同じ業務結果になる性質です。変化しないイベント識別子または決済識別子に一意性制約を設け、永続的なデータベース処理の中で提供状態を更新します。承認済みイベントが3回配信されても、ライセンスを3件発行したり、アカウントへ3回入金したり、サブスクリプションを3回延長したりしてはいけません。
Webhookだけを記録の根拠にしてはいけません。作成済みの決済リクエスト、承認済みの決済記録、ブロックチェーン上の入金、決済先ウォレットの動き、提供済みの注文を照合してください。この処理により、任意の送金を有効な注文として受け入れることなく、通知漏れや社内処理のエラーを検出できます。
例外、返金、照合に備える
最初の顧客が支払う前に、例外処理のルールを定めてください。
- 支払不足: 文書化した許容範囲の方針に従い、未払いまたは要確認の状態を維持する。
- 過払い: 実際の受取額を記録し、超過分を確認手続きに回す。
- 期限後の支払い: 古い見積もりを適用するか、新しい支払いを依頼するか、返金するかを決める。
- 重複支払い: 商品やサービスは一度だけ提供し、追加の送金は別途確認する。
- 誤ったトークン: 未対応または不一致のコントラクトには、自動で入金を反映しない。
- 誤ったネットワーク: 実際に使用されたチェーン上で取引を確認し、資産を回収できると約束しない。
- 不明な送金: 根拠がないまま、金額が近い注文へ関連付けない。
ブロックチェーンでの返金は、元の入金を取り消す処理ではなく、新しい出金取引です。送金前に、元の支払いと顧客を確認し、承認された資産と金額を確かめ、送金先が真正であることを確認し、ネットワーク手数料の負担者を定め、社内承認を得て、新しい取引として別に記録します。予期しないメールや問い合わせメッセージで届いた返金先アドレスを、本人確認の手順なしに使用してはいけません。
会計と照合のために、次の情報を保存します。
- 注文、請求書、顧客、決済リクエストの参照情報
- ネットワーク、ネイティブ資産またはトークン、トークンコントラクト
- 請求額と受取額
- 基準通貨での価値、レート情報の取得元、評価時刻
- 送金先アドレスとトランザクションハッシュ
- リクエスト、検知、承認、商品・サービス提供の各時刻
- 事業者が記録した手数料
- 状態の履歴、例外、返金、訂正取引
取引量とリスクに適した頻度で照合してください。一部入金、重複入金、未対応トークン、誤ったネットワークの申告、説明できない入金は、担当者と解決状態を設定した専用の一覧で管理します。暗号資産の税務、収益認識、評価に関する規則は地域によって異なるため、対象地域の有資格専門家へ相談してください。
よくある質問
BNB Chainで暗号資産決済を受け付けるにはどうすればよいですか?
ログイン済みの事業者向け設定画面で利用可能なBNB Chain資産を正確に確認し、事業者が管理する決済先ウォレットを設定してから、決済リンクを作成するか決済ページを組み込みます。ネットワーク名を明確に表示し、少額決済をテストして、送金内容がリクエストと一致し、必要な承認済み状態に達した後にのみ商品やサービスを提供してください。
BNB Smart ChainメインネットのチェーンIDは何ですか?
BNB Smart ChainメインネットのチェーンIDは56です。公式のウォレット設定ドキュメントにも、ネットワークシンボルとしてBNBが記載されています。設定の検証にはチェーンID 56を使いながら、顧客にはネットワーク名も明確に表示してください。
BNB ChainでUSDTを送る際、顧客にBNBは必要ですか?
通常のBEP-20送金では必要です。送信元ウォレットには、ガス代を支払うためのBNB Smart Chain上のBNBが必要です。ガス代用の残高は、事業者が請求するUSDTの金額とは別です。
どのBEP-20トークンでも受け付けられますか?
受け付けられるとは限りません。ログイン済みの実運用設定画面に表示され、かつウォレット、価格設定、承認、会計、問い合わせ対応、返金の各業務で扱えるトークンとネットワークの組み合わせだけを受け付けてください。コントラクトは発行体の一次情報で確認します。
BNB ChainとEthereumは同じですか?
同じではありません。BNB Smart ChainはEVM互換のため、アドレスや開発ツールが似ていますが、チェーンID 56とBNB建てのガス代を使用する別のネットワークです。Ethereum上で送信された取引がBNB Chain決済になることはありません。
BNB Chain決済は即時に処理され、すぐ確定しますか?
そのように約束してはいけません。送信、ブロックへの取り込み、承認、事業者による受け入れは、それぞれ異なる状態です。固定の時間や承認回数を保証するのではなく、決済フローの承認済み状態と、注文に適したリスク管理方針を使ってください。
BNBとステーブルコインのどちらを使うべきですか?
BNBは、すでにBNBを保有する顧客やBNB建ての商品に適しています。対応するステーブルコインは法定通貨建ての商品で使いやすい場合がありますが、顧客にはガス代用のBNBも必要です。実際の需要に基づいて選び、実運用中の設定画面で正確な決済経路を確認してください。
決済リンクと決済ページの組み込みのどちらから始めるべきですか?
試験導入、請求書、手作業で提供するサービスには決済リンクを使います。承認済みの決済に応じて注文、アカウント、クレジット残高、ライセンス、利用期間を自動更新する必要がある場合は、決済ページを組み込んでください。
BNB Chain決済は返金できますか?
事業者が承認し、新しい出金取引を実行できる場合は返金できます。元の支払い、受取人、送金先、資産、金額、手数料の扱い、承認を確認したうえで、返金を別の取引として記録してください。元の送金を取り消す処理ではありません。
まとめ
BNB Chainで暗号資産決済を安全に受け付けるには、資産とネットワークの各組み合わせを、管理対象となる1つの決済手段として扱うことが重要です。実運用中の選択肢を確認し、チェーンID 56を使い、すべてのBEP-20コントラクトを発行体の一次情報で検証し、ガス代にはBNB Smart Chain上のBNBが使われることを顧客へ伝えてください。
まず顧客がすでに保有している資産から始め、見積もり、ウォレットへの遷移、処理待ちと承認済みの状態、認証済みWebhook、冪等な提供処理、例外対応、照合、返金までの経路全体をテストします。多くの試験導入では決済リンクで十分です。基本の決済経路が安定して機能するようになったら、組み込み型の決済ページや継続的なアクセス提供を検討できます。実際の需要が追加の運用負担を上回る場合にのみ、対応トークンを増やしてください。


