Choose payment timing from delivery evidence, recovery cost, and release authority.
An agent is ready to buy a research report from another machine. The seller needs proof that funds are available before spending ten minutes gathering data. The buyer does not want an irreversible payment for an empty file. Asking whether the agent should pay “before or after” delivery hides the real design problem: authorization, custody, execution, acceptance, release, and settlement are separate events.
AI agent escrow payments are useful when those events cannot safely collapse into one request. They are not automatically safer for every machine purchase. A five-cent deterministic API response may be better protected by idempotency and a refund rule, while a higher-value, multi-step research task may justify conditional custody even if the payment rail is fast.
The deciding factor is not price alone. It is whether delivery can be verified objectively, how expensive a wrong release would be, and who has authority when the evidence is ambiguous.
“Before or After” Hides Four Different Payment Models
A machine buyer can commit value without immediately transferring it to the seller. That distinction creates four practical models.
Model | When value becomes unavailable to the buyer | When the seller receives value | Best fit |
|---|---|---|---|
Direct prepayment | At payment | Before execution or access | Instant, deterministic resources |
Capped preauthorization | When authorization is signed or reserved | After actual usage is calculated | Variable compute or token usage |
Conditional escrow | When funds are locked | After a delivery condition or decision | Delayed or contestable work |
Post-delivery credit | No prefunding | After invoicing or account settlement | Known counterparties with credit controls |
Direct prepayment minimizes state. The server verifies payment, executes once, and returns the resource. The buyer’s exposure is the request price. This is often rational when the resource is cheap, immediate, and mechanically testable.
Preauthorization separates a maximum budget from the final charge. The agent allows up to a ceiling, and the service records actual consumption. The x402 upto scheme reflects this pattern for supported implementations: the advertised price becomes a maximum, and the service determines the final amount from actual usage. Preauthorization reduces overcharging risk. Non-delivery still requires settlement to be linked to successful execution.
Escrow locks capital under release and refund rules. It protects the seller from beginning work with an unfunded buyer and protects the buyer from immediate release. That protection only becomes real when the system can decide what counts as delivery.
Credit reverses the exposure. The seller delivers first and trusts an account, identity, or intermediary to settle later. It can remove per-task locking, but requires underwriting, limits, collections, and a response to default. It is not simply “escrow after delivery.”
Use Escrow When Delivery Is Delayed or Contestable
Escrow earns its complexity when at least one of three conditions is present.
First, execution takes long enough that either party can incur meaningful exposure. A data lookup completed in 200 milliseconds creates little seller working-capital risk. A task that launches paid sub-agents, rents compute, or waits for external events can consume resources before producing a result.
Second, delivery can fail independently of payment. The seller may complete the job. The response can still be lost. The buyer may receive a file that fails validation. A network timeout may leave both agents uncertain about whether work should continue. Conditional funds give the system time to reconcile those states before final release.
Third, the service result has an acceptance condition that can be represented and checked. “Return JSON matching this schema before 14:00 UTC” is machine-verifiable. “Produce a persuasive investment memo” is not. Escrow can hold funds for either task, but the second requires a reviewer, arbiter, negotiated acceptance window, or a partial-payment rule.
Price changes the severity of a failure, not its shape. A $100 deterministic license key may need less arbitration than a $10 subjective analysis. The license can be checked against a signed entitlement. The analysis can satisfy the file-format requirement and fail the buyer’s expectations.
The Release Predicate Is the Core Product
An escrow contract can enforce a condition only if the condition resolves to data it can evaluate or to a decision produced by an authorized party. Developers should define the predicate before choosing the contract.
For a data service, the predicate might require a response hash signed by the seller, a schema-valid payload, and a timestamp before expiry. For a model job, it might require a completion receipt from a trusted execution environment. For a physical delivery, it may depend on an external carrier event, which introduces oracle and identity assumptions.
The predicate should answer five questions:
What exact artifact or event counts as delivery?
Who is allowed to submit the evidence?
Who evaluates the evidence?
How long can either side challenge the result?
What happens if the evaluator is unavailable?
Weak predicates create false automation. A transaction hash proves that value moved; it does not prove that a service ran. A seller-signed “completed” flag proves what the seller asserted; it does not independently establish quality. A buyer-controlled acceptance flag can become free cancellation if silence always triggers a refund.
For subjective work, the honest design may be a staged release. A portion covers verifiable execution costs, another portion releases on delivery, and the remainder depends on acceptance or arbitration. This reduces all-or-nothing incentives but adds accounting, partial-refund, and evidence requirements.
A Minimal Machine-to-Machine Escrow State Machine
The smallest credible escrow is more than a wallet balance labeled “held.” It needs explicit terminal states and transition authority.
Each transition should carry one purchase intent ID. The funded event records the amount, asset, network, payer, payee, expiry, and release policy. Execution records when work began and whether the seller incurred a non-refundable cost. Delivery records an artifact hash or receipt. A status string alone is insufficient.
Release must be idempotent. If two workers process the same callback, the second attempt must observe the terminal state instead of transferring again. Refunds require the same protection. A dispute must freeze automatic release until a defined deadline or decision.
Timeouts need asymmetric treatment. If the seller never starts, refunding the buyer is straightforward. If the seller starts but cannot finish because the buyer supplied invalid inputs, a full refund may reward bad requests. The service terms should state whether validation occurs before funding, after funding but before execution, or as a billable step.
One Identifier Must Bind Payment, Work, and Delivery
Escrow does not repair duplicate HTTP requests by itself. A client can time out after funding and retry. The seller can receive two task messages. A payment watcher and a webhook can report the same event through different paths.
Use one durable payment-intent or order ID across the quote, escrow deposit, work item, delivery receipt, release decision, and refund record. An HTTP request ID is not enough because retries create new requests. A transaction hash is not enough because one task may involve authorization, deposit, release, and refund transactions.
GOAT Network’s public developer stack illustrates this separation without turning payment confirmation into a delivery verdict. GOAT Flow documents order status and payment proof as authoritative signals for its payment surfaces, while warning that a wallet transaction hash is not a fulfillment decision. AgentKit’s runtime provides policy and idempotency controls that can prevent duplicate action execution. A developer can use those records as inputs to a separate escrow policy, but should not claim that payment middleware has judged service quality.
This separation is important for x402 escrow payments. x402 can communicate payment requirements and supported schemes over HTTP. Its batch-settlement model can use capital-backed commitments such as prefunded escrow or channels. The network binding still defines how commitments are backed and redeemed, while the application defines what service delivery means.
Arbitration Is an Authority Choice, Not a Technical Detail
When delivery is objectively verifiable, release can be automatic. When it is not, the system needs an authority model.
Buyer-controlled release favors buyers. It also lets them withhold payment. Seller-controlled release is barely different from prepayment. A platform arbiter can apply consistent rules and introduces operator trust and availability risk. A panel or reputation-weighted process can reduce unilateral control at the cost of additional delay and expense. Fully automated evaluation works only where the evaluator’s inputs and criteria are credible.
The evidence package should be fixed before the dispute occurs. It can include the signed quote, input hash, policy version, execution trace, output hash, timestamps, payment proof, delivery acknowledgment, and communications allowed by the service terms. Privacy rules should limit the package to what the dispute actually needs.
An arbiter also needs constrained remedies. The choices may be release, refund, split payment, credit, or re-performance. “Make the parties whole” is not machine-executable. Each remedy needs an amount, destination, deadline, and finality rule.
Select the Model by the Cost of a Wrong Release
Use direct prepayment when delivery is immediate, deterministic, low exposure, and cheap to retry or refund. Use capped authorization when the service can measure usage and the final charge is unknown in advance. Use escrow when work is delayed, the seller needs funded commitment, and delivery has either an objective predicate or a credible decision process. Use post-delivery credit only when the seller can underwrite the buyer or rely on an intermediary.
Then test the worst terminal state. Ask what happens if funds are committed, the seller starts, the result is ambiguous, the buyer disappears, and the evaluator is unavailable. If the system cannot determine the next state without inventing a rule during the incident, the escrow is not finished.
The practical rule is narrow: add escrow when the expected loss from an incorrect release or refund exceeds the operational cost and new failure surface created by conditional custody. For small deterministic machine calls, that threshold may never be reached. For multi-step agent work, it may be the difference between a payable service and an unacceptable counterparty risk.
FAQ
Does x402 include escrow by default?
No. x402 defines how a service communicates payment requirements and how clients provide payment evidence under supported schemes. Some batch-settlement bindings can use escrow-backed commitments, while separate products can add hold, release, refund, and arbitration logic. Developers must verify the exact scheme and implementation they use.
Should every AI agent payment use escrow?
No. Escrow adds custody, timeout, evidence, release, and dispute states. Direct payment is often simpler for low-value, immediate, deterministic resources where idempotent delivery and a clear refund process keep exposure bounded.
Can an AI agent decide that a service was delivered?
It can evaluate deterministic conditions such as schema validity, signatures, hashes, timestamps, or test outputs. Subjective quality requires an agreed evaluator, acceptance policy, or arbitration process. A model’s opinion should not silently become final financial authority.
What is the difference between preauthorization and escrow?
Preauthorization grants permission to charge up to a limit, often without transferring the final amount immediately. Escrow moves or locks funds under conditional release rules. Both reserve purchasing capacity, but their custody, counterparty exposure, expiry, and recovery mechanics differ.
