Your users authorise a budget. They never hand over a key.
Every agent that needs to buy something has the same ugly first step: ask someone to paste a secret into a chat window. Connect through OAuth instead. Your user approves a spending budget the way they approve any other app, and your bot gets a mandate rather than a credential to look after.
Works wherever your agent already lives, and your product never stores or sees a payment credential.
research-bot is asking to spend on your behalf.
- Up to
- $50.00
- Per transaction
- max $2.00
- Until
- 21 October
It will be able to pay any paid service on the internet, up to this amount, until this date. You can revoke it at any time.
What the grant is
Scoped, capped and revocable. In that order.
Scoped
A budget, not an account.
The grant covers spending and nothing else. A credential issued for account access or for buying credits is refused outright at the spend endpoint, so widening one consent cannot quietly widen another.
Capped
The ceiling is set by the person, in a browser.
Your user chooses the currency, the amount, the duration and the per-transaction limit during the approval. Funding is mandatory at consent, so a grant that could not pay for anything never gets minted.
Revocable
One action, and it stops.
Revocation is the standard OAuth mechanism, so anything that already speaks OAuth can do it. Fees accrued up to that moment are swept and settled rather than left stranded.
Say it plainly
The budget is the boundary.
A granted budget can pay any paid service on the public internet, up to its cap, until it expires. There is no per-merchant list to maintain and no approval queue in the middle. That is what makes it useful: your agent is not limited to the suppliers we happen to have relationships with.
It also means the cap, the expiry and revocation are the whole of the control surface, which is why your user sets all three and we show them on the approval screen.
The whole control surface
- A spending cap
- A per-transaction limit
- An expiry date
- Revoke, at any time
Where it works
Wherever your agent already talks to people.
Two ways in, and they use the same approval flow underneath.
Chat channels
Through a gateway
Run an open-source gateway such as OpenClaw and your agent meets people in the apps they already use. The channels it reaches:
MCP clients
Straight in
Anything that speaks MCP connects to our Commerce server directly and runs the same approval. It gets tools to search the catalog, pay for a service and read its own ledger back.
See what it can buyFor the engineer reading this
Ordinary OAuth. Nothing bespoke to learn.
It is a standard authorization server. If your client already does OAuth, it already does most of this.
Authorization code + PKCE
The browser flow, hardened against interception
Device authorization grant
For clients with no browser of their own
Token revocation
RFC 7009, with accrued fees swept on revoke
Protected resource metadata
Clients discover the authorization server
Dynamic client registration
A connector can register itself
Authorization server issuer
RFC 9207, so the response cannot be swapped
The other direction
The same agent can charge for its own work.
An agent that buys can also sell. Put a price on what yours does, meter it per call or per outcome, and settle through the payment provider you already use.
