Skip to content
Payvol

Agent payments

When both sides are software, prose is not a contract.

A service asks another service to pay. Nobody is going to read the terms, so every one of them has to be a field a machine can check, and every refusal has to be a code a machine can act on.

Start building Other situations

Request · available Verify · available Observe · in development Reconcile · in development

Nothing in prose

Most payment formats assume a person is looking at the screen.

They allow free text where a value belongs, leave the deadline to a convention, and describe failure in a sentence. That works when a human reads it and shrugs. An agent cannot shrug, so it either guesses or stops, and both are bad outcomes at machine speed.

Every term is a field with one meaning

Amount, asset, deadline, destination and conditions are typed, and the encoding of each is fixed. Two agents that never met agree on what the request says, character for character.

A reason code, not an error message

Knowing that a payment was refused is not enough. Knowing whether to retry, escalate to a person, or stop is what lets an agent behave sensibly without supervision.

A request cannot claim its own conditions are met

It declares what must be true. The paying side checks that at the moment it decides, which is the only moment when the answer is worth anything.

The request never sets its own ceiling

Per counterparty caps, daily ceilings and escalation thresholds live in the paying agent's own policy. A request that could raise its own limit would be a request worth forging.

How it works

Ask, evaluate, act.

01

Ask

  • The asking service builds a typed request
  • Conditions are declared by reference
  • An expiry bounds how long it can be acted on

02

Evaluate

  • The paying agent verifies the bytes and the envelope
  • It resolves conditions against current state
  • It applies its own policy, which the request cannot see

03

Act

  • Pay, refuse with a code, or escalate to a person
  • Every outcome is recorded locally
  • The asking side learns which of the three happened

Honest about the fit

Where this is thin.

Agent payments are the newest of these situations and the honest answer is that less has been proven here.

Identity is the hard part, and it is open An agent cannot ask a colleague whether a counterparty looks right. Until key discovery is solved, this works best between parties that already know each other.
No delegation model There is no way to express that an agent acts for a principal within limits. That is real work and it is not in the profile.
Nothing is metered This is not a per call payment protocol. Related work exists in the ecosystem and we would rather point at it than duplicate it.
No production traffic No agent has paid another agent with this in anger. Everything here is designed, tested, and unproven at scale.

There is no Payvol service to call. Every module runs on your own infrastructure or in your own process, which is the point and also the work.

Wire two services together.

One asks, the other pays, and both keep a record of why.

Open the app Validator and node services