From HTTP 402 to a Committed Payment
An x402 facilitator becomes understandable only when its decisions are placed on the payment path. This chapter follows one request from a payment-required response to a settlement result, with special attention to the distinction between looking valid and becoming committed. The practical outcome is a lifecycle model: a reader should be able to locate the client, resource server, facilitator, and blockchain at each transition, and recognize which payment flow a deployment is using.
One request carries two descriptions of a payment
The first description comes from the resource server. When a client asks for a protected API or other resource without an acceptable payment, the server returns a payment-required response. In x402 v2, that response contains a resource description and one or more acceptable payment requirements. A requirement identifies the payment scheme, network, amount, asset, recipient, and maximum completion time, with additional scheme-specific information where needed.
This is not merely a price label. It is the server's statement of the payment that would satisfy the access condition. The recipient says where value should go; the network says where the statement must be interpreted; the asset and amount describe what is to move; and the timeout limits how long the offer remains meaningful. The resource information ties the payment to the thing being requested. A client may choose among acceptable entries, but it is not supposed to invent a different payment and expect the server to treat it as equivalent.
The amount is expressed in atomic token units rather than a display-friendly decimal. That choice avoids leaving the facilitator to guess how many smallest units a human-facing price represents. Optional extension data can carry additional information, but the v2 rules also constrain how it travels: a client echoes the information the server provided rather than silently deleting or overwriting it. These details are easy to dismiss as schema design. They matter because an agent will make a selection from the fields it receives, and a facilitator will later use related fields to decide what can be verified or settled.
The second description comes from the client. The client returns a payment payload containing the chosen requirements and scheme-specific proof. For an exact EVM authorization, the proof includes a payer, recipient, value, validity window, nonce, and signature. The signature makes the payer's authorization portable: it can be presented to a facilitator rather than requiring the resource server to submit a blockchain transaction directly. But portability does not remove the need to compare descriptions. The server's requirements and the payload's accepted terms still have to refer to the same resource and payment.
That comparison is why the facilitator's verification request includes both objects: the payment payload and the server's payment requirements. The facilitator is being asked a constrained question, not a free-standing one. It must determine whether this proof is valid for these requirements, on the supported network and under the selected scheme. A signature that is genuine but authorizes a different recipient is not a successful payment for the server. A payload that has a plausible shape but names an unsupported network is not rescued by being well formed.
The response is then sent back to the resource server, not directly treated as a license by the client. The server owns the protected resource and decides how the payment outcome affects its business logic. That division of responsibility is easy to miss because the interfaces are machine-readable, but it determines where state lives. The client owns the signed intent. The server owns the access decision and any business side effects. The facilitator owns the verification and settlement behavior it exposes. The blockchain owns the final state that its consensus rules accept. A correct payment requires these state owners to agree at the boundaries between them.
This also explains why the resource server's requirements must remain available at verification time. If the facilitator checked only the payload, it could establish that a client signed some authorization without establishing that the authorization satisfies this server's price, recipient, asset, network, and timeout. Conversely, if the server checked only its own fields and trusted the facilitator to fill in every relationship, it would be unable to tell whether the proof and the submitted transaction remained bound to its original request. The two descriptions are separate precisely so they can be compared.
Verification observes; settlement commits
The v2 interface gives the two central facilitator operations different meanings. POST /verify is read-only: it validates payment state without executing the transaction or committing on-chain state. Its response can say that the authorization is valid or provide a reason it is not, such as insufficient funds, an expired authorization, or a mismatch in the payment fields. Verification is therefore a decision about eligibility, not yet the final movement of funds.
The read-only property is valuable for the default flow. It lets a server reject an invalid request before doing expensive business work, and it lets a facilitator avoid sponsoring a transaction that is already known to be malformed or non-settleable. But it also limits what the response can prove. A read-only check can observe a balance, signature, validity window, or other state without reserving every condition for the later settlement. Unless the system binds the two calls, the result is a time-stamped judgment rather than a permanent hold.
POST /settle is different. It durably commits payment state for the request, typically by broadcasting a transaction, although the exact mechanism depends on the payment scheme. Its success response includes settlement information such as the payer, network, and transaction identifier. For client-prepaid methods, settlement may instead bind an observed payment proof to the request or consume a challenge; durable commitment is a semantic property, not necessarily one particular kind of on-chain write. The server can use that result to establish that the payment reached the commitment point defined by the scheme.
The difference between the two operations is not a technical naming preference. It is the difference between checking a condition and changing the state on which later decisions depend. A verification response can be reused, become stale, or disagree with the transaction eventually submitted. A settlement response is supposed to describe the commitment that the server will treat as payment, but even that response needs a defined relationship to the transaction hash, network, and scheme.
The default authorization flow makes this distinction visible:
- The client requests the resource.
- The server returns payment requirements.
- The client sends a signed payment payload.
- The server asks the facilitator to verify it.
- If verification passes, the server executes its resource logic.
- The server asks the facilitator to settle.
- The server returns the resource according to its acceptance rule.
The separation has a useful purpose. A server can reject an obviously invalid or unaffordable payment before spending resources on its business operation or asking a facilitator to sponsor a transaction. It also avoids committing an irreversible transfer for a request that the server cannot fulfill. But the separation creates a time interval in which the payment can change. A nonce might be consumed by another request, a validity window might expire, or the payer's balance and the network state might change. A verification response is consequently evidence about a point in time, while settlement is evidence about a later commitment.
The server's acceptance rule matters at the last step. If it returns the protected resource merely because /verify returned isValid: true, it is treating eligibility as payment. If it waits for a successful settlement response—or has a carefully designed compensation path when the resource must run first—it is making a different state transition the access condition. The protocol defines the response shapes and ordering options, but it cannot automatically know whether a particular business side effect can be undone. That remains part of the server's integration responsibility.
Three flows, three commitment questions
The v2 specification makes the default sequence a named payment flow rather than an assumption that applies to every mechanism. In authorization, the ordering is verify, resource, settle, then respond. Funds move only after the resource operation completes successfully. This is attractive when a server wants to avoid charging for work it cannot deliver, but it leaves a gap between the pre-resource check and the final commitment. The server must decide what happens if it performs work and settlement later fails.
In upfront, settlement occurs before the resource executes. The server receives finality first, which can make access gating straightforward: no committed payment, no resource. The cost is that a failed or unavailable resource may require a refund, credit, or other compensation path. The facilitator and server have not eliminated failure; they have moved the commitment point and changed who bears the awkward case. The server also needs to ensure that an upfront commitment is for the resource and terms it is actually prepared to provide, rather than treating any successful settlement as a universal access token.
In escrow, an initial settlement commits a deposit or ceiling, the resource executes, and a later settlement records the final charge. This can separate authorization to spend from the amount ultimately charged, but it introduces more state. The facilitator must know how to distinguish the settlement steps, and the server must understand what the first commitment permits before the final amount is known. The v2 specification permits /settle to be invoked more than once for such a flow; repeated calls are not automatically duplicates, provided the scheme defines their meaning.
The specification also requires non-authorization flows to be made visible to clients and servers. A client should not select a payment method whose ordering it does not understand, and a server should not treat a pre-resource commitment as if it were the same as a post-resource authorization. That requirement is a protection against hidden state transitions. The same word—settle—can mean an upfront transfer, an escrow deposit, a final charge, or a request-side commitment depending on the scheme.
There is a related ambiguity around failure responses. A facilitator may report an ordinary settlement failure with no broadcast transaction, or it may report settlement_pending when it broadcast a transaction but could not establish confirmation. The latter is non-terminal: the transaction may still confirm. The v2 specification requires the response to carry the broadcast hash and network so the caller can reconcile the outcome on chain before deciding whether to retry. Treating every error as “nothing happened” can create a duplicate commitment; treating every pending response as success can release a resource too early. Correct handling requires the server and facilitator to share a state model, not just a status vocabulary.
That state model also has to account for retry behavior. A network timeout can occur after a facilitator submits a transaction but before the server receives the response. The server's next action cannot be chosen from the absence of an HTTP response alone. It needs an identifier or other scheme-specific evidence with which to reconcile the request, and it needs an idempotency rule that says what a repeated settlement means. This is not an argument for making every operation synchronous. It is an argument for making uncertainty explicit instead of allowing a retry to become an unexamined second payment.
The lifecycle is the security model
Following the path reveals why x402 facilitators become a trust boundary. At the beginning, the server declares what would count as payment. In the middle, the client signs an authorization and the facilitator interprets it. At the end, the facilitator causes—or records—the state change that the server and blockchain will treat as payment. A mismatch at any transition can produce a result that looks successful to one participant and unpaid or unsafe to another.
The protocol's value is therefore not just that it standardizes a request format. It gives the participants named places to state requirements, verify a proof, commit payment, and report the resulting state. Those names create a common vocabulary, but they do not guarantee a common implementation. The next chapter will ask whether the data and signature at each step still mean the same thing when they cross schemes, wallet models, and networks. That is where the facilitator's apparently ordinary lifecycle becomes a security-critical translation problem.