Payment Required for robot customers

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 should be allowed to pay, access, and continue.

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, L402 Lightning invoices, or future protocols. But the payment challenge is not the governance layer.

SatGate sits before upstream access and applies policy: identify the agent, 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 budget?
Should policy require human approval?
Is this L402 Charge, shared payment token, or another rail?
What should be audited before forwarding?

HTTP 402 flow types

Treat 402 as a protocol surface, not a single payment system. SatGate Charge is L402 Lightning; other 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.
Shared payment token
Agent receives a payment token for a supported 402 machine-payment flow.
Rail-specific; separate from SatGate Charge/L402.
L402 Lightning
API returns a Lightning-backed 402 challenge and verifies proof before access.
SatGate Charge uses this for robot-customer API monetization.
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 SatGate Charge

SatGate Charge uses L402 Lightning: an API returns a 402 challenge, the agent pays a Lightning invoice, and payment proof unlocks scoped access. This is SatGate's robot-customer monetization rail.

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, or audit.

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. SatGate Charge uses L402 Lightning.

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 be audited.

Related guides

Make 402 programmable, governed, and auditable

SatGate gives API teams the economic firewall for agent-native payments: Observe every 402 and paid request, Control who may spend, and Charge with L402 Lightning when APIs become robot-customer products.