Card Data Detection & Redaction

Preczn automatically scans transaction data for potential card numbers and redacts them to maintain PCI DSS compliance. This protection applies across all transaction fields — including order, description, and metadata — to prevent accidental exposure of sensitive payment data.

Detection Criteria

When a transaction is processed, Preczn inspects string values across all fields for numeric sequences that resemble credit card numbers. A value is redacted when it meets both of the following criteria:

1. Pattern match — The value contains a sequence of 13 to 19 consecutive digits that begins with the digit 2, 3, 4, 5, or 6 (the leading digit ranges for major card networks).
2. Luhn validation — The numeric sequence passes the Luhn algorithm, the industry-standard checksum used to validate card numbers.

When both conditions are met, the matching portion of the value is replaced with [REDACTED].

For example, the well-known Stripe test card 4242424242424242 is 16 digits, starts with 4, and passes the Luhn check — so it would be redacted. Any order number or reference ID that happens to share those same characteristics will also be redacted, because the system cannot tell the difference.

📘

Why both checks?

Requiring both a pattern match and Luhn validation minimizes false positives. A random 16-digit number has roughly a 1-in-10 chance of passing the Luhn check, so most non-card numeric values pass through unaffected.

Fields Subject to Redaction

Redaction is applied to all string fields in a transaction, including but not limited to:

🚧

Important

Redaction occurs before transaction data is stored and before it is sent to your payment processor (e.g., Stripe). This means redacted values will also appear in your processor's dashboard and cannot be reversed after the fact.

Why Non-Card Values May Be Redacted

Certain non-card values — such as order numbers, invoice numbers, or reference IDs — can trigger redaction if they happen to satisfy both the pattern match and Luhn checksum. The detection uses the same rules that identify real card numbers like 4242424242424242 (Visa) or 5500000000000004 (Mastercard) — any value that structurally resembles a card number will be treated as one.

Common scenarios include:

• Long numeric order numbers — An order number like 4242424242424242 (16 digits starting with 4) that passes the Luhn check is structurally identical to a Visa card number.
• Partial redaction — A mixed alphanumeric value like D4242424242424242 where only the numeric portion triggers the match, resulting in D[REDACTED].

This is by design. Because Preczn cannot distinguish between a card number and an order number that looks like one, the system errs on the side of security to maintain PCI compliance.

Impact on Your Payment Processor

Because redaction is applied before data is transmitted to your processor, the redacted value is what appears in your processor's dashboard (e.g., Stripe). This means:

• Transaction lookups by order number in your processor may be affected if the order number was redacted.
• Reconciliation should use fields that are not subject to redaction, such as the Preczn transactionId (e.g., txn_7knvtev46z89jrgc43eb4t4r17) or your processor's transaction ID.

📘

Reconciliation Best Practice

Use the Preczn transactionId or the processor's native transaction ID for reconciliation workflows instead of order numbers. These identifiers are never redacted and provide a reliable cross-reference between systems.

Preventing Unintended Redaction

If your order numbers or reference IDs are being redacted, consider adjusting their format to avoid triggering the card detection pattern. Any of the following strategies will prevent redaction:

Use Non-Numeric Separators Within Digit Sequences

Insert hyphens, spaces, or other non-digit characters to break up long digit sequences:

✅ 4222-2222-22222          (hyphens break it into shorter segments)
✅ ORD-4242424242424242         (hyphen between prefix and digits breaks the sequence)
❌ ORD4242424242424242          (letters are ignored — the regex still finds
                              "4242424242424242" as 16 consecutive digits)

🚧

Important

Leading or trailing letters alone do not prevent redaction. The detection scans for consecutive digit sequences within the full value, skipping over non-digit characters. Only a non-digit character between digits breaks the sequence.

Keep Digit Sequences Under 13 Characters

Card numbers are 13–19 digits (e.g., 4242424242424242 is 16 digits). If possible, limit consecutive digits to 12 or fewer:

✅ 424242424242             (12 digits — below the 13-digit minimum)
❌ 4242424242424242         (16 digits — matches Visa test card, will be redacted)

Start with 0, 1, 7, 8, or 9

Major card networks use leading digits 2–6 (e.g., Visa starts with 4, Mastercard with 5, Amex with 3). The pattern only flags sequences beginning with 2 through 6, so leading with other digits avoids detection entirely:

✅ 1242424242424242         (starts with 1 — not in the 2-6 range)
✅ 0242424242424242         (starts with 0 — not in the 2-6 range)
❌ 4242424242424242            (starts with 4 — matches Visa range)
❌ 5500000000000004         (starts with 5 — matches Mastercard range)

📘

Tip

The simplest approach is to include a non-numeric separator (such as a hyphen) within the digit sequence of any reference number longer than 12 digits. For example, changing 4242424242424242 to 4242-424242424242 ensures it is never flagged. Note that adding letters only to the beginning or end (e.g., ORD4242424242424242) does not help — the separator must appear between digits.

Frequently Asked Questions