Cards

Cards is available in sandbox only while we finish development. Dakota enables Cards per account. The Cards endpoints are in the API reference, marked Sandbox only. Endpoints, fields, and flows can still change before release.

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

Setup path

API recipes lists the calls for each of these steps, and for everything after a card exists.

Start here

API recipes

Every scenario as the calls to make, in order, and the signal to wait for.

Testing

Run the whole card lifecycle in sandbox, from activation to refunds.

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

Playground

Documentation

Import Share Tokens

Agentic Payments

Authentication

Developer Tools

Cards

At a glance

The objects

Setup path

Start here

API recipes

Testing

Not in the first release

​At a glance

​The objects

​Setup path

​Start here

API recipes

Testing

​Not in the first release

At a glance

The objects

Setup path

Start here

Not in the first release