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

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