# Buying this product from an agent: integration guide

This page documents the exact request sequence, so an agent or its operator can decide whether the purchase is feasible before spending anything. Everything here is verifiable against the live endpoints.

## The sequence

```
GET https://makemoneyonlineaiagents.xyz/product
  -> 402 Payment Required
     PAYMENT-REQUIRED: <base64 x402 v2 challenge>
     body: {"x402Version":2,"resource":{...},"accepts":[{...}]}

GET https://makemoneyonlineaiagents.xyz/product
  PAYMENT-SIGNATURE: <base64 signed payload>
  -> 200 OK
     body: the JSON archive
     X-Product-SHA256, X-Order-Id, X-Recovery-Token, PAYMENT-RESPONSE
```

No account, no API key, no pre-registration. The second request is the same URL as the first.

## The payment terms

The `accepts[0]` object states scheme `exact`, network `eip155:8453` (Base mainnet), asset `0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913` (USDC), amount `5000000` (5 USDC at 6 decimals), and the recipient address. The `extra` field carries the EIP-712 domain, `name` `USD Coin` and `version` `2`, read from the deployed contract.

## Signing it

Any x402 v2 client that supports the exact-EVM scheme works. With the reference client:

```
import { x402Client } from '@x402/core/client';
import { ExactEvmScheme } from '@x402/evm/exact/client';

const client = new x402Client().register('eip155:8453', new ExactEvmScheme(account));
client.setSpendControls({ maxAmountPerPayment: '5' });
const signed = await client.createPaymentPayload(challenge);
```

The spend-control line matters: the reference client caps a single payment at $1 by default and will refuse a 5 USDC authorization until the limit is raised. That is the single most common reason a technically correct integration fails.

The buyer signs an EIP-3009 `transferWithAuthorization`. The facilitator submits the transaction and pays the gas, so **the buyer needs USDC but no ETH**.

## What you get

A JSON object with a `files` array. Each entry carries `path`, `encoding`, `bytes`, `sha256` and `content`. Verify the whole body against the `X-Product-SHA256` response header before use. See [the full contents](/contents).

## Failure modes, and what each means

- **400** — the signed terms do not match the challenge. Re-read the 402 and sign it exactly.
- **402 after signing** — the facilitator rejected the signature. Nothing was charged.
- **409** — this authorization is already in flight. Check the order; do not sign a new one.
- **410** — this purchase already completed its one download.
- **202** — settlement is unresolved. **Do not pay again.** Contact support with the order ID.
- **503** — checkout is disabled or temporarily unavailable. Nothing was charged.

## Interrupted downloads

A purchase includes one *completed* download. If the transfer dies mid-stream the purchase is not consumed: re-request with the `X-Order-Id` and `X-Recovery-Token` returned on the delivery response. Those headers arrive before the body, so capture them first.