Skip to content
Developer platform

A paid response starts with one 402.

A protected route returns payment terms. A compatible client authorizes them, retries the request, and receives the paid response.

Read the docs Request access
HTTP payment sequence A protected route answers with payment terms; the client authorizes them and retries the request to receive the paid response. PAID REQUEST SEQUENCE GET 01 Protected route 402 02 Payment terms SIGN 03 Payment proof 200 04 Paid response The client reads the terms, authorizes payment, and retries the request. HTTP payment sequence A protected route answers with payment terms; the client authorizes them and retries the request to receive the paid response. PAID REQUEST SEQUENCE GET Protected route 01 402 Payment terms 02 SIGN Payment proof 03 200 Paid response 04 The client reads the terms, authorizes payment, and retries.
HTTP payment sequence A protected route answers with payment terms; the client authorizes them and retries the request to receive the paid response.

Payment closes the request loop before the protected response returns.

Event lifecycle

Keep product state tied to payment state.

Treat each stage as a distinct operational boundary. Verification is not settlement, and fulfilment belongs after the confirmed money-movement outcome.

  1. 01

    Created

    Your application or a hosted LinkSell surface defines the payment terms.

  2. 02

    Initiated

    A buyer opens checkout or an agent receives a payment challenge.

  3. 03

    Confirmed

    The submitted authorization is verified before settlement completes.

  4. 04

    Settled

    Your system receives the settlement outcome and can fulfil the purchase.

HTTP-native payment

Request → 402 → settle.

A protected route returns payment requirements. A compatible client authorizes those terms, retries with proof, and receives the paid response after settlement.

A paid HTTP request

A compatible client receives payment terms, authorizes them, and repeats the request with proof.

A paid HTTP request A compatible client receives payment terms, authorizes them, and repeats the request with proof. CLIENT Authorizes RESOURCE Returns result 01 · request 02 · HTTP 402 03 · signed retry 04 · 200 response A paid HTTP request A compatible client receives payment terms, authorizes them, and repeats the request with proof. CLIENT RESOURCE 01 · request 02 · HTTP 402 03 · signed retry 04 · 200 response
Payment closes the request loop. The resource checks proof before it returns the response.
Wallet, facilitator, asset, network, and finality support determine the exact production path.

Integration tasks

Add only the surfaces your product needs.

Start with one complete path, then add events, embeds, agent payments, or the published Laravel SDK when the job requires them.

01

Create checkout

Return a hosted payment URL

Create checkout terms from your server, then send the buyer to the URL returned by the API. Lists use a bounded data, count, and limit envelope.

REST API reference
02

Confirm settlement

Process signed state assertions

Verify the raw delivery body, accept active rotation signatures, deduplicate retries, and fulfil on the settled event.

Webhook guide
03

Add checkout

Progressively enhance an existing page

The small embed script opens a payment-link checkout and falls back to full-page navigation when a popup is unavailable.

Embed guide
04

Protect an API

Challenge compatible agents over HTTP

A protected route returns x402 terms. The client signs a single-use authorization, retries, and receives the upstream response after settlement.

Agent-payment recipe
05

Understand the protocol

Separate orchestration from the money path

LinkSell presents terms and records outcomes while compatible settlement moves USDC from the paying wallet to the configured merchant wallet.

What is x402?

Evidence first

The page still works before JavaScript.

REST, webhook, embed, and agent-payment doorways are server rendered. The optional integration examples enhance this path only when published and enabled.

Open the REST reference →
Operational boundaries Code-verified guidance
  • Keep API credentials on the server.Browser widgets use purpose-built, limited surfaces.
  • Verify webhook signatures against the raw body.Handle retry and rotation candidates before processing.
  • Fulfil on settlement, not verification.Treat events as state assertions because delivery order is not guaranteed.
Confirm event names against the runtime catalogue and the service descriptor for the environment you deploy.

Documentation

Open the reference for the job.

Move from protocol concepts to the exact API, event, embed, agent-payment, or published SDK surface you need.

Concepts REST API Webhooks Embeds Agent payments

Start getting paid

Start with a supported wallet.

Create your account, verify a receiving wallet, and configure a payment surface. Review the live networks, plan limits, and external costs before publishing.

Need help first? Contact [email protected].

Request access Read the docs