What Is a Machine Customer, and Why Nobody Has Built One End to End
The idea, stated without the hype it usually arrives with
A machine customer is software that buys on its own initiative, within limits somebody set, rather than a person clicking a button and software carrying out the click.
The interesting part is not that software can send a payment. It has been able to do that for decades. The interesting part is that the counterparty has to decide whether to deal with a buyer that is not a person, and that decision needs something to rest on.
The chain has five links
One: an identity for the buyer. Something durable that names this specific agent and survives across sessions and platforms.
Two: an authorisation. Evidence that this agent may make this purchase within a bound somebody with standing actually set.
Three: a rail. Something that moves the value.
Four: a merchant who accepts the first two. Not a merchant who could, in principle. One who does.
Five: recourse. When the agent buys the wrong thing, buys it twice, or buys it after its principal withdrew permission, somebody has to be answerable and there has to be a route to unwinding it.
Nobody has all five joined up, and the demonstrations that circulate usually have one, three, and a screenshot.
Where we sit, said narrowly
We hold link one. We issue an identifier and a credential and anchor a passport in a public registry, and this estate has published exactly what that does and does not establish.
We do not hold link three. We do not settle. No value moves through us, in any direction, under any arrangement.
Not few. None.
Link five is the hard one, and this product implements none of it
Measured, with a control: nothing. A search across the backend and the shared package for dispute, refund, chargeback and recourse machinery returns nothing.
CONTROL: the same paths return twenty-nine files for webhook and audit vocabulary, so the searcher works. And the one apparent hit was read rather than counted: the word "liability" appears in a test comment about specification completeness, not in a feature.
That is the correct result for a credential issuer, since recourse is contract law and payment network rules rather than a signature scheme. It is also the reason the chain does not close, and an issuer saying "not my layer" does not make the layer appear.
And the link recourse would rest on is our weakest
Recourse begins with knowing who is answerable. That is exactly what an ownership credential is for, and this estate has already measured what ours carries.
The assurance level in it is a free-text string supplied by the party it describes. The verdict from the surface that ran the identity check is not carried in the credential at all, though it is stored in the database.
And the credential has no expiry, so any authorisation built on top of one is valid until somebody revokes it rather than until it lapses.
For a shopping session, none of that matters. For a dispute months later, all of it does.
What we are not going to do on this page
No market figures. The phrase this page is named for comes from a research firm with published forecasts, and we have not verified any of them, so none appear here.
No timeline. A forecast written by a company that benefits from the forecast is marketing, and this estate has a rule against exactly that.
And no claim that identity is the missing piece. It is a missing piece. The rail, the merchant and the recourse are missing too, and three of those four are somebody else's to build.
What is real today, because absences alone would misdescribe us
A credential format that is a published standard and an identifier method registered in the W3C DID Method Registry, so an artefact can be checked by software that never heard of us.
And a separation of duties that holds: identity verification happens on another surface, this one ingests the result, and nothing here re-runs an identity check or moves money.
That is one honest link of five.