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.

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.