Payment And Execution Modes

PubFi has separate caller entry modes, but it does not maintain separate financial authorities for each mode. PubFi owns route execution and product presentation. Quantro owns the provider-neutral commercial, settlement, allocation, and receipt facts behind those product surfaces.

Mode Comparison

The free starter allocation is not Credits. PubFi uses Credits only for eligible, purchase-origin request_count units. Credits are service units, not money, a stored-value wallet, or a transferable token.

HTTP Lane Selection

For an x402-enabled gateway route: An invalid API key never falls back to x402. An x402 authorization never falls back to Credits. One request cannot debit both modes.

MCP Lane Selection

pubfi.route.execute has the same two mutually exclusive authorities:
  • API-key transport auth selects the registered account/allocation lane.
  • params._meta["x402/payment"] selects the accountless x402 lane.
  • Sending both is a conflict.
  • Sending neither on an eligible paid route returns an MCP CallToolResult payment requirement.
The bounded _meta object can contain unrelated MCP metadata. Only the x402/payment entry carries payment and selects the x402 lane. MCP is a transport adapter over the same route execution and x402 settlement owners as HTTP. It does not create a separate balance, ledger, provider route, or commercial authority.

Current x402 Scope

Current public runtime evidence supports a bounded x402 V2 exact lane on eligible Registry v2 routes with:
  • Base Sepolia network eip155:84532;
  • canonical Base Sepolia test USDC;
  • EIP-3009 authorization;
  • fixed terms known before provider execution;
  • non-streaming, bounded responses; and
  • standard PAYMENT-REQUIRED, PAYMENT-SIGNATURE, and PAYMENT-RESPONSE headers;
  • the official Signed Offers & Receipts extension with Ed25519 did:web verification; and
  • the official MCP x402/payment and x402/payment-response metadata flow.
The production PubFi API origin currently uses a testnet payment rail. Base Sepolia USDC has no financial value. PubFi does not currently publish a Base mainnet x402 payment route. Use the current 402 challenge as the payment-term authority. Do not hard-code a price, payee, timeout, or route from documentation.

x402 Settlement And Replay

PubFi binds the wallet authorization to the exact method, resource, request, and active route. Before provider I/O, PubFi creates a durable execution fence. Only a validated, bounded provider success can be staged for settlement. PubFi returns the staged response only after settlement converges. A successful response includes PAYMENT-RESPONSE. Replaying the exact signed request returns the same staged response and the same payment response without a second provider call or charge. Definite provider failures and ambiguous provider outcomes do not become billable x402 sales. Clients should retry the exact request and authorization when recovery is allowed instead of creating a second authorization for the same attempt.

Registered Purchases

The public API exposes provider-neutral purchase-offer, create, list, and status routes for registered billing accounts. Purchase creation requires an authenticated human Owner or Admin and an Idempotency-Key. The caller selects only an advertised offerKey; the server owns amount, currency, quantity, validity, provider, and effect. An API route existing does not prove that a production offer is available. Clients must inspect the current offer response. If no available offer is returned, the registered purchase lane is not currently open for sale.

Billing And Balance Readback

Registered accounts use the dashboard and authenticated billing routes for allocation, usage, purchase, and billing readback. Accountless x402 callers have no PubFi account balance, Credits balance, invoice, or anonymous dashboard. Their payment evidence is:
  • the wallet’s Base Sepolia activity;
  • the request-bound PAYMENT-RESPONSE;
  • the paired signed offer and signed receipt; and
  • exact replay of the same signed request.
PubFi does not expose internal Quantro settlement records or payment payloads as public accountless billing data. SIWX, a public wallet-history service, and anonymous Credits are not part of the current release.