The basic HTTP flow
In the x402 v2 HTTP flow, a resource server can return 402 Payment Required along with a PAYMENT-REQUIRED header containing structured payment requirements. A compatible client selects an accepted requirement, prepares a signed payment payload, and retries with PAYMENT-SIGNATURE. The server or a facilitator verifies the payload, settles according to the payment scheme, and returns a PAYMENT-RESPONSE describing the result.
That sequence is attractive for machine clients because the price and payment protocol are communicated in the same request-response environment the agent is already using. It can reduce the need for a human account-creation flow when the resource is intentionally sold per request or per unit of machine consumption.
Challenge, verification, and settlement are different evidence
A 402 challenge proves only that the server asked for payment under a defined requirement. A successful verification proves that the submitted payment authorization is valid under the selected scheme and requirement. Settlement is the economic event: the system reports that the payment completed. Collapsing those stages creates false revenue metrics.
A machine-commerce analytics product should therefore expose each stage separately. Operators need to know how many requests encountered a price, how many attempted payment, how many verified, how many settled, and how many were retries of an already-recorded transaction.
Replay safety is part of revenue truth
HTTP clients retry. Networks time out. Facilitators can return a successful transaction after the original caller has already retried the same request. Without idempotency and transaction-level deduplication, a dashboard can count one payment multiple times even if the underlying network settled only once.
The correct accounting rule is conservative: store enough settlement evidence to recognize a previously recorded transaction or payment fingerprint, and label repeats as already recorded rather than new revenue. This matters even more when the product later calculates platform fees or revenue shares.
Where paid machine access makes sense
The strongest candidates are resources with clear marginal value or cost: proprietary data, expensive computation, premium APIs, fresh structured feeds, licensed archives, or high-volume access that would otherwise impose infrastructure cost without compensating the publisher. Public marketing pages are usually a poor first target because their value often comes from broad discoverability.
A site should observe demand before turning on payment enforcement. If no machine clients repeatedly request the resource, adding a payment protocol creates complexity without a market. If a valuable endpoint is already attracting repeat automated use, a quote-only period can test pricing before any live settlement gate is enabled.