このページの内容
暗号資産決済の導入ガイドの多くは、当然のようにウェブサイトを持っていることを前提にしています。ところが、暗号資産で報酬を受け取りたい人の大半は、そもそもサイトを持っていません。3つの時差をまたいだクライアントに請求するデザイナー、プラグインを販売する開発者、家庭教師、翻訳者、編集者、コミュニティのモデレーター、依頼を受けるイラストレーター、フォントやプリセットパックを売る小さなスタジオなど、商業活動のすべてがDM、メールのやり取り、Discordサーバー、あるいは自分では管理できないプロフィールページの中だけで完結している人たちです。こうした人たちに対する正直な答えは、決済とは「プロジェクト」ではなく「1本のURL」であるということです。本ガイドはその決済リンクについて解説します。実際に成約へつながるリンクの作り方、商品を自動で納品させる方法、そしてクライアントが支払いやすい請求書へと変える方法を扱います。
本当にストアが必要な人、最初から不要だった人#
ストア(ウェブサイト)が解決すべき課題は3つあります。商品カタログの提示、代金の受け取り、そして納品です。すでに欲しい商品が決まっている相手に1点、あるいは数点だけを販売するのであれば、実際に必要なのは2番目と3番目だけです。そのためだけにサイトを構築するのは、荷物を1つ発送するために倉庫を借りるようなものです。
購入の意思決定がどこで行われているかを考えてみてください。見積もり、依頼、通話、コメントのやり取りなど、会話の中で決まるのであれば、ストアを用意してもクリックが増えるだけで、成約率は上がりません。その瞬間に必要なのは、会話がまだ温かいうちにそのまま貼り付けられるものです。反対に、見込み客があなたを知らない状態で見つけ、比較検討してから決めるタイプであれば、閲覧できるページが必要になります。この違いは、以下で紹介するどんな技術選択よりも重要であり、次のセクションで紹介するルートが1つではなく2つ用意されている理由でもあります。
唯一省略できないステップ:入金を受け取るためのアカウント開設です。no-KYCゲートウェイであれば所要時間は約30秒、書類の提出も不要です。だからこそ「サイトなし」というアプローチ全体が現実的になります。そうでなければ、「ノーコード」という利点も、数週間に及ぶ本人確認手続きの前ではかすんでしまいます。
ノーコードで使える3つの方法#
本ガイドの内容は、突き詰めると3つの型に集約されます。これらは競合するものではなく、多くの人が状況に応じてそのうち2つを使い分けることになります。
| ルート | 最適な用途 | 買い手が得るもの | 設定時間 |
|---|---|---|---|
| 決済リンク | 単品の商品、1件の見積もり、1通の請求書 | どこにでも貼り付けられるURL形式のホスト型決済ページ | 約1分 |
| ホスト型ショップ | 買い手が閲覧する小規模なカタログ | 独自ドメイン上のブランド化されたストア | 約15分 |
| QRコード | 対面、印刷物、画面表示 | クリックの代わりにスキャンする同じ決済画面 | 即時 |
CryptoPayInでは、決済リンクはcryptopaylink.co上に、ショップはshopycrypto.com上に置かれます。どちらもメインサイトとは別ドメインなので、クライアントに送るのは他人のブランドにクエリ文字列を継ぎ足しただけのURLではなく、すっきりとした専用の決済URLになります。QRコードは4つ目の商品ではなく、どのリンクも正方形の形に変換したものにすぎません。これは見た目以上に重要な意味を持ちます。同じ1つのオブジェクトが、メール、チャット、スライド、請求書のPDF、屋台の看板、名刺の裏面まで、あらゆる場面でそのまま使えるからです。
成約につながる決済リンクの作り方#
決済リンクの設計は、いくつかの小さな意思決定の積み重ねです。それぞれが実際の場面に対応しており、そこを正しく設定できるかどうかが、支払ってもらえるリンクと、質問攻めに遭うリンクとの分かれ目になります。
固定価格にするか、買い手に金額を入力させるか
プリセットパックやライセンス、1か月分のサポートなど、明確な商品を売る場合は価格を固定します。一方、チップや寄付、預かり金、「この請求書の残額を支払う」、残高のチャージなど、支払う側が金額を決める場合は、金額欄を空欄にしておきます。金額を買い手側の入力に任せられるなら、1本のリンクだけでクライアント全体をカバーできます。これはまさにフリーランスにとって典型的なケースです。
普段使っている通貨で価格を考える
見積もりは€400や$500のように普段の感覚で提示し、顧客はBitcoin、USDT、Moneroなど自分が保有している資産で支払います。価格設定は30種類の法定通貨に対応しており、暗号資産での金額は、複数の独立したソースで照合されたレートをもとに、請求書作成の瞬間に算出されます。そのスナップショットは請求書の有効期間中ずっと固定されるため、買い手がウォレットを探している間に相場が動いても、それはあなたの問題にはなりません。さらに、レートのソース間に食い違いがあったり、情報が古いと判断された場合は、価格を誤って提示するくらいなら、そもそも請求書自体が作成されない仕組みになっています。
上限、有効期限、そして「売り切れ」状態
リンクには支払い回数の上限を設定できます。1回限り、50回まで、あるいは背後の在庫が尽きた時点で自動的にクローズする設定も可能です。特定のクライアント向けの請求書には、1回限りのリンクを使いましょう。誤って転送されて二重に支払われる心配がありません。公開商品には上限なしのリンクを使います。請求書自体はデフォルトで30分後に失効し、最長24時間まで延長設定できます。この時間枠はレート変動リスクに備えるためのものであり、あなたを縛るものではありません。期限を過ぎた買い手には、単に新しい請求書が発行されるだけです。到着が遅れた資金も、問題なく入金されます。
納品に必要な情報を買い手に尋ねる
決済画面にカスタム項目を追加すれば、その回答は支払いデータと一緒に届きます。納品先のメールアドレス、ゲーム内のユーザー名、Discordのハンドル名、有効化するドメイン、希望のファイル形式、ライセンスに記載する名前など、用途はさまざまです。これはノーコード販売において、最も活用されていない機能と言っても過言ではありません。ここで追加する項目1つひとつが、後で送らずに済むサポートメールそのものであり、回答はあなたにしか見えません。
他人になったつもりで試す。自分のリンクをスマートフォンのプライベートウィンドウで開き、実際に最後まで進めてみてください。この2分間の確認だけで、抜けている項目、あいまいな商品名、間違った通貨で設定してしまった価格に気づけます。この3つは、確認を怠ると顧客に発見されることになります。
自動納品:決済を「商品化」する仕組み#
代金を受け取るだけの決済画面では、実際の作業は結局あなたが手作業でこなすことになり、しかも入金がいつ届くかはわかりません。リンクに納品の仕組みを組み込んで初めて、「暗号資産を受け付けています」という状態が、あなたが眠っている間にも自動で動く仕組みへと変わります。これが単なる決済ツールと、本当の意味での販売チャネルとの違いです。
サイトなしで販売されるものの大半は、次の3種類の納品方法でカバーできます。
- メッセージ。決済が確定すると領収書上に自由なテキストが表示される方式です。アクセス方法、クーポン、非公開の住所、予約用リンク、次のステップなど、内容は自由に設定できます。最もシンプルで、最も柔軟な方法です。
- ダウンロードまたはリダイレクト。決済確定の直後に、買い手がファイルや非公開ページへ直接アクセスできる方式です。デジタル商品、講座、テンプレート、素材パックなどに自然に合う方法です。
- ライセンスキー。最大1万件までのキーをまとめてアップロードしておくと、決済1件につき1件ずつ、重複なく配布されます。プールが空になると、納品できない商品を売ってしまう前にリンク自体が自動的にクローズします。
最後のライセンスキーの仕組みは特に強調しておく価値があります。というのも、無人販売における最も難しい課題、すなわち二重販売してはいけない在庫の管理を、静かに解決してくれるからです。キー、座席、コード、招待、ナンバリングされたエディションなど、数量が限られていて一意なものすべてが対象です。リンクそのものが在庫管理システムとなり、週末に帳尻を合わせる作業も発生しません。
納品内容は、決済が確定した瞬間に買い手の領収書上に表示されます。確定までの時間は選択したネットワークによって数秒から20分ほどです。誰もあなたの対応を待つ必要はなく、商品説明に「24時間ほどお待ちください」といった一文を書く必要もありません。
決済リンクがショップに進化するとき#
取り扱う商品が数点を超えたり、購入前に見比べてもらいたい場合、商品ごとにリンクを1本ずつ用意するだけでは足りなくなります。ホスト型ショップを使えば、専用URLを持つ1つのブランドページに商品をまとめられます。テーマを選び、商品を追加し、実際の画面をプレビューして、公開するだけです。コーディングもホスティングの手配も不要です。
バリエーションと在庫
各商品には最大30通りのバリエーションの組み合わせを設定できます。サイズ、プラン、エディション、期間、座席数などが対象で、それぞれに個別の価格と個別のキー在庫を持たせられます。この点こそが、ショップを単なる見栄えの良いリストで終わらせない部分です。「Standard/Pro/Studio」は、見かけ上は1つの選択肢ですが、重要な意味においては3つの独立した商品として扱われます。
物理商品と配送
データではなく実際に郵送する商品を扱う場合は、商品を「物理商品」に設定し、配送先国を選択してください。決済画面では、実際に配送できる国の買い手からのみ配送先住所が収集されます。デジタル商品と物理商品は別々の決済で購入される仕組みになっていますが、これは制約のように見えて、実はメリットです。1つの注文につき発送経路が1本に定まり、一部だけ発送済みのバスケットが生じることもありません。
どこまで拡張できるか
1アカウントにつきショップは最大10店舗、各ショップにつき商品は最大50点まで登録できます。これはデモの域を超えた、本物のスモールビジネスとして十分な規模です。クライアント向けに1店舗、副業プロジェクト向けに1店舗、コラボレーション向けに1店舗というように、それぞれ独自のフロントを持たせられます。内部的には、すべての商品が決済リンクとして扱われているため、買い手がショップ経由で来ても、チャットに貼り付けたURL経由で来ても、納品もキーもカスタム項目もまったく同じように機能します。
暗号資産でクライアントに請求書を発行する#
フリーランスやエージェンシーが抱える課題は、一般的な売り手とは少し異なります。金額は交渉で決まり、買い手は企業であり、後で誰かの経理担当者がこれをチェックすることになります。仕組み自体は同じで、決済リンクがそのまま請求書になりますが、押さえておくべきポイントが4つあります。
自国通貨で見積もり、相手の資産で受け取る
請求書には、€2,400や$3,000のように、普段どおりの金額をそのまま記載します。クライアントは自分が保有している資産で支払います。相手が資金を保有する企業であれば、多くの場合ステーブルコインでの支払いとなり、その場合は両者にとって計算が完全に一致します。相手のUSDT残高から2,400が減り、あなたの残高に2,400が入る、それだけです。換算をめぐる言い争いも、「どのレートを使ったのか」というメールのやり取りも発生しません。
金額のすぐそばにリンクを置く
決済リンクは、URLとQRコードの両方の形で、請求書の合計金額のすぐ横に記載するのが基本です。カスタム項目や支払い案内欄を追加できる請求書ソフトであれば十分で、わざわざ「暗号資産に対応した」ソフトを用意する必要はありません。PDFで送付する場合は、実際にスキャンされるのはQRコードのほうです。なぜなら、PDFを受け取った人と実際に支払う人が別であることも多いからです。
一括送金ではなく、マイルストーンごとの支払い
オンチェーン決済は、確定した時点で取り消しができません。これはチャージバックが発生しないという長所である一方、双方にとって同じ意味を持ちます。大型案件では、金額全体を1本のリンクにまとめないようにしましょう。着手金、中間金、納品時支払いというように分割するのです。3本のリンク、3つの支払い日があれば、どちらか一方だけがすべてのリスクを背負うことはありません。これはごく普通のビジネス慣行であり、暗号資産はそれを明確な形にしているだけです。詳しい考え方は確定性と返金についてのガイドで解説しています。
経理担当者には「退屈な」データを渡す
すべての決済は、行ごとに総額・手数料・純額を記録した台帳に反映され、トランザクションハッシュとともにCSV形式で書き出せます。収益は自国通貨で認識され、手数料は独立した経費項目として計上され、ハッシュは誰にも異議を唱えられない領収書として機能します。決済のレールが変わったからといって、納税義務が変わるわけではありません。とはいえ、各行が公開された恒久的な記録にリンクしている分、この帳簿は銀行の明細書よりもむしろ整理されていると言えるかもしれません。
人間ではない買い手という未来#
独自開発の決済画面よりもリンクを選ぶべき、将来を見据えた理由が1つあります。それは、有効な決済リンクは、機械が読み取れる決済窓口でもあるという点です。誰かの代理で買い物をするAIエージェントは、リンクのJSONを読み取り、価格、対応資産、入力すべき項目を正確に把握したうえで、請求書を作成し、支払いを行い、領収書を読み取ることができます。しかもAPIキーも、専用アカウントも必要ありません。これはショップのカタログについても同様です。
自律型の買い手が、あなたの収益の中で意味のある割合を占めるようになるかどうかは、今の時点で誰にも断言できません。確かなのは、あなたの商品がすでにリンクの形になっているなら、そうしたエージェントから到達可能であるためのコストはゼロだということです。独自フォームの場合は、決して小さくないコストがかかります。この仕組みに関わりたくない場合は、アカウント単位でオフに設定でき、その場合エンドポイントは403を返します。詳しい仕様はエージェント決済に関するページに記載しています。
APIに移行すべきタイミング#
ノーコードには現実的な限界があり、それがどこにあるのかを明確にしておく価値はあります。SaaSの課金サイクル、実行時に計算されるユーザーごとの金額、複数の売り手に分配するマーケットプレイス、決済確定と同時に残高を加算するゲームなど、自社システムからプログラムで決済を作成する必要が出てきたら、APIへの移行のタイミングです。判断基準は取引量ではなく、価格や納品内容が、自社ソフトウェアだけが持つデータに依存しているかどうかです。同じ商品を1万個売るだけならリンクで十分です。しかし、価格が顧客の先月の利用状況によって変わる商品を売るのであれば、それはもはやインテグレーション(システム連携)です。
その段階に来たとしても、必要なのは決済を作成する1つのエンドポイントと、決済完了を受け取る1つの署名付きwebhookだけであり、たいていの開発者は半日もあれば実装を終えます。その道筋は導入ガイド本編で最初から最後まで解説しています。それまでの間、この限界の天井は多くの人が思っているより高く、しかもここまで紹介してきたすべての仕組みは、料金体系という点ではまったく同じです。入金があったときだけ1%、入金がなければ無料。



