この記事では、筆者がこれまで関わってきた web3 × 決済 の実装事例を、Tips集という形でまとめます。
うまくいった話だけでなく、BANされた話やコストが爆発した話など、正直あまり表に出しにくい経験も含めています。
これから同じ領域に挑戦する人が、同じ地雷を踏まないための実践知になれば幸いです。
想定読者
- web3プロダクトの開発や企画に関わっており、これから決済の導入を検討しているエンジニア・PM
- NFTやトークンを扱いつつ、法定通貨決済（クレジットカード・オンランプ等）との接続に悩んでいる人
- StripeやGMO系決済など、既存のWeb2決済サービスを使ってWeb3事業を展開しようとしている事業者
- 決済トラブル（BAN、売上金凍結、API不安定、Reorgなど）を事前に理解し、地雷を避けたい人
なぜ「web3 × 決済」はトラブルが起きやすいのか
web3 × 決済のトラブルは、複数のレイヤーにまたがって発生します。
特に混同されやすいのが、Web2の決済API, Web3系の決済API, ブロックチェーンそのものの違いです。
それぞれ責任範囲とリスクの性質が異なるため、分けて理解する必要があります。
Web2の決済APIに起因するパターン
主にStripe や GMOペイメントゲートウェイ などのクレジットカード決済サービスが該当します。
このレイヤーでの問題は、技術的な障害よりも、利用規約や事業内容の解釈によって発生します。
実装が正しくても、決済事業者の判断によりアカウントが停止され、最悪の場合は売上金が没収されるケースさえあります。
決済はコードではなく、事業全体を評価対象として扱われます。
また、利用規約だけではなく、「実際に導入した事業者からの生の声」を聞くことも重要です（というかそれしか抜本的な対策はないかも）。
例えばStripeはじめ代表的な決済サービスはWeb3系のサイトに対して厳しい措置を取ることが多いですが、fincode by GMOは柔軟に対応してくれます。また、CSが日本国内なので、何かあった時の対応も早く、コミュニケーションが取りやすい。
Web3系の決済API・SaaSに起因するパターン
Web3系の決済APIには、暗号資産の オンランプ（法定通貨 → 暗号資産） や オフランプ（暗号資産 → 法定通貨） サービスが該当します。
このレイヤーでは、Web2のようなアカウントBANは少ない一方、APIエラーや処理失敗が頻発します。
また、Web3系SaaSは事業の継続性が不透明な場合も多く、破壊的な仕様変更やサービス終了リスクを内包します。
加えて、Web3系SaaSは事業継続性に不安があり、破壊的な仕様変更や、最悪の場合はサービスの突然終了も現実的なリスクです。
一時的な決済システム（イベントやNFTのPrimary Saleなど）の導入には良いですが、継続的なサービスにおいてはそもそも導入を控える方が良いです。また導入する場合も、万が一使えなくなった時のためのリカバリープランと、そのための疎結合なアーキテクチャを保つべきです。
ブロックチェーンそのものに起因するパターン
最後は、ブロックチェーン自体に起因する問題です。
代表的なのがReorg（リオーグ）で、一度確定したブロックが無効化され、取引が消失する可能性があります。
これは決済用途では致命的であり、チェーンの最終確定性やReorg頻度を理解せずに扱うのは危険です。
特にPolygonではReorgが頻発することで知られています（チェーンの高速化と引き換えにブロックサイズが大きいため）
実際の事例集
本セクションでは、筆者自身や近しいチームが関わった web3 × 決済 の実例を整理します。
成功・失敗の結果そのものよりも、「どのレイヤーで何が起きたのか」に注目して読んでいただければと思います。
漫画家のNFTマーケットプレイス （Shopify, Stripe, React）
Shopifyをベースにカスタマイズし、漫画家のNFTを販売するマーケットプレイスを構築しました。
結果として、日本初のクレジットカード決済に対応したNFTマーケットプレイスとなった事例です。
NFTはオンチェーンで発行していましたが、決済体験は完全にWeb2として設計し、Stripeを利用しました。
このケースでは、決済面で大きなトラブルは発生しませんでした。
（事業としては総合型のNFT Marketplaceを開発することとなり、そちらに吸収）
セクシー女優のファン向けサブスクリプション （Stripe, React）
当時、国内外でセクシー女優のNFT企画が相次いでおり、中国では大規模なセール（約1億5000万円）に成功した事例もありました。
僕たちもご縁があり、トップランクのセクシー女優の方のNFT企画に関わらせていただくこととなりました。
そして開発したのがファンコミュニティ向けのサブスクリプションサイトです。
月額課金制で、会員ランクに応じて毎月NFTを配布する設計です。
決済についてはStripeを利用し、こちらも特に大きな問題は発生しませんでした。
ここまではStripeで特に問題なかったのですが、おそらくNFTブームの初期だったからだと思います。
翌年からは、周りの会社でWeb3 x Stripeのトラブルが相次ぎました。
日本IPのNFT販売サイト （Stripe, Finocode, Next.js）
こちらは、友人の会社が運営していた日本IPのNFT販売サイトの事例です。
運用途中で、Stripeのアカウントが警告なしに突然停止されました。売上金も凍結され、引き出せないという最悪の状況に。
言語や地域の壁があり、コミュニケーションにも相当な苦労をしたようでした。
最終的に売上金の凍結はなんとか解除できたものの、アカウントの再開は認められなかったとのこと。
プロダクトについては、色々な決済サービスを模索した中で、Finocode by GMOにたどり着いたことでクリアしたようです。
FinocodeはWeb3事業に対しても利用を認めてくれており、またCSコミュニケーションもスムーズだったようです。
総合型NFT Marketplaceへのリブランディング (Stripe, Next.js, Moralis)
前述の漫画家向けのNFT Marketplaceをリブランディングして、OpenSeaのような総合型のNFT Marketplaceを開発しました（僕のweb3キャリアを通じて最もハードな挑戦の一つでした）。
日本の一般人・大衆層への普及を目指して、まずSNSベースのログインを導入して、次いでクレジットカード決済を導入しようとしました。
しかし、Stripeの実装については完了したものの、Stripeの本番環境での利用申請が承認されませんでした。
元々Stripeベースの実装アーキテクチャを想定していたので、Fincode等に差し替える実装は軽いものではなく、結局最後までクレジットカード決済を導入できませんでした。
（並行して行なっていた他のプロジェクトではFincodeによるクレジットカード決済を導入しました）
仮想通貨決済サービス （オンチェーン決済, Polygon, Laravel, Vue.js）
仮想通貨決済サービスの開発に関わった事例です（僕の主担当は社内の他のプロダクトでしたが、開発組織を率いる立場だったため間接的に関わりました）。
エンドユーザーは複数の暗号資産から支払い通貨を選択でき、受け取り側はステーブルコインで着金する設計（よくある仕様です）。
複数のブロックチェーンで使用でき、特にPolygonは手数料の安さと処理速度から人気がありました。しかしそのPolygonで問題が発生します。
PolygonはReorgが多いチェーンとして有名で（特に一時期はひどかった）、本件でもReorgにより決済データ消失が発生しました、当然、支払いの整合性もおかしくなってしまいます。
再発防止に向けて色々方法を模索したものの、結局力技で押し切らざるを得なかったようです。具体的には、全ブロックを取得して照合するという方法です。確かにこれならデータ整合性については間違いありませんが、ブロック取得に必要なRPC Endpointの負担が膨大となり、相当なインフラコストとなっていました。
とはいえ、「決済」という性質上、サービスの信頼性には替えられないのでやむをえない意思決定かなと思います。
まとめ
決済サービスは技術ではなく事業を見ている
これらの経験から強く感じたのは、決済サービスが見ているのはコードではなく事業の説明可能性だということです。
web3であること自体は、武器にもなりますが、同時にリスクにもなります。
「どう説明できるか」を常に考える必要があります。
Web3プロダクトにおける決済設計の現実的なベストプラクティス
実務的には、決済レイヤーは極力Web2に寄せ、web3要素は裏側に閉じ込めるのが一番安定します。
ユーザー体験、会計処理、運用負荷を優先し、ブロックチェーンは実装詳細として扱う。
この割り切りが、結果的にプロダクトを長生きさせます。