Payment Required, governed before execution

HTTP 402 for AI Agents

HTTP 402 is becoming the handshake between autonomous agents and paid APIs. The protocol can request payment; SatGate decides whether the agent has authority to spend, access, and continue — then preserves proof of the decision.

What HTTP 402 means in an agent world

For years, HTTP 402 Payment Required was mostly dormant. AI agents make it useful: a paid API can respond with a machine-readable challenge instead of forcing a human through checkout.

That challenge may point to different rails: card-based credentials, shared payment tokens, paid-rail context invoices, or future protocols. But the payment challenge is not the governance layer.

SatGate sits before upstream access and applies policy: identify the agent, confirm authority, estimate cost, enforce budgets, decide whether the rail is allowed, record the challenge, and unlock only scoped access after proof.

A 402-aware control plane asks

Which payment method is being requested?
Is this route approved for agent payments?
Does the agent have authority and budget?
Should policy require human approval?
Which paid rail is being requested, and is it allowed by policy?
What Evidence Pack receipt should be recorded before forwarding?

HTTP 402 flow types

Treat 402 as a protocol surface, not a single payment system. paid-rail context is one paid rail; x402, AgentCore Payments, Pay.sh, and payment-token flows are separate rails that still need governance.

Flow
How it works
SatGate implication
Card checkout
Agent receives a temporary card credential and fills a merchant checkout.
Good for web purchases, but not request-native API monetization.
x402
API returns a 402 payment challenge for stablecoin settlement across supported chains and clients.
x402, AgentCore Payments, and Pay.sh still need SatGate authority checks and Evidence Pack receipts above the rail.
Shared payment token
Agent receives a payment token for a supported 402 machine-payment flow.
Rail-specific; treat it as a subpattern of paid-rail context that still needs governance.
paid-rail context
API returns a Lightning-backed 402 challenge and verifies proof before access.
paid-rail context can support request-native paid API access; SatGate governs the decision and receipt.
Policy-only 402 observation
SatGate records and evaluates payment challenges even when another rail completes payment.
Useful for audit, deny/allow rules, and spend governance.

Where SatGate fits in a 402 exchange

Agent requests

An agent calls a paid API, model endpoint, MCP tool, or dataset.

SatGate evaluates

Policy checks identity, scope, budget, route, tenant, and allowed payment rail.

402 is handled

SatGate can issue, observe, or audit a payment challenge depending on the route.

Access is governed

Only approved, scoped, metered, auditable access proceeds upstream.

L402 is a paid rail, not the governance layer

paid-rail context can carry payment proof: an API returns a 402 challenge, the agent or wallet client pays a Lightning invoice, and proof unlocks scoped access. SatGate evaluates the action before payment/access and records proof after the decision.

Other 402 rails still need policy

Stripe-style shared payment tokens, card credentials, and future payment protocols can help agents pay. They do not replace request-path controls for budget, scope, revocation, metering, receipts, or Evidence Pack proof.

FAQ

HTTP 402 for AI agents questions

What is HTTP 402 for AI agents?

HTTP 402 lets an API tell an AI agent that payment is required before access. The response can include a machine-readable challenge describing how to pay.

Is HTTP 402 the same as L402?

No. HTTP 402 is the status code. L402 is a Lightning-based payment and access pattern that uses HTTP 402. paid-rail context is one rail SatGate can govern in the request path.

How are Stripe shared payment tokens different from L402?

Stripe-style shared payment tokens are a payment-credential method for supported 402 flows. L402 uses Lightning payment proof to unlock scoped API access. They are separate rails.

Why do 402 payment challenges need policy?

A payment challenge tells the agent how to pay, but it does not decide whether the agent should be allowed to spend, which budget applies, whether the route is in scope, or how the event should feed the Evidence Pack.

Related guides

Govern paid agent access before execution

HTTP 402 can carry payment context. SatGate turns that context into governed action: authority, policy, budget, proof, and an Evidence Pack receipt for every paid request.