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

# Card Transactions

> Unified crypto card activity across issuers, card programs, and chains — card spend, merchant settlement, and top-ups normalised into a shared schema.

The `payments.card_transactions` table unifies observable onchain card flows across supported issuers, card programs, and chains into a single schema. It focuses on user-generated activity and counts each card transaction exactly once — picking the best observable event per flow (`card spend`, `top-up`, or `settlement`) so volume is never double-counted across the top-up → settlement hop.

The dataset is one of the upstream sources for `payments.commerce_flows`, where card transactions are classified as `party_pair = c2b`, `purpose = commerce`, `confidence = high`, `protocol = card_provider`.

## Why this dataset matters

Crypto debit and credit cards are a large, measurable payment surface onchain — real consumer spend you can watch settle in stablecoins. Normalising activity across providers into a single table makes it possible to:

* Measure real card spend volume without double-counting across settlement hops.
* Compare adoption and volume across card issuers and card programs.
* Attribute stablecoin transfers to card payment context in downstream analytics.

## Coverage

**Chains:** EVM chains, Solana, Starknet, and Tron.

**Tokens:** Not restricted to stablecoins — each row carries `source_asset_type` (`stablecoin`, `volatile_asset`, or `NULL`), so flows funded from volatile assets are included and can be filtered. `NULL` is a third, deliberate state: Blast and Starknet emit it because stablecoin-reference coverage isn't available there yet, so account for it when filtering rather than assuming every row is one of the two typed values.

**Issuers / card programs:** Crypto debit and credit card providers whose settlement activity is observable onchain. The `card_provider` is the user-facing card program — the brand the user signs up and holds the card with. The `card_issuer` is the regulated entity or issuing infrastructure that puts the card on the network and settles the funds. The same company can play both roles (e.g. Gnosis Pay).

* **Card programs (`card_provider`):** Cypher, Etherfi, Exa, Gnosis Pay, Holyheld, Ready, Redotpay, Safepal.
* **Issuers / infrastructure (`card_issuer`):** Fiat24, Gnosis Pay, Holyheld, Immersve, Kulipa, PIX, Rain, Reap, StraitsX, Wirex.
* **Card networks (`network`):** Visa, Mastercard.

## What transactions do we track?

Detection logic is provider-specific — each issuer or card program exposes a different set of onchain signals, so individual provider models handle address and contract identification and event classification before normalising into the shared schema. The data contains a `tx_type` field so you know exactly what each row represents:

| tx\_type | Meaning |
| - | - |
| `card_spend` | Direct card spend event |
| `card_top_up` | User funding a card balance |
| `batch_settlement` | Batched settlement from custodial wallet to merchant |

Which of these events is observable differs by card program — some expose direct spend, others only the batched settlement leg or the top-up. Top-ups fund a card balance rather than record a purchase, so spend-focused analyses typically exclude them by filtering on `tx_type`, as in the sample query below.

## Table schema

Address columns are cast to `varchar` at the top level so that EVM (`varbinary`), Solana, and Tron addresses share a common type across the unioned schema.

| Column | Type | Description |
| - | - | - |
| `blockchain` | varchar | Chain name |
| `transfer_unique_key` | varchar | Unique transfer identifier; join key back to upstream stablecoin transfer tables |
| `block_month` | date | Block month (partition key) |
| `block_date` | date | Block date |
| `block_time` | timestamp | Block timestamp |
| `tx_hash` | varchar | Transaction hash |
| `transfer_evt_index` | bigint | Event index of the underlying token transfer |
| `activity_evt_index` | integer | Event index of the card activity event; `NULL` where not applicable |
| `token_address` | varchar | Token contract address |
| `token_symbol` | varchar | Token symbol, e.g. `USDC`, `USDT` |
| `sender` | varchar | Transfer sender address |
| `sender_label` | varchar | Role label for the sender: `user_wallet`, `custodial_deposit_address`, or `defi_pool` |
| `receiver` | varchar | Transfer receiver address |
| `receiver_label` | varchar | Role label for the receiver: `payment_collector` or `custodial_deposit_address` |
| `amount` | double | Normalized token amount |
| `amount_usd` | double | USD value at block time |
| `amount_raw` | uint256 | Raw token amount |
| `tx_type` | varchar | Card event type: `card_spend` (direct spend), `card_top_up` (user funding), or `batch_settlement` (custodial wallet to merchant) |
| `network` | varchar | Card payment network (e.g. `Visa`, `Mastercard`) |
| `card_issuer` | varchar | Regulated entity or issuing infrastructure that puts the card on the network and settles the funds (e.g. Rain, StraitsX, Fiat24, Kulipa) |
| `card_provider` | varchar | User-facing card program operating the card (e.g. Gnosis Pay, Redotpay, Etherfi) |
| `mode` | varchar | Payment mode or transaction subtype; values vary by provider (e.g. `pay_now`, `pay_later`, `liquidation`); `NULL` for providers that do not expose this field |
| `user_address` | varchar | End user's wallet address; may differ from `sender` for custodial flows |
| `project_version` | varchar | Version of the matched protocol or project |
| `project_address` | varchar | Contract or project address matched |
| `source_asset_type` | varchar | Type of source asset: `stablecoin`, `volatile_asset`, or `NULL` (unclassified — e.g. Blast, Starknet, where stablecoin-reference coverage is unavailable) |

## Composability

Because every row is at the transfer level and carries the end-user wallet (`user_address`) plus a `transfer_unique_key` back to the canonical token transfer, card activity composes with the rest of Dune. Join `user_address` out to other tables to answer questions cards alone can't:

* **Where do users get funded from?** Join to `tokens_evm.transfers` on inbound transfers to `user_address` to see which exchanges, on-ramps, or wallets top them up.
* **What else do they do onchain?** Join to `dex.trades` (and other protocol tables) to see which DEXs and protocols card users interact with.
* **How else do they use stablecoins?** Join to `stablecoins_evm.activity_enriched` on `from_address` / `to_address` to see a card user's full stablecoin footprint — CEX, DeFi, bridging, and payments — broken down by `category`.

## Sample query

### Card spend volume by provider

```sql theme={null}
SELECT
    card_provider,
    network,
    SUM(amount_usd)           AS volume_usd,
    COUNT(*)                  AS tx_count,
    COUNT(DISTINCT user_address) AS unique_users
FROM payments.card_transactions
WHERE tx_type IN ('card_spend', 'batch_settlement') -- excludes card top-ups
GROUP BY 1, 2
ORDER BY 3 DESC
```

### Which DEXs do crypto card users trade on?

```sql theme={null}
WITH card_users AS (
    SELECT DISTINCT
        blockchain,
        from_hex(substr(user_address, 3)) AS wallet  -- 0x varchar → varbinary
    FROM payments.card_transactions
    WHERE user_address LIKE '0x%'
)
SELECT
    t.project              AS dex,
    COUNT(*)               AS trades,
    COUNT(DISTINCT t.taker) AS card_users,
    SUM(t.amount_usd)      AS volume_usd
FROM dex.trades t
JOIN card_users u
  ON u.wallet = t.taker
 AND u.blockchain = t.blockchain
WHERE t.block_date >= NOW() - INTERVAL '30' DAY
GROUP BY 1
ORDER BY volume_usd DESC
```


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.