Why are card fees a problem for agent-to-agent payments?

Agents will pay for API calls, datasets and other services in very small amounts, and a fixed card fee can exceed the purchase itself. That is why stablecoin rails and standards such as x402 are being tested for machine payments. Raw transfer counts on those rails need care, since a large share of the activity is tests and scripts rather than agents buying something.

Fixed fees meet tiny amounts

A card payment carries a fixed component, often a few cents, plus a percentage. For a $40 purchase that is invisible. For a $0.002 API call, a $0.10 dataset or a fraction of a cent per inference, the fixed fee exceeds the price many times over. Machine-to-machine commerce is made of such amounts, repeated millions of times.

What is being tested

• Stablecoin rails with fees in fractions of a cent and instant settlement.
• Standards such as x402, which let a server request payment in the HTTP response and an agent pay inline.
• Prepaid balances and metered billing, which batch many calls into one card charge.

A caution on the numbers

Transfer counts on these rails look impressive, but a large share is test traffic and scripts rather than agents buying something. Operators evaluating the space should look at settled value and real counterparties. For now, the realistic path is batching: agents accumulate usage, and a card or bank payment settles it periodically. Direct per-call payments on new rails come when the standards and the regulation around stablecoins settle.