HTTP Payments

OpenPermit treats x402 protocol challenges, MPP protocol challenges, and OpenPermit onchain contract 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.

For generic agent commerce, OpenPermit should first check smart-account readiness and create a continuation only when the mandate, delegation, payee, token, and chain scope are ready:

const readiness = await openpermit.checkAgentCommerceReadiness({
	mandateId: 'mandate_...',
	storefrontUrl: 'https://storefront.example',
	sellerId: 'seller_...',
	resourceId: 'storefront:checkout',
	paymentChallenge: 'x402',
	paymentMode: 'metamaskErc7715',
	chain: 'eip155:10143',
	asset: 'USDC',
	payTo: '0xSellerPayTo...',
	tokenAddress: '0xUsdcToken...',
	tokenDecimals: 6,
	tokenName: 'USDC',
	tokenVersion: '2',
});

if (readiness.status === 'ready') {
	await openpermit.createAgentCommerceContinuation(readiness.scope);
}

The buyer SDK also supports direct paid fetches for agents that can run SDK code:

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.

Header behavior:

• x402 challenges use PAYMENT-REQUIRED; retries use PAYMENT-SIGNATURE; settlement responses can include PAYMENT-RESPONSE. The signature can be produced by a manual EIP-3009 wallet-signed flow or by OpenPermit's smart-account x402 path when readiness is satisfied.
• MPP challenges use WWW-Authenticate: Payment id="...", realm="...", method="...", intent="...", request="..."; retries use Authorization: Payment <credential>.
• OpenPermit onchain challenges use OPENPERMIT-ONCHAIN-PAYMENT; retries use OPENPERMIT-ONCHAIN-SETTLEMENT.

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.