§What PCI DSS requires
Source: Payment Card Industry Data Security Standard — maintained by the PCI Security Standards Council — accessed 2026-05-11.
Jurisdiction. Maintained by the PCI Security Standards Council, founded in 2006 by American Express, Discover, JCB International, MasterCard, and Visa. PCI DSS is not a government regulation — it is a contractual industry standard. The PCI SSC manages the standard itself; payment brands and acquirers enforce compliance through their own programmes.
Personal data definition. PCI DSS distinguishes cardholder data (CHD) from sensitive authentication data (SAD), and applies to "all entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD) or could impact the security of the cardholder data environment (CDE)." This includes merchants, processors, acquirers, issuers, and service providers.
Key requirements relevant to mobile analytics. PCI DSS "defines security requirements to protect environments where payment account data is stored, processed, or transmitted." It "provides a baseline of technical and operational requirements designed to protect payment account data." Compliance scope depends on how a merchant handles cardholder data: an app that routes all payments through a tokenising third party (Stripe, Adyen, App Store, Google Play) keeps the cardholder data environment outside its own perimeter and qualifies for the smallest assessment scope. The PCI SSC does not enforce compliance itself; payment brands do, through their respective compliance programmes.
⚑Where mobile analytics typically creates exposure for crypto & web3 apps
The simplest PCI DSS rule for mobile analytics is PAN (Primary Account Number) must never enter the analytics pipeline. A developer who logs purchase with parameter card_number: '4111…' has pulled the analytics SDK into the cardholder data environment, dramatically expanding the assessment scope. The same applies to track-2 data, CVV, and PINs (which fall under sensitive authentication data and must not be stored after authorisation at all).
Crypto apps process wallet addresses, transaction hashes, token symbols and amounts, NFT contract addresses, and on-chain holdings. Many also log fiat onramp KYC data, IP geolocation, and device fingerprints for fraud detection.
A wallet address, while pseudonymous on-chain, becomes a persistent identifier under GDPR once any link to a real-world identity exists. Fiat onramp KYC data is personal data outright. Combined with IP and device fingerprints, an analytics SDK can build a persistent profile that triggers GDPR, CCPA/CPRA, and AML/KYC concerns simultaneously.
▸What Respectlytics's design does (technical facts)
Respectlytics's API does not accept wallet addresses or transaction hashes as event parameters — those identify on-chain activity that lives on-chain. Product analytics records that a user opened the swap screen, completed an onramp, or viewed an NFT collection, without per-event identifiers tying those actions to a wallet.
Reduces the surface. Removing the surface where the categories covered by PCI DSS could be collected in the first place narrows what a PCI DSS review needs to scope. Whether the resulting posture meets the regulation's requirements for your specific app is something to discuss with your legal team.
❓Frequently asked questions
Is PCI DSS a law?
No. PCI DSS is a contractual industry standard maintained by the PCI Security Standards Council. It becomes binding on a merchant or service provider through the contracts they have with card networks and acquirers. Some U.S. states have referenced PCI DSS in legislation, but the standard itself is not government-issued.
If we use Stripe / Apple IAP / Google Play, are we still in PCI scope?
Yes, but at the smallest scope — typically SAQ A for merchants that fully outsource cardholder-data handling. The cardholder data never touches your servers, but the obligations don't disappear: you must ensure your code does not see, log, or transmit the PAN, and that any redirect/iframe to the payment processor is itself well-protected.
Does using Respectlytics by itself resolve PCI DSS obligations for our crypto & web3 apps app?
No — and no analytics SDK can credibly answer that question. Whether your product meets PCI DSS's requirements is a property of your whole product, contracts, and operational practice, evaluated by your legal team. Respectlytics's contribution is a smaller data surface: identifying fields and the regulation's special categories are rejected at the API. Whether that posture, combined with your other controls, satisfies PCI DSS for your specific app is a conversation for your counsel.
What if we already use a different analytics SDK today?
The starting point is an inventory of what your current SDK actually collects and where it sends it. Our privacy self-assessment worksheet walks through that in seven sections — it outputs an educational summary you can bring to your legal team.