Sources, Methodology & Verification Policy
This document outlines the exact mathematical algorithms used to synthesize test numbers, clarifies the technical distinction between generic synthetic numbers and provider sandbox credentials, and details our official verification policy.
1. Synthetic Card Generation Methodology
Every synthetic payment card number generated by TestCardTools.pro is constructed purely through client-side mathematical algorithms adhering to the ISO/IEC 7812 international standard for identification cards.
A. Major Industry Identifier (MII) & Network Prefix
The leading digit determines the major industry category (e.g., 4 and 5 represent banking and financial institutions). We allocate official network prefix ranges defined by each scheme:
- Visa: Prefix 4 (16, 13, 19-digit length)
- Mastercard: 51-55, 2221-2720 (16-digit length)
- American Express: 34, 37 (15-digit length)
- Discover: 6011, 65, 644-649, 622126-622925 (16-digit length)
- JCB: 3528-3589 (16-digit length)
- UnionPay: Prefix 62 (16, 19-digit length)
B. Account Body Generation & Randomness Model
The middle digits represent the synthetic individual account identifier. Our generator employs two distinct models:
- Default Generation (Non-deterministic): Uses the browser-native
crypto.getRandomValues()Web Crypto API. This provides entropy without network transmission or server logging. - Seeded Generation (Deterministic): Uses a 32-bit Mulberry32 pseudo-random number generator (PRNG) initialized by a seed string hashed via FNV-1a. Seeded generation is explicitly non-cryptographic and intended solely for repeatable automated CI/CD test fixtures.
C. Luhn Modulo 10 Check Digit Calculation
The final digit is computed so the entire sequence satisfies the Luhn algorithm (ISO/IEC 7812-1):
- Starting from the rightmost digit, double the value of every second digit.
- If doubling results in a number greater than 9, sum the digits of the result (equivalent to subtracting 9).
- Sum all processed values.
- The check digit is calculated as
(10 - (sum % 10)) % 10.
2. Generic Synthetic Numbers vs. Official Gateway Sandbox Cards
A critical distinction must be understood when engineering and testing payment checkout systems:
Generic Synthetic Numbers
Purpose: Client-side UI validation, form masking, Luhn error detection, and local component unit tests.
Behavior: They pass regex checks and Luhn Modulo 10 checksum validators. However, because they are purely synthetic and unassociated with real merchant accounts, they cannot authorize transactions against real banking networks or gateway sandbox APIs.
Official Gateway Sandbox Cards
Purpose: Backend API end-to-end integration, 3D Secure challenge simulation, webhook testing, and decline code verification.
Behavior: Pre-registered in gateway mock simulators (e.g. Stripe, PayPal, Adyen). Each specific card number or trigger simulates a deterministic processing outcome (e.g. insufficient_funds, card_declined, 3DS_challenge).
3. Official Gateway Verification Protocol
To ensure zero false positives and eliminate outdated or fabricated test values, all gateway sandbox entries published on TestCardTools.pro adhere to a strict verification protocol:
- No Inferred or Remembered Values: We do not extrapolate or guess test numbers. If a gateway does not explicitly document a specific card for an error scenario, we do not fabricate one.
- Direct Documentation Extraction: Every single card record is extracted directly from the provider's active developer documentation portal:
- Stripe: docs.stripe.com/testing
- PayPal: developer.paypal.com/credit-card-number-generator
- Adyen: docs.adyen.com/.../test-card-numbers
- Braintree: developer.paypal.com/braintree/.../testing-go-live/
- Square: developer.squareup.com/docs/devtools/sandbox/payments
- Razorpay: razorpay.com/docs/payments/payments/test-card-details/
- Semantics Preservation: When a provider uses rejection triggers rather than dedicated card numbers (such as PayPal's
CCREJECT-cardholder name values), we document the exact trigger mechanism rather than fabricating card numbers.
4. Verification-Date Policy & Dataset Integrity
Every published gateway record includes verification metadata:
Automated tests enforce the required source, recorded-date, status, and note fields. Every current gateway value was checked against its linked official provider documentation on September 16, 2026. Where a sandbox result depends on an amount, capture setting, authentication flow, or mock-bank choice, the record states that condition explicitly.