Card Transactions - Dune Docs

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

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?

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

Documentation Index

​Why this dataset matters

​Coverage

​What transactions do we track?

​Table schema

​Composability

​Sample query

​Card spend volume by provider

​Which DEXs do crypto card users trade on?