How It Works

Architecture

Axiom consists of two main components:

1. Axiom API: Manages payment methods, processes payments, runs the server-managed browser checkout, and serves as the MCP server for agent communication.
2. Axiom Dashboard: A web app where users manage their accounts, link payment methods, set rules, and monitor transactions.

Payment Flow

Axiom runs the entire merchant checkout server-side. The agent starts a purchase and polls for its status. It never sees card details or drives the merchant site.

1. Agent starts the purchase: The agent calls make_purchase via MCP with the user's command, the resolved merchant and item, and an optional approved subtotal. Axiom validates the request against an LLM intent mandate (purchase intent + prohibited-merchant screening) and returns immediately with a browserPurchaseSessionID.
2. Server-managed checkout: Axiom drives a managed browser session: acquiring the item, entering contact and shipping details, selecting delivery, and reaching the final total.
3. Automatic savings: On supported merchants, Axiom hunts for applicable promo codes and first-time-buyer discounts during checkout and applies the best one it finds. Where a new-customer discount requires a fresh email address, Axiom may check out with a one-time email it manages instead of your personal email, and it forwards the order and delivery confirmations to your real inbox. Applied discounts appear on the receipt.
4. Rules check & approval: Axiom evaluates the user's spending rules. If a rule requires it, the purchase parks and the agent surfaces an approvalLink for the user to approve before continuing.
5. Card issuance & charge: A single-use virtual debit card is issued with a spend limit matching the total, and the user's linked payment method is authorized (and later captured). The card is closed after the first authorization.
6. Order placed & receipt: Axiom enters the card at the merchant, confirms the order outcome, and captures the receipt.
7. Agent polls for status: The agent calls get_purchase_status in a loop; each call waits up to 30 seconds for the next parked or terminal status change. The final response carries the receipt, a transactionUrl linking to the transaction in the Axiom dashboard, and the purchase-finality fields (isFinal, safeToTellUserComplete, nextAction) that tell the agent exactly when it may report success. The agent can call get_transaction later to review the recorded transaction, receipt, and audit trail.

If Axiom needs the user to choose a variant or answer a question, the purchase parks at awaiting_user_input; the agent collects the answer and calls submit_purchase_clarification to resume.

Connecting agents

Clients with native MCP support, like ChatGPT (via the plugin store), Claude, and other connector-capable hosts, handle the OAuth flow themselves: add Axiom, sign in, approve the requested scopes, done.

For CLI-based agents like OpenClaw, we recommend mcporter rather than having the agent handle OAuth directly:

• Separation of access: mcporter manages the OAuth token and gives the agent access to MCP tools only. The agent never has access to your Axiom dashboard, wallet settings, or spending rules UI.
• Simplified token lifecycle: mcporter handles token caching, refresh, and re-authentication. Your agent doesn't need to implement OAuth2 with PKCE.
• Cross-device auth built in: mcporter integrates with Axiom's "Sign in on another device" flow, making it easy for browser-based agents to authenticate without native browser access.

For agents that need to handle OAuth directly, the same security model applies: scoped OAuth2 tokens ensure agents can only access the MCP tools they've been granted permission for.

Security Model

Axiom is designed with multiple layers of protection:

• Intent mandates: Every purchase request is screened by an LLM mandate that checks the agent's resolved purchase against the user's actual words and blocks prohibited merchants, before any checkout starts.
• Single-use cards: Each card works for exactly one transaction, eliminating the risk of card reuse or theft.
• Spend limits: Cards are created with explicit limits so agents can never spend more than authorized.
• User-defined rules: The rules engine evaluates every purchase attempt against user-configured policies before authorizing.
• Scoped permissions: MCP connections use OAuth2 with granular scopes, so agents only get access to the capabilities they need.
• Honest completion signals: Agents receive explicit safeToTellUserComplete finality flags, so an agent can't misread an intermediate state as a finished purchase.