The Next Customer Has No Card

How x402 turns a web request into a purchase, and where Qubic fits.

AI agents become customers

AI agents can write code, search databases and coordinate complex tasks. Buying access to the next resource still often depends on arrangements a human made beforehand.

The commercial web was built around people. Create an account. Choose a plan. Enter a card. Confirm the purchase.

An agent may need something much smaller. One API response. One dataset. One minute of compute.

The opportunity begins there: software purchasing precisely what a task requires, within an authorised budget, then continuing its work.

That changes the agent’s role. It becomes a customer.

Buying the next step

Imagine a research agent preparing an industry report. It needs a current market quote, a specialised dataset, a translation and a short computation. Four suppliers. Four useful outputs. Perhaps no reason to buy from any of them again.

A subscription is not always the right unit for that exchange. Neither is a long registration process for a single answer.

With payment at the point of use, an API can charge per call. A publisher can sell access to one article. A data provider can sell one premium lookup. A compute service can price a bounded job.

The same pattern could connect agents. A planning agent purchases a specialist analysis. A coding agent buys a security scan. A monitoring agent pays for a fresh measurement from another system.

These are potential business models, not evidence that an autonomous economy already operates at scale. Their shared requirement is practical: a buyer needs a consistent way to discover the terms, pay and receive the service.

For sellers, that could make occasional demand commercially useful. A customer who would never subscribe might still buy one valuable result. For operators, costs could be attached to individual tasks instead of scattered across unused plans.

Why checkout creates friction

Software can already use cards, accounts and provisioned payment tools. The problem is not an absolute inability to complete a form.

It is the work surrounding each new supplier. Registration. Credentials. Billing terms. Minimum commitments. Reconciliation. Cancellation.

An operator can arrange all of this for a small set of services. Doing it repeatedly across changing suppliers makes delegation harder.

An agent needs a commercial interface it can read: the resource, the price, the recipient and the evidence required to unlock access. A common format reduces the custom integration needed for each purchase.

Subscriptions will remain useful for predictable demand. Payment per request offers another option when demand is irregular, small or discovered during a task.

The important change is flexibility. Software can evaluate a purchase when it becomes relevant, rather than relying entirely on access arranged in advance.

Spending still needs authority

An agent’s wallet is not permission to spend without limits. Its operator must define budgets, acceptable suppliers and permitted purchases.

Consider a research task with a fixed spending allowance. The agent could compare a paid source with a free alternative, buy only when the extra information justifies the cost, and stop when it reaches its limit.

That requires more than a payment protocol. It needs purchase policies, receipts and recovery when a supplier fails. It also needs a distinction between paying successfully and receiving something useful.

A valid receipt does not establish that a dataset is accurate or an analysis is good.

The goal is accountable delegation: software handles routine purchases while people retain control over what it is authorised to buy.

x402 puts payment inside the request

HTTP already contains 402 Payment Required. The code has existed for decades, but the HTTP specification still reserves it for future use. x402 gives it a practical payment workflow. [1][2]

The exchange is straightforward:

• A client requests a resource.

• The server returns 402 with payment requirements.

• The client prepares or makes an authorised payment.

• It retries with payment evidence.

• After the required verification and settlement, the server returns the resource, normally with HTTP 200.

The mechanics vary. Some implementations accept a signed payment authorisation for subsequent settlement. Others accept evidence of a transaction already broadcast. A facilitator can handle the blockchain-specific verification and settlement work. The seller’s application controls access. [2]

A standard taking shape

Coinbase introduced x402 in 2025. The Linux Foundation announced the foundation initiative in April 2026, followed by its operational launch in July with 40 member organisations. Members include Coinbase, Cloudflare, Google, AWS and major payment companies. Participation in the standard does not imply endorsement of every implementation. [2][3]

The infrastructure is already multichain. Coinbase has documented facilitator support for Base, Solana and Polygon, among other evolving integrations. Qubic is joining a competitive field, rather than creating machine payments from scratch. [4]

Activity is measurable, but interpretation matters. Chainalysis reported more than 100 million cumulative x402 transactions on Base through the first quarter of 2026. Its analysis also found that memecoin activity drove much of the growth. Those transactions cannot simply be counted as independent AI agents purchasing useful services. In its June 2026 analysis, transfers of at least $1 accounted for 95% of transferred value by early 2026. Weekly wallet retention was trending upward, although it remained volatile. [5]

The stronger adoption measures will be repeat buyers, useful purchases and revenue that persists after experimentation.

One payment or a prepaid balance

The simplest approach associates each request with its own payment. It is easy to explain and audit, but repeats settlement overhead.

For frequent calls, a buyer can instead fund a balance and authorise subsequent purchases with signed vouchers. Each request can avoid waiting for a new blockchain transaction. Signing happens locally; verification and accounting still take time.

Prepaid designs differ in where funds sit, when settlement happens and how refunds work. They are implementation choices, not universal guarantees of x402. Q+Pay’s documented model, for example, uses credit already paid to the seller. [6]

The right model depends on purchase frequency, cost and how much trust the buyer accepts.

Where Qubic fits

Qubic offers feeless native QU transfers and a tick-based execution model. These are relevant foundations for small payments. They do not make every application free: contract execution has its own fee-reserve mechanism, and payment services charge separately. [7][8]

Nor does a fast tick mean an equally fast purchase. A transaction targets a future tick. Inclusion, verification and delivery contribute to the total waiting time. End-to-end latency must be measured at the application level.

Q+Pay’s payment path

According to its documentation, Q+Pay implements x402 on Qubic mainnet. The QPAY contract deducts its fee and forwards the seller’s proceeds within the payment transaction. The facilitator does not retain the funds. [6]

Its published charge is 0.75%, with a minimum of 100 QU. As a hypothetical pricing example, a 1,000 QU purchase would incur a 10% effective fee because the minimum applies. Native transfers stay feeless; the payment service has its own pricing, which matters when setting a price per call. [6]

The seller issues a pt1 ticket authenticated with HMAC-SHA256. It binds the seller, resource, amount, nonce and validity period. The buyer presents the ticket with the transaction hash.

The nonce links the payment to the ticket. It is included in transaction data, so it should not be described as permanently secret. An observer cannot reconstruct a valid authenticated ticket from the nonce alone without the signing key. Separately, settlement rejects payments already used. Both authentication and single-use enforcement matter. [6]

A payment we can show

PrimeQubic tested the complete flow with a dedicated demonstration endpoint and test wallets. A local Node.js client requested the resource, received a 402 with a signed ticket, and paid through the QPAY contract on Qubic mainnet.

The result was concrete: 20,000 QU paid, a 150 QU fee, and 19,850 QU forwarded to the seller. The facilitator returned success: true. The endpoint answered HTTP 200, and the client received the requested network snapshot. [9]

Public transaction hash:

peykbzrtnqmymdbbuirbsozoznibbfzenulxqzkjhdhpczrqojcklfhdkxia

The Q+Pay team separately reported checking the transaction on-chain and in the facilitator’s records. They confirmed the contract payment at tick 82,180,797, the fee split and settlement recorded once. The receipt’s transaction field is a contract receipt key, distinct from the public hash above. [9]

Two initial retries returned invalid_transaction_state. The same proof was then accepted, and the client received data reporting tick 82,180,815. This illustrates why clients need retry handling while payment evidence becomes available.

The client asked for human confirmation before broadcasting. The demonstration establishes payment and delivery from end to end. Autonomous purchase decisions remain a separate capability.

What comes next

Q+Pay also documents prepaid channels using SchnorrQ signatures over a KangarooTwelve digest and cumulative spending checks. Fees apply to the deposit rather than each voucher. Funds go to the seller upfront, creating exposure to undelivered service or unused credit. We did not test this mechanism in the integration described above. [6]

Seller tooling is still young, and the specification is already detailed enough to build on. Qubic must also attract services worth purchasing and buyers equipped to spend QU. Native-token pricing brings exchange-rate exposure, while other networks already offer stablecoin payment infrastructure.

If agents become customers, successful payment systems will make purchasing unobtrusive while keeping authorisation and settlement verifiable.

Can Qubic earn a place in that economy? Working integrations make the question concrete. Useful services, returning buyers and reliable delivery will determine the answer.

Sources

• IETF: HTTP Semantics, 402 Payment Required.

• Coinbase: Introducing x402.

• Linux Foundation: April announcement and July operational launch.

• Coinbase: Facilitator support for Polygon, Base and Solana.

• Chainalysis: Inside x402’s Path to Meaningful Adoption, June 3, 2026.

• Q+Pay: x402 specification, tickets, settlement, pricing and prepaid channels. Retrieved September 29, 2026. The nonce explanation follows the documented transaction layout.

• Qubic: Tokenomics and feeless transfers.

• Qubic: Smart contract execution and fee reserves.

• PrimeQubic demonstration: client output dated September 29, 2026, showing HTTP 200, the settlement receipt and returned data. Q+Pay verification: written confirmation supplied by the Q+Pay team and reviewed for this article. This private confirmation is attributed, not presented as a publicly accessible source. The public transaction hash is reproduced above; blockchain evidence alone does not prove HTTP delivery.

Primequbic

Proof, not promises.