Skip to main content

Objective

This module equips engineering, compliance, product, and executive teams with a clear understanding of:
  • What compliance frameworks (like PCI-DSS) apply to virtual card systems
  • How Visa, Mastercard, and other scheme rules affect what you build
  • How to stay ahead of audits, regulator queries, and partner evaluations
  • What technical and process controls must be in place to be compliant and audit-ready

Understanding PCI-DSS for virtual cards

PCI-DSS (Payment Card Industry Data Security Standard) is the global benchmark for how cardholder data is stored, processed, and transmitted. While your system may not be storing full PAN/CVV (as cards are issued via a licensed third party), you may still:
  • Display partial card data
  • Transmit data during card creation, top-up, or spend
  • Log metadata (e.g. last 4 digits, BIN, MCC)
  • Proxy card information through your frontend or backend
Your PCI responsibilities (as a card distributor or integrator):

Card scheme rules (Visa, Mastercard, etc.)

Your issuing partner is bound by Visa and Mastercard scheme rules, and so are you indirectly. Key expectations: If your platform enables top-up → spend → withdraw, it may fall under stored value or e-money compliance zones, which triggers additional local obligations (e.g., in the EU, UK, or Nigeria).

Examples of compliance failures

Regulatory zones that may apply

Even if you’re not directly licensed, your platform must design for: You are a regulated surface, even if not a licensed entity. Design like you’re regulated.

Partner due diligence readiness

Issuers, banks, and card processors may request due diligence and audit responses. You must be able to demonstrate:
  • Secure card issuance processes
  • KYC enforcement prior to high-risk MCCs
  • Card freeze/terminate workflows
  • Refund reconciliation across wallet/float/card
  • Transparent ledger tracking and transaction matching
  • Chargeback handling playbooks

Developer & product responsibilities

Audit checklist (internal readiness)

  • TLS 1.2+ enforced on all endpoints
  • No PAN/CVV in logs or response bodies
  • 2FA enabled for all admin/card dashboard access
  • Internal card operations are audit-logged
  • Webhooks signed and verified
  • Refund/chargeback SLAs met 99% of the time
  • KYC enforced before spending on MCC 6051, 7995, 4829
  • Partner card scheme documentation accessible
  • Float exposure reviewed weekly
  • Compliance reviews logged quarterly

Module 9 knowledge check

1. What does PCI-DSS primarily govern?

A. Merchant payouts B. Card issuance business models C. Storage and transmission of cardholder data D. Revenue reporting Answer: C

2. What must you never store or log?

A. Merchant name B. PAN/CVV in plaintext C. MCC codes D. BIN metadata Answer: B

3. Which MCCs are considered high-risk and require compliance safeguards?

A. 5732 and 5812 B. 7995, 6051, 4829 C. 4411 and 4511 D. 5045, 5065 Answer: B