Why HTTP 402 Payment Required Wins for Cellular IoT Agents

The default telco billing model—monthly SIM leases, multi-year contracts, manual provisioning workflows—was designed for humans who pay once a month and stay on one network for years. IoT devices don't behave like humans. They roam unpredictably, transmit sporadically, and scale in bursts. Yet we still force them through the same billing infrastructure built for iPhone users in 2007.

HTTP 402 Payment Required flips that model: the device pays per kilobyte (or per session) at request time, in stablecoins, with no standing contract. For cellular IoT specifically—not just "agentic payments" in the abstract—this architectural shift solves four production problems that telco billing can't: elastic SIM provisioning, sub-monthly billing granularity, multi-carrier failover without negotiation, and zero-trust metering. We run eSIMx402 on this pattern. Here's why it works.

The telco billing problem: inventory, lead time, and billing quantum mismatch

Traditional cellular IoT deploys hit three constraints:

1. SIM inventory. You provision 10,000 SIMs upfront because adding capacity mid-deployment takes 4-6 weeks (carrier negotiations, eSIM profile generation, QA). If your agent fleet scales to 50,000 nodes in month two, you're stuck waiting or over-provisioning by 5x from day one.
2. Billing quantum is monthly. Carriers bill per SIM per month, even if the device transmits 2 KB on Tuesday and nothing else. An agent that wakes up twice a quarter still costs $1.50/month × 12 = $18/year. Multiply by 100,000 agents and you're paying $1.8M/year for devices that are idle 98% of the time.
3. Failover = new contract. If your primary carrier (AT&T) has coverage gaps in Nevada, adding Verizon as failover means negotiating a second contract, integrating a second provisioning API, and managing two SIM inventories. Agents can't dynamically pick the strongest signal without human intervention.

HTTP 402 IoT solves all three by decoupling payment from provisioning. The agent requests an eSIM profile on-demand, pays for the exact data it consumes (down to 1 KB granularity on our facilitator), and switches carriers by requesting a different profile—no contract amendments, no inventory lead time. Our quickstart guide shows a working implementation in 47 lines of Python.

How x402 dispatch works for cellular eSIM (not just generic API billing)

The x402 protocol (defined by Coinbase at x402.org) specifies a challenge-response flow where the API returns 402 Payment Required with a stablecoin invoice. Our cellular implementation adds two layers:

Layer 1: eSIM profile dispatch

When an agent calls POST /esim/activate without a valid payment proof:

import requests

response = requests.post(
    "https://api.esimx402.com/v1/esim/activate",
    json={"region": "us-west", "data_mb": 100},
    headers={"X-Agent-ID": "sensor-fleet-prod-001"}
)

if response.status_code == 402:
    challenge = response.json()
    # challenge structure:
    # {
    #   "invoice_id": "inv_7k2m9",
    #   "amount_usdc": "0.42",
    #   "recipient": "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb",
    #   "chain": "polygon",
    #   "expires_at": 1717459200
    # }

The agent pays the invoice on-chain (Polygon USDC in this example), then retries with the transaction hash:

from web3 import Web3

w3 = Web3(Web3.HTTPProvider("https://polygon-rpc.com"))
tx_hash = w3.eth.send_transaction({
    "to": challenge["recipient"],
    "value": w3.to_wei(float(challenge["amount_usdc"]), "mwei"),  # USDC has 6 decimals
    "from": agent_wallet_address,
    "gas": 21000
})

activation = requests.post(
    "https://api.esimx402.com/v1/esim/activate",
    json={"region": "us-west", "data_mb": 100},
    headers={
        "X-Agent-ID": "sensor-fleet-prod-001",
        "X-Payment-Proof": tx_hash.hex()
    }
)

if activation.status_code == 200:
    esim_profile = activation.json()["qr_code"]  # LPA:1$sm-dp.example.com$activation_code

Our facilitator confirms the on-chain payment (typically 2-8 seconds on Polygon, faster on Base), then dispatches the eSIM activation code. The agent installs the profile via LPAd (Local Profile Assistant daemon) and starts transmitting.

Layer 2: metered usage and top-up

Unlike monthly plans, the agent pays per-byte. When the initial 100 MB runs low, the facilitator sends a 402 response on the next data request:

HTTP/1.1 402 Payment Required
Content-Type: application/json

{
  "remaining_kb": 47,
  "top_up_options": [
    {"data_mb": 50, "amount_usdc": "0.18"},
    {"data_mb": 500, "amount_usdc": "1.62"}
  ],
  "invoice_id": "inv_9m4k1"
}

The agent selects an option, pays, and data flow resumes. No human approval loop, no service interruption beyond the settlement latency (P50: 3.1 seconds on Polygon as of May 2026 production data).

Production cost comparison: x402 vs. telco IoT plans

We deployed a fleet of 12,000 environmental sensors (temperature, humidity, particulate) across industrial sites in Q1 2026. Transmission pattern: 2 KB every 6 hours when readings are stable, 200 KB/hour during anomaly events (roughly 3% of runtime). Here's the cost breakdown:

The x402 approach cuts costs by 94% because we don't pay for idle capacity. Average data per device per month: 7.2 MB (5.8 MB baseline + 1.4 MB anomaly bursts). On AT&T, that's $1.50 flat. On eSIMx402, it's $0.0216 ($0.003 × 7.2).

The crossover point where telco plans become cheaper: ~500 MB/device/month of sustained traffic. Below that threshold (which covers 80%+ of IoT deployments based on our customer data), x402 wins on pure economics.

Elastic provisioning and carrier failover without re-negotiation

In month two of the sensor deployment, we expanded from 12,000 to 41,000 devices (new sites in Texas and Arizona). With telco SIMs, that would have required:

1. Capacity planning 6 weeks ahead (AT&T's standard lead time for bulk eSIM provisioning).
2. Contract amendment (volume pricing tiers change at 25K, 50K, 100K SIMs).
3. QA cycle for the new batch of eSIM profiles (2-3 weeks).

With x402, we called POST /esim/activate 29,000 times over 72 hours. Each agent paid $0.42 for its initial 100 MB allocation. Total onboarding time: the time it takes to run the activation script. No contract calls, no lead time.

Carrier failover is similarly frictionless. Arizona sites had poor T-Mobile coverage (our default carrier). Agents detected signal strength below -110 dBm, requested eSIM profiles from the Verizon pool (via "carrier": "verizon" in the activation request), paid the marginal cost difference ($0.0035/MB on Verizon vs. $0.003/MB on T-Mobile), and switched. Downtime: ~12 seconds (the LPAd profile swap plus initial attach). No human in the loop.

Our use cases page shows this failover pattern in production for multi-agent fleets.

Zero-trust metering and fraud resistance

Telco billing relies on the carrier's usage reporting, which you audit monthly via CDR (Call Detail Records). If there's a metering error—say, the carrier bills you for 150 MB when the device transmitted 90 MB—you file a dispute and wait 30-60 days for resolution. During that window, you're paying the inflated invoice.

x402 inverts the trust model. The agent's wallet holds the funds. The facilitator can't charge without presenting proof of data delivery (in our implementation, a signed CDR from the carrier's SMSC, validated on-chain via an oracle contract). If the proof doesn't match the invoice, the agent refuses to pay and the eSIM is suspended—no funds leave the wallet.

Fraud vector comparison:

• Telco model: carrier over-bills → you dispute → eventual refund (maybe).
• x402 model: facilitator over-bills → agent withholds payment → no transaction → dispute resolves at request time, not 30 days later.

We log every invoice and payment proof to an immutable append-only ledger (IPFS with Filecoin archival). Audits take minutes, not months. Our technical docs include the full CDR validation schema.

Polygon vs. Base vs. Arbitrum: settlement latency and gas cost tradeoffs

We tested three EVM-compatible chains for the facilitator:

We chose Polygon because IoT agents tolerate 3-8 second activation latency (the device is already waiting for signal acquisition, which takes 2-15 seconds anyway). The $0.0007 gas savings per transaction adds up: 4.2M activations in May 2026 = $2,940 saved vs. Base.

For latency-critical use cases (autonomous vehicles, real-time industrial control), Base is the better default despite higher gas. Our facilitator supports all three; agents specify the chain in the activation request.

FAQ

Can HTTP 402 work with existing IoT devices, or does the device firmware need x402 support?

The device needs to send the payment proof header (X-Payment-Proof) in the activation request. If you're retrofitting legacy devices that can't modify HTTP headers, you can run a local proxy (e.g., on a Raspberry Pi gateway) that intercepts 402 responses, pays on behalf of the device using a shared wallet, and forwards the activation. We include a reference proxy implementation in our quickstart repo. Fully autonomous agents (LangChain, AWS Bedrock AgentCore) handle the payment loop natively.

What happens if the on-chain payment succeeds but the eSIM activation fails (network timeout, carrier API downtime)?

The facilitator retries activation for up to 60 seconds. If it fails, we issue a refund transaction to the agent's wallet within 10 minutes (automated via a monitoring cron job). Refund rate in production: 0.14% of activations (mostly carrier API 503 errors during maintenance windows). The agent can retry with a new invoice. No double-spend risk because each invoice has a unique invoice_id that can only be settled once.

How do you handle roaming charges when an agent crosses borders?

The eSIM profile includes a roaming policy (list of allowed MCC/MNC codes). If the agent attaches to a network outside that list, the carrier rejects the attach request. The agent detects the rejection (via modem AT command response), requests a new eSIM profile for the current region (e.g., "region": "eu-central" instead of "region": "us-west"), pays the regional rate, and switches profiles. Total downtime: ~15 seconds (profile swap + new attach). No surprise roaming bills because the agent pre-pays for the exact region.

Is there a minimum purchase amount to avoid high gas-to-payment ratios?

Yes. On Polygon at $0.0004 gas per transaction, a $0.10 payment has 0.4% overhead. A $0.01 payment has 4% overhead. We set a floor of $0.05 per invoice ($0.003/MB × 16.7 MB minimum). Agents that need smaller increments can batch: request 50 MB upfront, use it over days/weeks, then top up. Alternatively, use the TON chain facilitator (not yet in production as of June 2026, but on our Q3 roadmap), which has sub-cent gas costs.

Can I use x402 for non-cellular connectivity (Wi-Fi, LoRaWAN)?

The protocol is transport-agnostic. We focus on cellular eSIM because that's where the telco contract pain is most acute, but the same pattern works for any metered API. If you're building a LoRaWAN gateway that charges per uplink, x402 fits. Wi-Fi is trickier because captive portals don't natively support 402 responses, but you can layer it on top (the access point returns a redirect to an x402 payment page). Coinbase's x402.org spec has examples for non-cellular use cases.