x402 and protected resources

x402 is the protocol model behind payment-aware requests. In OpenPayment, it explains why payment can be part of the flow itself instead of an external step the user performs manually and proves later.

Why OpenPayment uses x402

Traditional crypto payment flows usually look like this:

1. display an address
2. tell the user how much to send
3. wait for them to transfer funds
4. manually decide whether the next action should happen

x402 replaces that loose coordination with a request/settlement model. Payment is treated as part of the same lifecycle that controls whether a client may continue.

That idea is what makes OpenPayment useful for both simple links and protected resources.

The x402 mental model

At a high level, x402 introduces three concerns:

• a client wants to perform an action
• a server can require payment before allowing it
• settlement is verified as part of the flow

OpenPayment applies that model to wallet-based USDC payments on Base.

How this maps to OpenPayment

In product terms, the mapping is straightforward:

This is why OpenPayment is more than a link generator. It is a structured payment gate.

Why this matters even for basic payment links

Even if you never use PROXY, the x402 model improves regular payment links:

• the requested network is explicit
• the amount model is explicit
• the recipient is explicit
• the system knows whether the link is reusable
• successful payment produces a verifiable receipt

The payer is not guessing what to send or where to send it.

PROXY is the clearest expression of x402

PROXY is the most direct product-level example of payment-aware access control.

With PROXY:

1. you create a fixed-price payment that points to a protected HTTPS resource
2. the payer opens the OpenPayment checkout
3. the payer settles the required amount
4. OpenPayment performs a server-side request to the protected resource
5. the payer receives the returned JSON or text response

This turns payment into a gate in front of a live resource, not just a passive transfer request.

Important PROXY design implications

When documenting or designing a PROXY flow, keep these rules in mind:

• PROXY is reusable, like MULTI_USE
• the price is fixed, unlike VARIABLE
• the protected resource should return JSON or text, not binary files
• the protected resource URL is not exposed to the payer
• the payment result and the protected response are related but distinct

That last point is especially important. A settlement can succeed and still be followed by a protected response that signals an application-level failure. For example, the payment may be valid while the protected upstream service returns an error response. In that case:

• the receipt still proves the payment succeeded
• the protected response still tells you whether the gated action succeeded

Treat them as two separate outputs of the same flow.

Query parameters in proxy flows

The OpenPayment checkout for PROXY supports optional query parameters. These are useful when the protected resource needs contextual input such as:

• locale
• report identifier
• customer segment
• city or country
• output variant

In the Web UI, the payer can supply these as flat key/value pairs before payment. OpenPayment forwards them to the protected resource after successful settlement.

What you usually do not need to think about

Most users of OpenPayment never need to work directly with low-level x402 protocol details. If you use the Web UI, CLI, SDK, or skill:

• you do not manually build payment challenges
• you do not manually construct settlement payloads
• you do not need to understand raw protocol headers to create links

You only need the x402 mental model to understand why the system behaves the way it does.