Skip to main content
With linked cards, the agent itself completes the merchant’s checkout. Anchorage Agentic Banking mints a one-shot credential scoped to that merchant; the agent uses it to fill in the merchant’s own form. The charge then flows directly through the card network to the issuer.

​
Cards belong to the user, not the org

Each linked card is owned by exactly one user. The user links their own card through a card-verification flow (one-time code plus passkey). An agent spending on a card always spends on a card the approving user linked themselves — when the approval page asks the user to pick a card, the picker shows only that user’s own cards. Org admins see a read-only roster of members’ linked cards and can revoke on a member’s behalf, but they cannot link, pause, or activate someone else’s card.

​
Lifecycle of a card purchase

1

Request

The agent requests a purchase with amount, currency, description, and a fresh idempotency key. Anchorage Agentic Banking creates a PurchaseRequest in pending_approval and returns a link the user opens to approve.
2

Approve

The user opens the approval link in their browser, picks one of their own linked cards, and passkey-approves the purchase. The PurchaseRequest moves to approved.
3

Long-poll

The agent waits for the verdict via a long-poll (~25 s) using the same idempotency key. Requests expire 2 hours after creation.
4

Retrieve credentials

The agent requests credentials, passing the merchant name, URL, country code, and (for physical goods) the shipping block. Anchorage Agentic Banking returns card credentials scoped to that merchant — a one-shot retrieval, bound to the merchant at the credential-mint moment.
5

Checkout

The agent fills the merchant’s checkout form with the credential. The merchant’s payment processor charges the issuer directly through the card network.

​
Approvals

Every linked-card purchase requires a fresh passkey approval — see Approve and Long-poll above for the mechanics. Every pending approval also lists in the Anchorage Agentic Banking web UI under Approvals, alongside the direct link from the purchase request itself. When the user denies a request, the agent mints a new PurchaseRequest with a new idempotency key to try again — the denied key stays bound to the denied request.

​
Scoped per purchase

Linked-card spend is gated per purchase by passkey approval. Each PurchaseRequest is its own event, bounded by the amount the user approved. Card purchases also count toward the same cross-rail daily safety cap as crypto payments — see Stopping a runaway agent.

​
Idempotency

(AgentID, IdempotencyKey) is the uniqueness shape. The same key from a different agent on the same owner mints a fresh PurchaseRequest. Use a fresh key per intent.

​
What Anchorage Agentic Banking captures

When the agent retrieves credentials, Anchorage Agentic Banking captures the merchant context (name, URL, country, optional products, optional shipping block) into the consumed PurchaseRequest’s audit fields. The credential is bound to that merchant at issuance, so the card network rejects any use at a different merchant.

​
Compliance screening

Linking a card runs compliance screening before the link is registered. A card that does not pass is refused at link time and shown in your card list with the reason — the row stays visible for audit, and no purchase ever reaches that card. Re-trying the same card returns the same refusal. Each linked-card purchase runs compliance screening before the scoped credential is minted. A purchase that does not pass is refused with the reason, and the PurchaseRequest is recorded as rejected.

​
Failure modes