Skip to content

Agentic Payments Made Easy

Payment is the
authentication.

An open standard for API & agentic payments using HTTP 402 and Stripe. No signup. No API keys. No OAuth. Just pay and use — AI agents pay for APIs on their first request, no human in the loop.

server.ts
import { paymentRequired } from '@stripe402/express'

// One middleware. $0.01 per request.
app.use('/api/weather', paymentRequired({ price: 100 }))

Overview

The 402 status code, finally realized.

Reserved since 1997 for 'Payment Required' but never standardized. stripe402 puts it to work — a machine-readable payment protocol between clients and servers, powered by credit cards.

Zero signup

No registration, no API keys, no OAuth. Identity is derived from the card fingerprint via HMAC — same card always produces the same identity.

Credit card rails

Built on Stripe and the payment infrastructure 99% of the internet already uses. No crypto wallets, no stablecoins, no bridging.

Agent-native

Pre-authorize a card and let your AI agent pay for any API on its first request. No human-in-the-loop needed for provisioning.


Protocol

Five steps. Fully automatic.

After the first payment, subsequent requests re-use the client ID until the balance runs out.

1

Client requests a paid resource

GET /api/weather HTTP/1.1
2

Server responds 402 with payment details

HTTP/1.1 402 Payment Required
payment-required: eyJwcmljZSI6MTAwLCJtaW5Ub3BVcCI6NTAwMDAuLi59
3

Client tokenizes card via Stripe and retries

GET /api/weather HTTP/1.1
payment: eyJwYXltZW50TWV0aG9kSWQiOiJwbV8uLi4iLCJ0b3BVcCI6NTAwMDB9
4

Server charges card, returns client ID and balance

HTTP/1.1 200 OK
payment-response: eyJjbGllbnRJZCI6ImM4YTJlLi4uIiwiY3JlZGl0c1JlbWFpbmluZyI6NDk5MDB9
5

Subsequent requests include the client ID

GET /api/weather HTTP/1.1
payment: eyJjbGllbnRJZCI6ImM4YTJlLi4uIn0=

Micropayments

Sub-cent pricing, without the fee problem.

Stripe charges $0.30 + 2.9% per transaction with a $0.50 minimum. stripe402 batches charges into credit top-ups, making per-request pricing at fractions of a cent economically viable.

Credits system

Unit
1/10,000 of a dollar (1 basis point)
Example
100 units = $0.01 per request
Top-up
$5.00 = 50,000 units = 500 requests at $0.01
Storage
Redis (Lua atomics) or PostgreSQL (WHERE clause)

Client identity

HMAC-SHA256(card_fingerprint, server_secret)
  • Deterministic — same card on the same server always produces the same ID
  • Private — the card fingerprint cannot be recovered from the client ID
  • Isolated — different servers produce different IDs for the same card

Comparison

Familiar payment rails, modern protocol.

How stripe402 stacks up against traditional API monetization and crypto-native alternatives.

This project

stripe402

Traditional

API Keys + Billing

Crypto-native

x402 (USDC)

User onboarding
None — just a card
Account + API key
Crypto wallet + USDC
Payment rail
Stripe (credit cards)
Invoicing / subscription
On-chain stablecoin
State model
Stateful (credits)
Stateful (user DB)
Stateless (per-tx)
Micropayments
Via credit top-ups
Not viable
Native
Agent-friendly
Pre-authorized card
Manual provisioning
Wallet signing
Regulatory burden
Low
Low
High (crypto)
Adoption barrier
Low (any card)
Medium (signup)
High (wallet + tokens)

Trade-offs

What you should know.

No protocol is perfect. stripe402 optimizes for low adoption friction at the cost of statefulness.

Strengths

  • Uses credit cards — the existing payment rail for 99% of the internet
  • Zero adoption barrier for end users
  • Self-describing protocol — the 402 response tells clients exactly what to pay and how
  • AI agents can pay for APIs autonomously on their first request
  • Low regulatory complexity compared to crypto-based alternatives

Limitations

  • Stateful — server maintains credit balances (vs. x402's stateless on-chain settlement)
  • 3D Secure — EU cards may require interactive authentication, breaking headless flows
  • $0.50 minimum charge — top-ups should be $5+ for efficiency
  • PCI scope — server-side tokenization requires SAQ-D; browser-based Stripe.js keeps you at SAQ-A
  • Single currency — one currency per route (for now)

Packages

Install only what you need.

@stripe402/coreSharedProtocol types, constants, base64 encoding/decoding, HMAC identity derivation, error classes. Zero dependencies.
@stripe402/serverServerStripe integration, payment processing, persistence stores for Redis and PostgreSQL.
@stripe402/expressServerExpress middleware — add 402 payment gating to any route with a single function call.
@stripe402/client-fetchClientFetch wrapper that automatically handles 402 responses, tokenizes the card, and caches the client ID.
@stripe402/client-axiosClientAxios interceptor that transparently handles 402 responses.
# server
npm install @stripe402/express

# client (pick one)
npm install @stripe402/client-fetch
npm install @stripe402/client-axios

Quick start

Running in under a minute.

Server

import express from 'express'
import { paymentRequired } from '@stripe402/express'

const app = express()

app.get('/api/weather',
  paymentRequired({ price: 100 }),
  (req, res) => res.json({ temp: 72 })
)

Client

import { wrapFetch } from '@stripe402/client-fetch'

const paidFetch = wrapFetch(fetch, {
  paymentMethodId: 'pm_...'
})

const res = await paidFetch(
  'https://api.example.com/weather'
)

FAQ

Common questions.

x402 uses cryptocurrency (USDC on various blockchains) for stateless per-request payments. stripe402 uses traditional credit cards via Stripe with a credits-based system. The protocol flow is similar, but stripe402 requires only a credit card — no crypto wallet or stablecoins.
Prices are in units where 1 unit = 1/10,000 of a dollar. 100 units = $0.01, 10,000 units = $1.00. Clients top up their balance in larger amounts (recommended $5+) and spend credits per-request.
stripe402 is in its early stages. The core protocol and packages are functional and tested, but should be evaluated carefully for production use. Contributions and feedback are welcome on GitHub.
Browser-based Stripe.js tokenization keeps you at PCI SAQ-A (22 requirements). Server-side tokenization requires SAQ-D (300+ requirements). The recommended path for browser clients is always Stripe.js.
Redis (using Lua scripts for atomic operations) and PostgreSQL (using WHERE clauses for atomic balance deduction). You can also implement a custom store via the persistence interface.
Yes — this is a primary use case. An AI agent pre-authorized with a Stripe PaymentMethod ID can autonomously pay for any stripe402-enabled API on its first request.
Some EU cards require interactive browser-based 3D Secure authentication, which can break headless flows. For fully autonomous agent use, cards that don't require SCA are recommended.