Machine Inbox raw HTTP 402 flow (x402 v2, USDC on Base mainnet)

The same POST that accepts Stripe MPP also accepts x402. The unpaid 402
carries both challenges; this file shows the x402 side on the wire.

1. Request an inbox without payment. x402 purchases require an
   Idempotency-Key. Choose a high-entropy value and treat it as a secret:
   it authorizes idempotent replays of the purchase.

     curl -i -X POST https://machineinbox.com/api/v1/inboxes \
       -H "Idempotency-Key: $(openssl rand -hex 16)"

   The response is HTTP 402 with a base64 PAYMENT-REQUIRED header. Decoded,
   it is an x402 v2 PaymentRequired object:

     {
       "x402Version": 2,
       "accepts": [{
         "scheme": "exact",
         "network": "eip155:8453",
         "asset": "0x8335...2913",        // USDC on Base mainnet
         "amount": "2000000",             // $2.00 in 6-decimal units
         "payTo": "0x735d...4b38",
         "resource": "https://machineinbox.com/api/v1/inboxes",
         ...
       }]
     }

   Before signing, verify the resource URL is https://machineinbox.com and
   the amount is 2000000 ($2.00) for the inbox or 1000000 ($1.00) for an
   extension. Reject anything else.

2. Sign the payment with an x402 client library (for example @x402/fetch
   with @x402/evm). The wallet signs an EIP-3009 USDC authorization;
   settlement runs through the PayAI facilitator and Machine Inbox never
   holds your keys.

3. Retry the identical request with the base64 payment payload and the same
   Idempotency-Key:

     curl -i -X POST https://machineinbox.com/api/v1/inboxes \
       -H "Idempotency-Key: <same key>" \
       -H "PAYMENT-SIGNATURE: <base64 signed payment>"

   A successful response is HTTP 201 with a PAYMENT-RESPONSE header carrying
   the settlement receipt and a JSON body containing inbox.id, inbox.address,
   inbox.expiresAt, and token (mi_live_...). The token is shown only in this
   response; store it now.

4. If the retry returns HTTP 503 payment_activation_pending, the payment
   settled and activation is being recorded. If it returns HTTP 409
   payment_in_progress, another request (usually the recovery queue) holds
   the activation claim. Both are transient: wait Retry-After seconds and
   retry with the same Idempotency-Key; do not start a new purchase. A
   retry never charges twice - an unfinished payment attempt is cancelled
   unused, and once activation completes the same key returns the inbox.

Notes

  - The thirty-day pro_inbox tier sells over x402 at its own path: POST
    /api/v1/inboxes/pro for $5.00 (amount 5000000), same flow, empty body.
    See raw-402-flow.txt for the Stripe MPP side.
  - The one-hour verification_inbox tier: POST /api/v1/inboxes/verification
    for $0.05 (amount 50000), same flow, empty body. Card buyers pay $0.50
    via Stripe MPP on /api/v1/inboxes instead (Stripe's minimum charge).
  - Extension: POST /api/v1/inboxes/{inboxId}/extend works the same way for
    $1.00, with the mailbox token in X-Mailbox-Token.
  - On-chain settlement records on Base are public even after the mailbox
    is erased.

Everything after purchase uses the bearer token; see read-reply-loop.ts or
read_reply_loop.py. A runnable buyer client is create-inbox-x402.ts.