x402 test mode

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

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

{
  "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. 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 — the 402 envelope and payment_required code.
• Deliverability & karma — the other half of anti-abuse.
• Rate limits & quotas — the published caps.