ApiCharge and x402: Converging on the Future of API Payments

The x402 Vision

x402 is an open payment protocol that embeds stablecoin payments directly into HTTP using the 402 status code. The vision is compelling: any HTTP client—including AI agents—can pay for API access with nothing more than a wallet and a standard HTTP request. No accounts, no OAuth, no subscriptions.

ApiCharge shares this vision. We've been building stablecoin-native API monetisation on Stellar since before x402 launched, solving the same problem from a different angle. Now we're bringing x402 compatibility to ApiCharge—not as an afterthought, but because we believe the two approaches are converging toward the same destination.

Where the Architectures Differ

The Facilitator Model

x402 defines three roles: Client, Resource Server, and Facilitator. The facilitator handles payment verification and blockchain settlement so the API seller doesn't have to touch blockchain infrastructure. This is a sensible default for sellers who want to monetise an API without learning crypto.

The x402 spec also allows the resource server to act as its own facilitator. ApiCharge takes this path: the proxy server handles API routing, payment processing, and blockchain settlement in a single service. No external payment processor, no additional point of failure, no third-party dependency.

This is the natural architecture. The alternative—depending on an external facilitator—introduces latency, operational complexity, and a third-party trust relationship for no client-facing benefit. ApiCharge includes lightweight Stellar RPC node integration by default, so API publishers have everything they need to handle their own settlement out of the box.

For the use cases that matter most—high-volume AI agent access, streaming, metered sessions—unifying the server and facilitator roles also enables something critical: the payment layer and the access control layer become one system. ApiCharge controls QoS directly, which means pricing promises made by the server are enforced by the same entity that issued them. Retroactive subscription caps and pricing debacles are avoided because ApiCharge respects previously issued promises signed by the server—the server controls the QoS, and the smart contract holds it accountable.

Client-Side Chain Integration

The x402 exact scheme works differently on each chain. On EVM chains, the client signs an EIP-3009 transferWithAuthorization—a relatively clean client-side operation. On Stellar, the exact scheme requires significantly more from the client:

• Construct a Soroban smart contract invocation
• Simulate the transaction against a Stellar RPC node
• Sign authorisation entries with ledger-relative expiration
• Encode the transaction as base64 XDR

This is appropriate for Stellar-native applications with full SDK integration. But it doesn't serve the x402 audience that matters most: AI agents and lightweight clients that have a keypair and nothing else.

ApiCharge moves all chain complexity to the server. The client receives a hash, signs it with their account key, and sends the signature back. The server handles simulation, transaction construction, and submission. The result: any client with a signing key can purchase API access with zero chain-specific knowledge. Today this means Ed25519 keys for Stellar settlement; the signing mechanism evolves as ApiCharge adds settlement chains.

Payment Granularity

The exact scheme settles a blockchain transaction for every API request. ApiCharge introduces ApiCharge Subscriptions: one blockchain transaction purchases a time-limited, metered access session. All subsequent API calls use an AccessToken with no further blockchain involvement.

1. Client → GET /x402/{pubkey}/api/weather     → 402 + payment terms
2. Client → GET (with PAYMENT-SIGNATURE)        → 200 + AccessToken + response
3. Client → GET /api/weather (with AccessToken)  → 200 (standard request, no blockchain)
4. Client → GET /api/weather (with AccessToken)  → 200 (still no blockchain)
   ...until session expires

This is inherently batched: one on-chain transaction covers an entire session of API calls. It also enables native rate limiting, streaming support, and QoS enforcement at the payment layer—capabilities that require the payment processor and the API gateway to be the same entity.

ApiCharge as an x402 Network

Beyond Chains

x402 uses CAIP-2 identifiers to specify settlement networks: eip155:8453 for Base, solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp for Solana mainnet, stellar:pubnet for Stellar. Today, each identifier maps to a single blockchain. But the protocol's design is more general than that.

A "network" in x402 is where settlement happens. The client doesn't interact with the network directly—it interacts with the facilitator, which interacts with the network. From the client's perspective, the network is an abstraction.

ApiCharge is that abstraction made explicit. Today, ApiCharge settles on Stellar. Tomorrow, it could accept payment via oracle bridges from other chains, or settle across multiple chains depending on the asset and the route. The client doesn't need to know or care. It sees one network—apicharge:mainnet—and signs one payload.

This is where x402's evolution naturally leads. As the protocol matures, the distinction between "which chain" and "which settlement layer" will blur. Metachains, cross-chain bridges, and aggregation layers will emerge as first-class x402 networks. ApiCharge is simply ahead of this curve, recognising that any distributed system is accessed through its network periphery—and building that periphery as a unified abstraction over multiple settlement backends.

The Network Periphery

Every blockchain network is accessed through infrastructure at its edges: RPC nodes, indexers, APIs. These periphery services mediate between clients and the chain. Today, this periphery is invisible in x402—the facilitator connects to RPC nodes behind the scenes, and the client never thinks about it.

ApiCharge makes the periphery a first-class concept. The ApiCharge proxy is the network periphery for its API publishers: it sits at the boundary between clients and blockchain settlement, handling both traffic and payments. When an AI agent connects to an ApiCharge-powered API, it's connecting to the edge of a payment network that happens to settle on Stellar (or wherever settlement makes sense for that transaction).

ApiCharge is not limited to HTTP. The proxy architecture supports multiple protocols and transports—gRPC, Server-Sent Events, and other proxied protocols work natively within an ApiCharge Subscription session. Lower-layer network metering over TCP and UDP direct is on the roadmap. The network periphery concept extends to any transport, not just HTTP.

This reframing—from "chain you settle on" to "network periphery you connect to"—is what enables ApiCharge to offer:

• Chain-agnostic client experience: the client signs with their account key regardless of the settlement chain
• Transport-agnostic access: HTTP, gRPC, SSE, and more—all metered under a single subscription
• Publisher-sovereign infrastructure: each API publisher runs their own periphery node
• Settlement flexibility: the network can route to different chains without changing the client interface

On-Chain Settlement and Trust

Smart Contract as Facilitator

In the standard x402 flow, the facilitator is a trusted off-chain service. It verifies signatures and submits transactions, but the settlement logic lives in the facilitator's code, not on-chain. There is no on-chain record of what was purchased, what terms were agreed, or what access was granted beyond the token transfer itself.

ApiCharge's Soroban smart contract serves as the on-chain facilitator. It doesn't just move money—it validates purchase terms, records the subscription, and creates an auditable trail. Every purchase is a verifiable on-chain event, not just a token transfer.

This enables capabilities that off-chain facilitation cannot provide:

• Neutral arbiter: the smart contract verifies that the server's promises are correct, acting as an independent check on what the server is offering—protecting both the buyer and the seller
• Transparent dispute resolution: purchase terms are recorded on-chain, not in a vendor's database
• Verifiable settlement: anyone can independently confirm that a payment was made and what it purchased
• Future extensibility: as zero-knowledge proof technology matures, purchase validation and access verification can move to cryptographic proofs, enabling privacy-preserving verification without revealing transaction details

Transaction Fees

ApiCharge charges a small transaction fee on subscription purchases, built into the smart contract and visible on-chain. This is a transparent, verifiable fee—not an off-chain platform charge.

The roadmap is to reduce this fee toward zero as the business model evolves toward premium infrastructure services and marketplace revenue. The fee sustains development during the beta period; it is not the long-term monetisation strategy.

Fee Sponsorship

ApiCharge already demonstrates fee sponsorship in production. The public Stellar RPC node offers gasless account activation: new Stellar accounts are created with XLM base reserves and USDC/EURC trustlines, with all network fees sponsored by the server. No fee bump transactions are required—the server simply pays fees as the transaction source account.

This same model extends to subscription purchases. API publishers can choose to sponsor transaction fees for their buyers, lowering the barrier for new users and AI agents.

x402 Compatibility

ApiCharge provides x402 compatibility through two paths.

As an interim measure, ApiCharge offers a custom apicharge scheme that x402-aware clients can use today to discover and purchase ApiCharge Subscriptions via standard x402 headers.

However, for the reasons described above—ApiCharge's role as a metachain abstracting over settlement backends, its unified server-facilitator architecture, and its transport-agnostic design—the appropriate long-term registration is as an x402 network: scheme: "exact" on network: "apicharge:mainnet". This positions ApiCharge alongside other settlement networks in the x402 ecosystem, with its own implementation of the exact scheme that reflects its simplified client flow and server-prepared transactions.

The stellar:exact scheme remains available separately for Stellar-native clients who prefer full SDK integration.

Summary

ApiCharge and x402 are solving the same problem. x402 defines the client-facing protocol—how clients discover and pay for APIs. ApiCharge contributes an architecture for the server side—how settlement, access control, and QoS come together in a single, self-sovereign infrastructure layer. Together, they move the ecosystem toward frictionless, programmable API payments for humans and AI agents alike.

ApiCharge is built on Stellar/Soroban with USDC and EURC stablecoin support. Learn more at apicharge.com.