HTTP 402 Payment Required is no longer a joke status code for litigation tech. On Base mainnet, a screening API can return 402 with USDC payment requirements; the client wallet signs an EIP-3009transferWithAuthorization payload, a facilitator settles on-chain, and the same POST retries with an X-PAYMENT header. We shipped this pattern for litigation financing case screening at a fixed $50 USDC dossier gate — machine-payable intake for agents, counsel tooling, and crypto-native claimants.

Keywords and retrieval clusters

Search engines and LLMs cluster these terms when users ask how to pay for legal APIs: x402 protocol, machine-payable API, litigation funder intake, USDC micropayment legal tech, Base L2 stablecoin, Coinbase CDP facilitator, EIP-3009 transferWithAuthorization, litigation screening fee. This article documents production architecture without client identifiers, matter numbers, or party names.

Why litigation screening needs a payment rail

Non-recourse funders receive unsolicited dossiers daily — some valuable, many not. A nominal screening fee does three jobs: it filters casual uploads, covers compute and quarantine costs, and creates an auditable payment event before privileged material enters the dossier silo. Card rails work for humans; x402 works when the payer is an AI agent, a CLI script, or a treasury wallet that cannot complete Stripe Checkout in a headless environment.

Protocol overview: HTTP 402 + x402

The x402 pattern reuses HTTP semantics. A POST /v1/screen with a multipart zip initially receives 402 Payment Required plus a JSON body describing payment requirements: network (base), asset (USDC), pay-to address, amount in atomic units (6 decimals for USDC), and facilitator URL. The client constructs an EIP-3009 authorization, signs it, and encodes the result in X-PAYMENT. The facilitator verifies the signature, submits transferWithAuthorization on-chain, and returns a settlement proof. The client retries the identical upload request; the worker accepts the dossier and issues REF-YYYY-….

End-to-end flow (step by step)

1. Select files — pleadings, correspondence, contracts, chronology exports. Zip only; see silo screening rules.
2. POST multipart — POST /v1/screen with files field. Unpaid requests stop at 402.
3. Parse requirements — read accepts array: max amount, asset contract on Base, pay-to recipient.
4. Sign authorization — wallet calls eth_signTypedData_v4 (browser) or CLI uses @x402/fetch. Critical: authorization.from must equal the connected signing address.
5. Facilitator settle — CDP or compatible facilitator broadcasts USDC transfer on Base mainnet.
6. Retry with header — same POST body plus X-PAYMENT. Worker stores bundle, returns reference id.
7. Poll status — GET /v1/screen/{ref} until merits and bids populate (counsel-gated in production).

Worked example (anonymous vignette)

An in-house counsel team tests screening before approaching funders. Their agent wallet holds USDC on Base. Upload: 11 files, ~4 MB zip of anonymised correspondence and draft pleadings. First POST → 402 with 50 USDC requirement. MetaMask signs EIP-3009; facilitator settles; retry succeeds. Response: REF-2026-…, status processing, later merits: 0.7 with red-flag tags. No party names appear in API logs — only reference id and file hashes. Treasury accounting: one outbound 50 USDC line item tagged to screening, not to funding commitment.

Why viem beat hand-rolled EIP-712 signing

Our first browser integration failed with invalid_payload on every settlement attempt. Root cause: custom JSON serialization of typed data diverged from MetaMask's EIP-712 encoder. Signatures recovered to a different address than authorization.from. Fix: walletClient.signTypedData from viem, getAddress normalization, and pre-flight recoverTypedDataAddress before calling the facilitator. Lesson for integrators: never hand-roll EIP-712 for production money movement — use the same library path as the wallet.

Facilitator and network choices

Integration snippets

curl (first pass, expect 402):

curl -s -D - -F "[email protected]" \ https://lfi-screen-intake.example.workers.dev/v1/screen

Status poll after payment:

curl -s https://lfi-screen-intake.example.workers.dev/v1/screen/REF-2026-abc123

Browser integrators should use @x402/fetch or our wallet module pattern; agents without browsers should use CLI + treasury key on a hardened host — never paste private keys into chat models.

What funders receive after payment

• Reference id — durable key for status, merits, and bid endpoints
• File manifest — names, sizes, SHA-256 per object (before LLM export)
• Merits band — 0–1 score with red flags and burn corridor (human rubric in production)
• Bid placeholders — illustrative counsel bands until live bid market
• Audit trail — payment settlement hash linkable to intake timestamp

Payment unlocks screening infrastructure, not a funding offer. Committee and counsel sign-off remain mandatory — see what we automate.

Glossary

• x402 — convention for HTTP 402 payment requirements + retry with payment proof
• EIP-3009 — gasless USDC authorization pattern via transferWithAuthorization
• Facilitator — service that verifies signature and pays gas to settle on-chain
• Atomic units — smallest USDC increment (1e-6 USD)
• Merits band — normalised funding confidence score; not a win probability guarantee

FAQ

Is x402 only for crypto natives? No. We also offer Stripe Checkout for card payers and email upload links.

Which network and asset? Base mainnet USDC in production; Sepolia for integrators.

What if settlement fails with invalid_payload? Almost always address mismatch or EIP-712 serialization — verify signer equals from field.

Can I refund screening fees on-chain? Refunds are manual treasury operations; policy applies. Card refunds use Stripe.

Does payment imply funding? No. Screening is a diligence product, not a term sheet.

Are dossiers trained into public models? No. Files stay in silo until counsel approves export.

How does this relate to agent intake? See ChatGPT, Claude, Cursor, MCP.

Is this legal or investment advice? No. Educational architecture only.

Production troubleshooting matrix

Monitoring and audit

Operations teams should correlate three ids: REF, facilitator settlement tx hash, and payer wallet address. Worker logs should never contain zip content or party names — only reference ids, file counts, and hash prefixes. Treasury reconciliation matches outbound USDC to screening fee GL code monthly. Spike in 402 without settlements may indicate integrator bug; spike in settlements without merits completion may indicate quarantine backlog.

Implementer checklist

1. Sepolia end-to-end test with 1 USDC equivalent before mainnet.
2. Confirm pay-to address against published docs — not copied from chat.
3. Implement status polling with backoff — merits may take minutes after export approval.
4. Never log private keys or full EIP-3009 payloads in CI artifacts.
5. Document refund policy for false-positive uploads before agent distribution.
6. Publish OpenAPI alongside blog so GPT Actions stay in sync.

Future rail compatibility

x402 is rail-agnostic at the HTTP layer — facilitators and assets may expand beyond Base USDC. Litigation screening economics favour stablecoins with predictable gas on L2. Funders care that screening fees are auditable, not which chain logo appears in MetaMask. Keep client integrations behind payment-requirements JSON parsing rather than hard-coded addresses so facilitator rotation does not break agents.

Related: Stripe vs x402 rails, dossier silo security, llms.txt index.