What Machine-to-Machine Payments Actually Require

Why consumer payment assumptions break

Consumer payment systems assume a person: someone who authenticates at the moment of purchase, who can be asked to confirm, who notices a wrong charge, and who can dispute it afterwards. Every layer of that stack, from authentication to chargebacks, is built around that assumption.

A machine breaks all of it at once. There is no one to authenticate at the moment of purchase, because the purchase happens while nobody is watching. There is no one to confirm, because confirmation defeats the automation. There is nobody to notice a wrong charge until reconciliation runs. And the dispute mechanism assumes an account holder who can describe what went wrong.

The economics invert too. Consumer systems are optimized for relatively few, relatively large transactions where a fixed fee plus a percentage is tolerable. Machines generate the opposite: many small payments where a fixed fee larger than the purchase makes the entire model impossible.

So the design question is not how to give a machine a card. It is what a payment system looks like when authorization must be granted in advance, enforced without a human, and bounded so that being wrong is survivable.

The five requirements

Pre-granted, bounded authority. Since nobody approves at the moment of purchase, the machine must carry authority granted earlier, with an explicit ceiling. The bound is the safety property. Without it, a single fault spends everything available.

Per-device scope. Authority granted to a fleet is authority you cannot reason about. Each unit needs its own limits, so a compromised or malfunctioning device costs its float and nothing more, and so you can revoke one without stopping the rest.

Settlement cost far below transaction value. If a payment costs a meaningful fraction of the purchase, high frequency low value commerce does not exist. This is a hard filter on where settlement happens.

Deterministic retry. Machines retry on timeout, and the network is unreliable by nature. A payment must be bindable to a specific request so a retry presents the existing payment rather than making a new one.

Per-machine attribution. When spend looks wrong, you need to know which unit, under what instruction, bought what. An account-level view aggregates exactly the information you need.

Where the money has to live

Every requirement above points at the same unsolved piece: how a machine holds funds it can spend without a person, without a custodian in the path, and without holding authority it could lose catastrophically.

The naive approach is to give the device a key with a balance behind it. That converts any compromise, whether a supply chain problem, a prompt injection into a software agent, or a stolen unit, into a full drain. The bound has to exist below the level of the key.

CryptoCadet is built for this shape. It is a non-custodial USDC payment rail for agents on Base, where an agent operates a bounded spending float authorized by session keys, with custody held in the OS keychain. The ceiling is a property of the session key rather than a rule the software promises to follow, so exceeding it is not a matter of the agent behaving well. It supports x402-style pay-per-call and ERC-20 subscriptions, settling in USDC so that the amount quoted is the amount owed.

Base-only is a deliberate consequence of the requirements rather than a limitation: settlement needs to be fast and cheap enough that small payments are viable, in an asset counterparties already accept.

What to build first

If you are designing for machines that transact, the order that avoids rework is roughly this.

Decide the unit of authority. Usually one bounded float per device or per agent instance, sized to what it should be able to spend before a human looks at it.

Define the failure budget. If this unit is compromised or malfunctions for a full period, what is the maximum loss, and is that acceptable. That number sets the float, not the other way around.

Make payments idempotent from the start. Bind each payment to a request identifier and treat retry as the normal case rather than the exception, because for machines it is.

Instrument attribution before you scale. Which device, which instruction, which purchase, which price. Reconstructing this later across thousands of small payments is not realistic.

Then add the payment protocol. It is the easiest part, and building it first tends to produce a demonstration that cannot be operated.