Skip to main content
Anchorage Agentic Banking’s crypto rail lets an agent pay any URL that quotes a price. Merchants quote in one of two protocols and the platform speaks both: x402, an HTTP-402 challenge/response that turns a URL into a paywall, and the Machine Payments Protocol, which quotes in a WWW-Authenticate: Payment header instead. From the agent’s perspective it is a single call either way: supply a URL, an idempotency key, and the budget to draw on; the platform reads which protocol the URL speaks and 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. On the Machine Payments Protocol only a GET is payable: a price quoted in answer to a write means the merchant already took the write, and paying for it would leave the agent unable to tell whether calling again repeats the change.
2

Read the quote

The merchant responds with its price: on x402, an HTTP 402 carrying an accepts array of the rails it takes; on the Machine Payments Protocol, a WWW-Authenticate: Payment header naming one.
3

Select

Where the merchant offers a choice, 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. Paid inference offers one chain per kind of call: chat completions, streamed or not, settle in USDC on Solana, and image, video, and audio generation settle in USDC on Base. An agent can also pay Solana merchants that charge by metered usage on each request. Anchorage Agentic Banking reserves the merchant’s per-request maximum, charges the actual amount the merchant reports, and releases the rest. The payment shows the charged amount once the merchant reports it. For paid URLs and non-streamed chat completions, when a merchant offers both a metered option and a fixed-price option, Anchorage Agentic Banking picks the metered one, so the charge can be anywhere up to that maximum. A maximum above 10 USDC, streamed chat completions, and image, video, and audio generation use the fixed-price option. The budget must cover the per-request maximum: a metered payment whose maximum exceeds the remaining budget is declined and does not wait for approval.
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. A Machine Payments Protocol quote is payable on Solana only, and one naming another chain is refused.
6

Retry

On x402, Anchorage Agentic Banking re-issues the request carrying the payment credential, and the merchant’s facilitator broadcasts to chain. On the Machine Payments Protocol the credential goes straight to the merchant’s charge endpoint rather than back to the agent, and the merchant’s sponsor broadcasts it and pays the network fee.
7

Return

On x402 the merchant’s response body — the paid resource — lands in the agent’s tool result. On the Machine Payments Protocol what lands there is the merchant’s charge-endpoint response, and Anchorage Agentic Banking reads it for the merchant’s acknowledgement that it took the payment. An acknowledged charge completes; Anchorage Agentic Banking treats the acknowledgement as a claim and confirms it against the chain before the payment is final. A merchant that answers without acknowledging the charge — no readable acknowledgement, one naming a different charge, or one reporting failure — returns an error that quotes the merchant’s own response. The payment reached the merchant and the merchant may still settle it, so paying again risks paying twice. Confirm settlement on chain, or with Anchorage, before re-attempting: the merchant holds the credential and is the party that would submit it, so its own answer cannot settle the question. The protected resource is not re-fetched either, so treat an acknowledged charge’s body as a receipt rather than as the content.

​
Approvals

When a fixed-price 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. A metered payment whose per-request maximum exceeds the remaining budget is declined instead of queued, so the budget must cover the maximum. After an org admin approves, the agent polls for the verdict and then re-issues the payment with the same idempotency key to resume. An agent polls the verdict for the payments it created. A payment another agent created stays invisible to it, even inside the same organization. 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 side broadcasts to chain (its facilitator on x402, its sponsor on the Machine Payments Protocol). 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.

​
Receiving payments

When your account receives a crypto payment — for example, a facilitator or another Anchorage Agentic Banking customer paying a priced URL you host — compliance screening runs on the payment before the funds become available. Each received payment carries one of these labels: A received payment shows its label on the payments page next to the transaction, and on the payment’s own detail page. Outbound payments you send carry no screening label.

​
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. When a repeated payment call returns the first call’s recorded result, the result is normally marked as a replay. On rare occasions the first result wasn’t retained. On x402 the merchant is then asked again under the same payment, and that result isn’t marked. On the Machine Payments Protocol the call returns an error naming the transaction, for operations to resolve. Either way, no new payment is made. Repeats sent at the same time can leave the mark off a call that shared the payment or put it on the call that made it, so treat the mark as a hint rather than proof of which call paid.

​
Cost estimates

Before calling for a paid URL, an agent can ask Anchorage Agentic Banking to price it without paying: no idempotency key, no budget, no signature, no funds held. The preview forwards the same method, headers, and body the real call would use, and reads the merchant’s quote back without acting on it — except that it does not resolve merchant-specific custom headers the way a real call does, so a merchant that requires one of those to answer may reject the preview even though the real call would reach it. For a merchant that charges by metered usage, the estimate shows the per-request maximum the payment reserves, not the expected charge. That preview is not free of side effects, because the request it issues is real: a preview against an endpoint that writes or deletes performs that write or delete, exactly as paying for it would, before any money moves. The tool’s safety hints reflect this, so a client that reads those hints sees a cost preview classed the same way as paying, not as a silent read — whether that client actually pauses for approval before acting on the hint is up to that client, not something Anchorage Agentic Banking can guarantee from here.

​
Who can see a payment

Org admins open any payment their org’s agents make. Their Payments page lists their own agents’ payments first, and switching to all payments lists every payment in the org. A plain org member sees the payments made by agents delegated to them. A payment made by another member’s agent opens as a not-found page, including from a direct link. An agent can open and list only the payments it made.

​
What the agent sees

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

​
Failure modes