What Proves an x402 Payment? Requests, Receipts and Settlement

When a service advertises x402 payments, a useful question follows: what evidence shows that a payment actually happened? A request, a signed authorisation and a confirmed settlement describe different stages. Treating them as interchangeable makes dashboards and customer support less reliable.

For builders, the answer starts with keeping those stages separate.

A payment requirement is an offer

An HTTP 402 response tells the client that payment is required and describes acceptable terms. It is a quotation for access, not evidence that money has moved. A service can issue thousands of payment requirements without completing a single purchase.

Likewise, receiving a signed payment payload shows that a client submitted an authorisation. The service still needs to validate the payload and follow the settlement process for the supported payment scheme.

Verification and settlement answer different questions

Verification checks whether a submitted payment satisfies the expected requirements. Settlement is the step that executes the payment through the relevant network and scheme. A facilitator can help with these operations, but a successful verification response should not be counted automatically as a confirmed settlement.

Applications should record the result of each stage. If settlement fails, the record should retain the failure rather than present the earlier verification as a completed sale.

Build a useful receipt trail

For an on-chain settlement, keep the network and transaction hash together. Also record the asset, amount, intended recipient and settlement result. Connect that evidence to the application request so a customer can identify which purchase it belongs to.

A transaction hash alone is not enough context. The transfer must match the expected network and payment terms, and its outcome must be checked. Confirmation policies should reflect the network and the service’s delivery requirements.

Count purchases carefully

In a hypothetical API purchase, one customer request might generate a quote, a signed retry and several status checks. Those are several HTTP interactions but not several settled payments. Conversely, a single transaction can contain multiple events, so counting every log as another purchase can also inflate totals.

Define the unit being measured before displaying it. Use separate labels for requests, successful settlements and unique paying addresses. An address is not proof of a unique person.

Make evidence easy to inspect

A good payment record helps an operator answer three questions: what was purchased, what settled and what was delivered? Clear records make disputes easier to investigate and help public activity figures reflect the underlying payments.

Official facilitator concepts: https://docs.x402.org/core-concepts/facilitator

Official HTTP 402 concepts: https://docs.x402.org/core-concepts/http-402