Key Takeaways

• Machine-to-machine payments are transactions in which software, devices, or autonomous systems programmatically pay for resources, without a human authorizing the individual purchase.
• The machine economy is a commercial ecosystem where software, APIs, and connected devices act as buyers and sellers, paying each other directly.
• Micropayments are financial exchanges involving tiny amounts of money that usually occur online.
• Machine payment infrastructure combines machine identity, programmable spending rules, machine-readable pricing, and settlement cheap enough for constant fractional-cent transfers. Several designs compete for that role, including off-chain payment channel networks such as the Fiber Network.

A printer notices that its ink is running low and orders a replacement. An AI travel assistant needs one flight-data query before completing an itinerary. An electric vehicle connects to a charger, reads the current electricity price, and begins paying as it consumes energy.

None of these actions necessarily requires a person to stop what they are doing, open a checkout page, enter a card number, and approve the transaction.

The machine can do it.

Software has been making decisions automatically for decades. What is changing is its ability to act economically on those decisions.

With the recent advances in AI, an agent or a machine may know what resource it needs, where to find it, and whether the price fits within its programmed budget. But traditional commerce still assumes that somewhere in the process a human will create an account, agree to billing terms, enter payment credentials, or approve a purchase.

That works when purchases are occasional and predictable, but becomes impractical when software needs to buy resources autonomously, at machine speed, potentially thousands of times a day.

This is the problem machine-to-machine payments are designed to solve.

Instead of requiring a human to authorize every purchase, the human defines the rules in advance: what the machine may buy, how much it may spend, and under what conditions. The machine can then discover a resource, read its price, determine whether the purchase is permitted, pay for it, and continue its task automatically.

At sufficient scale, this creates something larger than automated payments: a machine economy, where software, AI agents, servers, vehicles, sensors, and other connected systems can buy and sell resources directly.

The challenge is building payment infrastructure that operates at the same speed and granularity as the machines themselves.

The concept of machine-to-machine (M2M) communication predates the current AI wave. Initially, it described the communication between devices using wired or wireless communications channels.

However, in the context of the digital economy and AI, this concept has evolved significantly. A "machine" can be a server, software service, API client, IoT sensor, industrial controller, vehicle, robot, or AI agent. As these systems become more advanced, they no longer just exchange data; they consume digital and physical resources. What unites them today is the need to acquire these resources autonomously, without waiting for human approval.

Machine-to-machine payments are transactions where software, devices, or autonomous systems programmatically pay for goods, services, data, compute, or other resources without human involvement. The human remains accountable, setting the overarching budgets and policies, but is not in the transaction loop at the moment of purchase.

While machine-to-machine payments can use different protocols and settlement rails, the basic flow is usually similar:

1. Request a resource: An AI agent, application, or connected device requests something it needs, such as an API response, data feed, compute job, or charging session.
2. Receive payment terms: The provider responds with machine-readable instructions describing the price, accepted payment method, and where payment should be sent.
3. Authorize the purchase: The client checks those terms against its programmed spending rules—such as its budget, permitted services, or maximum price.
4. Pay: If the purchase is allowed, the client authorizes or signs the payment and sends the required payment information or proof.
5. Verify and deliver: The provider verifies that payment has been made or authorized, then delivers the requested resource.
6. Settle: The underlying payment network transfers or settles the value according to its own rules.

No checkout page or manual approval is required at the moment of purchase. Once the spending rules are in place, software can request, authorize, pay for, and consume a resource entirely through code.

The machine economy is a commercial ecosystem where machines are the buyers and sellers. They produce resources, consume them from each other, and pay for what they consume. Machine-to-machine payments are the mechanism that makes this system possible.

In this ecosystem, machines act as economic participants rather than just tools, because they can independently execute payments. For instance, a machine can produce a certain resource (e.g., generating solar power), while another machine consumes it (charging). On top of that, they can pay each other directly for these exchanges. This creates an interconnected web where hardware devices, software, and autonomous AI agents interact at a scale and speed impossible for humans to manage.

To illustrate how autonomous payments operate across different scenarios, here are some examples ranging from simple token triggers to complex autonomous multi-party ledgers:

• Trigger-based micro-payment (Smart EV Charging): An electric car plugs into a charging station. The car talks to the charger, confirms an account balance via an API, and pays per kilowatt-hour as it charges.
• Conditional smart contract payments (Compute): An AI agent rents GPU capacity for a task and locks payment upfront. Once the compute provider completes the job and returns the agreed proof or signed completion record, the payment is released; if the job is not completed, the funds can be refunded after a timeout.
• Fully autonomous multi-device ecosystem (AI Agent Supply Chains): Autonomous software agents manage a factory. One AI buys raw materials from another factory's AI, negotiates price based on real-time stock, and settles the funds instantly in crypto assets.

For autonomous commerce to work at scale, software and devices need more than a way to move money. They need a machine-native commerce stack that can handle identity, authorization, pricing, payment, and settlement without requiring a person at every step.

Identity and authentication: Software, AI agents, and connected devices need a reliable way to prove who or what they are, authenticate requests, and establish which person or organization has authorized them to act.

Programmable spending rules: An AI agent should not have unrestricted access to a crypto wallet or bank account. Its authority needs to be bounded by rules defining how much it can spend, what it can buy, which counterparties it can pay, and when those permissions expire.

Machine-readable pricing: Prices and payment terms need to be expressed as structured data that software can interpret automatically, rather than buried on a pricing page or presented through a checkout screen.

Programmatic payment protocols: Once a purchase is approved, the client needs a standardized way to authorize payment, submit proof, and receive the requested resource entirely through code.

Low-cost settlement: If services are priced per API call, inference, megabyte, second of compute, or other small unit, fixed transaction fees cannot exceed the value being exchanged.

Low latency: Payment authorization and verification need to happen quickly enough that the payment step does not become a bottleneck in the underlying service.

Interoperability: Common standards are needed so AI agents, APIs, wallets, payment networks, and service providers can communicate without requiring a custom integration for every counterparty.

Together, these components allow software to move through the entire commercial process (identify, evaluate, authorize, pay, and consume) without leaving the programmatic environment in which it operates.

Traditional payment systems can automate transactions, but they were not designed for software making huge numbers of tiny, independent purchases.

Consider card payments. Stripe’s standard US pricing currently charges 2.9% + $0.30 per successful domestic card transaction. On a $50 purchase, the fixed 30-cent component is relatively small. On a $0.002 API call, it is larger than the payment itself by orders of magnitude.

That creates a fundamental mismatch.

Traditional payment infrastructure generally works best when many small units of consumption are aggregated into larger charges: a monthly cloud bill, an annual software subscription, or a prepaid balance.

Autonomous software can create the opposite demand. An AI agent might want to purchase one API response, a few seconds of compute, or a single inference from a provider it has never used before—and then move on to another service seconds later.

For that model to work efficiently, the payment layer needs to support small, frequent, programmatically authorized transactions without imposing a meaningful fixed cost on every purchase.

Traditional rails can support machine commerce through accounts, subscriptions, stored credentials, and aggregated billing. What they struggle to support economically is the more granular model: paying independently for each tiny unit of consumption as it occurs.

Software consumes resources differently from humans.

A person might buy a monthly software subscription. An AI agent may instead need one API call from one provider, a few seconds of compute from another, and a single model inference from a third—all within the same task.

That means consumption can be extremely granular: per request, per inference, per megabyte, per second of compute, or per kilowatt-hour.

Ideally, payments should be just as granular.

If every tiny unit of consumption can be paid for economically, providers no longer have to bundle usage into subscriptions, prepaid credits, or monthly invoices simply to make the payment economics work.

An AI agent could pay exactly for what it consumes, when it consumes it.

That is why micropayments matter to the machine economy. They make it possible to turn individual units of digital or physical consumption into individual economic transactions—as long as the payment infrastructure can keep the cost of each transaction below the value being exchanged.

Data, inference, storage, and compute, most resources a machine would buy, are already exposed as web APIs. The web runs on HTTP (Hypertext Transfer Protocol), the request-and-response protocol a client uses to ask a server for a resource and receive it with a status code describing the outcome.

When the early architects of the web built HTTP in the 1990s, they explicitly reserved a status code for native digital purchases: 402 Payment Required. If an API server requires payment, it can intercept a client's request and return an HTTP 402 status code, a native client error response indicating the content cannot be served until payment is made.

At the time, the 402 status code was shelved because internet-native money did not exist, until it was revived in May 2025 when Coinbase introduced the x402 protocol.

The x402 protocol is an open payment standard that repurposes the HTTP 402 status code to provide a stateless mechanism for machine-to-machine commerce. Instead of routing a user to a visual checkout page, the server returns a 402 code with machine-readable payment terms as structured data, including the price and the target crypto wallet address. The client checks and verifies these terms, generates a cryptographic payment proof, and retries the original HTTP request—this time carrying the payment proof in its header. The server verifies the proof and instantly returns the requested resource.

The x402 protocol is chain-agnostic as well. Its primary use cases include machine-to-machine payments, pay-per-use APIs, and micropayments without account creation.

The l402 protocol takes the same status code into the Lightning Network. The server answers a gated request with a 402 code and a header carrying an authentication token known as a macaroon, plus a Lightning invoice, with the token committing to that invoice by containing its payment hash. The client pays, obtaining the preimage as proof, then presents the token and preimage together to access the endpoint. Because the token's cryptographic validity already implies payment, the provider can verify access without querying a payments database.

Machine-to-machine payments do not inherently require blockchain or cryptocurrency. Traditional payment systems can already support automated billing, stored credentials, and API-driven payments.

But blockchains become particularly useful when software needs to transact globally, continuously, programmatically, and at very small values—especially when the buyer and seller have no prior relationship or shared payment provider.

They offer several useful properties for autonomous commerce:

Programmable authorization: Software can control cryptographic keys and sign transactions directly, allowing payments to be authorized entirely through code within predefined spending rules.

24/7 availability: Public blockchains operate continuously, without banking hours, settlement windows, or dependence on a particular national payment network.

Global reach: An AI agent can pay a service on the other side of the planet in seconds, without relying on a shared bank, card network, or permissioned payment platform to connect them.

Programmable assets: Stablecoins allow software to transact with digital dollars while retaining the programmability and global accessibility of blockchain-based payments.

But using a blockchain directly introduces its own problem.

If every API call, inference, or tiny unit of compute becomes a separate on-chain transaction, the system once again runs into transaction fees, limited blockspace, and confirmation delays. For a payment worth a fraction of a cent, the network fee can easily cost more than the service itself.

So blockchain solves only part of the machine-payment problem.

For high-frequency machine commerce, the challenge is to combine the programmability and open settlement of blockchains with a payment layer capable of moving tiny amounts quickly and cheaply without recording every individual transaction on-chain.

This is where off-chain payment networks become relevant.

Instead of recording every payment on a blockchain, a payment channel lets two participants commit funds on-chain once and then exchange signed balance updates directly. A payment channel network connects those channels, allowing payments to be routed between participants that do not share a direct connection.

The result is a payment layer designed for exactly the kind of activity machine commerce can generate: small, frequent, low-latency transactions without a separate blockchain fee for every payment.

Fiber Network is an open, peer-to-peer payment and swap network built on CKB. It uses CKB as the settlement and enforcement layer while moving repeated payments through off-chain channels.

Several properties make this architecture particularly relevant to machine-to-machine payments:

Micropayment economics: Fiber routing fees are proportional to the amount being forwarded, with no fixed base routing fee. That matters for fractional-cent payments because the fee does not automatically overwhelm the payment simply because the transaction is small.

Low latency: Individual payments are processed between the peers involved in the route rather than waiting for a new CKB block. An AI agent paying for an API call or inference therefore does not need to wait for base-layer confirmation before the service can continue.

Multi-asset payments: Fiber supports channels funded with CKB or supported CKB assets such as User-Defined Tokens (UDTs), including stablecoins. Across the network, this allows different assets to serve as payment liquidity rather than forcing every transaction into a single native currency.

Payments and swaps: Fiber is designed not only to route payments but also to exchange assets when suitable liquidity exists. This creates the possibility for a payer to hold one asset while the recipient ultimately receives another, with conversion becoming part of the payment flow.

Open routing: Machines do not need a direct payment channel with every service they use. Fiber can route a payment across existing channels through intermediate nodes, provided a viable path with sufficient liquidity exists.

For machine commerce, that combination is important. The web layer can tell software what to pay and how to authorize the purchase; Fiber can provide the underlying rail for moving the value quickly and economically.

A small experimental project called fiber-pay shows what this stack can look like in practice.

The project turns a locally hosted AI agent into a paid service. The operator sets a price per request and exposes the agent through an HTTP endpoint protected by an L402-style payment gate.

The flow works like this:

1. A client sends a prompt to the AI service.
2. Because no payment is attached, the server responds with HTTP 402 Payment Required, along with a Fiber invoice and payment token.
3. The client pays the invoice over Fiber.
4. It retries the original request with proof of payment attached.
5. The server verifies the payment and runs the AI model.

From the user’s perspective, the result is simple: pay for one AI request, receive one AI response.

The important part is what happens underneath. Pricing is exposed programmatically, payment happens off-chain, proof is passed back through the web request, and the service is delivered only after payment is verified.

fiber-pay is still an early experiment rather than production infrastructure, but it demonstrates the basic machine-payment loop end to end: request, price, pay, verify, deliver.

It is a small example of what machine-native commerce could look like when web protocols and low-cost payment rails are combined.

Machine-to-machine payments are about more than automating checkout. They allow software, AI agents, and connected devices to discover resources, evaluate prices, authorize purchases, and pay for what they consume without requiring a human to approve every transaction.

That becomes especially valuable when consumption is granular and frequent: one API call, one inference, a few seconds of compute, or a small amount of energy.

Building that economy requires several layers to work together. Machine-readable protocols can communicate prices and payment requirements, programmable authorization can define what software is allowed to spend, and low-cost payment networks can move value without making every tiny transaction prohibitively expensive.

The result is a new model for digital commerce: humans define the rules and budgets, while software can transact autonomously within them.

Machine-to-machine payments are transactions in which software, AI agents, connected devices, or autonomous systems programmatically pay for resources without a human approving each individual purchase.

A client requests a resource, receives machine-readable payment terms, checks them against its spending rules, pays, and then receives the service. The entire interaction can happen programmatically without a checkout page.

No. IoT payments are one subset of M2M payments involving connected physical devices, while M2M also includes software services, APIs, servers, and AI agents.

AI agent payments are a subset of machine-to-machine payments involving autonomous AI software. M2M is the broader category covering everything from simple scripts and servers to vehicles, sensors, and AI agents.

AI agents can consume resources in very small units—such as individual API calls, model inferences, or seconds of compute. Micropayments allow payment to match that consumption without bundling everything into subscriptions or larger invoices.

No. Traditional payment systems can support automated payments, but blockchains are useful when payments need to be global, programmable, continuously available, and capable of moving very small amounts between parties without a shared payment provider.

x402 is an open payment protocol built around HTTP 402 Payment Required that lets a server return machine-readable payment terms and a client automatically pay before retrying the request with proof of payment.

L402 is a payment and authentication protocol that combines HTTP 402 with Lightning payments, allowing clients to pay an invoice and use the resulting cryptographic proof to access a protected resource.

Payment channels allow large numbers of payments to happen off-chain without requiring a new blockchain transaction for each one. This makes them particularly suitable for high-frequency, low-value, latency-sensitive payments.

Fiber Network is a peer-to-peer payment and swap network built on CKB that uses payment channels for low-latency, multi-asset payments. It is designed to support use cases such as micropayments and machine-to-machine commerce.