# x402 test mode

{/* // 402, THEN SETTLE */}

Postern speaks **x402** — the HTTP-native "pay to proceed" pattern. A paid action answers `402 Payment
Required`; the agent signs a payment authorization and retries; the server verifies and settles before
provisioning. In V1 this runs in **test mode on Base Sepolia testnet**, so you can wire and exercise
the entire paid path before any real money moves.
**Free early access — payment is optional in V1:** Early-access enrollment keys provision **without any payment**. x402 test mode coexists so you can
  build the paid flow against the real challenge/settle handshake today. A config flag flips to
  mainnet (a CDP facilitator) later.

## The flow

1. **Request a paid action.** For example `POST /v1/inboxes` (or a `/v1/purchase` endpoint) for an org
   with paid provisioning enabled.

2. **Get `402` with a challenge.** The response carries a `PAYMENT-REQUIRED` header describing the
   amount, asset, network, and pay-to details. 402 Payment Required

3. **Sign an EIP-3009 authorization.** The agent signs a `transferWithAuthorization` for the quoted
   amount on Base Sepolia (CAIP-2 `eip155:84532`).

4. **Retry with the payment.** Re-send the request with the signed payload attached.

5. **Server verifies + settles.** Postern verifies and settles via the signup-free facilitator at
   `https://x402.org/facilitator`.

6. **Provisioning runs on settlement.** **The action is gated on settlement confirmation — not on
   receipt of the signed payload.** Once settled, the mailbox is created and returned. settlement-gated

## The 402 challenge

```http title="402 response"
HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: network=eip155:84532; asset=USDC; amount=5000000;
  pay_to=0xFacilitator…; resource=mailboxes:5; facilitator=https://x402.org/facilitator
Content-Type: application/json
```

```json
{
  "error": {
    "code": "payment_required",
    "message": "Paid action. Sign the EIP-3009 authorization and retry."
  },
  "payment": {
    "network": "eip155:84532",
    "asset": "USDC",
    "amount": "5000000",
    "resource": "mailboxes:5",
    "facilitator": "https://x402.org/facilitator"
  }
}
```

In the SDK this surfaces as a `PaymentRequiredError` with the challenge on `err.paymentRequired`, so
your client can sign and retry programmatically.

## Why payments are also anti-abuse

x402 spend is the **economic** half of Postern's abuse story, alongside the
[karma and ramping caps](https://docs.agents.mszazu.com/concepts/deliverability-and-karma/). Making bulk provisioning cost something
— even a tiny testnet amount — prices out the "spin up 10,000 throwaway inboxes" attack without
punishing a legitimate agent that needs a handful. The capability model bounds *who* can provision;
x402 bounds *how cheaply* abuse scales.

## Test-mode specifics

| Aspect | V1 (test mode) |
|---|---|
| Network | Base Sepolia testnet — CAIP-2 `eip155:84532` |
| Asset | testnet USDC |
| Facilitator | signup-free `https://x402.org/facilitator` |
| Authorization | EIP-3009 `transferWithAuthorization` |
| Gating | provisioning waits for **settlement confirmation** |
| Mainnet | deferred — a config flag flips to a CDP facilitator later |
**Deferred to a later release:** Real-money / mainnet x402 and production billing are out of V1 scope. The test-mode handshake is
  complete and stable so the mainnet flip is a config change, not a rewrite.

## Next

- [Errors](https://docs.agents.mszazu.com/api/errors/) — the `402` envelope and `payment_required` code.
- [Deliverability & karma](https://docs.agents.mszazu.com/concepts/deliverability-and-karma/) — the other half of anti-abuse.
- [Rate limits & quotas](https://docs.agents.mszazu.com/operating/limits/) — the published caps.