A Guide to Machine-to-Machine Payments

Machine-to-machine payments, or M2M payments, allow software systems and connected devices to pay one another programmatically. The buyer could be an AI agent purchasing data, an application paying for one API request or an IoT device paying for electricity.

The transaction may be worth dollars, cents or fractions of a cent. It may also happen thousands of times without a person opening a checkout page.

That combination of tiny payment values, high frequency and autonomous execution creates problems for payment systems designed around human buyers.

In 2026, protocols including x402, the Machine Payments Protocol, L402 and Mastercard Agent Pay for Machines are approaching the problem in different ways.

What are machine-to-machine payments?

A machine-to-machine payment is a transaction initiated and completed programmatically between software systems or connected devices. For example: 

• An AI research agent might buy a single web-search result;
• An autonomous vehicle could pay a charging station;
• A software application could buy ten seconds of GPU processing;
• A sensor network could purchase weather data only when conditions require it.

These transactions form part of the emerging machine economy, in which software can discover, purchase and consume digital or physical services with limited human involvement.

Machine-to-machine payments overlap with agentic commerce, which normally refers to an AI agent acting on behalf of a person or business. Machine payments are wider. The payer could simply be deterministic software, an IoT device or an automated service.

A smart meter does not need to “reason” about a purchase for the payment to be machine-to-machine.

Why cards struggle with machine-scale payments

The first problem is economic in nature. 

Consider a payment processor charging a typical US online card price of 2.9% plus $0.30 per successful transaction.

At $100, the $0.30 fixed component is barely noticeable.

At $1, the processing fee is approximately:

$1 × 2.9% + $0.30 = $0.329

That is roughly 32.9% of the transaction value.

At $0.10:

$0.10 × 2.9% + $0.30 = $0.3029

The fee is more than three times the value of the thing being sold.

This is one reason conventional card economics become difficult for direct microtransactions. Stripe’s published US card pricing provides a useful real-world reference at 2.9% plus $0.30 for a domestic card transaction.

Businesses work around this today by accumulating usage and billing later.

That works well for many SaaS products, but it creates an account, credit and reconciliation relationship between seller and buyer. A completely new autonomous agent cannot necessarily create that relationship before requesting a $0.005 service.

Machine payment protocols try to move authorization and payment closer to the resource itself.

The HTTP 402 status code finally has a job

The technical story begins with one of HTTP’s least-used status codes.

Indeed, the official HTTP Semantics specification defines 402 Payment Required but reserves it for future use.

For decades, there was no universal mechanism telling a client:

“This resource costs $0.01. Here are the payment conditions. Pay them and retry.”

That is exactly what newer machine payment systems are now building:

1. A machine makes an HTTP request;
2. The server responds with a 402 Payment Required message containing payment terms;
3. The client satisfies them programmatically;
4. The request is repeated with payment authorization;
5. The server verifies payment and delivers the resource.

This is attractive because payment becomes part of the same request-response environment applications already understand.

There is no pricing page for the machine to read, form to fill in or employee waiting to approve a five-cent invoice.

x402 payments

Coinbase created x402 to turn the HTTP 402 status into an internet-native payment mechanism.

A typical x402 flow looks like this:

 

1. A client requests /api/weather;
2. The server responds with 402 Payment Required;
3. The response specifies the accepted payment options, amount and network;
4. The client chooses an option and creates a cryptographically signed payment payload;
5. The request is retried with a PAYMENT-SIGNATURE header;
6. The payment is verified and settled;
7. The server returns the resource and settlement information.

Verification can occur locally or through an x402 facilitator.

The facilitator can validate the signed payload and execute settlement without taking custody of the buyer’s money. This saves every API operator from having to build its own blockchain verification system.

The protocol is already handling material activity. x402’s current public dashboard reports about 75 million transactions during the previous 30 days, alongside more than $24 million in payment volume.

For developers, the attraction is straightforward: an endpoint itself can become a product.

An API does not necessarily need a user account, credit-card form and monthly plan before the first paid request.

For a deeper technical explanation, see 0xProcessing’s x402 protocol guide.

A live example: search priced at half a cent

Machine payment economics make more sense when the product is real.

You.com currently documents x402 access to its search endpoints at $0.005 per call. Other research requests cost $0.11 or $0.50 depending on the service.

That is a useful example of API monetization that would be awkward as a standalone card purchase.

An autonomous agent researching ten companies could simply pay for ten calls.

There is no need to buy a $20 subscription that it may never use again.

Other live services expose similarly small payments. dTelecom, for example, offers machine-paid speech-to-text priced by the minute and settled through x402.

This is where programmable money changes the billing unit. The merchant can charge for the resource the machine actually consumes rather than bundling tiny units into a human-friendly monthly invoice.

MPP: charges, sessions and subscriptions

The Machine Payments Protocol was launched by Stripe and Tempo on March 18, 2026.

MPP uses the same general idea that a machine-readable service should be able to request payment programmatically, but it supports several distinct payment patterns:

• A charge covers a fixed one-time purchase;
• A session covers measured usage;
• A subscription covers recurring access.

The session mechanism is particularly important.

Imagine an AI agent consuming an LLM stream. Charging and settling for every individual token would be inefficient even on low-cost networks.

An MPP session allows the buyer to authorize spending and increment the cumulative amount as usage grows. The service can therefore meter at very small units without executing an independent settlement transaction for every unit consumed.

Stripe says businesses including Browserbase and Parallel are already using MPP for machine-paid services. Browserbase lets agents buy browser sessions, while Parallel uses machine payments for web access. 

Cloudflare also describes MPP clients as backwards-compatible with x402 services.

This is an important sign for merchants. Protocol fragmentation does not necessarily mean every standard will remain isolated.

L402 and the Lightning Network

L402 approaches the same problem using Bitcoin’s Lightning Network.

An L402 credential combines a Macaroon, which acts as a restricted authorization credential, with proof that a Lightning invoice was paid.

A service sends the user an invoice and partial credential. Paying the invoice reveals the payment preimage. The client then presents the Macaroon plus that preimage as proof of payment.

Lightning Labs describes L402 as a mechanism for metered APIs without requiring logins, email addresses or passwords.

L402 therefore shares several goals with x402, especially around pay-per-call services and machine-readable access.

The difference lies primarily in its payment mechanism and ecosystem. L402 is closely tied to Bitcoin and Lightning, while x402 has expanded across stablecoin settlement mechanisms and multiple networks.

Mastercard Agent Pay for Machines

In June 2026 Mastercard launched Agent Pay for Machines, or AP4M.

The service is intended to support high-frequency machine transactions using the controls and credentials of Mastercard’s network while allowing settlement preferences that can include fiat or stablecoins.

Mastercard announced more than 30 early participants and supporters, including Adyen, Ant International, Coinbase, Stripe, Tempo, Cloudflare, Checkout.com and Global Payments. 

Its approach includes several functions that will be familiar from other agent-payment systems:

• Machine identity and discovery;
• Permissioning;
• Spending limits;
• Verifiable credentials;
• Cryptographic verification;
• Machine-speed execution.

AP4M demonstrates that machine-to-machine commerce is developing across both blockchain-native systems and existing payment networks.

Comparing the main machine payment protocols

Machine payments in IoT

AI has pushed machine payments into the spotlight, but IoT payments may eventually generate equally interesting applications.

Consider an electric vehicle negotiating with a charging point.

The vehicle can identify the charger, verify its tariff, authorize a maximum spend and pay for the electricity consumed.

Or consider a sensor that normally uses free public data but buys a high-accuracy reading for $0.02 when a threshold is crossed.

The economic requirement is similar in both cases.

The machine needs an identity, payment authority and spending guardrail. It needs machine-readable pricing. The seller needs reliable settlement and a record of what happened.

The user does not need to approve every individual transaction, which is where governance becomes especially important. 

What happens when a machine goes wrong?

Imagine a legitimate device is authorised to spend up to $5 per day on data.

A software bug causes it to call the same $0.01 endpoint 100 times per second.

Without controls, that would mean $60 per minute and $86,400 in a day.

The payment mechanism may be functioning perfectly, but the machine itself is malfunctioning.

A compromised agent can create the same problem intentionally, which is why businesses need controls outside the payment itself.

An effective machine wallet should have limits by transaction, session and time period. Merchants should also use rate limits, duplicate-request protection, allowlists, anomaly detection and emergency credential revocation.

For higher-value applications, separate machine identity from access to the underlying treasury. The software should receive narrowly scoped spending authority rather than unrestricted control of the wallet holding the organisation’s funds.

A useful principle is to assume that a machine will eventually loop. That is why it is key to design the maximum possible financial loss before it happens.

Can machine payments be reversed?

A card-funded machine payment may still sit inside card-network dispute and refund rules.

However, an on-chain stablecoin transaction behaves differently. Once confirmed, it generally cannot be reversed by the sender through a conventional chargeback.

The merchant can issue a refund as a separate transaction, but that is different from reversing settlement.

This has advantages for sellers of instantly consumed digital resources. A buyer cannot ordinarily consume an API response and later initiate the same type of chargeback used for a card transaction.

It also increases the importance of spending controls on the buyer side.

If a compromised AI agent wallet sends 10,000 valid stablecoin payments, blockchain finality does not determine whether those purchases were sensible.

Stablecoins versus cards for the machine economy

Cards remain excellent for human commerce because they combine acceptance, consumer protection, credit and an enormous global network.

Machine payments optimise for somewhat different requirements.

They may need:

• Values below one cent;
• Instant machine-readable authorization;
• 24/7 settlement;
• Thousands of transactions;
• Wallets controlled programmatically;
• Per-request billing;
• Cross-border access without opening a billing account first.

Stablecoins fit many of these characteristics well.

That explains their prominent role in x402 and other machine payment systems.

MPP and Mastercard demonstrate another possible direction: hide the differences between the underlying payment methods behind a common machine interface.

If that approach succeeds, an autonomous agent may eventually care less whether the final settlement uses a card network, bank account or stablecoin.

It will simply select an acceptable payment option according to cost, authorization rules and service requirements.

Should your business build for M2M payments now?

For most mid-market companies, the decision can be made with four questions.

Do machines consume your product directly?

If you sell API access, data, compute, search, inference, storage or another digitally delivered service, machine payments deserve attention now.

If you sell furniture to ordinary consumers, they are less urgent.

Is the natural billing unit small?

The smaller the unit, the stronger the case for machine-native payment. A $500 annual SaaS contract works perfectly well with conventional billing. A $0.002 data query does not.

Can the service be delivered automatically?

A machine payment works best when successful payment can trigger immediate delivery without human review.

Can you control financial risk?

Before giving an autonomous system access to funds, define spending limits, wallet permissions, rate limits, retry rules and incident procedures.

A small pilot on one paid endpoint is generally more useful than rebuilding the entire billing system around a protocol that is still changing.

Where 0xProcessing fits into machine payments

Machine payment protocols sit above many functions a crypto merchant already needs, including wallet connectivity, transaction monitoring, callbacks and reconciliation.

0xProcessing provides these capabilities through its API and webhooks, alongside Web3 wallet payments and automatic conversion of supported incoming assets into USDT through VRCS. Its AI payment processor page also describes spending limits, whitelisted addresses and transaction caps.

Protocol support is a separate issue. x402 and MPP require their own payment challenges, credentials and settlement flows, and 0xProcessing’s public documentation does not currently establish native support for x402, MPP, L402 or AP4M.

Instead, 0xProcessing can provide the underlying crypto payment infrastructure while businesses add protocol-specific integrations where needed. Its crypto payment API guide provides more detail on this setup.

 

FAQ