> ## 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. **Issuers / card programs:** Crypto debit and credit card providers whose settlement activity is observable onchain. * **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 | ## 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 that issues the cards (e.g. Rain, StraitsX, Fiat24, Kulipa) | | `card_provider` | varchar | Card program operating the user-facing 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` or `volatile_asset` | ## 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 ```