Hermes Bank technical map.

Quickstart

Hermes Bank gives users and agents a controlled prepaid card surface. The dashboard handles Solana wallet authorization, card request creation, pending request tabs, transaction history, and agent-facing card requests.

Local site:
http://localhost:4174

Production:
https://hermesbank.one

Core pages:
/          marketing page
/dashboard prepaid card desk
/agent     agent wrapper
/docs      technical documentation

Hermes endpoints:
/api/cards
/api/transactions
/api/payment-intents
/api/agent-card-issue

Architecture

Hermes should be structured as a thin product layer over three secure systems: crypto checkout, prepaid fulfillment, and internal ledger. The user should never see raw provider implementation details. The dashboard should only show Solana authorization, Hermes-branded cards, orders, and transaction state.

1. User chooses card type, country, amount, and recipient label.
2. Backend creates a crypto payment intent with amount plus fee.
3. Crypto watcher confirms payment on the selected network.
4. Backend creates the prepaid card order through fulfillment rails.
5. Backend stores card metadata and encrypted card delivery data.
6. Dashboard reads cards and transactions from Hermes API.

Browser
  -> Hermes API
    -> Crypto payment service
    -> Ledger database
    -> Manual fulfillment operator
  -> Dashboard card tab + transaction ledger

Dashboard

The dashboard is the operating console. It should answer four questions immediately: which Solana wallet is connected, what cards exist, what was paid, and what is waiting for settlement.

Manual Card Requests

A manual request is created after wallet connection and email submission. The request tab shows amount, delivery email, order ID, and pending manual fulfillment state.

{
  "type": "Hermes Prepaid Visa",
  "country": "US",
  "amount": 50,
  "recipient": "Research Agent",
  "status": "PENDING_MANUAL",
  "orderId": "manual_8K2DPN4M9Q",
  "issuedAt": "2026-06-21T19:35:00.000Z"
}

Manual mode does not expose card number, PIN, CVV, or redemption secrets in the site. Final delivery happens out-of-band to the provided email after review.

Transactions

Every user-visible card should map to ledger events. At minimum, each card order creates a crypto payment transaction and a prepaid order transaction. Later versions should add refunds, failed orders, settlement adjustments, and manual review events.

{
  "id": "tx_01J...",
  "type": "Crypto payment",
  "status": "CONFIRMED",
  "amount": 51.50,
  "asset": "USDC",
  "reference": "PAY-2K4M9-Q8W7P",
  "createdAt": "2026-06-21T19:35:00.000Z"
}

Solana Wallet Auth

Hermes uses Reown AppKit for Solana-only wallet connection. The wallet step proves checkout ownership and gives Hermes a user address for order attribution. Connecting a wallet does not send a transaction or grant card issuance permission by itself.

{
  "projectId": "reown_project_id",
  "network": "solana",
  "address": "connected_solana_address",
  "balanceSource": "Solana mainnet RPC",
  "permissions": [
    "address:read",
    "balance:read"
  ]
}

Production checkout should create a payment intent after wallet connection, wait for the crypto transaction confirmation, then deliver the Hermes prepaid card tab after fulfillment completes.

Agent Shell

The Agent Shell is the machine-facing wrapper around Hermes. It is designed for AI agents that need to discover allowed payment actions, request permissioned prepaid cards, and read ledger state without receiving owner wallet access.

Agent startup flow:
1. Read assigned policy and spend scope.
2. Connect or receive an authorized Solana wallet context.
3. POST /api/payment-intents with idempotency key.
4. POST /api/agent-card-issue after payment confirmation.
5. GET /api/transactions to reconcile the mission ledger.

Required scopes:
wallet:read
transactions:read
cards:issue
cards:read

Manual Fulfillment

The current production mode records a pending request instead of automatically issuing card credentials. Users connect a Solana wallet, enter a delivery email, choose amount and country, then Hermes stores the request for operator review.

Manual flow:
1. Connect Solana wallet through Reown.
2. Submit card amount, country, label, and delivery email.
3. Hermes creates a PENDING_MANUAL request.
4. Operator reviews payment and risk.
5. Card details are delivered manually by email outside the website.

Security and Risk Rules

• Never create a card order before crypto confirmation.
• Encrypt card delivery data at rest.
• Do not log full card codes, PINs, redemption URLs, or secrets.
• Apply per-user, per-agent, and per-day issuance limits.
• Block unsupported countries before checkout.
• Require manual review for repeated failed payments or high velocity.
• Keep provider API keys in server environment variables only.
• Use idempotency keys for payment and card order creation.

Product Copy Rules

Hermes should sound private, premium, and operational. Avoid claiming regulated banking functionality until the legal and issuing partner setup exists. The product promise is controlled prepaid spend for agents, not a full bank account.

Roadmap

1. Connect real crypto payment intents and confirmation webhooks.
2. Add database-backed balances, cards, users, and transactions.
3. Expand fulfillment coverage across supported prepaid products.
4. Add secure card reveal flow with encrypted storage.
5. Ship admin reconciliation for failed orders and refunds.
6. Expand authenticated user and agent account controls.