Skip to main content
Anchorage Agentic Banking’s crypto rail lets an agent pay any URL that quotes a price. The protocol underneath is x402, an HTTP-402 challenge/response that turns a URL into a paywall an agent can satisfy. From the agent’s perspective it is a single call: supply a URL, an idempotency key, and the budget to draw on; the platform does the rest.

​
What Anchorage Agentic Banking does for you

The agent only supplies a URL. Anchorage Agentic Banking owns every merchant-side interaction:
1

Fetch

Anchorage Agentic Banking issues the agent’s GET or POST to the merchant URL.
2

Read the 402

The merchant responds with HTTP 402 and an accepts array describing the price and acceptable rails.
3

Select

Anchorage Agentic Banking picks the cheapest payable entry among the chains the agent is set up to pay on. Today: USDC on Base (EVM) and USDC on Solana.
4

Gate

Compliance and spending gates run. Failures here return a structured error to the agent.
5

Sign

Anchorage Agentic Banking signs the payment authorization for the selected chain — an off-chain EIP-3009 authorization on Base, or an SPL token transfer on Solana.
6

Retry

Anchorage Agentic Banking re-issues the request with the payment header. The merchant’s facilitator broadcasts to chain; the merchant returns the resource.
7

Return

The merchant’s response body lands in the agent’s tool result.

​
Approvals

When a crypto payment exceeds the budget cap (but passes compliance), the payment is queued as pending_approval. The agent gets a structured response naming the approval; an org admin sees the request in the Anchorage Agentic Banking web UI under Approvals and approves or denies it. After an org admin approves, the agent polls for the verdict and then re-issues the payment with the same idempotency key to resume. Pending approvals expire after 24 hours and auto-deny. After that, the agent mints a new request with a new idempotency key to try again. Compliance failures (merchant not on allowlist, merchant inactive) are hard rejects — they stay outside the approval queue.

​
Idempotency

idempotency_key is agent-scoped: two calls from the same agent with the same key collapse to one transaction; the same key from a different agent is a separate transaction. Use a fresh key for every distinct intent.

​
The agent’s view

The agent sees the URL it asked for and the merchant response body it gets back. Negotiation detail — the accepts array, the signed EIP-3009 payload, the facilitator’s address, the funding account’s balance — is handled inside Anchorage Agentic Banking and stays internal.

​
Failure modes