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 aspending_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.
If the organization is frozen, approving a queued payment is rejected with a
message naming the reason, and the payment stays in the approval queue. The
same check runs when an approved payment is re-issued, so a freeze that lands
after approval still stops the payment. Once the organization is unfrozen,
approving or re-issuing works without any new request.
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.
Settlement
After signing, the payment stays pending briefly while the merchant’s facilitator broadcasts to chain — settlement normally lands in seconds. If the signed authorization can no longer settle (it expired unused, and the chain shows no settlement), the payment declines automatically and its reserved funds normally release back to the account in the same pass — in the rare case the release needs another step, Anchorage resolves it. Either way no action is needed from the agent; an agent that still wants the resource makes a new request with a new idempotency key. A payment whose settlement did land on chain is never declined this way — it completes as usual.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.