pii.payment_card
A payment card number — valid Luhn checksum and a real issuer's BIN prefix — appears in the free text.
What it looks at#
Candidate 13-19 digit runs (grouped with spaces or dashes the way people actually type card numbers) are checked against the Luhn checksum, then against the published BIN prefix ranges for Visa, Mastercard, American Express, Discover, Diners Club and JCB. Luhn alone passes roughly one random number in ten; the issuer-prefix check is what keeps this from flagging arbitrary digit runs.
The matched network — visa, mastercard, amex, discover, diners or jcb — is
returned as network on the match in data.matches[]. It is absent when a match’s
network can’t be determined, which does not happen today since every match here comes
from one of those six ranges.
Public test numbers are not reported: the card numbers printed in Stripe, PayPal, Adyen
and card-scheme documentation (4242 4242 4242 4242, 4111 1111 1111 1111,
5555 5555 5555 4444, 3782 822463 10005, and about sixty more) identify no cardholder,
and neither does any number with a run of eight or more identical digits.
Why it matters#
A full, checksum-valid card number matching a real issuer’s range is about as sensitive as free text gets — this gate exists partly so a card number pasted into a support ticket or a bug report doesn’t sit there unnoticed.
What to do#
High severity. Treat any hit as something to redact immediately and to investigate why a raw card number reached a text field at all — that’s usually a signal a form or an integration is capturing more than it should (PAN data belongs in a PCI-scoped vault, not in free text).