Legal tech intake needs two payment personas: humans with cards and AI agents with wallets. We run Stripe Checkout and USDC x402 against the same screening worker — different front doors, identical REF lifecycle, same dossier silo and merits API. This article compares rails for litigation financing screening so product and engineering teams pick the right path per payer — not per feature tier.
Keywords: Stripe legal payments, x402 comparison, litigation screening fee, agent commerce
Users search: Stripe for legal tech, x402 vs Stripe API payment, litigation screening $50 fee, AI agent pay for API, USDC legal intake. We map those queries to concrete flows below.
Why two rails instead of one
A single Stripe-only product blocks headless agents that hold USDC treasuries. A single crypto-only product blocks claimants who will never connect MetaMask. Litigation financing sits at the intersection: human claimants, in-house counsel, fund ops teams, and increasingly autonomous agents orchestrating diligence. Price parity across rails avoids creating a "crypto discount" that would skew underwriting samples.
Comparison matrix
| Rail | Payer | Flow | Best for |
|---|---|---|---|
| Stripe Checkout | Human, card, Apple Pay | POST checkout → pay → magic-link email → browser upload | Claimants, in-house counsel, ChatGPT users without wallets |
| x402 USDC | MetaMask, agent treasury, CLI | 402 → sign EIP-3009 → retry POST with X-PAYMENT | Cursor agents, crypto-native funds, batch screening scripts |
Stripe flow (step by step)
- Client calls
POST /api/checkout(or opens hosted pricing link). - User completes Stripe Checkout — card, Apple Pay, or local methods per Stripe config.
- Webhook confirms payment; worker issues upload session token.
- Email delivers magic link to browser upload UI.
- User uploads zip; worker returns
REF-YYYY-…. - Agent or user polls
GET /v1/screen/{ref}for merits.
Stripe path never requires wallet software. It is the recommended handoff when ChatGPT or Claude orchestrates screening but cannot sign EIP-3009.
x402 flow (step by step)
- Client
POST /v1/screenwith multipart zip. - Worker responds 402 + USDC requirements on Base.
- Wallet or CLI signs authorization; facilitator settles on-chain.
- Client retries POST with
X-PAYMENTheader. - Same
REFand merits pipeline as Stripe.
Technical depth: x402 on Base mainnet.
Price parity and accounting
Both rails gate at $50 per dossier screening (currency equivalent on Stripe). Same merits API, same status endpoint — choose rail by who pays, not by service tier. Finance teams should tag both as screening fees, distinct from success fees or funding draws. On-chain settlements produce tx hashes; Stripe produces payment intent ids — both linkable to REF in audit logs.
Agent limitation (ChatGPT / Claude)
Consumer GPT and Claude cannot sign on-chain authorizations today. Recommended pattern: agent creates Stripe checkout URL → user pays in browser → user follows upload email → agent polls status via API key or MCP. Never instruct users to paste seed phrases or private keys into chat. For Cursor and CLI workflows with treasury wallets, x402 is preferred.
Refunds and reversals
Stripe refunds flow through dashboard or API per policy. USDC refunds require manual treasury send — there is no card-network chargeback path. Communicate this in agent system prompts so users know crypto screening fees are policy-governed, not instant-click refundable.
Anonymous vignette
Team A: in-house counsel, no crypto. Stripe checkout from homepage → upload 9 pleadings → REF issued → merits 0.62. Team B: fund ops agent with Base USDC treasury → x402 CLI → 11 files → same merits endpoint shape. Funder comparing both refs sees identical JSON schema; only payment rail metadata differs. No client names stored in comparison memo.
Security and compliance notes
- Both rails hit identical zip quarantine — payment does not skip malware screening.
- PCI scope stays with Stripe; worker never sees card numbers.
- Crypto rail shifts custody risk to payer wallet — treasury ops must secure keys.
- Neither rail constitutes legal advice or funding commitment.
Glossary
- Magic link — time-limited upload URL after Stripe payment
- Payment intent — Stripe object tracking checkout state
- x402 — HTTP 402 payment required convention for APIs
- Price parity — same screening fee regardless of rail
FAQ
Same merits quality on both rails? Yes — identical pipeline after upload.
Can agents use Stripe headlessly? User must complete checkout in browser once.
Refunds? Policy-based; crypto refunds manual from treasury.
Testnet? x402 on Base Sepolia; Stripe test mode keys.
Which rail for widest reach? Stripe first in docs; x402 for crypto agents.
EU PSD2 analysis? Out of scope — product comparison only.
Corporate invoicing? Contact team for volume arrangements.
Choosing a rail: decision tree
- Payer has MetaMask or treasury CLI on secured host? → x402.
- Payer is consumer GPT user without wallet? → Stripe handoff.
- Batch screening 20+ dossiers programmatically? → x402 with rate awareness.
- Need chargeback/dispute path familiar to finance? → Stripe.
- Regulatory reporting requires fiat trail? → Stripe primary, x402 supplementary.
Webhook and reconciliation
Stripe path: checkout.session.completed webhook unlocks upload session — monitor webhook failures aggressively; paid users without upload links generate support debt. x402 path: facilitator callback or on-chain confirmation — reconcile tx hash to REF in worker KV. Both should appear in monthly screening revenue report with rail dimension.
UX copy agents should use
When presenting payment choice: "Screening costs $50. Pay by card (Stripe) or USDC on Base (x402). Payment starts analysis — not funding approval. Upload privileged files only via official link after payment."
Related: x402 technical guide, agent intake, llms.txt.