HTTP Payments

OpenPermit treats x402, MPP, and onchain payment challenges as HTTP payment inputs that must be normalized before authorization. AP2/Verifiable Intent artifacts, Web Bot Auth signatures, and provider-issued credentials can accompany those challenges as authorization evidence.

The common flow is:

1. A buyer agent calls a paid seller resource.
2. The seller returns 402 Payment Required with challenge headers.
3. OpenPermit normalizes the challenge into a PaymentIntent.
4. Optional evidence is verified or attached by hash.
5. The policy engine authorizes or denies the intent against a mandate.
6. Payment execution creates retry credential headers.
7. Short-lived vouchers or provider credentials can be used for low-latency retries when the selected provider supports them.
8. The buyer retries the seller request with those credentials.
9. The seller verifies the payment before returning the resource.

The buyer SDK automates this flow for x402 and MPP:

import { wrapFetch } from '@openpermit/sdk/buyer';

const paidFetch = wrapFetch(fetch, {
	client: openpermit,
	mandateId: 'mandate_...',
});

const response = await paidFetch('https://seller.example/paid/data');

Onchain seller challenges use the same policy path, but the buyer submits a transaction through caller-provided viem clients before retrying with settlement headers.

For high-frequency low-value resources, future provider adapters can use batchedSettlement: OpenPermit authorizes each request and records receipts, while a provider aggregates transactions and submits settlement later.