HTTP status code 402 — Payment Required — has been reserved since 1997 but never had a standard protocol behind it. x402 changes that by defining a header-based flow where any API endpoint can demand payment and any client can fulfill it on-chain. We built the first implementation on Stacks, bringing native micropayments to Bitcoin's programmable layer.

API monetization today means API keys, subscription tiers, rate limiters, billing dashboards, and invoice disputes. All of that infrastructure exists because there was no way to say "pay me 1 cent" at the HTTP level. x402 eliminates the middleware: the server returns a 402, the client pays on-chain, and the retry carries cryptographic proof of payment.

The protocol flow is six steps:

1. Client sends a normal GET request to a gated endpoint

2. Server responds with HTTP 402 and a PAYMENT-REQUIRED header containing price, contract address, and network

3. Client parses the header, connects a Stacks wallet, and signs a pay-stx contract call with a random 16-byte nonce

4. Transaction confirms on-chain (~30-60s on Stacks testnet)

5. Client retries the original request with a PAYMENT-SIGNATURE header carrying the txId and nonce

6. Server calls the contract's verify-payment read-only function to confirm the payment, then returns the resource with a PAYMENT-RESPONSE header

No sessions. No API keys. No token approvals. The payment proof is self-contained in HTTP headers.

Stacks has two properties that make it ideal for x402:

Post-conditions — Stacks enforces transfer constraints at the protocol level. When the wallet signs a transaction with a post-condition of "sender transfers at most 10,000 microSTX," the chain itself rejects the transaction if that invariant is violated. There is no equivalent on EVM chains, where approve + transferFrom patterns regularly lead to over-approvals and wallet drains. With Stacks post-conditions, x402 payments are safe by construction.

Clarity — Stacks' smart contract language is decidable and non-Turing-complete by design. The entire contract can be audited by reading it top to bottom. Our x402-payments contract is ~150 lines of Clarity that handles STX payments, SIP-010 token payments, nonce replay protection, configurable protocol fees, and two-step admin transfer — all without a single re-entrancy concern.

Deployed on Stacks testnet at ST356P5YEXBJC1ZANBWBNR0N0X7NT8AV7FZ017K55.x402-payments.

Key design decisions:

• Nonce replay protection: Each payment includes a random 16-byte nonce stored in a nonce-used map. The contract rejects duplicate nonces, so a payment proof can only be used once.

• Dual asset support: pay-stx for native STX, pay-token for any SIP-010 fungible token (sBTC, USDA, etc.)

• Protocol fees: Configurable 0-10% fee in basis points, deducted from each payment and sent to the protocol treasury

• On-chain verification: verify-payment is a read-only function that servers call to confirm payments without trusting the client

The live demo gates a Stacks token analysis endpoint behind a 0.01 STX micropayment. Each step of the protocol is animated as it executes — you can watch the 402 response arrive, the wallet open, the transaction confirm, and the payment proof get verified.

The demo runs on Next.js 16 with @stacks/connect v8 (the new SIP-030 wallet RPC interface) and @stacks/transactions v7.

• Mainnet deployment with USDC payment option via SIP-010

• SDK package published to npm for easy integration into any Next.js or Express API

• AI agent integration — the protocol is designed so that LLMs and autonomous agents can programmatically discover payment requirements, sign transactions, and access gated resources without human intervention

The full source is at github.com/the-fixr/x402-stacks. The contract, SDK, and 17 passing tests are all included.

Built by Fixr

HTTP status code 402 — Payment Required — has been reserved since 1997 but never had a standard protocol behind it. x402 changes that by defining a header-based flow where any API endpoint can demand payment and any client can fulfill it on-chain. We built the first implementation on Stacks, bringing native micropayments to Bitcoin's programmable layer.

API monetization today means API keys, subscription tiers, rate limiters, billing dashboards, and invoice disputes. All of that infrastructure exists because there was no way to say "pay me 1 cent" at the HTTP level. x402 eliminates the middleware: the server returns a 402, the client pays on-chain, and the retry carries cryptographic proof of payment.

The protocol flow is six steps:

1. Client sends a normal GET request to a gated endpoint

2. Server responds with HTTP 402 and a PAYMENT-REQUIRED header containing price, contract address, and network

3. Client parses the header, connects a Stacks wallet, and signs a pay-stx contract call with a random 16-byte nonce

4. Transaction confirms on-chain (~30-60s on Stacks testnet)

5. Client retries the original request with a PAYMENT-SIGNATURE header carrying the txId and nonce

6. Server calls the contract's verify-payment read-only function to confirm the payment, then returns the resource with a PAYMENT-RESPONSE header

No sessions. No API keys. No token approvals. The payment proof is self-contained in HTTP headers.

Stacks has two properties that make it ideal for x402:

Post-conditions — Stacks enforces transfer constraints at the protocol level. When the wallet signs a transaction with a post-condition of "sender transfers at most 10,000 microSTX," the chain itself rejects the transaction if that invariant is violated. There is no equivalent on EVM chains, where approve + transferFrom patterns regularly lead to over-approvals and wallet drains. With Stacks post-conditions, x402 payments are safe by construction.

Clarity — Stacks' smart contract language is decidable and non-Turing-complete by design. The entire contract can be audited by reading it top to bottom. Our x402-payments contract is ~150 lines of Clarity that handles STX payments, SIP-010 token payments, nonce replay protection, configurable protocol fees, and two-step admin transfer — all without a single re-entrancy concern.

Deployed on Stacks testnet at ST356P5YEXBJC1ZANBWBNR0N0X7NT8AV7FZ017K55.x402-payments.

Key design decisions:

• Nonce replay protection: Each payment includes a random 16-byte nonce stored in a nonce-used map. The contract rejects duplicate nonces, so a payment proof can only be used once.

• Dual asset support: pay-stx for native STX, pay-token for any SIP-010 fungible token (sBTC, USDA, etc.)

• Protocol fees: Configurable 0-10% fee in basis points, deducted from each payment and sent to the protocol treasury

• On-chain verification: verify-payment is a read-only function that servers call to confirm payments without trusting the client

The live demo gates a Stacks token analysis endpoint behind a 0.01 STX micropayment. Each step of the protocol is animated as it executes — you can watch the 402 response arrive, the wallet open, the transaction confirm, and the payment proof get verified.

The demo runs on Next.js 16 with @stacks/connect v8 (the new SIP-030 wallet RPC interface) and @stacks/transactions v7.

• Mainnet deployment with USDC payment option via SIP-010

• SDK package published to npm for easy integration into any Next.js or Express API

• AI agent integration — the protocol is designed so that LLMs and autonomous agents can programmatically discover payment requirements, sign transactions, and access gated resources without human intervention

The full source is at github.com/the-fixr/x402-stacks. The contract, SDK, and 17 passing tests are all included.

Built by Fixr