Chapter 35 · Will Machine Payments Become an Internet Protocol?

A Real-World Problem

Your software requests an interface. The response is 402, Payment Required.

Then it stops.

Other codes have known responses: 404, find elsewhere; 401, supply credentials; 403, stop; 429, wait and retry.

They work because everyone agrees on the next action. Software follows rules without interpreting meaning.

402 is the exception, reserved for decades but without a standard answer to:

How much?
To whom?
Using what?
How do I prove payment?
Can I recover it if service is not delivered?

Humans use pages, prices, cards, and forms. Software cannot, because none of those steps is standardized.

The internet bypassed this through advertising, third-party funding, and accounts, prepaid relationships with later deductions.

Both assume a human payer and continuing relationship.

Software may need an interface only once. Ads have no meaning; registering for a few cents costs more effort than the transaction.

This chapter asks how machines pay for one API call.

We cover the problem and usual approaches, not specification fields, versions, or signatures, which change rapidly. Consult current primary documentation using Keeping Up with Crypto.

Thought Experiment

Software makes ten thousand calls daily, each worth fractions of a cent, totaling roughly a dozen currency units.

It has no previous relationship with the provider and may use it only today.

Four pricing models follow.

Subscription: unlimited usage for a monthly fee.

Potentially cheap, but requires predicting continuing use. One day's use pays for twenty-nine unused days.

Registration establishes a relationship, requiring credentials, payment, and terms. Dynamic selection across hundreds of interfaces needs human intervention.

Prepaid: deposit, meter requests, refill.

Chapter 33 explained this effective mainstream method, batching tiny uses into one real payment.

Providers times agents means many accounts, and prior registration prevents immediate use after 402.

On-chain payment for every call.

No registration or previous relationship; the payer is an address.

But network fees on every transfer may exceed the service cost across ten thousand calls.

This repeats the card mismatch: large-infrequent settlement applied to small-frequent consumption.

Establish credit, meter lightly, settle periodically.

The viable structure combines one setup, ongoing metering, periodic settlement.

Setup can be permissionless funding or authorization rather than provider-approved registration.

Compare:

The first two are reality; the fourth is a direction, whose standardization we assess.

Metering and settlement are separate:

Metering records usage; settlement moves money.

Micropayment difficulty lies in metering. Separate them and choose any economical settlement rail.

Your Decision

You operate an interface service for software. How do you charge?

What Happens

Six questions require standardized answers:

HTTP standardized information flows, but not money.

402's reservation was deliberate. Suitable internet money was absent: cross-border, tiny, relationship-free, and machine-operable.

Banks and payment networks had separate interfaces, account rules, and coverage. A protocol could require payment but could not specify a universal way to pay.

Chapter 13 described internet-native money, held without accounts and settled publicly, creating a possibility.

The core claim:

HTTP carries information; machine economics also needs a protocol carrying money.

The missing layer awaited suitable money, not interest in building it.

Possibility does not ensure adoption.

Build a Model

1. Three Independently Evolving Layers

Separate independently evolving layers:

Metering is genuinely hard for nontechnical reasons.

A provider reports 10,312 calls. How do you verify? Independent logs may disagree; existing arrangements let the prepaid provider decide.

Contracts and reputation support this for companies. Stranger software-provider pairs lack that foundation.

Per-call payment eliminates later reconciliation, but costs too much.

Coarser payments reduce cost and increase required trust.

2. Four Models by Required Trust

Moving down reduces friction and increases trust.

Check whether required trust matches the relationship. A stranger-oriented system demanding large prepayment has not solved its claimed problem.

Small batches fit machines best, limiting counterparty loss while settling often enough to keep exposure small.

3. Three Costs Determine Granularity

Payments impose:

Network:     Transfer fees
Time:        Waiting for confirmation
Complexity:  Steps and state both parties maintain

Balance these against trust:

Do not pay at a granularity where all three costs exceed an acceptable fraction of the transaction.

Fractions-of-cent services are smaller than nearly any chain operation. Avoid per-call settlement even as chains cheapen, since service prices decline too.

4. Standards Win Through Adoption, Not Technical Quality

This determines the chapter's central answer.

HTTP did not win solely by technical superiority. Standards need conditions:

The second and fourth are nontechnical barriers.

Two-sided adoption means recipients wait for payers and vice versa, as in Chapter 30.

The incumbent works well. Replacement needs order-of-magnitude improvement or previously impossible capability.

Watch:

1. Real accepting services, especially supply
2. Why they accept: new customers or lower costs?
3. Uses impossible without it

The third is strongest, such as tiny payments to strangers in Chapter 33.

5. Likely Form

A plausible outcome:

An optional convention over HTTP, alongside accounts and subscriptions, rather than universal replacement.

Settlement rails remain replaceable. Stablecoins fit internet-native, account-free, programmable requirements, but should not lock the protocol to one rail.

Metering standardizes first in narrow valuable scenarios, especially previously uncollectible payments.

Least likely is universal adoption simply because the architecture is excellent.

What It Is Called

In one sentence:

HTTP carries information; machine economics also needs a protocol carrying money.

Metering is the technical challenge; supply adoption is the market challenge. Count accepting services, not specifications.

Hands-on

Service:
Billing: per call / usage / subscription / hybrid
Price:
Minimum deposit:
Monthly minimum or fee:
Free allowance:
Overage: tiers / higher prices / throttling

Sticker cost:
Amortized minimum or monthly fee:
Unused prepaid balance:
Integration time, valued approximately:

Real cost per call = Sum of four costs ÷ Call count

Below ___ daily calls, per-call is cheaper
Above ___, subscription is cheaper
Crossover: ___

Cards?
Prepaid?
Any on-chain method?
Opening requirements: email / company / identity
Can software complete opening alone?

Caller category and scenario:
Usage:
Exclusion reason: expensive / no account / one use
Potential per-call market:
Why the provider has not addressed it:

Additional engineering, accounting, compliance costs:
Additional revenue:
Main concern:
Conditions guaranteeing adoption:

AI Lab

Compare current approaches to payments between machines.
For each:
1. Which questions are solved: quote, recipient, rail, completion, proof, dispute?
2. How is metering handled?
3. Maturity: idea, proposal, or actual services?
4. Verifiable accepting services; admit uncertainty.

Requirements:
- Source every specification name, version, code, and field.
  Mark uncertainty as requiring official verification.
- Do not call proposals standards.
- Separately list shared unresolved problems.

Claimed             | Verified             | Correct?
Version             |                      |
Status code         |                      |
Field               |                      |
Interface usage     |                      |

Why would providers integrate each approach?
Does integration increase revenue or cost?
If cost, what persuades them?

Real-World Case

Integration time: more than a week slows adoption
Otherwise impossible use: strongest signal
Dense initial group: for example, a service category

Change One Variable

Takeaway Questions

Chapter Check