Skip to content

PATTERN Cited by 1 source

Machine-native per-request payment

Intent

When an agent needs to pay for API usage / data access / per- request tool invocation, human-checkout-shaped payment flows are disqualifying: too slow, too much UX assumption, too much human-in-the-loop. This pattern composes an HTTP-native payment primitive (HTTP 402 / x402) with a stablecoin settlement rail so the payment fits inside the same API call that delivers the resource.

Canonicalised in the 2026-03-12 Stripe retrospective: "Agents also don't pay like humans. They might make thousands of small decisions a day and need low-latency, HTTP-native payments for pay-per-call or pay-per-task business models... With a few lines of code, you can use the PaymentIntents API to charge agents for things such as API usage, MCP calls, or HTTP requests."

Shape

Agent                                  Seller
  │                                      │
  │──── GET /resource ────────────────▶│
  │                                      │ (calls PaymentIntents
  │                                      │  with amount+currency)
  │                                      │
  │◀── 402 Payment Required ────────────│
  │    {deposit_address, amount,         │
  │     currency, expires_at}            │
  │                                      │
  │──── pay via stablecoin rail ───────▶│ (to deposit_address)
  │                                      │
  │──── GET /resource (w/ proof) ─────▶│
  │                                      │ (verifies settlement)
  │◀── 200 OK + resource ───────────────│

Five properties of the composition:

  1. In-band negotiation. Price is discovered at request time via 402 Payment Required, not via a separate pricing API or subscription registration.
  2. Per-transaction deposit address. The seller's payment provider generates a unique address per request (Stripe's PaymentIntents API does this); no persistent merchant-account setup per caller.
  3. Stablecoin settlement. Card-network economics fail at micropayment scale (fixed fees dwarf the amount); stablecoins (USDC on Base per Stripe's 2026-03-12 preview) settle programmatically in seconds with negligible fixed cost.
  4. HTTP-native, not session-native. No cookies, no state, no human redirect. Request → 402 → pay → retry → 200. Every agent request is self-contained.
  5. Vendor-backed settlement. The seller doesn't hold the stablecoin; a payment provider (Stripe) converts the settlement back into the seller's Stripe balance in the seller's currency of choice.

Canonical use cases (2026-03-12 Stripe disclosure)

  • Per API call: charging agents for inventory lookups, pricing queries, delivery-quote requests, pick-up-slot holds.
  • Per task: charging agents for fitment checks, bundle building, quote generation, replenishment orders.

Why human-checkout rails don't fit

  • Latency: a checkout session takes seconds-to-minutes; agents make "thousands of small decisions a day" and need payment to complete in the same RTT as the underlying API call.
  • Human assumptions: checkout UX expects a human confirmer, saved addresses, tax calculation for shipping. Per-request agent payments have none of these.
  • Fee economics: card-network fixed fees (30¢ per transaction) make $0.01 API calls non-viable; stablecoins let the fee scale with the amount.

Composition with checkout rails

This pattern does not replace agentic-commerce checkout. The two coexist:

  • Buy a dress on OpenAI's shopping surface → ACP + SPT + card-network settlement. Human buyer, human currency, human checkout semantics.
  • Pay an agent-gateway API per call → x402 + PaymentIntents + stablecoin. No human, no currency conversion, no checkout.

Different workloads → different rails → different primitives. Both are "agentic" but they solve structurally different problems — see concepts/machine-payment for the concept boundary.

Seen in

Last updated · 476 distilled / 1,218 read