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
CallToolResultpayment requirement.
_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 V2exact 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, andPAYMENT-RESPONSEheaders; - the official Signed Offers & Receipts extension with Ed25519
did:webverification; and - the official MCP
x402/paymentandx402/payment-responsemetadata flow.
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 includesPAYMENT-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 anIdempotency-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.