> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dakota.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Cards

> Virtual Visa debit cards that spend directly from a customer's Dakota wallet

<Warning>
  **Cards is available in sandbox only while we finish development.** Dakota enables Cards per
  account. The Cards endpoints are in the [API reference](/api-reference/introduction), marked
  **Sandbox only**. Endpoints, fields, and flows can still change before release.
</Warning>

Dakota Cards issues **virtual Visa debit cards** that spend straight from a customer's Dakota wallet. There is no separate card balance to fund: a card spends the wallet's available balance, and Dakota authorizes every purchase against it in real time.

Cards use the same API keys, idempotency rules, and webhook stream as the rest of your Dakota integration.

## At a glance

| | |
| - | - |
| **Card type** | Virtual Visa debit. Physical cards are not in the first release. |
| **Funding** | An EVM wallet owned by the customer. Cards spend Dakota's RD token on Base, or USDC where RD is not yet supported. Only that token on that network funds cards. |
| **Currency** | USD. The network converts foreign-currency purchases. |
| **Cardholders** | People authorized by a business customer, or an individual customer spending their own wallet. |
| **Digital wallets** | Apple Pay and Google Pay at launch, through manual provisioning: the cardholder enters or scans the card details in their wallet app. |
| **Card data** | The API never returns the full card number or CVV. They render in the cardholder's browser through [Cards.js](/documentation/cards/cards-js). |
| **3-D Secure** | Supported for online merchants that ask for it. The cardholder is verified through their phone number. Your application does not implement anything. |

## The objects

| Object | What it is |
| - | - |
| **Customer** | Your end client, already onboarded with Dakota. Everything below belongs to a customer. |
| **Wallet** | The customer's EVM wallet. It funds the cards and keeps working normally for everything else. |
| **Wallet card enablement** | A one-time grant, signed by the customer for each wallet, that lets Dakota recover settled card spend from that wallet. |
| **Cardholder** | The person who carries the card. |
| **Card** | A virtual card, held by one cardholder and funded by one wallet. |
| **Card transaction** | One purchase, from authorization through clearing, reversal, or refund. |

A wallet can fund many cards, and a cardholder can hold many cards. Every card on a wallet spends from the same available balance.

```mermaid theme={null}
erDiagram
    CUSTOMER ||--o{ CARDHOLDER : "authorizes"
    CUSTOMER ||--o{ WALLET : "owns"
    WALLET ||--o| CARD_ENABLEMENT : "signed once"
    CARDHOLDER ||--o{ CARD : "holds"
    CARD }o--|| WALLET : "funded by"
    CARD ||--o{ CARD_TRANSACTION : "generates"
```

## Setup path

```mermaid theme={null}
flowchart LR
    A["Dakota activates your account<br/><i>once</i>"] --> B["Customer accepts the Cards terms<br/><i>once per customer</i>"]
    B --> C["Create a cardholder<br/><i>once per person</i>"]
    B --> D["Enable a wallet<br/><i>once per wallet</i>"]
    C --> E["Create a card"]
    D --> E
```

[API recipes](/documentation/cards/api-recipes) lists the calls for each of these steps, and for everything after a card exists.

## Start here

<CardGroup cols={2}>
  <Card title="API recipes" icon="list-check" href="/documentation/cards/api-recipes">
    Every scenario as the calls to make, in order, and the signal to wait for.
  </Card>

  <Card title="Testing" icon="flask" href="/documentation/cards/testing-sandbox">
    Run the whole card lifecycle in sandbox, from activation to refunds.
  </Card>
</CardGroup>

## Not in the first release

* Physical cards
* Choosing which token and network fund cards
* Spending several assets from one wallet
* Withdrawing a wallet's card enablement
* Reading dispute reports back, and dispute webhooks