> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fade.finance/llms.txt
> Use this file to discover all available pages before exploring further.

# Any HTTP service

> Behind an x402 gateway, one paid HTTP request opens a payout. No Solana SDK, no wallet, no SOL on the caller's side.

## The pattern

Payment services, game servers and backends on other chains already speak HTTP. An **x402 gateway** lets them use Fade with one request.

x402 turns a payment into a step of an HTTP request: the server answers `402 Payment Required` with what it wants paid, the client pays in a stablecoin and retries with proof of payment, and the server serves the request.

```http theme={null}
POST /wager
Content-Type: application/json

{ "paytable": "win-back-1-in-100", "amount": "1.00", "beneficiary": "<USDC account>" }

← 402 Payment Required        (pay 1.00 USDC to the gateway)
→ POST /wager  + payment proof
← 201 Created
  { "wager": "9xQe…kP4d" }
```

The gateway is an app like any other. On a paid request it:

1. checks the payment;
2. opens the Fade wager with itself as `integratorAuthority`, `payer` and `stakeOwner`, staking from its own USDC account, with the caller's account as `beneficiary`;
3. hands the wager to a keeper, or settles it itself;
4. returns the wager address, which the caller can follow on-chain or through the keeper API.

Nothing changes in the protocol. The gateway chooses which paytables it offers, sets its own fee, and is accountable for its own service to its callers.

## What it unlocks

Any service that can make an HTTP request can offer a fixed-odds payout: a checkout backend, a web2 game studio, a payment API, a server on another chain. The caller needs no Solana SDK, no wallet and no SOL. This is also the cheapest way to add the [checkout](/use-cases/checkout-win-back) and [rewards](/use-cases/rewards) use cases to an existing payment flow.

## Design notes for a gateway

* **Simulate before you answer 402.** Build the `open_wager` transaction for the requested paytable and simulate it against the current pool. If it would be refused (for example `PerWagerCap` on a pool that cannot back the prize yet), say so before taking payment. See [Errors](/build/errors).
* **Pin the paytables.** Offer named paytables you have checked, rather than accepting arbitrary ones from callers.
* **Return the wager address immediately.** The draw resolves a few seconds later; let callers poll the keeper's `GET /v1/wagers/:address` or watch the chain.
* **Keep the payment and the wager linked.** Store the payment reference against the wager address, so a caller can verify what applied.

## What not to build

Agents spending their users' money on games of chance are a poor product and a regulatory risk. The gateway pattern is for servers and services that offer a payout to their own users.

<Warning>
  Prize-linked payouts are subject to local gaming and promotion law. A gateway inherits the legal nature of the use behind it: a merchant promotion, a reward, or a game.
</Warning>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.