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

For accountless x402, the caller’s USDC balance in the selected environment’s wallet is the available payment balance. PubFi does not copy that value into an account or Credits balance. 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. Authorization and the rejected legacy X-PubFi-Api-Key header both count as API-key carriers for this lane decision.

​
MCP Lane Selection

pubfi.route.execute separates the two authorities by endpoint:
  • The primary endpoint accepts a PubFi API key or OAuth access token and selects the registered account/allocation lane. It rejects x402/payment and never falls back to x402.
  • The explicit /x402 endpoint rejects every Bearer credential. On that endpoint, params._meta["x402/payment"] carries payment and selects the accountless x402 lane.
  • Sending no payment on /x402 for 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.

​
x402 Environment Scope

PubFi enforces these x402 environment boundaries: The historical Production health acceptance on 2026-07-27 used canonical Base USDC and 0.001 USDC per request. Those values and that route are not current payment or availability authority. The environment boundary does not prove current route or offer availability. Use the selected environment’s live Registry catalog as route authority. Use the route’s live unsigned 402 challenge as the authority for the asset, amount, payee, timeout, and other payment terms. An enabled route uses a bounded x402 V2 exact lane with:
  • 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 public Base Sepolia example is Staging-only. Base Sepolia USDC has no financial value. See the Staging guide for the endpoint and credential boundary.

​
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 HTTP response includes the PAYMENT-RESPONSE header. A successful MCP result includes the decoded response at result._meta["x402/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 submits the advertised offerKey, its exact catalog release and Service Credit Terms identities, and a shortest-canonical USD amount. PubFi accepts 1through1 through 1,000 in $0.10 increments only when the offer produces a whole-Credit quantity. Currency, quantity derivation, validity, provider, and effect remain server authority. The current checked-in pricing target uses a base offer of $1 for 1,000 Credits. This checked-in target does not prove that an offer is installed or open for sale in an environment. 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 activity on the network in the accepted challenge;
  • the request-bound HTTP PAYMENT-RESPONSE or MCP x402/payment-response;
  • the paired signed offer and signed receipt; and
  • exact replay of the same signed request.
The signed receipt is verifiable evidence for the settled payment and execution. It is not an account-balance, Credits, top-up, or deposit record. 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.