> ## 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.

# Linked cards

> Link your own card; the agent gets a one-shot scoped credential per purchase.

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

<Steps>
  <Step title="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.
  </Step>

  <Step title="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`.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.

    {/* req: cards/purchase-requests.md#12, #5 */}
  </Step>

  <Step title="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. {/* req: cards/purchase-requests.md#13 */}
  </Step>
</Steps>

## 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](/agentic-banking/concepts/agents#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. {/* req: cards/purchase-requests.md#9 */}

## 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. {/* req: cards/purchase-requests.md#2, #12 */}

## 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

| Verdict                                  | What it means                                     | What to do                                                                   |
| ---------------------------------------- | ------------------------------------------------- | ---------------------------------------------------------------------------- |
| Card compliance mismatch                 | The card itself did not pass compliance screening | Link a different card                                                        |
| Purchase compliance mismatch             | The purchase did not pass compliance screening    | Mint a new PurchaseRequest with a new idempotency key                        |
| Credential retrieval — temporary failure | The card network was indeterminate (5xx)          | Retry credential retrieval on the same PurchaseRequest — it stays `approved` |
| Credential retrieval — rejected          | The card network refused the request (4xx)        | Mint a new PurchaseRequest with a new idempotency key                        |