From HTTP 402 to Service Access: The Payment Lifecycle Needs a Recovery State

An HTTP 402 response starts a payment conversation; it does not finish a service transaction. A robust AI agent payment lifecycle must preserve the original requirement, authorize one payment, verify its state, deliver the requested resource and recover when any step becomes uncertain. The distinction matters because a transaction can be broadcast while the response is lost, or payment can be admitted while the business operation later fails.

The common shorthand is “request, 402, pay, retry.” That is useful for understanding the protocol, but incomplete for production. The merchant also needs order state, receipt handling, replay protection, delivery state and a rule for resuming verification without paying twice. The payer needs a matching policy: it should know when a timeout means “wait” rather than “authorize another transfer.”

GOAT Network's documented paid-route and order flows make these boundaries concrete. Its MPP profile describes a challenge, direct transfer, verification and signed Payment-Receipt; its merchant guide separately describes order state and fulfillment. These are implementation details of the documented GOAT surfaces, not a claim that every x402 deployment has the same endpoints or receipt format.

A 402 response is a request for terms

The resource server returns HTTP 402 when the request lacks acceptable payment proof. In the general x402 model, the response communicates requirements, the client creates a payment authorization, and the server or facilitator verifies and settles that authorization before returning the resource. The status code indicates the next required action; it is not itself evidence that money moved.

The requirement should be treated as an object, not as prose. It normally needs the amount, asset, network, destination, resource scope and expiry. The agent should retain the raw requirement and a normalized interpretation. This allows it to compare the payment with its spending policy and later prove which terms it accepted.

The x402 documentation describes V2 message stages through PAYMENT-REQUIRED, PAYMENT-SIGNATURE and PAYMENT-RESPONSE. That vocabulary is useful for the generic protocol boundary. GOAT's MPP guide uses a different, implementation-specific challenge and receipt profile. A client should negotiate the format it actually supports rather than assume that one header or receipt parser handles every 402 response.

The first decision is authorization, not signing. An agent should check that the service is allowed, the amount is within the task budget, the recipient is acceptable and the expiry leaves enough time for execution. If a required field is missing or inconsistent, returning an explicit refusal is safer than guessing.

Broadcast is not verification

After authorization, the payer submits the transfer or payment payload. The submission produces evidence such as a transaction hash, but a hash is not the same as merchant acceptance. The network may still be processing the transfer, the amount may not match the challenge, or the merchant may be watching a different route.

The agent should move to a pending state and keep the challenge, payment identifier, transaction hash and request correlation ID together. It should then call the documented verification path or wait for the merchant's supported status signal. If that check times out, the safe action is to resume verification with the original evidence. It is not to call the payment function again merely because the HTTP response disappeared.

GOAT's MPP documentation distinguishes successful verification from pending finality. A 200 response can return a Payment-Receipt; 202 indicates that the payment is still pending, while 429 requires backoff. These status meanings belong to that documented profile. They illustrate a broader rule: payment systems need a pending branch that is visible to the client rather than collapsing every non-success response into “pay again.”

The merchant should make verification idempotent as well. Repeated checks for the same transaction should return the same accepted state or a clear pending/failed state. They should not create additional orders or consume a one-use receipt on every polling attempt.

Admission and delivery are separate state machines

Once payment proof is accepted, the service still has to execute. A paid API may need to query a database, run a model, create a file or call another provider. A payment receipt can authorize access without proving that the result exists or meets a quality requirement.

Use separate state for payment and service delivery. A compact model might look like this:

The separation prevents a dangerous shortcut: treating verified as delivered. If the service fails after payment admission, the merchant needs a retrieval, retry or refund policy. The agent needs to know whether it may request the same result again without creating a second commercial obligation.

GOAT's order documentation also illustrates why terminology needs care. Server-created orders and QuickPay sessions can expose different terminal states. A legacy field described as a proof signature may be an unsigned digest rather than the cryptographically signed receipt used by the paid-route profile. Developers should name these records according to what they actually prove instead of using “receipt” for every hash or status snapshot.

This is not merely a documentation concern. Support teams often receive a transaction hash and a claim that the product was paid for. Without the accepted offer, order state and delivery record, they cannot determine whether the buyer paid the correct amount, whether the payment was already consumed or whether fulfillment began.

Route binding limits what a receipt proves

Payment proof should be bound to the resource that will be returned. A verifier can check the signature, merchant audience, expiry, route and, where configured, whether the receipt has already been consumed. These checks reduce the chance that proof for one resource is replayed against another.

The inspected GOAT middleware uses a route-binding rule that accepts an exact canonical route or a documented colon-delimited suffix under the configured route. That is narrower than claiming that the proof covers every byte of an arbitrary request body. If a service's price depends on request parameters, the application should bind or record those parameters separately and verify them before execution.

One-use consumption also needs shared storage when the service runs across replicas. A local in-memory flag can allow the same proof to be accepted by two instances. If the configured receipt store is unavailable, rejecting the request is more defensible than silently bypassing consumption. The middleware documentation treats store failure as a service error, not as permission to deliver anyway.

Replay protection does not solve bad delivery. It only protects admission. The delivery record must still connect the accepted payment to the result that the agent receives. For a generated report, that could be a result ID and immutable content hash. For an API response, it could be a request ID, response status and durable retrieval endpoint. The right evidence depends on the service.

Recovery should begin with the last known state

Consider an agent that sends a payment and loses its connection before the merchant responds. The agent has at least four possible observations: no transaction was submitted, a transaction was submitted but is pending, payment was verified but delivery was lost, or the transaction failed. Each state needs a different next action.

The merchant should make recovery endpoints discoverable to its own client integration. The original challenge and payment identifier are the keys to recovery. Reconstructing the request from today's price or a mutable product description can create a new transaction by accident.

Retries also need an idempotency key. The key should identify the intended business operation, not just the network transaction. A retry after a server crash can then return the existing order or result. If the request is intentionally a new purchase, it needs a new business identifier and a new authorization decision.

Refunds are a business policy, not an automatic consequence of HTTP failure. The merchant may refund a payment when fulfillment cannot complete, offer a delayed result, or require support review for a disputed outcome. The policy should state which evidence starts the timer, who pays network costs and whether a partial result changes the obligation. Do not promise an automatic refund unless the actual system implements one.

Design the merchant record around correlation

A production record should let an operator follow one request across payment and service systems. Useful identifiers include an agent or client ID, request ID, order ID, payment ID, transaction hash, receipt ID, tool invocation ID and result ID. They do not all need to be public, but the merchant should know how they relate.

Record the terms before payment: resource, amount, asset, network, recipient, expiry and offer revision. Record authorization and broadcast next. Then append verification, receipt admission, service execution, delivery and settlement events. An append-only event trail makes late webhook delivery or a duplicated client request easier to reconcile.

The same model works for an MCP tool, a paid API or a digital download. The tool call is the business request; the 402 challenge is the payment requirement; the receipt proves an allowed admission event; the result record proves delivery. For a complex workflow, one parent task may own several child payments, each with its own order and service result.

A lifecycle test that catches the expensive bugs

Do not test only the happy path. In a test environment, run a normal request, then interrupt the client after broadcast, delay verification, repeat the verification call, replay the receipt against another route and make the service fail after payment admission. Check that each event lands in the intended state and that retries do not create a second charge.

Also test concurrent replicas. The same proof should not be admitted twice when two requests arrive at nearly the same time. A receipt-store outage should produce a visible error and an operator alert. A stale challenge should require a fresh requirement rather than being accepted because the amount happens to be unchanged.

These are implementation tests, not claims that a public GOAT deployment has passed them. They are the minimum evidence needed before calling a paid resource production-ready. The protocol can move value; the merchant application remains responsible for making value movement correspond to service access.

One further distinction helps during incident response: a network confirmation, a merchant verification response and a service response are observations from different systems. They may arrive in a different order, and one may be temporarily unavailable while the others remain true. The incident record should therefore preserve event timestamps and the source of each assertion. A merchant operator can then distinguish a delayed indexer from a rejected payment, and a slow downstream tool from a missing transfer.

The agent should expose the same distinctions to its own planner. “Paid” can mean authorized, broadcast, verified or delivered, depending on the application vocabulary. Those words should not be collapsed into one Boolean because a planner might treat it as permission to continue with a dependent task. A workflow that needs the returned report should wait for a delivery state, not merely for a verified payment state.

Where a service uses asynchronous execution, the initial paid response can return a durable job or result identifier. The agent can poll or subscribe to that result without repeating payment. The merchant can expire an abandoned job while preserving the payment and refund decision separately. This pattern is often clearer than holding an HTTP request open until every downstream dependency completes.

An AI agent payment lifecycle is complete only when the system can answer three separate questions: what did the agent authorize, what payment did the merchant verify and what service did the buyer receive? HTTP 402 starts the first question. Order and receipt records connect it to the second. Delivery and settlement evidence close the third. GOAT's documented Flow and MPP surfaces provide concrete patterns for those handoffs, while the merchant must still implement its own recovery and fulfillment rules.