> For the complete documentation index, see [llms.txt](https://docs.ur.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ur.app/design/user-experience/card-activation.md).

# Card activation

Currency authorization and card activation by integration mode.

Card activation bridges account verification and spending capability. This page covers the currency authorization users complete during activation and the authentication patterns that protect card details, for both Managed Custody Mode and External Wallet Access Mode.

### Currency authorization and enablement

For regulatory reasons, your users must authorize currencies for payment. To prevent payments from failing at the point of purchase, include currency authorization in the card activation flow.

{% hint style="success" %}
Enable all currencies by default to maximize payment success. For wallet partners, currencies must be enabled via EIP-7702 to batch the transactions.
{% endhint %}

### Managed Custody Mode

<img src="https://621536571-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7N1L1zymu2YdfMlQWxe1%2Fuploads%2Fgit-blob-779b11c38a59e23ee3e47e0e7c877640702e8912%2Ffile.excalidraw%20(5).svg?alt=media" alt="" class="gitbook-drawing">

{% hint style="info" icon="figma" %}
Figma reference:\
[**Managed Custody Mode card activation**](https://www.figma.com/design/WKbdwKpCGPRaAN43tGXHiN/Partner-UX-Guide?node-id=28-107\&t=LdSer2mHyoMOtsCs-1)
{% endhint %}

**Authentication requirement**

Every "View card" action requires re-authentication, for both activated and inactive cards. Card details are highly sensitive information, comparable to physical card access. Gating them protects against unauthorized access: someone with temporary access to an unlocked phone still cannot read the full card number and CVV. It also follows the industry standard set by financial apps, and it builds trust by tying card access to a verification step users recognize. Authentication adds friction, but the trade-off is acceptable because users expect this measure for financial data.

In Managed Custody Mode, users authenticate with their UR credentials (Google Sign-In or email one-time password (OTP)) to view card details, and they activate through your standard authentication flow via UR's webview. Currency authorization is included within the activation flow.

### External Wallet Access Mode

<img src="https://621536571-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7N1L1zymu2YdfMlQWxe1%2Fuploads%2Fgit-blob-da780e44d83f12bda6b57c1926672c6b6ce90dd8%2Ffile.excalidraw%20(6).svg?alt=media" alt="" class="gitbook-drawing">

{% hint style="info" icon="figma" %}
Figma reference:\
[**External Wallet Access Mode card activation**](https://www.figma.com/design/WKbdwKpCGPRaAN43tGXHiN/Partner-UX-Guide?node-id=135-6297\&t=LdSer2mHyoMOtsCs-1)
{% endhint %}

**Authentication requirement**

Every "View card" action requires wallet authentication, for both activated and inactive cards. The same reasoning applies as in Managed Custody Mode: it protects against unauthorized access, follows industry standards, and creates a security ritual that builds trust.

In External Wallet Access Mode, users authenticate with their wallet (for example, biometric or PIN) to view card details. The wallet signature proves ownership and intent. To activate the card, users sign with their wallet, and currency authorization is recommended as part of the activation flow.

Viewing sensitive card data (full number, CVV) requires cryptographic proof of wallet ownership every time.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.ur.app/design/user-experience/card-activation.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
