PCI-DSS vs crypto payments: what actually applies in 2026

Every other week a procurement team sends us the same email: "Before we can integrate, please confirm BchainPay is PCI-DSS compliant." The honest answer is "PCI-DSS doesn't apply to the part of the flow we're running for you, but here's what does, and here's the SAQ you should file." That answer takes a 40-minute call. This post is the call.

If you're building a stablecoin checkout, accepting USDC/USDT for a SaaS, or wiring up an on-chain donation page, this is what PCI-DSS covers, what it doesn't, and where teams still get burned.

What PCI-DSS actually regulates#

PCI-DSS v4.0.1 (in force since 31 March 2025) is a contract enforced by the card brands — Visa, Mastercard, Amex, Discover, JCB — through acquiring banks. It exists to protect cardholder data (CHD) and sensitive authentication data (SAD). The standard's own glossary defines those as:

• PAN (Primary Account Number, the 13–19 digit card number)
• Cardholder name, expiry, service code (when stored with the PAN)
• Full track data, CAV2/CVC2/CVV2/CID, PIN/PIN block

If none of those data elements ever touch your system, PCI-DSS as written doesn't apply to that data flow. That's the whole legal hook. A USDC payment never produces a PAN, so the PAN-protection rules (encryption at rest, key rotation, masking, render unreadable, etc.) have nothing to operate on.

But "doesn't apply" is doing a lot of work in that sentence. Let's unpack it.

Pure crypto checkout: where the standard goes quiet#

A clean crypto-only flow looks like this:

// Server-side: create a payment intent
const intent = await fetch('https://api.bchainpay.com/v1/payment_intents', {
  method: 'POST',
  headers: {
    'authorization': `Bearer ${process.env.BCHAINPAY_SECRET}`,
    'content-type': 'application/json',
  },
  body: JSON.stringify({
    amount: '49.00',
    currency: 'USDC',
    chain: 'base',
    metadata: { order_id: 'ord_8821' },
  }),
}).then(r => r.json());
 
// Client-side: render intent.address + intent.uri (BIP-21 / EIP-681)

The shopper sends USDC to the deposit address (or signs an EIP-3009 authorization, etc.). At no point does a PAN, CVV or magnetic stripe exist anywhere in the call graph. The objects in flight are:

• A wallet address (public, by definition)
• An on-chain transaction hash (public)
• An amount and chain identifier
• A merchant-defined order id

None of that is CHD or SAD under PCI's definitions. The DSS controls that target CHD storage, transmission and display do not bind a crypto-only flow.

What this means in practice: if you accept only on-chain payments, you are not in PCI scope, you do not need an SAQ, and you do not need a QSA. Procurement will still ask you to attest to it. We attach a short letter to RFPs that says exactly the above; that's usually enough.

The hybrid trap: "we also take cards"#

Here's where 80% of the real-world confusion lives. Most merchants who add crypto are not pure-crypto — they already have Stripe, Adyen, Braintree, or a direct acquirer relationship for cards. The moment a PAN flows through any system you operate, you are in PCI scope, and the size of that scope depends on how the PAN gets in.

Three common patterns:

The crypto half of your checkout doesn't change which SAQ you file, but it does change two things you should write down:

1. Network segmentation. The infrastructure handling crypto addresses, webhooks, and on-chain confirmations should sit in a different VPC / project from your cardholder-data environment (CDE). PCI-DSS 1.3 / 1.4 want clear boundaries; mixing the two makes both halves harder to audit.
2. Shared auth surfaces. If the same admin SSO covers both your Stripe dashboard and your crypto treasury, the PCI scope creeps onto the SSO provider. Use distinct roles, and for high-value wallets, hardware-backed signers.

What the standard does still touch in a crypto stack#

Even with no PAN in sight, several PCI-DSS v4 requirements describe controls that any payments-grade crypto system should already meet — not because the standard binds you, but because acquiring banks, cyber-insurance underwriters and SOC 2 auditors will hold you to the same bar. The mappings worth knowing:

• Req 6 (Develop and maintain secure systems). Dependency scanning, SAST/DAST in CI, signed deployments. For a crypto stack this also means pinning RPC endpoints and verifying smart contract addresses against a checked-in allowlist.
• Req 8 (Identify users and authenticate access). MFA for any console that can move funds, hardware keys for treasury operations, short-lived API tokens. Treat your withdrawal API like cardholder data even though it isn't.
• Req 10 (Log and monitor all access). Immutable audit logs for every signing operation, address generation, sweep, and webhook redelivery. Ship them to a write-once store.
• Req 11 (Test security regularly). Quarterly external scans for any internet-facing surface. For a crypto merchant that's the checkout page, the webhook receiver, and the admin console.
• Req 12 (Information security policy). A written incident-response plan that includes on-chain-specific scenarios: lost signer, compromised hot wallet, RPC provider outage during finality, reorg on a low-finality chain.

A useful reframing: PCI-DSS is the floor for card systems. For a crypto system, treat it as a checklist of controls you should already have, ignore the PAN-specific requirements, and add the on-chain controls PCI doesn't know about.

What PCI-DSS doesn't cover (but auditors will ask about)#

This is where crypto merchants actually lose money:

Address poisoning and clipboard malware#

A shopper copies your deposit address, malware swaps it for a look-alike, the funds are gone. Mitigations:

• Render the address as a QR code and show the first/last 6 characters in a contrasting color so manual verification is fast.
• For B2B invoices, sign the deposit address with the merchant's key and ship the signature in the email so the recipient can verify client-side.

Reorg-driven double-credit#

You credited an order on 1 confirmation. The chain reorged. The shopper has the goods and the funds. PCI says nothing about this. BchainPay's defaults — 12 blocks on Ethereum mainnet, "finalized" on Solana for >$1,000, and a follow-up payment_intent.invalidated webhook on reversion — exist precisely to plug this gap. If you implement webhooks yourself, your handler must accept that the latest event for a payment_intent.id is the truth.

Sanctions screening#

OFAC, UK OFSI, EU consolidated lists. Cards push this onto the acquirer; on-chain you screen the counterparty address before crediting an order or before paying out. This is not PCI, this is BSA / AML / sanctions law, and it applies in the US whether or not you think of yourself as a money services business.

Travel Rule (FATF Recommendation 16)#

For transfers above the local threshold (USD 1,000 in the US, EUR 1,000 in the EU under TFR) between hosted wallets, you must transmit originator/beneficiary information to the receiving VASP. Pure merchant flows (consumer wallet → your treasury) generally don't trigger it; payouts to other VASPs do. Worth a separate post; not PCI.

Key custody#

PCI-DSS Requirement 3.5 / 3.6 covers cryptographic key management for PANs. The same principles — split knowledge, dual control, key rotation, HSM-backed storage — map cleanly onto custody of signing keys. We use FIPS 140-2 Level 3 HSMs for hot wallets and a 3-of-5 threshold scheme for cold storage. PCI auditors will recognise the controls even if the data being protected is different.

A concrete RFP-grade answer#

When procurement asks "are you PCI-DSS compliant?", here's the template that ends the conversation:

BchainPay processes only on-chain payments. Cardholder data as defined
by PCI-DSS v4.0.1 (PAN, CVV, magnetic stripe, PIN) does not enter our
systems at any point in the integration, so PCI-DSS does not apply to
the merchant<>BchainPay flow.
 
For the controls PCI-DSS requires that *do* apply to any payments-grade
system, BchainPay maintains:
 
- SOC 2 Type II (annual)
- ISO/IEC 27001:2022 (annual)
- Quarterly external penetration tests
- HSM-backed hot wallet signing (FIPS 140-2 Level 3)
- Threshold-signed cold storage with split knowledge / dual control
- Immutable audit log of every signing event (Req 10 equivalent)
- MFA + hardware keys for all production console access (Req 8)
- Sanctions screening on every counterparty address (OFAC, OFSI, EU)
 
The merchant remains responsible for PCI-DSS compliance of any card
acceptance flow they operate alongside crypto acceptance.

Procurement signs that. Save it as a PDF.

Key takeaways#

• PCI-DSS regulates cardholder data. A pure crypto checkout doesn't generate any, so the PAN-specific controls don't bind.
• The moment you also take cards, your SAQ type is determined by how the PAN reaches you, not by the existence of a crypto sidecar. Segment the two environments to keep scope tight.
• Treat PCI-DSS v4 Requirements 6, 8, 10, 11 and 12 as a free checklist for the crypto half — they encode controls every payments-grade system should already meet.
• The real risks in a crypto checkout — address poisoning, reorgs, sanctions, key custody, Travel Rule — sit outside PCI entirely. Put them in your incident response plan explicitly.
• Have a one-page attestation ready for procurement. It saves a 40-minute call every time.

If you'd rather inherit most of these controls instead of building them, the BchainPay docs cover the control mapping in more depth and our security page lists the current attestation reports. Sandbox keys are free, no card required (which is sort of the whole point).