一言で言えば、サーバーが「このリソースを利用するには支払いが必要です」と言っている状態です。
HTTP 402 Payment Required は、HTTP 仕様の中で最も神秘的で活用されていないステータスコードの一つです。404 (Not Found) や 401 (Unauthorized) などの有名なコードとは異なり、402 はウェブ上でネイティブな決済メカニズムを可能にするという先見の明を持って設計されました。
サーバーが 402 レスポンスを返すとき、それは明確なメッセージを伝えています。「このリソースは存在し、あなたの認証情報も正しいですが、アクセスするには支払いが必要です。」 これは、通常認証や認可の問題を示す他の 4xx クライアントエラーコードとは根本的に異なります。
402 ステータスコードには、初期のウェブコマースに対する楽観的な期待を反映した興味深い歴史があります。
HTTP 402 は、1997年に公開された最初の HTTP/1.1 仕様 (RFC 2068) に含まれており、「将来の使用のために予約済み」と明記されていました。当時は、電子商取引の進化に伴い、支払い要求の標準化された方法が不可欠になると考えられていました。HTTP の設計者たちは、デジタルマイクロペイメントが一般的になると予測していました。
20年以上にわたって仕様の一部であったにもかかわらず、402 はほとんど使われないままでした。標準化されたデジタル決済システムの欠如と、プラットフォームを越えた決済フローの実装の複雑さにより、ウェブサイトは独自の色々な決済フローを開発することになりました。
暗号通貨、USDC のようなステーブルコイン、そして x402 のようなプロトコルの登場により、402 ステータスコードはようやくその目的を見出しました。現代のブロックチェーン技術は、HTTP とシームレスに連携できる標準化されたプログラム可能な決済レイヤーという、欠けていたパズルの一片を提供しています。
これらのステータスコードの違いを理解することは、適切なウェブ開発と API 設計において非常に重要です。
| ステータス | 意味 | 一般的なシナリオ | 必要なユーザーアクション |
|---|---|---|---|
| 401 Unauthorized | 認証が必要 | 未ログイン、トークンの期限切れ | ログインまたは認証情報の更新 |
| 403 Forbidden | 認証済みだが許可なし | アカウントに権限がない | 管理者にアクセス権をリクエスト |
| 402 Payment Required | 支払いが必要 | ペイ・パー・ビュー、マイクロペイメント | 決済トランザクションを完了 |
| 404 Not Found | リソースが見つからない | リンク切れ、コンテンツの削除 | URLを確認するかサポートに連絡 |
1997年から HTTP 仕様の一部であったにもかかわらず、402 の採用率は非常に低いものでした。その理由は以下の通りです。
HTTP 仕様はステータスコードを定義しましたが、支払いがどのように行われるべきかは規定していませんでした。標準化された決済ヘッダー、リクエスト形式、またはレスポンス構造がなかったため、それぞれの実装に互換性がありませんでした。
クレジットカード決済には、決済プロセッサとの複雑な統合、PCI コンプライアンス、継続課金ロジック、不正防止システムが必要です。このオーバーヘッドにより、少額のトランザクションに 402 を使用するのは非現実的でした。
従来の決済システムには最低取引手数料があり、マイクロペイメント（1ドル未満）を経済的に不可能にしていました。取引コストが 0.30 ドルの場合、0.05 ドルの記事アクセス料は成立しません。
企業は代替案を開発しました。サブスクリプションモデル、広告ベースのコンテンツ、OAuth ベースのアクセストークン、または JavaScript ベースのアクセス制御で 200 OK を返すカスタムペイウォールなどです。
RFC 9110（現在の HTTP 仕様）によると、402 ステータスコードは以下のように定義されています。
公式に標準化されてはいませんが、一般的な実装には以下が含まれます。
X-Payment-Required：必要な支払いに関する情報X-Price：支払うべき金額X-Currency：支払いの通貨（USD、USDCなど）X-Payment-Address：支払いの送信先アドレスx402 プロトコルは、包括的な決済ネゴシエーションシステムによってこれらのヘッダーを標準化しています。x402 対応のサーバーから 402 レスポンスを受け取ると、レスポンスには決済を自動的に完了するために必要なすべての情報が含まれています。
402 ステータスコードは、いくつかの新しいユースケースに特に適しています。
API のコールごとに課金する場合に 402 を使用できます。AI サービス、データ API、プレミアム機能にサブスクリプションなしでアクセスでき、使った分だけ支払うことができます。
ニュース記事、研究論文、プレミアムコンテンツを少額の支払いでアンロックできます。サブスクリプションは不要で、個別のコンテンツに対して支払うだけです。
自律型エージェントやボットが、人間の介入なしに有料リソースにアクセスして支払いを行うことができます。402 レスポンスは、自動決済処理に必要なすべてを提供します。
Web3 アプリケーションは 402 を使用して分散型リソースへのアクセスを制限し、決済は USDC や他のステーブルコインでオンチェーンで決済されます。
ゲーム内購入、デジタルアセット、プレミアム機能を、402 レスポンスによってトリガーされる即時決済でアンロックできます。
すべてのモダンブラウザは 402 を有効な HTTP ステータスコードとして認識しますが、組み込みの処理機能は持っていません。
| プラットフォーム | ステータス | 備考 |
|---|---|---|
| Chrome/Edge | ✅ 認識済み | クライアントエラーとして表示 |
| Firefox | ✅ 認識済み | クライアントエラーとして表示 |
| Safari | ✅ 認識済み | クライアントエラーとして表示 |
| Node.js/fetch | ✅ フルサポート | プログラムで処理可能 |
| cURL | ✅ フルサポート | ステータスコード 402 を返す |
ブラウザは 402 決済を自動的に処理しませんが、クライアントサイドのライブラリやブラウザ拡張機能が 402 レスポンスをインターセプトして決済フローをトリガーできます。
それこそが x402 が解決することです。「支払いが必要」というシグナルを、自動的でシームレスなチェックアウト体験に変換します。
全行程は数秒で完了し、多くの場合ユーザーの介入は不要です。これは HTTP 402 が本来意図していたビジョンであり、現代の暗号資産インフラによってようやく実現されました。
アプリケーションに 402 を実装したい開発者の方は、こちらのクイック概要をご覧ください。
// Express.js の例
app.get('/premium-content', (req, res) => {
if (!isPaid(req)) {
return res.status(402).json({
error: '支払いが必要です',
price: '0.10',
currency: 'USDC',
paymentAddress: '0x...'
});
}
res.json({ content: 'プレミアムコンテンツはこちら' });
});// JavaScript の例
const response = await fetch('/premium-content');
if (response.status === 402) {
const paymentInfo = await response.json();
// 決済フローをトリガー
await processPayment(paymentInfo);
// 支払い証明を持ってリトライ
return fetch('/premium-content', {
headers: { 'X-Payment-Proof': proof }
});
}x402 のようなプロトコルにより、HTTP 402 の未来は明るいものです。
ウェブが本来持っていたネイティブ決済のビジョンがようやく現実のものとなりつつあり、HTTP 402 はその変革の中心にあります。