What is machine-to-machine payment.
Machine-to-machine payment is payment between two non-human endpoints: servers, IoT devices, agents, microservices. Both the payer and the payee are software running without a human reviewing each transaction in real time. The broader category that includes agent-to-agent payments as a subset, plus older patterns like IoT device billing and per-call microservice billing.
The category older than AI agents, newly relevant.
M2M payment is not new. Telecom carriers have settled inter-carrier traffic between machines for decades. Cloud providers bill servers by the second. Ad networks settle micropayments per impression. What changed in 2024-2025 is the shape of the participants: where M2M used to mean "two large infrastructure systems batching periodic settlements," it increasingly means "two small autonomous services paying per call in real time." AI agents are the most visible new participants, but the pattern generalizes.
The infrastructure converging around M2M (stablecoin rails on cheap L2 chains, programmatic payment protocols like x402, per-payer spend policies, signed webhook events) was built primarily for the agent use case, but applies cleanly to non-agent M2M too. The same wallet, API, and middleware that lets your agent pay an MCP server can let your IoT fleet pay its cloud, or your backend service pay a third-party translation API. The label of the payer matters less than the shape of the transaction.
The same primitives, narrower endpoints.
- Identity per payer. Each paying machine has a wallet address (its identity). Wallets are scoped narrowly (one wallet per device or per service) rather than broadly (one corporate wallet for everything) so that compromise is bounded.
- Per-payer spend permission. A per-transaction cap and a per-period allowance enforced at the payment infrastructure layer. Bounds the worst case if the paying machine misbehaves.
- Programmatic payment requests. The payee surfaces payment requirements in a machine-parseable form (x402-style 402 responses, AP2-style mandates, or simple JSON-RPC invoices) that the payer can act on without human translation.
- Settlement and webhook. Settlement happens on the chosen rail (USDC on Base is common for new deployments). Both endpoints receive webhook confirmations that the transaction is final.
- Audit log. Every transaction is logged with the wallet, amount, timestamp, and reason. For compliance-bound deployments, the log is tamper-evident and exportable to SIEM systems.
Three shapes of M2M.
IoT device paying for cloud bandwidth
A connected sensor in the field uploads data to a cloud telemetry service. The cloud service charges per MB. The sensor's embedded wallet pays in USDC on an L2 chain each time it pushes data. The whole loop runs without human involvement; the operator only sees aggregate spend in the monthly dashboard.
Microservice paying a third-party API
A backend service in a SaaS product needs to call a paid translation API for user requests. Instead of a corporate procurement contract with the translation vendor, the service has a wallet that pays per call. The economic granularity is per request; the vendor sees programmatic per-call revenue rather than monthly subscription invoices.
AI agent paying another AI agent (the subset)
An orchestrator agent delegates a sub-task to a specialist agent. Both endpoints are AI agents; the payment is one specific instance of agent-to-agent payment, which is itself a subset of the broader machine-to-machine category. The patterns and primitives are the same; the participants' nature is what distinguishes the sub-categories.