Billing and payment

WAVE has two payment rails, and which one you use depends on who is calling.

Both rails meter the same way and bill the same underlying units. Agent commerce is not a separate product — it is how the platform works.

Subscription billing

Your plan and payment method are managed through Stripe.

• Start or change a plan — POST /v1/billing/checkout returns a hosted Stripe Checkout URL.
• Manage, update or cancel — POST /v1/billing/portal returns a Stripe Billing Portal URL,

where you can change payment method, download invoices, or cancel.

Both endpoints require authentication and return 401 AUTH_REQUIRED without it — they are first-party account routes, not metered product routes, so they are never behind a payment challenge.

You can do all of this from the console at console.wave.online/billing without touching the API.

What "metered" means here

Every product records usage against a named meter — for example render minutes, GPU seconds, or stored gigabytes. Metering happens at the gateway, in one place, for every product. Your invoice is the sum of those meters over the period, plus any plan fee.

You can read your own current usage at any time; see API endpoints.

Agent payment (HTTP 402)

An agent with no account calls a product route directly. The gateway answers 402 Payment Required with a machine-readable quote:

{
  "x402Version": 1,
  "error": "payment required",
  "accepts": [
    {
      "scheme": "exact",
      "protocol": "x402",
      "network": "base",
      "maxAmountRequired": "1000",
      "resource": "/v1/render",
      "payTo": "0x…",
      "maxTimeoutSeconds": 60
    }
  ]
}

The accepts array is a list, and the agent picks a rail it can satisfy. WAVE speaks two:

• x402 — the HTTP-402 payment standard.
• MPP — the Machine Payments Protocol.

They are equal citizens. Neither is a fallback for the other, and the discovery documents describe each on its own terms rather than assuming x402's answer applies to both.

The network is per product, not global

Do not assume one chain for the whole API. accepts[].network and accepts[].scheme are resolved per product and must be read from the challenge you actually received. Live examples:

An agent that hardcodes the network from one endpoint's challenge will fail on another.

Retrying after payment

Send the payment envelope back on the retry, and echo the challenge's session identifier in the x-payment-session header. A 402 that comes back with a new session id means the payment was not accepted — treat it as a rejection to diagnose, not as a fresh quote to pay again.

Discovering what things cost, as an agent

Prices are advertised, not published in prose:

• GET /.well-known/payments.json — which payment rails this deployment speaks.
• GET /.well-known/wave-scopes.json — the scope catalog: what exists and what each route needs.
• The 402 challenge itself — the authoritative price for the route you are calling, right now.

Where to go next

• Agent commerce — the full agent payment flow end to end.
• API endpoints — the product surface and its scopes.
• Rendering — a worked example of a metered product.