# Card Data Scope

This project treats PAN and CVV as highly sensitive cardholder data.

## Current Controls

- The local card issuer generates PAN and CVV only during virtual card creation.
- The API returns PAN and CVV only in the `POST /v1/virtual-cards` create response.
- `cardissuer.SensitiveCard` does not serialize PAN or CVV through default JSON marshalling.
- The create endpoint must explicitly call `OneTimeDisclosure()` to include one-time card details.
- The database stores only card metadata: `last4`, expiry, status, spending limits, external IDs and an HMAC PAN fingerprint.
- Card issuer webhook payloads and card authorization raw events are redacted before storage.
- Audit metadata uses safe fields such as `last4`, status, amount, currency and external IDs.

## Allowed Card Metadata

- Card ID and external card ID.
- Card network and card type.
- Cardholder name.
- Last four digits.
- Expiry month and year.
- Status and spending limit state.
- HMAC PAN fingerprint used only for duplicate detection or investigation.

## Prohibited Outside The One-Time Create Response

- Full PAN.
- CVV, CVC, CVV2 or CVC2.
- Track data or magstripe data.
- Provider payloads containing unredacted PAN or CVV.
- Logs, audit events, admin exports or frontend persistence containing PAN or CVV.

## Production Notes

These controls reduce accidental scope inside the demo/local issuer implementation, but they do not complete PCI DSS readiness. Before real card issuing, complete a formal PCI DSS scope assessment with the issuer or processor, prefer issuer-hosted/tokenized card data handling, document data-flow diagrams, validate logging/export controls, and approve the card data environment with security/compliance owners.