Skip to main content
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:

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.

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

Which DEXs do crypto card users trade on?