> ## Documentation Index > Fetch the complete documentation index at: https://docs.anchorage.com/llms.txt > Use this file to discover all available pages before exploring further. # Crypto payments > How Anchorage Agentic Banking settles a paid URL on the crypto rail. Anchorage Agentic Banking's crypto rail lets an agent pay any URL that quotes a price. The protocol underneath is [**x402**](https://x402.org), 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: Anchorage Agentic Banking issues the agent's GET or POST to the merchant URL. The merchant responds with HTTP 402 and an `accepts` array describing the price and acceptable rails. 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. Compliance and spending gates run. Failures here return a structured error to the agent. 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. Anchorage Agentic Banking re-issues the request with the payment header. The merchant's facilitator broadcasts to chain; the merchant returns the resource. 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. 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. ## What the agent sees 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 | Verdict | What it means | What to do | | ---------------------------- | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | Compliance mismatch | Merchant not on allowlist or inactive | Pick a different merchant | | Spending mismatch | Over the budget cap | Ask an org admin to approve, then poll for the approval verdict | | Daily safety cap reached | Hard reject, no approval path | See [Stopping a runaway agent](/agentic-banking/concepts/agents#stopping-a-runaway-agent) | | Agent deactivated | Hard reject, no approval path | See [Stopping a runaway agent](/agentic-banking/concepts/agents#stopping-a-runaway-agent) | | Account locked or frozen | Hard reject, no approval path | Contact Anchorage support — resolution requires staff action | | Insufficient account balance | Hard reject, no approval path | Fund the account, then retry | | Resource mismatch | The merchant's quote names a resource at a different address (host or port) than the URL actually reached | Hard reject, no approval path. The merchant endpoint is misconfigured; pick a different merchant | | Schema mismatch | Request body doesn't match the merchant's published schema | Fix the request body and retry with a **new** idempotency key | | Upstream 5xx | Merchant indeterminate | Retry with the **same** idempotency key — repeat calls collapse to one settlement |