How to Compare Agent Payment Approaches
Four shapes cover the field: a challenge issued at request time, a channel between two parties, escrow released on a condition, and a prepaid balance drawn down. Compare any named protocol by identifying its shape, then checking relationship requirements, fee floor and post-settlement behaviour.
The four shapes
Challenge at request time. The buyer requests, the seller responds with machine-readable terms, the buyer settles and retries with proof. No relationship needed beforehand, no capital committed, and every payment costs a settlement. This is the shape x402 takes, using the reserved HTTP 402 status code to carry the challenge.
Channel. Two parties lock a balance, exchange signed running totals off-chain, and settle once at the end. Removes the per-payment fee entirely and commits capital to one counterparty for the duration.
Escrow. Funds are held by a contract and released when a condition is met or a period elapses. The only shape that meaningfully addresses delivery happening after payment, which makes it the relevant one for anything other than immediate digital delivery.
Prepaid balance. The buyer funds an account with the seller and it is drawn down per use. Cheap per transaction and it requires trusting the seller's accounting and their solvency.
When a new protocol appears, identifying which of these it is tells you most of its properties before reading further. Proposals differ in encoding, in settlement asset and in identity handling, and those matter, but the shape determines the fundamentals.
Reading the table
Three notes make the comparison usable.
Relationship requirement is the sharpest divider. A challenge at request time works between parties who have never met, which is the entire reason it suits an agent buying from a provider it found a moment ago. Channels, escrow and prepaid balances all require establishing something first, which rules them out for the long tail.
Fee floor decides which prices exist. If a settlement costs more than a fraction of the charge, per-request payment is not viable at that price no matter how good the protocol is. That is why the low-fee network matters as much as the protocol choice, and why channels exist at all.
Post-settlement behaviour is where three of the four have nothing to say. Challenge, channel and prepaid all assume delivery is immediate and verifiable. For an API call that holds. For anything delivered later, only escrow addresses it, and even then the release condition has to come from somewhere outside the protocol.
Hybrids are normal and sensible. A prepaid balance with a frequently used provider alongside request-time challenge for everything else captures most of the benefit of each.
What none of them provide
Worth stating, because a great deal gets attributed to these standards.
None decides whether a price is reasonable, whether a counterparty is trustworthy, or whether the current task should be buying anything. Those are policy questions answered by the buyer before settling, and enforced outside the model, because a check the model performs is one the model can be argued past.
None bounds spending. Making payment possible is the opposite of bounding it, so limits live in the credential and the policy layer regardless of which shape you use.
None establishes identity. A seller cannot distinguish a well behaved buyer from a hostile one before serving, and a buyer cannot tell a legitimate seller from a fraudulent one before paying. Reputation systems are the obvious answer and none is settled, so allowlists maintained by each side remain the practical substitute.
For most agent workloads, request-time challenge on a low-fee, fast-finality network covers the case without additional machinery, with a prepaid balance added for the one or two providers that dominate usage. That is the shape CryptoCadet is built around: USDC on Base, with bounded delegation through session keys so the policy question has an enforced answer.
| Shape | Prior relationship | Fee per payment | Capital committed | Handles later delivery |
|---|---|---|---|---|
| Challenge at request time | None | One settlement each | None | No |
| Payment channel | Yes, one counterparty | Two settlements total | Yes, until close | No |
| Escrow | Yes, plus a condition | One or two settlements | Yes, until release | Yes |
| Prepaid balance | Account with seller | Effectively none | Yes, held by seller | No |
Frequently asked questions
- How do you compare agent payment protocols?
- Identify which of four shapes it takes: a challenge issued at request time, a channel between two parties, escrow released on a condition, or a prepaid balance drawn down. The shape determines the fundamentals, and encoding, settlement asset and identity handling vary within it.
- Which approach works without a prior relationship?
- Only a challenge issued at request time. Channels, escrow and prepaid balances all require establishing something with the counterparty beforehand, which is why they do not suit an agent buying from a provider it discovered moments earlier and will never use again.
- Which one handles delivery that happens after payment?
- Escrow, and only escrow. The other three assume delivery is immediate and verifiable, which holds for an API call and not for anything fulfilled later. Even escrow needs the release condition supplied from outside the protocol, which the application has to provide.
- Do these protocols make agent spending safe?
- No. None decides whether a price is reasonable or a counterparty trustworthy, none bounds spending, and none establishes identity. Making payment possible is the opposite of bounding it, so limits live in the credential and the policy layer regardless of the shape.