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, add cards, set rules, and monitor transactions.

Payment Flow

Axiom runs the entire store checkout server-side. The agent places the order and Axiom finishes it in the background. The agent never sees card details, drives the store's site, or polls for status.

1. Agent places the order: The agent calls place_order via MCP with the user's command, the resolved store and item, and an optional approved subtotal. Axiom validates the request against an LLM intent mandate (purchase intent + prohibited-merchant screening) and replies within about 25 seconds with an orderID.
2. Server-managed checkout: In the background, Axiom drives a managed browser session: adding the item, entering contact and shipping details, selecting delivery, and reaching the final total. When the browser can't finish, Axiom's team places the order instead; either way the status is in_progress.
3. Automatic savings: On supported stores, 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 order waits at awaiting_approval and Axiom emails the user an approval link.
5. Card issuance & charge: A single-use virtual debit card is issued with a spend limit matching the total, and the payment method on file is authorized (and later captured). The card is closed after the first authorization.
6. Order placed & receipt: Axiom enters the card at the store, confirms the order outcome, and captures the receipt. The order ends as completed, could_not_place, or cancelled, and Axiom emails the user the result.
7. Status on request: When the user asks how an order is going, the agent calls get_order_status with the orderID; it answers immediately. Once the order is completed, the response carries the receipt and an orderUrl linking to the order in the Axiom app. Only completed means the order went through (see the order response contract). list_orders returns recent orders and their orderIDs.

If Axiom needs the user to choose a variant or answer a question, the order waits at needs_answer. The question comes back in the place_order reply when it arises within the first 25 seconds; otherwise Axiom emails the user. The agent collects the answer and calls answer_order_question to continue the order.

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, allow the app to place orders for you, 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: Only the completed status means an order went through, so an agent can't misread an intermediate state as a finished order.