> Source: [/docs/resources/guides/402-payment-required](https://tempo.xyz/developers/docs/resources/guides/402-payment-required.md) > Section: [Get Started](https://tempo.xyz/developers/get-started.md). Choose a starting point, send a test payment, get testnet funds, connect a coding agent, find the SDKs and CLI, and use the resource guides to plan payment workflows, liquidity, provider selection, and partner integrations. > [Documentation index](https://tempo.xyz/developers/llms.txt) · [Docs skill](https://tempo.xyz/developers/SKILL.md) > Tempo MCP: Use `search`, `find_pages`, `read_page`, and `code` at `https://mcp.tempo.xyz` for Tempo and related documentation. > If an indexed page is missing or reflects an older site, read this site’s [documentation index](https://tempo.xyz/developers/llms.txt) and Markdown pages directly. [Guides](https://tempo.xyz/developers/docs/resources/guides) / [Machine payment models](https://tempo.xyz/developers/docs/resources/guides#machine-payment-models) / HTTP 402 Payment Required # HTTP 402 Payment Required HTTP `402 Payment Required` is a status code that payment protocols use to request payment for a resource. The HTTP standard reserves the code without defining a payment flow. On Tempo, use [Machine Payments Protocol integrations](https://tempo.xyz/developers/docs/guide/machine-payments) to let applications and agents pay for APIs, datasets, or other digital resources inside the request flow. ## What HTTP 402 specifies The HTTP standard [reserves `402` for future use](https://www.rfc-editor.org/rfc/rfc9110.html#name-402-payment-required). It doesn't define a price, accepted asset, payment destination, proof format, or settlement rule. A payment protocol supplies those details. The [Machine Payments Protocol](https://mpp.dev/) (MPP) supplies a challenge, credential, and receipt flow. Payment methods define the authorization and settlement rules. Each endpoint advertises the methods, assets, and networks it accepts. ## Follow an MPP payment request | Stage | Client or server action | | --- | --- | | Request a resource | The application or agent sends its HTTP request. | | Receive a challenge | The server returns `402` with payment terms in `WWW-Authenticate: Payment`. | | Authorize payment | The client checks the terms against its budget and permissions, then creates a credential for a supported method. | | Retry with a credential | The client supplies payment authorization in `Authorization: Payment` by default, or the credential header selected by the challenge. | | Verify and respond | The server verifies the credential according to the payment method and returns the resource with a `Payment-Receipt`. | The [Payment authentication draft](https://paymentauth.org/draft-httpauth-payment-01.html#name-credentials) lets a challenge select `Payment-Authorization` instead of the default `Authorization` header. Keep payment credentials separate from any application authentication the endpoint requires. On Tempo, a credential can carry a signed transaction, a transaction reference, or a payment-channel voucher, depending on the intent. A voucher and an onchain transfer are different evidence. Follow the [MPP request flow](https://tempo.xyz/developers/docs/guide/machine-payments) and the selected method's verification rules. A valid payment doesn't authorize access to a particular customer's data. ## Choose a charge or a session Use [one-time payments](https://tempo.xyz/developers/docs/guide/machine-payments/one-time-payments) when each purchase has a distinct amount and delivery, such as a single dataset. The server verifies payment for that request before returning the resource. Use [pay-as-you-go sessions](https://tempo.xyz/developers/docs/guide/machine-payments/pay-as-you-go) for repeated usage against a funded channel. The payer signs cumulative offchain vouchers, and the recipient can settle authorized usage onchain. A session can require top-ups and periodic settlement. Use [streamed payments](https://tempo.xyz/developers/docs/guide/machine-payments/streamed-payments) when usage and delivery happen during a stream. The service meters billable units and checks the authorized voucher amount as it delivers them. Renewing a voucher increases authorized usage; adding funds to a channel is a separate operation. For fixed recurring charges, use the [subscription billing guide](https://tempo.xyz/developers/docs/resources/guides/subscriptions-on-tempo). Access keys constrain spending, while the application schedules charges and manages subscriptions. ## Bound what an agent can purchase Define the acceptable service, amount, asset, and network before allowing a client to answer payment challenges automatically. Use separate application budgets for a request or task and [access-key controls](https://tempo.xyz/developers/docs/accounts/access-keys) for the account authority delegated to the agent. An access key can limit token spending, permitted calls, and expiry. A key without bounds has none of those checks. A spending limit doesn't restrict destinations or services, and scopes check only the calls the key signs directly. Read the [scope limits](https://tempo.xyz/developers/docs/accounts/access-keys/scopes#scope-limits) before allowing a contract. For sessions, bound the amount deposited into channels and monitor outstanding channel funds. Authorized usage, channel deposits, settled funds, and the account's available balance are separate quantities. ## Handle payment retries and service delivery Give each billable operation an application record. Preserve its request identifier, payment evidence, delivered result, and refund or recovery status. If the server receives a retry, determine whether it belongs to an existing operation before treating it as a new purchase. Don't send another payment because a request timed out. Inspect the existing request and payment state first. For direct onchain payments, use the [receiving guide](https://tempo.xyz/developers/docs/guide/payments/accept-a-payment) to verify the network, token, intended recipient, amount, and delivered transfer. A successful transaction can still leave the funds held by a receive policy. An MPP receipt covers payment, not delivery. Track whether your application delivered the purchased resource, how the customer can retrieve an existing result, and how failed delivery is resolved. ## Test a payment-gated endpoint :::steps ### Configure the server's payment terms Follow the [MPP server guide](https://tempo.xyz/developers/docs/guide/machine-payments/server) to set the server secret, recipient, supported method, currency, and network. Choose which requests or units are billable. ### Fund a compatible client Follow the [MPP client guide](https://tempo.xyz/developers/docs/guide/machine-payments/client). Match the client's network and asset to the server's challenge. Testnet faucet tokens cannot pay a mainnet challenge. ### Exercise the complete request flow Check the unpaid challenge, successful payment, receipt, and delivered resource. Exercise repeated requests, insufficient funds, exceeded budgets, and interrupted responses before enabling unattended purchases. ::: ## HTTP 402 questions ### Does every browser or agent automatically pay a 402 response? No. The client needs a compatible payment method, a funded account, and authority to spend. An ordinary HTTP client can receive the response without acting on it. ### Does HTTP 402 require stablecoins? No. The status code does not select a payment rail. MPP supports multiple payment methods, and the Tempo method is one of them. ### Is every service unit a separate onchain transaction? Not with payment sessions. Signed vouchers account for cumulative usage between onchain settlements. Retain usage and voucher records alongside settlement records. See [microtransaction billing](https://tempo.xyz/developers/docs/resources/guides/microtransactions).