Editorial Policy

Last reviewed: August 2, 2026

This page describes how content on ccgenerator.org is chosen, sourced, verified, and corrected. It exists so you can judge whether to trust what you read here, and so you know exactly what to do when we get something wrong.

Our scope

We write about the mechanics of payment card data from a developer’s point of view. That means:

• Payment card number structure — IIN/BIN ranges, PAN length, formatting and grouping
• The Luhn algorithm and other checksum schemes
• Card network format rules and how software should detect them
• Test data management: generating, storing, and disposing of synthetic data safely
• Payment integration testing — sandbox environments, gateway test cards, fixtures
• The parts of PCI DSS that affect how developers build and test

We do not write about consumer finance. No credit card application advice, no debt management, no investment guidance, no card comparison or affiliate round-ups, no “best card for X” content. That is financial advice, it is not our expertise, and publishing it would make this site worse. If you need it, a licensed financial adviser or your own bank is the right source.

Keeping the subject narrow is deliberate. We would rather be reliable on a small topic than approximate on a large one.

How we source technical claims

Sources are ranked, and higher tiers win when they conflict.

Tier 1 — Standards. The normative documents that define the formats themselves.

• ISO/IEC 7812-1 — identification cards, identification of issuers, numbering system (https://www.iso.org/standard/70484.html)
• ISO/IEC 7813 — financial transaction cards, magnetic stripe data content (https://www.iso.org/standard/43317.html)
• ANSI X4.13 — the American standard in which the Luhn check digit formula is specified

Tier 2 — Network and industry documentation. Specifications published by the bodies that run the payment system.

• EMVCo specifications — https://www.emvco.com/
• PCI Security Standards Council document library — https://www.pcisecuritystandards.org/document_library/
• Technical publications from Visa, Mastercard, and American Express

Tier 3 — Processor documentation. Vendor-published behaviour, authoritative for that vendor and nothing else.

• Stripe testing documentation — https://docs.stripe.com/testing
• Adyen test card numbers — https://docs.adyen.com/development-resources/testing/test-card-numbers/
• PayPal, Braintree, and Square developer documentation

Tier 4 — Verification against source code. Implementations in established open-source payment libraries, used to check that a rule described on paper matches what production software actually does. Useful corroboration, never a sole source.

The rule: if a claim cannot be supported by a Tier 1–3 source, it is either labelled clearly as unsourced or it is not published. Where sources disagree, we say so rather than picking one silently.

What we verify before publishing

• BIN/IIN ranges are checked against official network documentation, not against other websites repeating each other.
• Card number lengths must be confirmed by at least two independent sources before we state them as fact.
• Code samples are run and tested before publication, and we state the language and version they were tested with.
• Gateway test card numbers are taken from the provider’s own documentation and linked back to it. We never invent a number and present it as a provider’s test card.
• Legal statements are general in nature, describe the common position across major jurisdictions, and are presented as background rather than legal advice.
• Anything about our own tool is checked against the source code that ships with the page, not against what we intended to build.

Corrections policy

We publish corrections rather than quietly editing.

• Report an error to . A source reference helps enormously and gets the fix made faster.
• When we make a substantive correction — a changed fact, a corrected range, a fixed code sample, a reversed conclusion — we add a dated correction note at the foot of the page saying what was wrong and what it now says. We do not remove the trace.
• Typographical and formatting fixes are made without a note.
• Every substantive edit updates the page’s dateModified value, so the change is visible in the structured data as well as on the page.

If you told us about an error and nothing happened within five business days, tell us again — it means the message went missing, not that we disagreed.

Review and refresh cycle

Payment standards drift, so pages are re-checked on a schedule rather than left alone until someone complains.

Each page shows when it was last reviewed. A review can conclude that nothing needed changing — in that case only the review date moves.

AI use disclosure

We would rather tell you this plainly than have you guess.

We use AI-assisted tools in drafting and editing. Every technical claim, BIN range, code sample, and legal statement is reviewed by a human against the primary sources listed above before publication. We do not publish unreviewed generated text. Where a page is primarily a reference table, we state where the data came from.

In practice this means an AI tool may help structure an explanation or tighten a paragraph, but it is never the authority for a fact. Numbers, ranges, standards references, and anything about how payment systems behave are checked by a person against a Tier 1–3 source. Code is executed, not assumed to work.

Advertising and independence

• This site carries advertising through Google AdSense. That is what makes it free.
• Advertisers have no influence over editorial content. They cannot commission it, review it before publication, or have it changed afterwards. We do not know in advance which advertisers will appear.
• We do not publish paid reviews, sponsored posts, or guest articles placed for a link.
• We currently use no affiliate links. If that ever changes, affected links will be labelled as affiliate links on the page where they appear.
• Recommending a payment provider’s sandbox over our own tool, where that is the better advice, is normal here. See the Disclaimer for how advertising is kept separate from the tool itself.

What we will not publish

Some things are simply out of bounds, regardless of traffic:

• Real cardholder data, or content derived from breaches and leaks. No stolen card details, no compiled identity-and-payment packages of the kind traded in fraud markets, under any name or in any format. Not now, not ever.
• Instructions for defeating payment, age, or identity verification systems. Explaining why synthetic numbers fail authorisation is education; explaining how to get around a control is not, and we do not do it.
• Methods for committing fraud against specific sites or services, including anything framed as a “loophole” for obtaining goods, services, or trials without paying.
• Card validation or checking services, or links to them. Testing numbers against live issuers to see which are active is fraud tooling. We do not build it, host it, describe how to build it, or link to anyone who does.

If you think something on this site crosses one of these lines, tell us and we will look at it the same day.

Contact

Corrections, sourcing questions, and comments on this policy:

Other subjects have their own addresses on the Contact page. Related reading: About, the editorial team who apply this policy, How This Site Works, Disclaimer, and Terms of Service.