[{"content":"An American Express number begins with 34 or 37, is 15 digits long, is printed in 4-6-5 groups, and carries a four-digit CID on the front of the card rather than a three-digit code on the back.\nSix of its seven format properties differ from Visa and Mastercard. Only the Luhn check digit is shared. Every one of those differences has a reason, and knowing the reasons makes them easier to remember than a table does — which matters, because Amex is the card that finds the assumptions in your payment form.\nFor numbers to test with, the American Express generator produces them.\nThe format at a glance Property Value Same as Visa/Mastercard? Prefixes 34, 37 No Length 15 digits No Grouping 4-6-5 No Check digit Luhn Yes Security code CID, 4 digits No Code location Front of card No Why 3, and why two prefixes The first digit is the Major Industry Identifier, and ISO/IEC 7812 assigns 3 to travel and entertainment. American Express landed there because that is where the company came from.\nIt is worth appreciating how literal that is. American Express was founded in 1850 as an express freight company — moving parcels, valuables and cash between cities — and moved into financial services through traveller\u0026rsquo;s cheques in 1891, decades before issuing its first charge card in 1958. By the time card numbering was standardised, Amex was a travel and entertainment business that happened to issue a card, not a bank. The MII reflects the company it was.\nDiners Club and JCB occupy the same range for the same reason, which has a practical consequence: unlike Visa, a leading digit is not enough to identify an Amex. You need two.\nThe two prefixes, 34 and 37, date from a period when the blocks separated different product lines. That distinction has not been meaningful for a long time and neither prefix tells you anything about the card today. What matters is that both are ordinary issuance — a pattern written against 37 alone, which happens more often than it should because 37 numbers are the ones most commonly used in examples, rejects a large share of genuine cards.\nWhy 15 digits Amex settled on 15 before 16 became the industry norm, and never moved. There is no technical case for either length; there is a very strong case against changing one, since it would mean reissuing every card and updating every system that touches them.\nThe number decomposes the same way as any other — prefix, account identifier, check digit. Amex simply allocates one fewer digit to the middle section: eight rather than nine on a six-digit IIN, which is a difference of a hundred million possible accounts per issuer identifier and no difference at all to how the checksum works.\nFifteen digits is the reason Amex is the canonical test case for length assumptions. The length rules across networks cover the others, but if you only ever add one non-16-digit fixture to your suite, make it this one — a right-to-left Luhn implementation written left-to-right is correct on even lengths and wrong on odd ones, so Amex is also the card that exposes that bug.\nWhy 4-6-5 The grouping mirrors how the digits are embossed on the card. It is not a standard and nothing enforces it, but it is what users see when they look at the card in their hand.\nThat is the whole argument for implementing it. Someone typing a long number checks their work by comparing the screen to the plastic, and a 4-4-4-4 mask over 15 digits puts every group boundary in a different place from the card. Nothing breaks technically; the error rate on the field goes up, on the one input where a typo costs a sale.\nfunction groupAmex(pan) { const d = String(pan).replace(/\\D/g, \u0026#39;\u0026#39;); return `${d.slice(0, 4)} ${d.slice(4, 10)} ${d.slice(10)}`; } // 378282246310005 → \u0026#34;3782 822463 10005\u0026#34; The CID American Express calls its security code the CID, it is four digits rather than three, and it is printed on the front of the card above the account number rather than on the signature panel.\nMechanically it is the same kind of value as a CVV2 or CVC2: computed by the issuer from the account number, expiry and service code under keys that never leave its hardware security module. Nothing about the four-digit form makes it stronger in any way that matters — the security comes from the keys, not the length.\nBoth differences break forms built for other networks, and they break them separately:\nA field with maxlength=\u0026quot;3\u0026quot; truncates the CID, and the payment fails with a code mismatch that looks like the customer mistyped. Help text reading \u0026ldquo;the 3 digits on the back of your card\u0026rdquo; sends the Amex holder looking at a signature panel that does not have them. Both are trivial to fix and both are still extremely common, because a form tested only with Visa numbers never surfaces either. The CVV generator emits four-digit codes for exactly this test.\nValidation const AMEX = /^3[47]\\d{13}$/; function isAmex(pan) { const digits = String(pan).replace(/\\D/g, \u0026#39;\u0026#39;); return AMEX.test(digits) \u0026amp;\u0026amp; luhnValid(digits); } Anchored at both ends, both prefixes, exactly 15 digits, paired with a checksum test rather than replacing one. Cases worth keeping:\nNumber Expected 378282246310005 valid 371449635398431 valid, 37 prefix 374245455400126 valid 378282246310004 invalid — check digit altered 3782822463100051 invalid — 16 digits 348282246310005 not Amex — 34 needs the right length and checksum All of these were executed before publication; paste the valid ones into the validator to confirm. For where Amex sits in the wider detection order — it goes first, because 3[47] is unambiguous and the other MII 3 networks need more digits — see the brand detection guide.\nProducts, and the three-party model Green, Gold, Platinum and Centurion are tiers of one consumer product. Corporate, business and co-branded cards use the same format. None of it is encoded in the number: tier, issuer and country come from a BIN database, not from the digits.\nOne structural difference does affect integration work. Visa and Mastercard run four-party models — network, issuing bank, acquiring bank, merchant — while American Express traditionally acts as network, issuer and acquirer at once, although it licenses issuance to banks in many markets.\nThat single-party arrangement is also the reason Amex behaves differently in ways that have nothing to do with the number. It sets its own interchange rather than publishing a schedule that thousands of issuers apply, which is why Amex acceptance costs merchants more and why some smaller merchants decline it outright. Disputes are handled by one organisation rather than passed between an issuer and an acquirer, which changes both the timetable and who you talk to. And because the same company sees both sides of every transaction, its fraud and approval decisions draw on data that a four-party network\u0026rsquo;s participants each only see half of. None of this is visible in the digits, and all of it is worth knowing before you assume an Amex transaction will behave like a Visa one. The practical consequence is that Amex acceptance is frequently a separate commercial arrangement, with its own pricing and sometimes its own settlement timetable and routing. Amex\u0026rsquo;s developer portal is the reference for its APIs, and the company\u0026rsquo;s own history covers the freight and traveller\u0026rsquo;s cheque origins behind that first digit.\nCommon integration mistakes Assuming 16 digits. The single most common Amex failure, in validation rules, input masks and database columns alike. A fixed three-character security code field. The field length has to follow the detected brand, which means brand detection has to run before the code field is validated. A 4-4-4-4 input mask. Correct for 16 digits, wrong for 15, and visible to the user on every keystroke. \u0026ldquo;The 3 digits on the back.\u0026rdquo; Wrong count and wrong side for one network in every checkout. Matching only 37. Both prefixes are current issuance. Late brand detection. 3[47] is decidable on the second digit — waiting longer delays the field-length switch that everything else depends on. Frequently Asked Questions Why does American Express start with 3? Because ISO/IEC 7812 assigns Major Industry Identifier 3 to travel and entertainment, and that is the industry American Express came from — it sold traveller\u0026rsquo;s cheques for sixty years before it issued a charge card. Diners Club and JCB share the 3 range for the same reason, which is why identifying an Amex needs two digits rather than one. Why are there two Amex prefixes, 34 and 37? They date from a period when the two blocks distinguished different product lines, and the distinction has not been meaningful for a long time. Today both are ordinary American Express issuance and neither tells you anything about the card beyond the network. Validation must accept both — a pattern matching only 37 will reject a large share of genuine cards. Why is an American Express number 15 digits? Because Amex settled on 15 before the industry converged on 16, and changing would have meant reissuing every card and updating every system that handles them. There is no technical advantage either way. The consequence for developers is that Amex is the card that breaks any rule hard-coded to 16 digits, and it usually breaks it in production rather than in testing. What is the CID and how is it different from a CVV? The CID is American Express\u0026rsquo;s security code: four digits, printed on the front of the card above the account number rather than on the signature panel. Mechanically it is the same kind of value as a CVV2 or CVC2 — computed by the issuer under keys that never leave its hardware security module — but the length and the location both differ, and both differences break forms built for other networks. How should an Amex number be grouped on screen? 4-6-5, as in 3782 822463 10005. That mirrors how the digits are printed on the card itself, which matters because a user checking their typing compares the screen to the plastic in their hand. A 4-4-4-4 mask on a 15-digit number puts every group boundary in the wrong place. Do I need a separate merchant agreement for Amex? Often, yes. American Express traditionally operated a three-party model in which it is the network, the issuer, and the acquirer at once, so acceptance can be a separate commercial arrangement with its own pricing and settlement timetable. Confirm it with your processor before your first Amex transaction rather than after one is declined. ","permalink":"https://ccgenerator.org/guides/amex-card-number-format/","summary":"An American Express number begins with 34 or 37, is 15 digits long, is printed in 4-6-5 groups, and carries a four-digit CID on the front of the card rather than a three-digit code on the back.\nSix of its seven format properties differ from Visa and Mastercard. Only the Luhn check digit is shared. Every one of those differences has a reason, and knowing the reasons makes them easier to remember than a table does — which matters, because Amex is the card that finds the assumptions in your payment form.","title":"Amex Card Number Format Explained"},{"content":"BIN and IIN are the same thing under two names. IIN — Issuer Identification Number — is the term in ISO/IEC 7812. BIN — Bank Identification Number — is what the payments industry says. Both refer to the leading digits of a card number that identify which institution issued it: historically six digits, now moving to eight.\nThose digits are the routing information of the payment system. They decide which network a transaction enters, which bank is asked to authorise it, and often what it costs the merchant to accept.\nThis guide is about the system behind the prefix — how the numbers get allocated, who actually stands behind a BIN, and how much of what a lookup tells you is safe to act on. The practical companions are linked in place below: one for calling a commercial database safely, one for testing your own prefix handling with synthetic data from the all-network generator.\nBIN or IIN — which term to use There is no technical distinction, only a difference in dialect.\nISO/IEC 7812-1 says IIN, and standards-adjacent documents follow it. The industry says BIN, and so does virtually every piece of tooling: BIN range, BIN table, BIN file, BIN sponsor, BIN attack. Nobody says \u0026ldquo;IIN attack\u0026rdquo;.\nThe practical rule: write IIN when you are quoting the standard, write BIN everywhere else, and never assume a colleague means something different by the other word. Where confusion does arise, it is almost never about the term — it is about the width, which is a real question with a real answer below.\nHow IINs are allocated The chain has three links, and knowing all three explains most of the surprising results a lookup can return.\nThe registration authority. ISO/IEC 7812 designates a registration authority to maintain the global register of issuer identifiers; that role is held by the American Bankers Association. It is the body that assigns identifiers and publishes the register — a clerical function rather than a commercial one.\nThe schemes. Card networks hold large blocks and subdivide them. Everything beginning with 4 is Visa; 51–55 and 2221–2720 are Mastercard; 34 and 37 are American Express. Within their block, a scheme allocates ranges to the institutions it licenses. This is why the first digit tells you the network with high confidence — that assignment sits at the top of the tree and effectively never moves. The rest of the structural picture is in the card number structure guide.\nThe issuers. An institution receiving a range subdivides it further across its own products: a credit portfolio in one sub-range, a debit portfolio in another, a co-brand programme in a third, a different country\u0026rsquo;s operation in a fourth. A single bank can hold dozens of BINs, and two cards from the same bank can differ in the sixth digit because they belong to different products.\nBIN sponsorship, and why the issuer name lies Here is the part that is rarely written down, and that explains most \u0026ldquo;wrong\u0026rdquo; lookup results.\nIssuing cards requires a licence from the scheme, and most fintechs do not have one. Instead they work with a BIN sponsor: a licensed bank that holds the BIN and issues the cards on the fintech\u0026rsquo;s behalf. The card carries the fintech\u0026rsquo;s brand, its app, and its customer relationship. The BIN belongs to the sponsoring bank.\nSo when a lookup returns an issuer name, what you often get is the sponsor — a bank the cardholder has never heard of and whose name appears nowhere on the card. The data is not wrong. It is answering \u0026ldquo;which licensed institution issued this?\u0026rdquo; while you were asking \u0026ldquo;whose card is this?\u0026rdquo;, and those have been different questions since programme-managed issuing became normal.\nThe consequences are practical. Issuer-name matching for fraud rules produces false signals. Analytics that group customers by bank will merge unrelated card programmes into one sponsor bucket. And an \u0026ldquo;unknown issuer\u0026rdquo; is more often a new programme than a bad number.\nThe six-to-eight digit migration The short version: six digits allow on the order of a hundred thousand practical assignments, the space ran short, and ISO/IEC 7812-1:2017 defined an eight-digit identifier. Visa and Mastercard moved new assignments to eight digits from April 2022, as set out in Visa\u0026rsquo;s numerics guidance.\nTwo properties of the change are worth holding on to, because they follow from how allocation works rather than from any implementation detail:\nIt was an extension, not a renumbering. Existing six-digit assignments kept their first six digits; two further digits subdivide them. No card was reissued and no cardholder noticed anything, because the card number stayed exactly as long as it was. What moved was the internal boundary between \u0026ldquo;issuer\u0026rdquo; and \u0026ldquo;account\u0026rdquo;, which is invisible from outside.\nBoth widths are permanent. Six-digit assignments were not withdrawn. A card issued under one is still valid, still in wallets, and will be for as long as it keeps getting renewed. There is no cutover date after which everything is eight digits.\nTogether those produce the failure mode: two different issuers can now share the same first six digits and diverge only at the seventh or eighth. A system keyed on six digits maps both to whichever it learned first, silently, with no error raised — the payments still succeed, they just take the wrong route, carry the wrong interchange assumption, or land at the wrong acquirer. Nobody files a bug for a payment that worked.\nThe implementation checklist for handling both widths — schema, provider granularity, longest-prefix matching, and generating eight-digit test fixtures — is on the BIN generator page, next to the tool that produces the test data for it.\nWhat a BIN lookup actually returns Most sources present BIN data as fact. It is a commercially compiled best effort, and the fields differ enormously in how much they deserve your trust:\nField Example Reliability Network / scheme Visa High — derived from ranges that effectively never move Country GB High Card type debit / credit / prepaid Medium-high — usually right, occasionally stale after a product change Card level classic / gold / platinum / corporate Medium — granular, frequently repackaged, often behind Regulated status (EEA) regulated / unregulated Medium — depends on both country and issuer type being current Issuer name Example Bank plc Low — BIN sponsorship routinely obscures it The two questions worth asking about any field before you build on it: how badly does it break if it is wrong, and what does the provider return when it does not know? A service that guesses rather than answering unknown will quietly corrupt every decision downstream.\nWhat BIN data cannot decide on its own The uses — routing, interchange estimation, surcharge rules, currency conversion offers, fraud scoring, authentication flow, approval analytics — are covered on the BIN lookup page. What is worth adding here is the other half: the limits, because BIN-driven logic fails in a characteristic way.\nIt is a lookup, not a fact about the card. Every field is a claim from a file that was compiled at some point and shipped through a distribution chain. Recency is a property of your provider, not of the number. This is the opposite of the Luhn check, which is pure arithmetic over the digits in front of you and needs no external data to be correct — one of the two checks is self-contained and one is a database query, and they fail in completely different ways.\nIt cannot see the account. Nothing in the prefix knows whether the card is active, what its limit is, or whether this particular transaction will be approved. A number that is structurally perfect and sits in a real issuer\u0026rsquo;s range can still be attached to nothing at all — that is the normal state of every number this site generates.\nIt should never be a decision on its own. A country mismatch between BIN, IP, and delivery address is an input to a fraud model, not a verdict. Blocking on a single BIN signal declines travellers, expatriates, and anyone using a card issued somewhere they no longer live.\nFree lists are a provenance problem. Beyond being stale, downloadable \u0026ldquo;free BIN databases\u0026rdquo; of uncertain origin are sometimes compiled from leaked or scraped data, which makes ingesting one a decision about your own compliance posture as much as your data quality. If your gateway already returns brand, country, and funding — Stripe\u0026rsquo;s card object does — start there and add a vendor only when you have identified a field you genuinely cannot live without.\nBIN attacks, and why prefixes are sensitive BIN data has a fraud use as well as a business use: it is targeting information. A BIN attack generates numbers within a known issuer range and tests them at scale against a merchant\u0026rsquo;s payment endpoint, looking for combinations that authorise. This is why commercial providers gate their data behind accounts and terms of use, and why this site publishes no BIN lists and no mapping between prefixes and institutions.\nIf you run a checkout, the defence is entirely on your side of the transaction:\nRate limit by IP, by device, and by card prefix — bursts are the signature, and a single-number-per-minute limit is not one. Block on failure patterns, not just volume — many declines from one BIN in a short window is the specific shape to alert on. Protect zero-amount and one-unit authorisation endpoints. Card testing gravitates to them because they are cheap, quiet, and often unauthenticated. Add friction at the right layer — a CAPTCHA or device attestation on the payment step, not on the whole site. Turn on your gateway\u0026rsquo;s card-testing protection. Stripe Radar and its equivalents exist for this and are usually a configuration change rather than a project. The attacker\u0026rsquo;s economics matter here: card testing is profitable because it is cheap to run at volume. Anything that raises the per-attempt cost works, which is why rate limiting outperforms cleverness. The carding guide covers the broader picture, and the brand detection guide covers identifying a network from a prefix without a lookup service at all.\nFrequently Asked Questions What is the difference between BIN and IIN? None — they name the same digits. IIN, for Issuer Identification Number, is the term ISO/IEC 7812 uses. BIN, for Bank Identification Number, is what the payments industry says in practice, and it survives in every compound term: BIN range, BIN table, BIN file, BIN sponsor. Standards documents say IIN, engineers say BIN, and both mean the leading digits that identify the issuing institution. How many digits is a BIN? Six or eight, and you have to handle both. Six was the original width; ISO/IEC 7812-1:2017 defined an eight-digit identifier and the major schemes moved new assignments to eight digits from April 2022. Existing six-digit assignments were not withdrawn or renumbered, so both widths circulate simultaneously and will for years. Code that assumes one width is wrong about the other. Can I look up which bank issued a card? A commercial BIN database will return an issuer name, but treat it as the least reliable field it gives you. Fintechs and card programmes routinely issue under a licensed bank\u0026rsquo;s BIN, so the name you get back is often the sponsoring bank rather than the brand printed on the card. The network and the country are dependable; the issuer name frequently is not. Why is the BIN moving from 6 to 8 digits? Arithmetic. Six digits allow on the order of a hundred thousand practical assignments worldwide, and the growth in card issuing — driven mostly by fintechs and programme managers — was consuming the remaining space faster than the schemes could reclaim it. Eight digits raises the ceiling by roughly two orders of magnitude. Nothing changes for the cardholder: the card number stays the same length, only the boundary between issuer and account moves. Does my payment provider give me BIN data? Usually enough of it. Stripe\u0026rsquo;s card object returns brand, a two-letter country, and a funding type of credit, debit, prepaid, or unknown, and most other gateways return equivalents alongside the authorisation. That covers routing, surcharge, and currency logic with no extra vendor and no extra latency. The main gap is the issuer name, which is also the field you should trust least. What is a BIN attack? Generating candidate numbers inside a known issuer range and testing them at scale against a merchant\u0026rsquo;s payment endpoint, looking for combinations that authorise. It is a merchant-side problem rather than a card-number problem: the defence is rate limiting, blocking bursts of failures from one prefix, protecting zero-amount authorisation endpoints, and turning on your gateway\u0026rsquo;s card-testing protection. It is also the reason no reputable source publishes BIN lists. ","permalink":"https://ccgenerator.org/guides/bin-iin-explained/","summary":"BIN and IIN are the same thing under two names. IIN — Issuer Identification Number — is the term in ISO/IEC 7812. BIN — Bank Identification Number — is what the payments industry says. Both refer to the leading digits of a card number that identify which institution issued it: historically six digits, now moving to eight.\nThose digits are the routing information of the payment system. They decide which network a transaction enters, which bank is asked to authorise it, and often what it costs the merchant to accept.","title":"BIN and IIN: What Card Prefixes Tell You"},{"content":"Most card brand regexes on the internet are out of date. They were written before Mastercard added the 2221–2720 range in 2017, before Visa issued 19-digit numbers, and before UnionPay started using the 81 prefix. A regex from a 2013 Stack Overflow answer will reject cards that are in wallets today.\nHere are current patterns, each executed against boundary values, plus the detection order that matters and the cases where a regex is the wrong tool.\nThe patterns const CARD_PATTERNS = { visa: /^4\\d{12}(?:\\d{3})?(?:\\d{3})?$/, mastercard: /^(?:5[1-5]\\d{4}|222[1-9]\\d{2}|22[3-9]\\d{3}|2[3-6]\\d{4}|27[01]\\d{3}|2720\\d{2})\\d{10}$/, amex: /^3[47]\\d{13}$/, discover: /^(?:6011\\d{12}|65\\d{14}|64[4-9]\\d{13}|622(?:12[6-9]|1[3-9]\\d|[2-8]\\d\\d|9[01]\\d|92[0-5])\\d{10})(?:\\d{3})?$/, jcb: /^35(?:2[89]|[3-8]\\d)\\d{12,15}$/, diners: /^3(?:0[0-5]\\d{11,16}|095\\d{10,15}|[689]\\d{12,17})$/, unionpay: /^(?:62|81)\\d{14,17}$/, maestro: /^(?:5[06-9]|6\\d)\\d{10,17}$/, troy: /^9792\\d{12}$/, }; Each pattern encodes both the prefix range and the permitted lengths, which is why they are longer than the prefix-only versions you usually see. The lengths are not decoration — they differ by network, and a pattern that ignores them will match a truncated number as readily as a complete one.\nThe trailing (?:\\d{3})? on Visa and Discover is the 19-digit case. It is easy to leave out and expensive to leave out, as the test suite below demonstrates.\nReading each pattern Visa — everything beginning with 4, at 13, 16 or 19 digits. The two optional three-digit groups are the 16 and 19-digit forms; the base 4\\d{12} is the legacy 13-digit format that most patterns forget exists. The Visa format guide covers why Visa is the only network identifiable from a single digit.\nMastercard — the 51–55 block plus the decomposed 2221–2720 range, each alternative written to six digits so that a single \\d{10} tail fixes the total at 16. Mastercard uses no other length, which is why this is the only pattern here with a fixed tail.\nAmerican Express — 34 or 37, always 15 digits. The simplest pattern on the page and the one most likely to be broken by surrounding code, since a 15-digit number and a four-digit security code both violate the assumptions of a form built around 16 and 3.\nDiscover — four separate ranges that have accumulated over time: 6011, 65, 64[4-9], and the 622126–622925 block, which is itself another numeric range needing decomposition. The optional trailing group covers 19 digits.\nJCB — 3528 through 3589, expressed as 2[89] or [3-8]\\d after the leading 35, at 16 to 19 digits.\nDiners Club — three branches for 300–305, 3095, and 36/38/39, spanning 14 to 19 digits. The 14-digit form is the shortest PAN in common circulation and the one that minimum-length rules exclude by accident.\nUnionPay — 62 or 81, 16 to 19 digits. Worth remembering that some UnionPay ranges are not Luhn-valid, so a checksum failure on these prefixes should warn rather than block.\nMaestro — 50, 56–69, and 12 to 19 digits, which is the broadest pattern here in both dimensions. That breadth is exactly why it goes last.\nTroy — 9792 at 16 digits. The narrowest pattern, because the scheme was allocated a single four-digit block under the MII reserved for national standards bodies.\nWhy Mastercard is the ugly one A numeric range cannot be expressed as a prefix match, so 2221–2720 has to be decomposed:\nRange Pattern piece Why 2221–2229 222[1-9] Lower boundary 2230–2299 22[3-9]\\d 2300–2699 2[3-6]\\d\\d Bulk of the range 2700–2719 27[01]\\d 2720 2720 Upper boundary Five alternatives for one contiguous range. Anyone who writes ^2[2-7] instead is accepting 2200–2799, which includes numbers Mastercard has not been assigned — and the Mastercard page has test numbers for checking the edges.\nDetection order matters Several ranges overlap, so the first pattern that matches wins and the order determines what you get:\nOverlap Networks Resolution 65 Discover, Maestro Discover first — its ranges are specific 64[4-9] Discover, Maestro Same 622126–622925 Discover, UnionPay A historical partnership; a business rule decides 6… broadly Maestro, Discover, UnionPay Maestro last — it is the catch-all The rule is most specific first, broadest last:\nconst DETECTION_ORDER = [ \u0026#39;amex\u0026#39;, \u0026#39;visa\u0026#39;, \u0026#39;mastercard\u0026#39;, \u0026#39;troy\u0026#39;, // unambiguous prefixes \u0026#39;discover\u0026#39;, \u0026#39;jcb\u0026#39;, \u0026#39;diners\u0026#39;, \u0026#39;unionpay\u0026#39;, // specific ranges \u0026#39;maestro\u0026#39;, // broad catch-all, last ]; function detectBrand(input) { const pan = String(input).replace(/\\D/g, \u0026#39;\u0026#39;); for (const brand of DETECTION_ORDER) { if (CARD_PATTERNS[brand].test(pan)) return brand; } return null; } Order is not a style preference here. With Maestro placed earlier, 6011… resolves to Maestro and every Discover card in your system is mislabelled.\nProgressive detection while typing While someone is still typing there is no complete number, so the full patterns match nothing. Prefix-only patterns are a separate set:\nconst PREFIX_PATTERNS = { amex: /^3[47]/, visa: /^4/, mastercard: /^(5[1-5]|222[1-9]|22[3-9]|2[3-6]|27[01]|2720)/, troy: /^9792/, discover: /^(6011|65|64[4-9]|622)/, jcb: /^35(2[89]|[3-8])/, diners: /^3(0[0-5]|095|[689])/, unionpay: /^(62|81)/, maestro: /^(5[06-9]|6)/, }; function detectBrandFromPrefix(input) { const pan = String(input).replace(/\\D/g, \u0026#39;\u0026#39;); if (pan.length \u0026lt; 1) return null; for (const brand of DETECTION_ORDER) { if (PREFIX_PATTERNS[brand].test(pan)) return brand; } return null; } The useful property of this set is that it returns null while the input is still ambiguous, which is exactly the behaviour you want:\nTyped so far Result Why 2 null Could be Mastercard; not enough digits to know 222 null Still could fall below 2221 2223 mastercard Now determined 5 null Mastercard needs 5[1-5], Maestro needs 5[06-9] 51 mastercard 62 unionpay Discover\u0026rsquo;s overlapping range needs 622 6011 discover Show the brand logo as early as you can, and never while it is ambiguous. Displaying the wrong logo and then swapping it is worse than showing nothing: the flicker reads as a bug, and on the one field where users are already nervous about typos, it invites them to re-check a number that was fine.\nWhen a regex is the wrong tool Being clear about the limits is what separates a working detector from a source of subtle bugs:\nDebit or credit — not encoded in the number at all. That needs a BIN database, which is what BIN lookup is for. Country of issue — same answer. The BIN and IIN guide explains what the prefix does and does not identify. Whether the card exists — a regex checks shape. Existence is a question only the issuing bank answers. New ranges — a regex is static and networks add ranges. This is maintenance work, not a one-time task. Anything that affects money — your payment provider returns the brand it actually routed the card as. Use your regex for the interface and the provider\u0026rsquo;s answer for business logic. When the two disagree, the provider is right and your pattern has aged. That last point is the architectural one. Detection in the browser is a display concern; treating it as a source of truth means a stale pattern can misprice a transaction or route it to the wrong acquirer, and the failure is silent because the card still works.\nThree regex mistakes specific to this problem Forgetting the anchors. Without ^ and $ these patterns match a substring, so a 19-digit number matches the 16-digit Visa pattern at its prefix and any longer garbage string containing a valid-looking run matches too. Every pattern on this page is anchored at both ends deliberately, and removing either anchor turns a length check into no check.\nTesting before stripping. Users paste 4539 1488-0343 6467. Run replace(/\\D/g, '') first, always, and do it in one place rather than at each call site — a pattern that works in your unit test and fails on real input is nearly always this.\nBuilding patterns by string concatenation. Assembling a range from user-supplied or configuration data invites both injection and catastrophic backtracking. These patterns have no nested quantifiers and cannot backtrack pathologically; a generated one might. Keep them as literals.\nMaintenance Review the patterns annually. Ranges change rarely and consequentially. Log every disagreement between your detection and the brand your provider reports. That log is your early-warning system, and it costs one line. Never hard-reject an unrecognised prefix. Accept it, let the provider decide, and treat null as \u0026ldquo;unknown\u0026rdquo; rather than \u0026ldquo;invalid\u0026rdquo; — new BIN ranges appear before your regex learns about them. Keep the test suite next to the patterns in the same file. A pattern edited without its boundary cases re-run is the specific change that ships this class of bug, and the suite takes milliseconds. The failure mode worth guarding against is not a pattern that breaks loudly. It is one that keeps working for the 95% of cards you see daily while quietly misclassifying the rest, which is why the boundary cases matter more than the happy-path ones.\nThe full test suite Copy this alongside the patterns. Every case below was executed before this page was published, including the boundary cases either side of each range:\nconst TESTS = [ [\u0026#39;4539148803436467\u0026#39;, \u0026#39;visa\u0026#39;], [\u0026#39;4222222222222\u0026#39;, \u0026#39;visa\u0026#39;], // 13-digit [\u0026#39;4532015112830366187\u0026#39;, \u0026#39;visa\u0026#39;], // 19-digit [\u0026#39;5425233430109903\u0026#39;, \u0026#39;mastercard\u0026#39;], [\u0026#39;2223003122003222\u0026#39;, \u0026#39;mastercard\u0026#39;], // 2-series [\u0026#39;2221000000000000\u0026#39;, \u0026#39;mastercard\u0026#39;], // lower boundary [\u0026#39;2720999999999999\u0026#39;, \u0026#39;mastercard\u0026#39;], // upper boundary [\u0026#39;2220000000000000\u0026#39;, null], // below 2221 [\u0026#39;2721000000000000\u0026#39;, null], // above 2720 [\u0026#39;374245455400126\u0026#39;, \u0026#39;amex\u0026#39;], [\u0026#39;378282246310005\u0026#39;, \u0026#39;amex\u0026#39;], [\u0026#39;6011111111111117\u0026#39;, \u0026#39;discover\u0026#39;], [\u0026#39;6011000000000000000\u0026#39;, \u0026#39;discover\u0026#39;], // 19-digit [\u0026#39;3530111333300000\u0026#39;, \u0026#39;jcb\u0026#39;], [\u0026#39;3528000000000000\u0026#39;, \u0026#39;jcb\u0026#39;], // lower boundary [\u0026#39;3589000000000000\u0026#39;, \u0026#39;jcb\u0026#39;], // upper boundary [\u0026#39;3527000000000000\u0026#39;, null], // below 3528 [\u0026#39;3590000000000000\u0026#39;, null], // above 3589 [\u0026#39;30569309025904\u0026#39;, \u0026#39;diners\u0026#39;], [\u0026#39;9792000000000000\u0026#39;, \u0026#39;troy\u0026#39;], [\u0026#39;6212345678901234\u0026#39;, \u0026#39;unionpay\u0026#39;], [\u0026#39;8171999927660000\u0026#39;, \u0026#39;unionpay\u0026#39;], [\u0026#39;5018000000000000\u0026#39;, \u0026#39;maestro\u0026#39;], [\u0026#39;6759000000000000\u0026#39;, \u0026#39;maestro\u0026#39;], ]; TESTS.forEach(([pan, want]) =\u0026gt; { const got = detectBrand(pan); console.assert(got === want, `${pan}: expected ${want}, got ${got}`); }); One case in that list is there because it caught a real bug during writing. 6011000000000000000 is a 19-digit Discover number, and against the widely circulated Discover pattern — which allows only 16 digits — it falls through every specific rule and is detected as Maestro. The (?:\\d{3})? suffix on the Discover pattern above is the fix. If you copied a Discover regex from anywhere, that is the case to try first.\nThe numbers used here are synthetic and Luhn-valid where a real card would be; generate more with the card generator, check them against the validator, and pair this with the Luhn implementations — brand detection and checksum validation are separate checks and both belong in your form.\nThe patterns and test cases above were last checked against provider documentation on 4 August 2026. Providers do change what they publish — the official link beside each claim is authoritative. Frequently Asked Questions What regex detects a Visa card? Visa is the easy one: /^4\\d{12}(?:\\d{3})?(?:\\d{3})?$/ matches the 13, 16 and 19-digit lengths Visa permits, all of which begin with 4. The common mistake is /^4\\d{15}$/, which accepts only 16 digits and silently rejects both the legacy 13-digit format and the newer 19-digit ranges. Why does my Mastercard regex fail on new cards? Because it predates 2017. Mastercard exhausted the 51–55 space and began issuing in 2221–2720, an MII originally earmarked for airlines. Any pattern written before that — and most answers still circulating do — classifies a 2-series card as unknown. The range also cannot be written as a simple prefix match, since it is a numeric range and has to be decomposed into five alternatives. Should I detect the card brand in the browser? For display, yes — showing the right logo as someone types is exactly what this is for. For business logic, no. Your payment provider returns the brand it actually routed the card as, and that answer is authoritative where yours is a static pattern that ages. Use the regex for the interface and the provider\u0026rsquo;s response for anything that affects money. Can regex tell me if a card is debit or credit? No. Nothing in the digits encodes funding type, country, issuer, or card level — those come from a BIN database, which is commercially compiled data rather than something the number carries. A regex can tell you the network with reasonable confidence and nothing else at all. How often do card BIN ranges change? Rarely, but the changes matter when they happen: Mastercard\u0026rsquo;s 2-series in 2017 and the 19-digit ranges are both recent enough that code written a decade ago is wrong today. Review your patterns annually, and log any disagreement between your detection and the brand your provider reports — that mismatch is the earliest signal that a pattern has aged. ","permalink":"https://ccgenerator.org/guides/card-brand-detection-regex/","summary":"Most card brand regexes on the internet are out of date. They were written before Mastercard added the 2221–2720 range in 2017, before Visa issued 19-digit numbers, and before UnionPay started using the 81 prefix. A regex from a 2013 Stack Overflow answer will reject cards that are in wallets today.\nHere are current patterns, each executed against boundary values, plus the detection order that matters and the cases where a regex is the wrong tool.","title":"Card Brand Detection with Regex"},{"content":"A token is a stand-in for a card number that is useless to anyone who steals it. Your system stores the token; the provider stores the card. If your database is breached, the attacker gets a list of identifiers that only work against your own account with that provider — not card numbers they can spend.\nThat single property is why tokenisation is the default architecture for anything storing a card, and why the alternative — encrypting card numbers yourself — is a harder problem with a worse outcome.\nTokenization is not encryption The two get used interchangeably and they are structurally different:\nEncryption Tokenization Reversible Yes, with the key No — the token has no mathematical relationship to the number If your store is breached The attacker needs the key, which may be breached alongside it The token alone is worthless PCI scope An encrypted PAN is still cardholder data, still in scope The token is generally out of scope Format Ciphertext Often format-preserving, so it looks like a card number The row that matters is the third. Encrypting card numbers is real work — key management, rotation, access control, an audit trail — and at the end of it you still hold cardholder data and still carry the scope that comes with it. The PCI guide sets out what that entails. Tokenisation sidesteps the whole category by not holding the data.\nThe format-preserving row is worth a warning too. Because tokens frequently look like card numbers — right length, sometimes a plausible prefix, sometimes even Luhn-valid — code that sees one may treat it as a PAN and log it, mask it, or validate it. That is harmless but confusing, and it is why token values should be labelled as such in your schema rather than sharing a column type with card numbers.\nThe two kinds of token This is the distinction most explanations skip, and it has real operational consequences.\nGateway tokens are issued by your payment provider: Stripe\u0026rsquo;s pm_… payment methods, Braintree\u0026rsquo;s payment method tokens, and the equivalents elsewhere. They are provider-specific and not portable. If you change providers, you migrate — most providers support a provider-to-provider migration, but it is a project rather than a config change, and it is worth knowing that before you have a million saved cards.\nNetwork tokens are issued by the card networks themselves: the Visa Token Service, Mastercard\u0026rsquo;s MDES, and American Express\u0026rsquo;s equivalent. They sit one level up, and that buys three things:\nThe token survives card reissuance. When a customer\u0026rsquo;s card is lost, replaced or simply expires, the network repoints the token at the new card. On a subscription business this is the difference between a customer churning silently and never noticing anything happened. Approval rates are generally higher. Issuers treat network-tokenised transactions as lower risk, because the token carries cryptographic provenance the network vouches for. Wallets already use them. Apple Pay and Google Pay are network tokenisation with a device-specific token and a per-transaction cryptogram, which is why a wallet payment exposes nothing reusable even if intercepted. Most merchants reach network tokens through their gateway rather than directly — the gateway enrols the card and manages the network relationship. Ask your provider whether it is enabled, because it often is not by default and the reissuance benefit alone usually justifies turning it on.\nHow a token is created The flow, and the property that makes it work:\nThe customer types their card into a field rendered by the provider — a hosted field or an iframe, not an input you own. That field sends the card directly to the provider, bypassing your server entirely. The provider returns a token to the browser. Your code sends the token to your server and stores it. The card number never touches your infrastructure. Not in a request body, not in a log, not in memory. That is not a policy you enforce; it is a consequence of where the input element lives.\n// Stripe Elements: the card details go from the iframe to Stripe, never through you. const stripe = Stripe(process.env.STRIPE_PUBLISHABLE_KEY); const elements = stripe.elements(); const cardElement = elements.create(\u0026#39;card\u0026#39;); cardElement.mount(\u0026#39;#card-element\u0026#39;); form.addEventListener(\u0026#39;submit\u0026#39;, async (event) =\u0026gt; { event.preventDefault(); const { paymentMethod, error } = await stripe.createPaymentMethod({ type: \u0026#39;card\u0026#39;, card: cardElement, }); if (error) { showError(error.message); // never surface a raw decline code to the customer return; } // paymentMethod.id is \u0026#34;pm_...\u0026#34; — this is what your server stores. // paymentMethod.card gives you brand and last4 for display, without the number. await fetch(\u0026#39;/api/save-payment-method\u0026#39;, { method: \u0026#39;POST\u0026#39;, headers: { \u0026#39;Content-Type\u0026#39;: \u0026#39;application/json\u0026#39; }, body: JSON.stringify({ paymentMethodId: paymentMethod.id }), }); }); Two details in that snippet do real work. The card object returned alongside the token carries the brand and last four digits, which is everything a \u0026ldquo;saved cards\u0026rdquo; list needs — you never need the number to show a customer which card they used. And nothing card-shaped appears in the request to your own API, which is what keeps that endpoint out of scope. The Elements documentation and the payment methods reference cover the rest of the API surface.\nUsing tokens One-off payments — tokenise, charge, discard. The customer is present and authenticating. Card on file — store the token against the customer, charge it later with their agreement. Subscriptions — the same, on a schedule. This is where network tokens earn their keep. Merchant-initiated transactions — charges the customer is not present for. These must be flagged as MITs, because an unflagged one may be challenged for authentication when nobody is there to answer; the 3-D Secure exemptions interact directly with this. Multi-provider setups — tokens do not transfer between providers, so a second provider means a second tokenisation of the same card, not a shared reference. What to store alongside the token A token on its own is not enough to run a checkout, and the metadata you keep with it is worth deciding deliberately rather than accumulating:\nBrand and last four digits, so the customer can tell their saved cards apart. Both come back with the token; neither is card data on its own. Expiry month and year, for showing a card as expiring soon. Useful, and it goes stale — the provider\u0026rsquo;s copy is authoritative. A provider identifier, if you use more than one. A token is meaningless without knowing which provider it belongs to, and that is exactly the field people forget until the second provider arrives. Your own customer reference, not the provider\u0026rsquo;s, as the primary key. Providers change. What not to store: anything you would have to protect. If a field would be awkward in a breach notification, the question to ask is why you are holding it rather than how you are encrypting it.\nWhat a token cannot do It cannot be used on the card network directly. It is meaningful only in the context of your account with your provider. It cannot be reversed to a card number by you. The mapping is held elsewhere by design. It cannot be used by another merchant. A token stolen from you is worthless to anyone else, which is the property that makes the whole approach worthwhile. It does not zero your PCI scope. That last point corrects the most common misconception on this subject. Storing tokens instead of card numbers takes your database out of scope. It does not take out the flow that created the token: the checkout page, every script running on it, and your integration code. Hosted fields on your own page typically map to SAQ A-EP rather than the shorter SAQ A, because the page hosting the iframe can still be attacked — swap the frame, overlay a fake field, or read keystrokes before the real field sees them.\nThe scope reduction is large and it is not total, and a team that believes otherwise stops doing the things — script inventory, CSP, Subresource Integrity — that the remaining scope requires.\nTokens and the rest of the card data A token replaces the number. It does not replace the other two credentials, and the rules for those are unchanged: the expiry is stored by the provider alongside the card, and the security code may never be retained after authorisation by anyone, tokenised or not. This is why a saved card cannot ask for its code on a repeat charge — there is nothing stored to compare against, and there was never allowed to be.\nTesting tokenised flows The paths worth exercising deliberately:\nTokenisation succeeds and the token is stored against the right customer Tokenisation fails — a declined card at the tokenisation step is a different branch from a declined charge A stored token is charged successfully later A token that has expired or been revoked is handled without an unhandled exception The customer removes a saved card, and the token is deleted at the provider as well as in your database A card is reissued: with a network token the charge still succeeds, with a gateway token it does not — confirm which behaviour you actually have A provider migration, if you ever expect one, is at least rehearsed Use your provider\u0026rsquo;s sandbox for all of it — the test card reference collects the published numbers, and the Stripe set documents the tokens that stand in for raw card numbers in server-side tests. Numbers from the generator are the right input for the form layer that sits in front of tokenisation, and the wrong input the moment the request leaves the browser for the provider.\nFrequently Asked Questions What is a payment token? A stand-in identifier for a card number. Your system stores the token, your payment provider stores the card, and the token only works against your own account with that provider. If your database is breached, the attacker gets a list of references that cannot be spent anywhere — which is the entire point. Is tokenization the same as encryption? No, and the difference matters for compliance. Encrypted card data is still card data: it can be reversed with the key, and it remains in PCI scope. A token has no mathematical relationship to the number it replaces, cannot be reversed by anyone holding it, and is generally out of scope. Encryption protects data you still hold; tokenisation means not holding it. What is the difference between a gateway token and a network token? A gateway token is issued by your payment provider and only works with that provider, so switching means a migration. A network token is issued by the card network itself — Visa Token Service, Mastercard MDES, or American Express — and survives the card being reissued, because the network keeps it pointed at the current card. That difference is worth real money on a subscription business. Does tokenization remove me from PCI scope? It reduces scope substantially and does not eliminate it. Storing tokens rather than card numbers takes your database out of scope, but the flow that created the token is still in scope — the page your customer typed their card into, the scripts running on it, and your integration with the provider. Hosted fields typically map to SAQ A-EP rather than the shorter SAQ A. Can a token be turned back into a card number? Not by you, and that is deliberate. The mapping lives with the provider or the network, and there is no algorithm that recovers a card number from a token. If you need the last four digits to show a customer which card they saved, the provider returns those separately as metadata — you do not need the number itself for anything a normal checkout does. ","permalink":"https://ccgenerator.org/guides/card-tokenization-explained/","summary":"A token is a stand-in for a card number that is useless to anyone who steals it. Your system stores the token; the provider stores the card. If your database is breached, the attacker gets a list of identifiers that only work against your own account with that provider — not card numbers they can spend.\nThat single property is why tokenisation is the default architecture for anything storing a card, and why the alternative — encrypting card numbers yourself — is a harder problem with a worse outcome.","title":"Card Tokenization Explained"},{"content":"Brazil has the feature that surprises foreign engineering teams more than any other: a card payment here can be split into monthly instalments at checkout, and that instalment count travels with the authorisation. If your payment model assumes one sale equals one charge, it does not fit this market.\nPayment card landscape: Brazil Currency BRL (Brazilian real) Card networks in common use Visa, Mastercard, Elo and Hipercard National card scheme Elo \u0026mdash; operated by Elo Serviços S.A. (domestic credit and debit) Other payment methods a checkout has to handle Pix, Boleto bancário and Card instalments (parcelamento) Payments regulator Banco Central do Brasil Strong customer authentication Not mandated nationally; individual acquirers and issuers may still require it Instalments are part of the transaction, not a financing add-on Parcelamento lets a customer split a card purchase across monthly instalments — commonly up to twelve, sometimes more, often advertised as sem juros, without interest, with the merchant absorbing the cost. It is not a separate financing product bolted onto the side. The number of instalments is chosen at checkout and sent with the authorisation, and it changes what the merchant receives and when.\nAlmost everything downstream has to accommodate this. The order record needs an instalment count, not just an amount. Settlement arrives in pieces over months rather than in one payout, so reconciliation matches many receipts to one sale. A refund on a partly-settled instalment plan is its own small problem. And the price shown on the page is frequently the instalment price rather than the total — \u0026ldquo;12x R$ 49,90\u0026rdquo; — which means your display logic, not just your payment logic, has a Brazil-shaped branch in it.\nFor testing, the important consequence is that the instalment count is an input field with a range, and range inputs are where bugs live. What happens at one instalment? At the maximum? Above the maximum? With a total so small that dividing it produces sub-cent instalments? Those are ordinary boundary tests, and they simply do not exist in a checkout built for a single-charge market.\nElo, Hipercard, and brand detection that has to be told Brazil has its own card schemes. Elo is the larger, a domestic network issuing both credit and debit, created by a group of Brazilian banks Elo1. Hipercard is a second domestic brand with a strong regional presence.\nThese carry their own issuer identification ranges, which means brand-detection code assembled from the usual four or five international networks will not recognise them. The failure mode is specific and bad: an Elo card is entered, the detector matches nothing, and the form either shows no brand icon or — worse — rejects the number as invalid. The customer has a working card in their hand and a checkout telling them it is fake.\nIf you are localising for Brazil, brand detection is not a cosmetic feature you can defer. The mechanics of how prefix ranges map to networks are in the BIN and IIN guide, and the same principle applies here as everywhere: a detector should return \u0026ldquo;unknown\u0026rdquo; and let the payment attempt proceed, rather than blocking a card it does not recognise. New ranges get allocated constantly, and a hardcoded table is out of date the day it ships.\nPix, and what it changes Pix is the instant payment system run by the central bank, live since late 2020 Pix2. It settles in seconds, at any hour, with no card network in the path.\nFrom a checkout perspective Pix is asynchronous in a way cards are not. The customer is shown a QR code or a copy-paste key, leaves your page to approve the transfer in their banking app, and your server learns about it through a webhook. That is a different shape of flow: there is a pending state that can last minutes, a customer who may never come back to your tab, and a success path that arrives out of band. Testing it means testing the waiting state, the webhook-arrives-late case, the customer-pays-twice case, and the expiry.\nWhat Pix does not do is instalments. That, more than anything, is why Brazilian checkouts carry both: Pix for immediacy and lower fees, cards for the instalment plan customers expect on larger purchases.\nWhat to test, concretely Instalment boundaries. One, the maximum, one above the maximum, and a total small enough that instalments round badly. Elo and Hipercard detection. Confirm your brand detector handles them, and confirm it degrades to \u0026ldquo;unknown, proceed anyway\u0026rdquo; rather than rejecting. Amount formatting. Comma as the decimal separator, dot as the thousands separator. R$ 1.234,56 is a thousand-odd reais, and a parser that reads it as 1.23 will not warn you. CPF input. The taxpayer identification number is routinely collected at checkout and has a check-digit algorithm of its own. The identity generator produces synthetic identity fields for exercising forms like this. The Pix pending state. Everything that happens between the QR code being shown and the webhook arriving, including the case where it never does. The card field itself is the easy part. Generate a Luhn-valid number from the generator and the input behaves normally — it is everything Brazil wraps around the card field that needs the test coverage.\nThe same is true of every market that has its own payment culture. Germany runs a large share of its commerce through direct debit and invoice, and India bars merchants from storing card numbers outright. A checkout built to handle only cards is a checkout that has not been localised.\nThe scheme and regulatory details on this page were last checked against provider documentation on 4 August 2026. Providers do change what they publish — the official link beside each claim is authoritative. Frequently Asked Questions What is parcelamento and why does it affect my checkout? Brazilian card payments can be split into monthly instalments at the point of sale, commonly up to twelve. The instalment count is part of the authorisation request, not an afterthought, so your checkout needs a field for it, your order model needs to store it, and your reconciliation has to handle a single sale settling across many months. Do I need to support Elo separately from Visa and Mastercard? Yes, if you sell in Brazil. Elo is a domestic scheme with its own IIN ranges, so brand-detection code built only from Visa, Mastercard and Amex prefixes will fail to identify an Elo card and may reject it outright. Does Pix replace card payments? It has taken a large share of transactions, but it does not replace cards for everything — notably not for instalments, which remain a card feature customers expect. Most Brazilian checkouts carry both. ","permalink":"https://ccgenerator.org/guides/cards-in-brazil/","summary":"Brazil has the feature that surprises foreign engineering teams more than any other: a card payment here can be split into monthly instalments at checkout, and that instalment count travels with the authorisation. If your payment model assumes one sale equals one charge, it does not fit this market.\nPayment card landscape: Brazil Currency BRL (Brazilian real) Card networks in common use Visa, Mastercard, Elo and Hipercard National card scheme Elo \u0026mdash; operated by Elo Serviços S.","title":"Payment Cards in Brazil: Instalments and Pix"},{"content":"Germany is the market that breaks the assumption most checkout code is built on: that \u0026ldquo;payment\u0026rdquo; means \u0026ldquo;card\u0026rdquo;. It does not here, and a German checkout that ships with a card field and nothing else will convert badly for reasons that never show up in your test suite.\nPayment card landscape: Germany Currency EUR (Euro) Card networks in common use Visa, Mastercard and girocard National card scheme girocard \u0026mdash; operated by Die Deutsche Kreditwirtschaft (domestic debit) Other payment methods a checkout has to handle SEPA Direct Debit (Lastschrift), Purchase on invoice (Kauf auf Rechnung), PayPal and Klarna Payments regulator BaFin Strong customer authentication Required \u0026mdash; PSD2 / EBA RTS on SCA Why the card field is not the whole job German consumers pay for things online in ways that have no card in them at all. Direct debit under the SEPA scheme — Lastschrift — lets a merchant pull funds from a bank account given a mandate, and it is deeply established. So is buying on invoice, Kauf auf Rechnung, where the goods ship first and the customer pays within a couple of weeks. That model exists in almost no other large market at the same scale, and it puts a payment method in your checkout whose entire flow happens after fulfilment.\nThe consequence for testing is structural rather than cosmetic. A card payment either authorises or it does not, at checkout, synchronously. An invoice payment has no authorisation step, a settlement window measured in weeks, a dunning path when it is not paid, and a risk decision that has to happen before the goods leave the warehouse. If your order state machine was designed around \u0026ldquo;authorised → captured → settled\u0026rdquo;, invoice payment does not fit in it, and you will find that out in production rather than in QA.\nDirect debit sits somewhere between the two. It clears, but it can be returned — the payer can reverse a SEPA Direct Debit for eight weeks without giving a reason, and up to thirteen months for an unauthorised one. A merchant that treats a cleared direct debit as final revenue is carrying a liability it has not modelled.\ngirocard, and why it is not a card number problem girocard is the domestic debit scheme, operated by the German banking industry association girocard1. It is overwhelmingly a point-of-sale scheme: the card in a German wallet is usually a girocard, and it is usually co-badged with an international debit product so it works abroad.\nThat co-badging is the part that catches developers out. When such a card is used online, the transaction runs on the co-badged network, not on girocard — so the PAN your form receives looks like an ordinary Visa or Mastercard number, because it is one. There is no \u0026ldquo;girocard number format\u0026rdquo; to validate against, and any guide offering you a girocard prefix range to detect is describing something your checkout will never see.\nWhat this means practically: you cannot test girocard by generating a number. Testing it means testing terminal integrations, and that is a different discipline from testing a web form. If your product is online-only, the correct amount of girocard-specific code is zero, and the correct amount of girocard-specific worry is also zero.\nWhat actually needs testing The card path itself is unremarkable. Germany runs on the same Visa and Mastercard rails as everywhere else, so the number rules in the card length reference apply unchanged, and a Luhn-valid test number exercises the field normally. Generate one from the Visa generator or the Mastercard generator and the field behaves the way it would for any European market.\nThe parts worth deliberate test coverage are the ones Germany adds:\nSCA. Germany is in the EEA, so PSD2 applies and most remote card payments carry a 3-D Secure challenge. Test the challenge path, the frictionless path, and the abandoned-challenge path — the 3-D Secure testing guide covers the states your code has to survive. IBAN input. If you accept direct debit, you accept IBANs, and a German IBAN is 22 characters with a checksum of its own. The IBAN generator produces structurally valid ones for exercising that field. Address format. House number after street name, five-digit postal codes with meaningful leading zeros. A postcode field that stores an integer loses Dresden. Refunds and returns. German consumer law gives a fourteen-day withdrawal right on most distance sales, which means refunds are a normal path, not an exception path. Test them as such. The mistake worth avoiding The pattern we see most often is a checkout built and tested entirely against card payments, with the German-specific methods bolted on afterwards as separate buttons that bypass most of the order pipeline. It works in the demo and it fails quietly later: refunds go down a path nobody tested, reconciliation reports do not balance, and the state machine has two shapes depending on which button the customer pressed.\nIf you are building for this market, model the non-card methods first and make the card path one case among several. It is more work up front, and it is the only version of this that survives contact with the accounting team.\nGermany is not unusual in having its own shape — every large market does. Brazil attaches an instalment count to the authorisation itself, and India forbids merchants from storing card numbers at all. The specifics differ; the lesson that a card field is the smallest part of a localised checkout does not.\nThe regulatory and scheme details on this page were last checked against provider documentation on 4 August 2026. Providers do change what they publish — the official link beside each claim is authoritative. Frequently Asked Questions Can I use a Visa or Mastercard test number to test a German checkout? For the card path, yes — Germany uses the same Visa and Mastercard rails as everywhere else, so a Luhn-valid test number exercises the card field normally. What it will not exercise is girocard, SEPA Direct Debit or invoice payment, which is where a large share of German transactions actually go. Those need their own test paths. Do girocard numbers work in a normal card field? Not usefully. girocard is a domestic debit scheme processed on its own rails, and cards are typically co-badged with an international network for use outside Germany. A checkout that treats girocard as just another 16-digit PAN is testing the co-badge, not girocard. Is SCA required in Germany? Yes. Germany is in the EEA, so PSD2 and the EBA regulatory technical standards on strong customer authentication apply. In practice that means 3-D Secure on most remote card payments, with the usual exemptions for low value and low risk. ","permalink":"https://ccgenerator.org/guides/cards-in-germany/","summary":"Germany is the market that breaks the assumption most checkout code is built on: that \u0026ldquo;payment\u0026rdquo; means \u0026ldquo;card\u0026rdquo;. It does not here, and a German checkout that ships with a card field and nothing else will convert badly for reasons that never show up in your test suite.\nPayment card landscape: Germany Currency EUR (Euro) Card networks in common use Visa, Mastercard and girocard National card scheme girocard \u0026mdash; operated by Die Deutsche Kreditwirtschaft (domestic debit) Other payment methods a checkout has to handle SEPA Direct Debit (Lastschrift), Purchase on invoice (Kauf auf Rechnung), PayPal and Klarna Payments regulator BaFin Strong customer authentication Required \u0026mdash; PSD2 / EBA RTS on SCA Why the card field is not the whole job German consumers pay for things online in ways that have no card in them at all.","title":"Payment Cards in Germany: What to Test"},{"content":"India is the market where the usual \u0026ldquo;just save the card for next time\u0026rdquo; pattern is not a design choice you get to make. The regulator removed it, and what replaced it changes how a saved card works everywhere in your system.\nPayment card landscape: India Currency INR (Indian rupee) Card networks in common use RuPay, Visa and Mastercard National card scheme RuPay \u0026mdash; operated by National Payments Corporation of India (domestic credit and debit) Other payment methods a checkout has to handle UPI, Net banking and Cash on delivery Payments regulator Reserve Bank of India Strong customer authentication Required \u0026mdash; RBI Additional Factor of Authentication (AFA) Merchants cannot store card numbers Under the Reserve Bank of India\u0026rsquo;s tokenisation framework, merchants and payment aggregators may not store card credentials — not the number, not the expiry, not the CVV Master Directions1. The card-on-file model that most checkouts are built around is simply unavailable.\nWhat replaces it is network tokenisation. The customer consents, the card network issues a token, and the merchant stores the token instead of the number. The token is scoped to that one merchant, so it is worthless if stolen and used elsewhere — which is the entire point.\nThis is a bigger change than it sounds, because a token is not a drop-in replacement for a PAN in the places PANs tend to leak into a system. Support tools that let an agent search orders by card number stop working. Fraud rules keyed on \u0026ldquo;same card, many accounts\u0026rdquo; need rewriting against a value that is deliberately different per merchant. Analytics that deduplicated customers by card number silently stop deduplicating. Anywhere a PAN was doing double duty as an identifier, tokenisation takes that job away, and the code that relied on it has to be found.\nThe general mechanics — what a token is, who issues it, how it differs from the PCI-scope reduction sense of the word — are in the tokenisation guide. India is the clearest large-scale case of it being mandatory rather than optional.\nTwo-factor authentication on domestic card payments India required an additional factor of authentication on domestic card transactions well before Europe\u0026rsquo;s PSD2 arrived, and the requirement is unusually broad: it applies to card-not-present payments generally, with a narrow set of exceptions, rather than being risk-scored away.\nFor a developer this means the challenge path is the normal path, not the exception. A checkout that treats authentication as a rare branch — a spinner that appears occasionally, an error state nobody tested — will show its seams here. Recurring payments have their own regime built on pre-debit notifications and mandate registration, which is why subscription flows written for other markets frequently need reworking before they function in India at all.\nRuPay, and a prefix collision worth knowing about RuPay is the domestic scheme, operated by the National Payments Corporation of India RuPay2. It issues both credit and debit cards and is very widely held, so a brand detector built only from Visa, Mastercard and Amex prefixes will fail to identify a large share of Indian cards.\nThere is a specific technical trap here. Some RuPay ranges sit at prefixes that overlap what other tables assign to other networks — the 6- and 8-series in particular are crowded, with Discover, UnionPay, Maestro and RuPay all allocated in nearby space. A detector that resolves matches by \u0026ldquo;first rule that matches wins\u0026rdquo; will give different answers depending on the order its rules happen to be declared in, which is a bug that hides well because it produces a plausible brand name every time.\nThe fix is not to add RuPay to the top of the list. It is to rank matches by specificity — the rule that pins down the most digits wins, and an exact prefix beats a range that merely spans it. The BIN and IIN guide covers how the ranges are structured, and the brand detection guide covers writing a detector that does not depend on declaration order.\nUPI is not a card The Unified Payments Interface moves money directly between bank accounts using a virtual payment address, with no card, no PAN and no network in the path. It carries an enormous share of Indian digital transactions.\nThe reason to mention it in a guide about cards is precisely that it is not one. Nothing a card generator produces is relevant to a UPI flow, no card validation logic applies to it, and a UPI payment does not enter the parts of your system that handle cards. If you are localising for India, UPI is a separate integration with a separate test plan — treating it as \u0026ldquo;another card method\u0026rdquo; is the mistake, and it is a common one.\nWhat to test, concretely The tokenised saved-card path, including the first payment where the token is created and a later one where it is used. Confirm no PAN is stored at any step; that is a compliance requirement, not a preference. The PCI DSS guide covers what counts as cardholder data. Authentication as the default path. Success, failure, timeout, and the customer who closes the tab mid-challenge. RuPay brand detection, and specifically that your resolver is not order-dependent. Amount formatting. The Indian digit grouping system groups the first three digits then pairs — ₹12,34,567 — and a formatter using thousands separators throughout will render amounts that read wrong to every Indian customer. For the card field itself, a Luhn-valid number from the generator exercises the input normally. As everywhere, the generated number tells you nothing about whether a payment would succeed — and here is why.\nIndia\u0026rsquo;s constraint is regulatory, but the general shape is common to every market worth localising for. Germany puts much of its commerce outside the card rails entirely, and Brazil changes what a single card authorisation even means.\nThe regulatory and scheme details on this page were last checked against provider documentation on 4 August 2026. Providers do change what they publish — the official link beside each claim is authoritative. Frequently Asked Questions Can I store card numbers for customers in India? No. Under the Reserve Bank of India\u0026rsquo;s tokenisation framework, merchants and payment aggregators may not store the card number, expiry or CVV. A saved card is a network token, issued per merchant, that only that merchant can use. What is RuPay? RuPay is India\u0026rsquo;s domestic card scheme, run by the National Payments Corporation of India. It issues both credit and debit cards and is widely held, so brand-detection code written only for the international networks will miss a large share of Indian cards. Does UPI use card numbers at all? No. UPI moves money between bank accounts using a virtual payment address, with no card and no PAN in the flow. Nothing a card generator produces is relevant to a UPI transaction. ","permalink":"https://ccgenerator.org/guides/cards-in-india/","summary":"India is the market where the usual \u0026ldquo;just save the card for next time\u0026rdquo; pattern is not a design choice you get to make. The regulator removed it, and what replaced it changes how a saved card works everywhere in your system.\nPayment card landscape: India Currency INR (Indian rupee) Card networks in common use RuPay, Visa and Mastercard National card scheme RuPay \u0026mdash; operated by National Payments Corporation of India (domestic credit and debit) Other payment methods a checkout has to handle UPI, Net banking and Cash on delivery Payments regulator Reserve Bank of India Strong customer authentication Required \u0026mdash; RBI Additional Factor of Authentication (AFA) Merchants cannot store card numbers Under the Reserve Bank of India\u0026rsquo;s tokenisation framework, merchants and payment aggregators may not store card credentials — not the number, not the expiry, not the CVV Master Directions1.","title":"Payment Cards in India: Tokenisation Rules"},{"content":"Short answer: no, not in the sense people mean when they search for it. There is no pool of unassigned card numbers sitting somewhere that happen to have money on them. A card number is a pointer, not a container — it identifies an account at a bank, and it has value only because that account exists and someone funds it.\nThe numbers that \u0026ldquo;work\u0026rdquo; are the ones belonging to real people, and using those is theft. The rest — every number a generator produces, including ours — point at nothing.\nThat is the whole answer. The rest of this page explains why the question feels like it should have a different one, because the reason is genuinely interesting and it explains a lot about how payments actually function.\nWhat \u0026ldquo;works\u0026rdquo; actually means For a card transaction to be approved, all of the following have to be true at once:\nThe number falls in a BIN range assigned to a real issuing bank. That bank has linked the specific number to an active account. The account has available credit or balance. The expiry date matches what the issuer holds. The CVV matches the value the issuer computed for that card. The card is not blocked, frozen, or closed. The issuer\u0026rsquo;s and the merchant\u0026rsquo;s fraud systems both allow it. A generator satisfies none of these. It produces something that resembles the format implied by point 1 — a plausible prefix, a plausible length, a correct check digit — and stops there, because everything from point 2 onward is a fact held in a bank\u0026rsquo;s database rather than a property of the digits.\nA generated number is a well-formed sentence in a language nobody speaks. Grammatically correct, semantically empty.\nThis is also why \u0026ldquo;which generator makes numbers that work\u0026rdquo; is a question with no answer. No arrangement of digits can create an account record at a bank. The bottleneck is not the algorithm; it is that the thing being asked for does not live in the number.\nThe number is not even the whole credential Points 4 and 5 above are worth separating out, because they are frequently overlooked. A card number on its own does not authorise anything; a transaction needs the expiry date and the security code as well, and neither of those is derivable from the digits.\nThe expiry date is an issuer decision recorded in the issuer\u0026rsquo;s systems. The CVV is computed by the issuing bank from the card number, the expiry, and a pair of cryptographic keys that never leave the bank — which is exactly the security property it exists to provide. There is no formula that turns a card number into its CVV, for us or for anyone else. What sits beside a generated number on this site is a random value of the correct length, present so that a form\u0026rsquo;s field-length validation has something to chew on.\nPut differently: a card number is one of three independent facts, and none of the other two are encoded in it. Even a number that did belong to a live account would be incomplete on its own.\nWhy Luhn validity fools people Here is where the confusion almost always starts.\nYou enter a generated number into a payment form. The field turns green. The card logo appears. The form accepts it and moves to the next step. It looks exactly like the number worked.\nWhat actually happened: JavaScript in your browser checked the digits against the Luhn checksum and matched the prefix against a list of network ranges. Both passed, so the field accepted the input. No bank saw the number. No payment network saw it. In most implementations it had not even reached the merchant\u0026rsquo;s own server yet.\nForm validation is not payment authorisation. They happen at different times, in different places, and answer different questions:\nForm validation Authorisation Runs in Your browser The issuing bank\u0026rsquo;s systems Asks Are these digits well-formed? Does this account exist and can it pay? Takes Microseconds A second or two, over the card network Needs the internet No Yes Can be satisfied by a generated number Yes No Our card validator does the left-hand column and says so explicitly, because a tool that reports \u0026ldquo;valid\u0026rdquo; without that qualifier is the direct cause of this misunderstanding.\nWhat about the numbers people post online? Numbers do circulate. They come from three places, and none of them is a generator.\nPublished test cards. Numbers like Stripe\u0026rsquo;s 4242 4242 4242 4242 appear in the processor\u0026rsquo;s own documentation. They are public precisely because they are inert — deliberately assigned to no account, recognised only inside a sandbox, and incapable of moving money anywhere. Our test card number reference collects the ones worth knowing across gateways, and the Stripe set is documented in full including every decline code.\nCards stolen in breaches. These are real cards belonging to real people. Using one is card theft with an identifiable victim, and it is the kind of offence Europol treats as organised crime rather than a minor infraction. Most are blocked quickly, which is why lists of them are sold in bulk and churn constantly.\nNumbers that are simply invented. Clickbait, filler content, and bait — the business model behind those pages is worth understanding on its own.\nThat third category shades into the fourth thing worth knowing about this search:\nA large share of results promising \u0026ldquo;working card numbers\u0026rdquo; exist to get you to download something — a generator executable, a \u0026ldquo;checker\u0026rdquo; tool, a browser extension, or an installer behind a survey wall. The standard payloads are information-stealing trojans, browser session hijackers, and crypto miners. The most likely outcome of pursuing this search is not a working card number. It is your own credentials, saved cards, and session cookies ending up in someone else\u0026rsquo;s hands.\nThat is not a moral argument, it is a threat model. The people publishing those pages are not offering free money to strangers; they are running an acquisition funnel, and the person searching is the product.\nThe victim side It is easy to think of a card number as abstract. It is worth being concrete about who absorbs the cost when one is misused.\nThe cardholder gets a frozen account, a statement they have to dispute line by line, and a replacement card that takes days to arrive — during which every subscription and saved payment method tied to the old number breaks. The money is usually recovered. The fortnight is not.\nThe merchant, if the transaction went through, pays a chargeback fee, loses the goods already shipped, and carries the loss. Small businesses feel this disproportionately, and a rising chargeback ratio can get a payment account terminated outright, which ends the business\u0026rsquo;s ability to take card payments at all.\nEveryone else pays through the system\u0026rsquo;s response: higher processing fees, more aggressive fraud scoring, and more legitimate transactions declined by mistake. If you have had a genuine purchase rejected while travelling, you have met the downstream effect. In the US, incidents can be reported to the FBI\u0026rsquo;s IC3; most other jurisdictions have an equivalent.\nWhat generated numbers are actually good for There is a real use case here, and it is the reason this site exists:\nPayment form validation — does the field accept 13 to 19 digits, strip spaces, and reject a wrong check digit? Brand detection — does a 2-series Mastercard show the right logo? Field length and masking — does the input mask handle a 15-digit Amex and a 19-digit UnionPay? Automated test fixtures — deterministic, shareable test data that is safe to commit to a repository Teaching and demos — showing how a number decomposes without exposing anyone\u0026rsquo;s card Data-masking verification — proving your redaction logic catches a PAN before it reaches a log All of these test your code, which is why generated numbers are the correct tool: they exercise the format layer and never reach an authorisation network. The generator produces them, and the payment form testing checklist covers what to test with them.\nIf you need to pay for something and cannot Sometimes the search behind this page is not about fraud at all. It is about wanting something you cannot currently afford. That is a different problem with real solutions:\nFree and open-source alternatives exist for most categories of paid software, and in several categories they are the better tool. Free tiers cover far more than they used to, particularly for developer services. Student and educational licences are widely available and often just require a school email address. Regional pricing — many services charge substantially less depending on the country you are in, and do not advertise it. Payment plans and monthly billing turn a large one-off cost into a manageable one. Open-source maintainer programmes from companies such as JetBrains, GitHub, and most major cloud providers give free access to people working on public projects. Any one of these gets you the thing you wanted, permanently, without a declined transaction or a criminal offence attached to it. If the specific case is a free trial, the free trial guide covers the practical options in more detail.\nFrequently Asked Questions Are there any credit card numbers that work? Not in the sense the question intends. There is no reserve of unassigned numbers that happen to carry a balance, because a card number does not hold money — it points at an account at a bank, and the money lives in the account. The numbers that work are the ones belonging to real people, and using those is theft. Every generated number, including the ones on this site, points at nothing. Why do fake card numbers pass validation on some websites? Because that first check is a formatting check running in your browser. It confirms the digits satisfy the Luhn checksum and match a known network prefix, and that is all it can do without contacting anyone. No bank has seen the number at that point. The real test happens when the merchant\u0026rsquo;s server asks the issuing bank to authorise a charge, which is a different step with a different answer. What is a test card number? A number a payment processor publishes deliberately, such as Stripe\u0026rsquo;s 4242 4242 4242 4242, which its sandbox recognises and responds to with a scripted result. Test cards are public precisely because they are inert: they are not assigned to any account and cannot move money. They exist so developers can exercise approvals, declines, and 3-D Secure flows without touching a live authorisation network. Are the numbers posted on forums real? Some are stolen and belong to real cardholders, some are published test numbers that do nothing, and many are simply invented. What the three have in common is the delivery: lists of working numbers are one of the oldest lures for information-stealing malware, and the most likely outcome of chasing them is having your own accounts compromised. Is it illegal to use a card number I found online? Yes. Using card details you are not entitled to use is fraud in essentially every jurisdiction, whether the number was found, bought, guessed, or generated, and whether or not the transaction succeeds. Where the number came from does not change the offence — what matters is that you used details belonging to someone else to obtain something. What can I do with generated card numbers? Test your own software. They are the right input for payment form validation, brand detection, field length and masking rules, automated test fixtures, teaching material, and verifying that a data-masking routine works. They are the wrong input for anything that requires an answer from a bank, because no bank has an answer to give. ","permalink":"https://ccgenerator.org/guides/do-credit-card-numbers-that-work-exist/","summary":"Short answer: no, not in the sense people mean when they search for it. There is no pool of unassigned card numbers sitting somewhere that happen to have money on them. A card number is a pointer, not a container — it identifies an account at a bank, and it has value only because that account exists and someone funds it.\nThe numbers that \u0026ldquo;work\u0026rdquo; are the ones belonging to real people, and using those is theft.","title":"Do Credit Card Numbers That Work Exist?"},{"content":"If you are looking for a generated card number to start a free trial, it will not work. Trial signups run a small authorisation against the card, and a synthetic number has no account behind it to authorise. It fails at the first step, every time.\nBut the reason people search for this is usually reasonable: you want to try something without handing over your real card, and without waking up to a charge you forgot about. There are real ways to do that. This page covers them.\nThe three worries behind this search Almost everyone who looks for a card number to use on a trial is trying to avoid one of three specific things, and none of them is unreasonable:\nBeing charged for something you meant to cancel. Trials are priced on the assumption that a predictable share of people will forget. That is not paranoia; it is the business model. Handing your card to a service you do not know yet. You are evaluating whether the product is any good. Committing your primary card number to it — where it will sit in someone\u0026rsquo;s database indefinitely — is a bigger step than the decision warrants. Suspecting that cancelling will be difficult. Sometimes it genuinely is: buried settings pages, retention flows, cancellation by email only. Every one of these has a real fix, and the fixes work better than a generated number would even if a generated number worked. The rest of this page is those fixes. If you are here for the broader question of what synthetic card numbers can and cannot do, the FAQ covers it directly.\nWhy generated numbers fail at signup A trial signup rarely takes money, but it almost always tests the card. The service sends an authorisation request — commonly for zero, sometimes for one unit of currency — and that request follows the same path a purchase would:\nThe merchant\u0026rsquo;s gateway reads the leading digits and identifies the network. The network routes the request to the bank that issued the card. The bank looks the account up in its own records. It finds nothing, and declines. Step 3 is where a generated number ends. There is no issuer record because no issuer ever created one — the number was calculated by a formula, not assigned to a person. Luhn validity is irrelevant at this point; the checksum is a typing check that runs in the browser, and roughly one in ten random digit strings passes it by chance. It has nothing to say about whether an account exists. The full path a declined test card takes is worth reading if you want the detail.\nSome services accept the card at signup and only charge later. That is not a loophole; it is a deferred failure. The charge fails, the account is suspended, and depending on the service you may be liable for whatever you consumed in the meantime.\nThe legal risk nobody mentions This is worth stating once, plainly, without lecturing.\nUsing card details you are not entitled to use in order to obtain a service is fraud in essentially every jurisdiction, and it is fraud whether or not it succeeds. In the United States that is 18 U.S.C. § 1029, access device fraud, which explicitly covers counterfeit and unauthorised access devices. In the United Kingdom it falls under the Fraud Act 2006, primarily fraud by false representation. Across the EU, the relevant instrument is Directive (EU) 2019/713 on combating fraud and counterfeiting of non-cash means of payment. In Türkiye, Article 245 of the Turkish Penal Code covers misuse of bank and credit cards.\nWhere each of those statutes sits, and where the line falls between generating test data and misusing it, is set out in the guide to the legal position.\nProsecution over a single failed trial signup is unlikely, and pretending otherwise would be scaremongering. The realistic outcomes are smaller and more durable: services log failed attempts, share signals with fraud-prevention networks, and act on them. A banned account, a flagged email address or device fingerprint, and a payment-provider blocklist entry all outlast the trial you were trying to start.\nWhat actually works: real virtual cards This is the part that solves the underlying problem.\nA virtual card is a real card number issued against your real account, generated on demand and usually disposable. It spends your actual money — that is the point — but it stands between the merchant and your primary card number.\nWhat it gets you:\nYour real card number never reaches the service. If that merchant is breached later, the exposed number is one you already closed. A spend limit you set. If the trial silently converts to £9.99 and you capped the card at £1, the charge is declined rather than paid. A kill switch. Closing the card stops a renewal instantly, without arguing with a cancellation flow. Merchant locking, on some providers. The card works at that one merchant and nowhere else, so a leaked number is useless to anyone. Where to get one:\nProvider Region Notes Privacy.com US Purpose-built for this; merchant locking and per-card spend limits Capital One (Eno) US Free with a Capital One card Citi Virtual Account Numbers US Free with a Citi card Revolut UK, EU, US Disposable virtual cards, refreshed per transaction on paid tiers Wise Global Virtual cards with multi-currency balances Monzo UK Virtual cards created in-app Starling UK Virtual cards tied to spending spaces N26 EU Virtual card issued alongside the account Curve UK, EU Sits in front of your existing cards Most Turkish banks Türkiye Virtual cards (sanal kart) are standard in the mobile apps of Garanti BBVA, İş Bankası, Yapı Kredi, Akbank, and others No affiliate links here, and no recommendation between them — availability depends on where you bank, and the feature you want (limits, merchant lock, disposability) varies by provider.\nOne honest caveat, because the marketing around virtual cards tends to blur it:\nA virtual card still spends your money. If the trial converts, you have not cancelled, and the card has room on it, you get charged. The protection comes from the limit and the kill switch, not from the card being virtual.\nThe word \u0026ldquo;virtual\u0026rdquo; does a lot of work in search results, and it is worth separating the two things it can mean. A virtual card from your bank is a real card number attached to your real account. A \u0026ldquo;virtual card\u0026rdquo; from a generator is test data attached to nothing — which is why it can never carry a balance, however it is labelled.\nOther approaches that work Check whether the trial needs a card at all. A significant share of services offer card-free trials or a permanent free tier and simply do not advertise it on the pricing page. Look before you sign up.\nSet a calendar reminder. Unglamorous and the single most effective thing on this list. Two days before the trial ends, not the day of.\nCancel immediately after signing up. Most services let you cancel a trial and keep access until the trial period expires. You get the full trial and there is no renewal to forget. When it is offered, this is the most reliable method available.\nPay through PayPal where it is an option. The merchant never sees a card number, and you can revoke the recurring payment agreement from PayPal\u0026rsquo;s own dashboard rather than hunting for the merchant\u0026rsquo;s cancellation page.\nUse in-app subscriptions on iOS or Android. Subscriptions started through the App Store or Google Play are all cancellable from one screen, with the platform\u0026rsquo;s refund process behind them.\nLook for education and open-source licences. Many developer tools are free for students, teachers, and maintainers of open-source projects. If you qualify, a trial is beside the point.\nHow to cancel a trial properly Trial cancellation flows are designed to be forgettable. Work against that:\nWrite down the cancellation date the moment you sign up, with a reminder set two days earlier. Find the cancel page during signup, while you are already logged in and motivated. Bookmark it. Keep the confirmation email. If it does not arrive, you are probably not cancelled. Check your statement one billing cycle later. Cancellation confirmations and actual billing systems do occasionally disagree. If you are charged anyway, contact the merchant first with the confirmation, then go to your bank for a chargeback if that goes nowhere. A saved confirmation email makes that conversation short. If you are testing your own trial flow If you build trial signups rather than sign up for them, you need two different things.\nFor the form itself — field validation, brand detection, length rules, error states — generated test numbers are exactly right, and our virtual card format generator produces the same shapes a real VCC would have. Nothing leaves the browser and no authorisation is attempted, which is precisely what you want when the thing under test is your own input handling.\nFor anything that requires an answer from the processor, you need your gateway\u0026rsquo;s sandbox test cards. Those numbers are recognised by the sandbox and return scripted results, which generated numbers cannot do because no issuer answers for them.\nThe scenarios worth covering:\nThe trial-start authorisation, at zero or at one unit of currency Trial converting to a paid subscription The conversion charge being declined Cancellation during the trial period The customer replacing their card mid-trial Duplicate-signup prevention — same card, or same email, signing up twice The last one is where most trial abuse actually gets stopped, and it is worth testing properly. It is also a reminder of why the search that brought you here does not pay off: the systems on the other side are built to notice.\nFrequently Asked Questions Can I use a generated card number for a free trial? No. A trial signup runs an authorisation against the card — usually a hold for zero or one unit of currency — and that request travels to an issuing bank that has to recognise the account. A generated number has no issuer behind it, so there is nothing to approve and the signup fails at that step. Passing the Luhn check in the browser does not change the outcome; that check only confirms the digits were typed correctly. Is it illegal to use a fake card for a trial? Using card details you are not entitled to use in order to obtain a service is fraud in essentially every jurisdiction, and it remains fraud whether or not it succeeds. In the United States it falls under 18 U.S.C. § 1029, in the United Kingdom under the Fraud Act 2006, across the EU under Directive (EU) 2019/713, and in Türkiye under Article 245 of the Turkish Penal Code. Prosecution over a single failed signup is unlikely, but banned accounts and payment-provider blocklists are common and lasting. What is the safest way to try a paid service? A virtual card from your own bank or a card issuer, with a spend limit set to roughly the trial amount and merchant locking enabled if it is offered. Your real card number never reaches the service, the limit caps what can be taken if the trial converts, and you can close the card in one tap. Pair it with a calendar reminder two days before the trial ends. Do virtual cards let me get things for free? No — and this is the honest part. A virtual card spends real money from your real account. If the trial converts, you have not cancelled, and the card has room on it, you are charged exactly as you would be with a plastic card. The protection comes from the spend limit and the ability to kill the card, not from the card being virtual. Can I get a free trial without a card at all? Often, yes. A large share of services offer a card-free trial, a free tier that never expires, or a demo environment, and it is worth checking before signing up. Developer tools in particular frequently give free licences to students, educators, and open-source maintainers, in which case a trial is not needed at all. How do I test my own free trial flow? With two different sets of numbers. Use generated test numbers for the form layer — field lengths, brand detection, Luhn validation, error states. Use your payment gateway\u0026rsquo;s own sandbox cards for anything that needs a response from the processor: the initial authorisation hold, the conversion charge, a declined renewal, and 3-D Secure. Generated numbers cannot produce those responses because no issuer answers for them. ","permalink":"https://ccgenerator.org/guides/free-trial-cards-the-legitimate-way/","summary":"If you are looking for a generated card number to start a free trial, it will not work. Trial signups run a small authorisation against the card, and a synthetic number has no account behind it to authorise. It fails at the first step, every time.\nBut the reason people search for this is usually reasonable: you want to try something without handing over your real card, and without waking up to a charge you forgot about.","title":"Free Trial Cards: What Actually Works"},{"content":"Card fraud is an industry. It has supply chains, specialised roles, and a well-worn set of techniques, most of which are more mundane than people expect. Understanding the shape of it is useful for two groups: people who want to protect their own cards, and developers who build the systems that fraud passes through.\nThis page describes how the ecosystem works at a level that helps you defend against it. It does not name tools, sites, or channels, and it does not describe any technique in operational detail.\nWhere stolen card data comes from Almost none of it is guessed, and none of it is generated. It is taken, through six routes:\nData breaches. A merchant, processor, or service provider is compromised and card records are extracted in bulk. The cardholder does nothing wrong and usually learns about it months later, if at all. This is the largest single source by volume.\nPhishing. A fake checkout page, a message about a failed delivery, a text claiming to be from your bank. The details are typed in voluntarily by someone who believes they are somewhere else. Modern phishing pages are visually identical to the real thing; the domain is the only reliable tell.\nPhysical skimming. A device fitted over an ATM or petrol pump card reader, often with a pinhole camera or overlay keypad for the PIN. Chip adoption has reduced its value but not eliminated it, because many terminals still fall back to the stripe.\nDigital skimming. JavaScript injected into a legitimate e-commerce site\u0026rsquo;s payment page, reading fields as the customer types. The merchant is a victim too and frequently has no idea. This is the category most relevant to developers, and it is why the scripts on a checkout page are a security boundary rather than a marketing decision.\nInformation-stealing malware. Software that empties a browser\u0026rsquo;s saved payment methods, cookies, and session tokens. It is distributed through cracks, keygens, pirated software, and — worth stating plainly on this site — downloads advertised as card generators or checker tools. Anyone searching for those is precisely the target audience, and the business model behind those pages is the download rather than the numbers.\nSocial engineering. Fake technical support, fraudulent refund calls, and delivery scams. No technical compromise at all — just a convincing person and time pressure.\nWhy \u0026ldquo;checker\u0026rdquo; tools exist Stolen card lists are mostly dead on arrival. Cards get cancelled, expire, or were never valid to begin with. So the lists get filtered: small authorisation attempts are run against them to see which ones still respond. That filtering step is what \u0026ldquo;checker\u0026rdquo; tools do, and it is why they are the defining tool of the ecosystem rather than a peripheral one.\nIt is also why a legitimate testing tool never includes one. Verifying whether someone else\u0026rsquo;s card is live has no place in testing your own software — your code never needs that answer. A generator that also offers to check cards is telling you what it is for, and it is the clearest single signal in this entire category.\nFor merchants, this filtering is not somebody else\u0026rsquo;s problem: it happens against your checkout. Bursts of small or zero-value authorisations from one source, many failures against a narrow range of card prefixes, and traffic concentrated on your cheapest payment endpoint are the recognisable shape of it. The defences are covered below and in the BIN and IIN guide.\nWhat \u0026ldquo;dumps\u0026rdquo;, \u0026ldquo;fullz\u0026rdquo;, and BIN lists refer to These terms appear here because people search for them and deserve an accurate answer about what they are.\nDumps — magnetic stripe data, used historically to produce counterfeit physical cards. Chip adoption has substantially reduced its value. Fullz — a package combining card data with identity information, sold for identity theft rather than a single purchase. BIN lists — targeting data, used to choose which issuer\u0026rsquo;s cards to attempt against a given merchant. Every category above consists of stolen data taken from real people. There is no version of any of them that is not somebody\u0026rsquo;s compromised account.\nWhat happens to the cardholder The financial loss is usually recoverable. The rest is not:\nThe card is cancelled the moment fraud is confirmed, and a replacement takes days to arrive. Every subscription, saved payment method, and recurring bill tied to the old number breaks simultaneously. The dispute process puts the burden of describing what happened on the victim, transaction by transaction. Where identity data was taken alongside the card, the exposure extends to credit applications made in your name, which is slower and harder to unwind. Consumer liability is limited in most jurisdictions — Regulation E and Regulation Z in the United States, PSD2 across the EU — provided the report is prompt. The cost that remains is time and disruption, and it falls entirely on the person who did nothing wrong.\nWhat happens to the merchant Merchants absorb a different set of costs, and small businesses feel them hardest:\nChargebacks. The transaction amount is reversed, the goods are already gone, and a per-chargeback fee is added on top. Programme thresholds. Card networks monitor chargeback ratios. Crossing the threshold means enrolment in a monitoring programme, fines, and in the end the loss of the ability to accept cards at all. False positives. Tightening fraud controls in response declines legitimate customers. Every merchant that has over-corrected knows the revenue lost to blocked genuine orders can exceed the fraud it prevented. That last item is the reason fraud prevention is a balancing exercise rather than a maximising one.\nHow to protect your own cards In rough order of effectiveness:\nTurn on transaction alerts. Push or SMS notification for every transaction. This single step converts a problem you find at month end into one you find in seconds. Use a virtual card for online purchases, with a spend limit and merchant locking where offered — the options are set out here. Do not save card details in the browser. Browser-stored payment data is the primary target of information-stealing malware. Use your bank\u0026rsquo;s app or a password manager instead. Check the domain before you type. Not the design, not the padlock — the domain. Phishing pages copy everything except the address. Avoid paying on public devices or untrusted networks. Especially anywhere that offers to remember the card. Read your statement, including the small amounts. A tiny unexplained charge is frequently a test of whether the card is live, not a mistake. Freeze first, ask later. Most banking apps freeze a card instantly. Do that before calling — it costs nothing if you are wrong. Prefer tokenised payment methods. Digital wallets present a device-specific token and a one-time cryptogram rather than your actual number, so a compromised merchant learns nothing reusable. How developers reduce their exposure The systems fraud passes through are built by people reading pages like this one:\nNever touch card data. Hosted fields, iframes, or the gateway\u0026rsquo;s SDK. The data you never receive cannot leak from your systems. Tokenise everything you keep. Tokenisation removes the stored PAN from the equation entirely. Lock down the payment page\u0026rsquo;s scripts. A strict Content Security Policy plus Subresource Integrity on third-party scripts is the direct countermeasure to digital skimming. Minimise third-party scripts on checkout. Every tag manager, chat widget, and analytics snippet is another party who can modify the page where cards are typed. Rate limit, by IP, device, and card prefix. Card testing is profitable because it is cheap at volume; anything that raises the per-attempt cost works better than cleverness. Protect zero-amount and low-value authorisation endpoints. They are the preferred target because they are cheap, quiet, and often unauthenticated. Use strong customer authentication. 3-D Secure shifts liability as well as blocking attempts, and it is mandatory in the EEA regardless. Test that card data never reaches your logs. Assert it in CI rather than assuming — the PCI DSS guide covers where it escapes and the CVV guide has a log-audit test you can copy. Audit your dependencies. The npm packages loaded on a payment page are part of its attack surface, and a compromised transitive dependency is indistinguishable from a compromised script. If your card has been compromised Freeze the card in your banking app, immediately. Call your bank and report the unauthorised transactions specifically, with dates and amounts. Request a replacement, and ask whether the account itself needs re-issuing. Update your subscriptions and saved payment methods, so a failed renewal does not cancel something you rely on. Change passwords anywhere you reused the credentials associated with the compromised account. Report it to the national body. In the United States, IdentityTheft.gov for identity theft and the FBI\u0026rsquo;s IC3 for cybercrime. In the United Kingdom, Action Fraud is the reporting body and the NCSC publishes current guidance. In Türkiye, USOM handles cyber incident reporting and 155 is the police line. Monitor your credit report if identity data was exposed alongside the card, and check exposed accounts through a service such as Have I Been Pwned. Do all of this even if the amount was small. The small charge is often the test, and the large one follows.\nWhy this page exists on a generator site It would be simpler to leave this subject alone. But a meaningful share of the traffic searching for card generators is searching adjacent to this ecosystem, and the honest thing to publish is what it actually is: an industry built on stolen data from real people, serviced by tools that mostly exist to infect the people looking for them.\nNothing generated here can participate in any of it — a synthetic number has no account behind it, which is what makes it safe test data and useless for everything else. The tools that claim otherwise are the subject of the paragraph above.\nFrequently Asked Questions What is carding? Carding is the umbrella term for obtaining stolen payment card data and turning it into money — filtering lists of card details to find the ones still active, then using them for purchases or resale. It is an organised criminal industry with specialised roles rather than a lone activity, and every card in it belongs to a real person who did not consent to being part of it. How do fraudsters get card numbers? Overwhelmingly through breaches of merchant and processor systems, phishing pages that imitate a real checkout, physical skimming devices on ATMs and terminals, JavaScript injected into legitimate e-commerce payment pages, and information-stealing malware that empties a browser\u0026rsquo;s saved payment details. Almost none of it involves guessing numbers, and none of it involves generating them. Can someone use my card with just the number? Usually not on its own. Most online payments need the expiry date and the security code as well, and increasingly a strong customer authentication step through your bank. That is why breached data is often sold as a package rather than as bare numbers — and why a card number alone, of the kind any generator produces, is not a usable payment credential. Am I liable for fraudulent charges? In most jurisdictions your liability for unauthorised card transactions is capped or zero, provided you report promptly — Regulation E and Regulation Z in the United States, PSD2 across the EU, and comparable rules elsewhere. The money is usually recovered. What is not recovered is the fortnight of disputes, a replacement card, and every subscription tied to the old number breaking at once. How do I know if my card data was in a breach? You often cannot know directly, because a merchant may not identify which records were taken. Practical signals: transaction alerts from your bank, small unexplained charges, or a breach notification from a company you have used. Services like Have I Been Pwned track exposed accounts, and enabling real-time transaction notifications is the single most effective early-warning step available to you. ","permalink":"https://ccgenerator.org/guides/how-carding-works-and-how-to-protect-yourself/","summary":"Card fraud is an industry. It has supply chains, specialised roles, and a well-worn set of techniques, most of which are more mundane than people expect. Understanding the shape of it is useful for two groups: people who want to protect their own cards, and developers who build the systems that fraud passes through.\nThis page describes how the ecosystem works at a level that helps you defend against it. It does not name tools, sites, or channels, and it does not describe any technique in operational detail.","title":"How Card Fraud Works, and How to Stay Safe"},{"content":"Most credit card numbers are 16 digits. American Express uses 15. Diners Club Classic uses 14. Visa has issued 13-digit and 19-digit numbers. Maestro ranges from 12 to 19. The ISO/IEC 7812 standard permits any length up to 19 digits, and card networks use most of that range.\nIf your payment form assumes 16, it rejects real cards.\nLength by network Network Digits Prefix Security code American Express 15 34, 37 4 Diners Club (classic) 14 300–305, 3095, 36, 38, 39 3 Diners Club (newer) 16, 19 36, 38, 39 3 Discover 16, 19 6011, 622126–622925, 644–649, 65 3 JCB 16–19 3528–3589 3 Maestro 12–19 50, 56–69 3 Mastercard 16 51–55, 2221–2720 3 Troy 16 9792 3 UnionPay 16–19 62, 81 3 V PAY 16 4 3 Visa 13, 16, 19 4 3 Visa Electron 16 4026, 417500, 4405, 4508, 4844, 4913, 4917 3 Two notes on reading this table. The prefix column is the published range, not a guarantee that every number in it has been issued — what a prefix identifies is an institution, not a card. And where a network lists several lengths, all of them are current; the shorter ones are not deprecated, merely less common.\nWhy lengths vary at all ISO/IEC 7812 defines a maximum of 19 digits for a Primary Account Number. It does not mandate a fixed length, and that single design choice is the source of everything on this page.\nWithin the ceiling, each network built its own numbering plan, and the total falls out of three components: the issuer identification number, the account identifier the issuer assigns inside it, and one check digit. Change the width of the middle component and the total changes with it — the structure guide works through how the three fit together.\nThe arithmetic is worth seeing once, because it explains why lengths cluster the way they do. A 16-digit card with a six-digit issuer identifier leaves 16 − 6 − 1 = 9 digits for the account, or a billion cards per issuer identifier. A 15-digit Amex leaves 8, or a hundred million. Once an issuer approaches that ceiling it needs either another identifier or a longer number, and both routes have been taken: the eight-digit IIN migration subdivided the existing space, while the 19-digit ranges extended it. Neither changed the check digit, which has occupied the final position throughout.\nHistorical decisions then became permanent. American Express settled on 15 and Diners Club on 14 before 16 became the norm, and by the time it did, changing meant reissuing every card and updating every terminal in the world. Later, as networks exhausted their available account space, some extended upward rather than sideways — which is where 19-digit Visa, Discover, and UnionPay numbers come from.\nThe lengths that break forms Five lengths cause essentially all the bugs.\n15 digits — American Express. A maxlength=\u0026quot;16\u0026quot; attribute is harmless, but a check for length === 16 rejects every Amex card. The display grouping is 4-6-5 rather than 4-4-4-4, and the security code field has to widen to four digits — which means the code field\u0026rsquo;s validation depends on the number field\u0026rsquo;s brand detection, a coupling that is easy to miss. The Amex generator produces cards for exactly this test.\n14 digits — Diners Club Classic. The shortest PAN in common circulation. A minlength=\u0026quot;15\u0026quot; rule excludes it entirely, and these cards are still in wallets.\n13 digits — legacy Visa. Rare, valid, and killed by the most popular Visa regex on the internet: ^4\\d{15}$ matches 16 digits and nothing else.\n19 digits — Visa, Discover, JCB, UnionPay, Maestro. The one that does real damage, because it fails silently. An input capped at 16 characters truncates on entry; a VARCHAR(16) column truncates on write with no error raised. The row saves, the stored number is wrong, and the symptom appears weeks later as declines affecting one subset of customers. Size inputs at maxlength=\u0026quot;23\u0026quot; if you keep the spaces, and columns at VARCHAR(19) minimum.\n12 digits — Maestro. The floor. Maestro\u0026rsquo;s 12-to-19 span defeats any fixed-length rule by itself, which is why the Maestro generator is the quickest way to find out whether your form has one.\nHow to validate length correctly Validate against the brand\u0026rsquo;s permitted set, not against a single number:\nconst LENGTHS = { amex: [15], diners: [14, 16, 19], discover: [16, 19], jcb: [16, 17, 18, 19], maestro: [12, 13, 14, 15, 16, 17, 18, 19], mastercard: [16], troy: [16], unionpay: [16, 17, 18, 19], visa: [13, 16, 19], }; function lengthIsValid(brand, pan) { const digits = pan.replace(/\\D/g, \u0026#39;\u0026#39;); const allowed = LENGTHS[brand]; if (!allowed) return digits.length \u0026gt;= 12 \u0026amp;\u0026amp; digits.length \u0026lt;= 19; return allowed.includes(digits.length); } The fallback branch is the important line. When the brand is unrecognised, accept anything from 12 to 19 digits and let the payment provider decide. New BIN ranges appear — the 2-series Mastercard range is the obvious recent example — and a hard reject on an unknown prefix loses real customers, while the provider\u0026rsquo;s check is authoritative anyway.\nThe same reasoning applies to the Luhn test on UnionPay: some UnionPay ranges are not Luhn-valid, so a checksum failure on 62 or 81 should warn rather than block.\nLength alone cannot identify a network A related mistake is running the inference backwards — treating length as a brand signal. It is not one. Sixteen digits covers Visa, Mastercard, Discover, JCB, UnionPay, Troy, Maestro, newer Diners Club, V PAY, and Visa Electron; the length narrows nothing. Fifteen digits is nearly always American Express, but Maestro reaches 15 as well.\nThe prefix identifies the network and the length then constrains what is acceptable for that network. Doing it in the other order produces code that misroutes cards whenever a network adds a length — which is precisely what happened to systems that inferred brands before the 19-digit ranges appeared.\nTesting for length problems Length bugs are cheap to catch and expensive to discover in production, because the failures are partial: everything works except one brand, or one product within a brand.\nThe minimum set of fixtures worth having, one card each:\n15 digits — Amex, for the === 16 check and the four-digit security code branch 14 digits — Diners Club Classic, for minimum-length rules 13 digits — legacy Visa, for regexes pinned to 16 19 digits — for input truncation, column truncation, and the 4-4-4-4-3 grouping 12 digits — Maestro, for the floor A 2-series Mastercard — not a length case, but it fails alongside these for the same reason: a rule written before the range existed Assert on the stored value, not on the form\u0026rsquo;s acceptance. A 19-digit number that the form accepts and the database truncates passes any test that only checks whether submission succeeded, which is why this specific bug survives so long — the test suite and the bug are looking at different ends of the same request.\nInput field configuration Setting Value Note maxlength 23 19 digits plus four spaces inputmode numeric Numeric keypad on mobile autocomplete cc-number Enables browser and password-manager autofill pattern [0-9\\s]* Digits and spaces Type text, never number That last row causes more grief than its length suggests. type=\u0026quot;number\u0026quot; strips leading zeros, renders spinner arrows on a card field, allows e and + in several browsers, and on some platforms silently applies locale formatting. A card number is a string of digits, not a quantity — treat it as text from the input element through to the database column.\nGrouping by length Display grouping follows the length, not the brand:\nLength Grouping Example 14 4-6-4 3056 930902 5904 15 4-6-5 3782 822463 10005 16 4-4-4-4 4539 1488 0343 6467 19 4-4-4-4-3 4532 0151 1283 0366 187 Every example above is a synthetic, Luhn-valid number produced by the generator and checked before publication — paste any of them into the validator to confirm. None of them belongs to an account.\nGet the grouping wrong and nothing breaks technically, but the field stops matching the card in the user\u0026rsquo;s hand, which measurably increases mistyping on exactly the input where a typo costs you the sale. Brand detection is what tells your formatter which grouping to apply, and the form testing checklist covers asserting all of this before it reaches production.\nFrequently Asked Questions How many digits is a Visa card? Usually 16. Visa\u0026rsquo;s specification also permits 13 and 19 digits: the 13-digit format is legacy and rare but still valid, and 19-digit Visa numbers exist in some markets. Validation that requires exactly 16 digits will reject both, which is why the safe rule is to accept the range a network publishes rather than the length you see most often. Why is American Express 15 digits? Because American Express defined its own numbering plan before the industry converged on 16, and never changed it. There is no technical advantage to 15 over 16; it is a historical decision preserved by the cost of changing every card, terminal, and system that handles them. The practical consequence is that Amex breaks any rule hard-coded to 16 digits, and its security code is four digits rather than three. What is the longest credit card number? Nineteen digits, which is the ceiling set by ISO/IEC 7812. Visa, Discover, JCB, UnionPay, and Maestro all have products at that length. Anything longer is not a card number, and any field or column sized below 19 will eventually corrupt one. What is the shortest credit card number? Twelve digits, which appears in the Maestro range. Diners Club Classic at 14 digits is the shortest length still commonly encountered on the major networks. Both are well below the 16 digits most forms assume, so a minimum-length rule of 15 or 16 silently excludes real cards. Can a card number be 19 digits? Yes, and this is the length that causes the most damage when it is not handled. A 19-digit number entered into a form capped at 16 characters is truncated at input; stored in a VARCHAR(16) column it is truncated at write, silently and without an error. The row saves, the number is wrong, and the failure surfaces later as an unexplained decline. What length should my database column be? VARCHAR(19) at minimum, and never an integer type. An integer column drops leading zeros and a 19-digit value exceeds the range of a 64-bit signed integer. If you are storing separators as entered, size for 23 characters — 19 digits plus four spaces — though normalising to digits before storage is the better habit. ","permalink":"https://ccgenerator.org/guides/card-number-length-by-network/","summary":"Most credit card numbers are 16 digits. American Express uses 15. Diners Club Classic uses 14. Visa has issued 13-digit and 19-digit numbers. Maestro ranges from 12 to 19. The ISO/IEC 7812 standard permits any length up to 19 digits, and card networks use most of that range.\nIf your payment form assumes 16, it rejects real cards.\nLength by network Network Digits Prefix Security code American Express 15 34, 37 4 Diners Club (classic) 14 300–305, 3095, 36, 38, 39 3 Diners Club (newer) 16, 19 36, 38, 39 3 Discover 16, 19 6011, 622126–622925, 644–649, 65 3 JCB 16–19 3528–3589 3 Maestro 12–19 50, 56–69 3 Mastercard 16 51–55, 2221–2720 3 Troy 16 9792 3 UnionPay 16–19 62, 81 3 V PAY 16 4 3 Visa 13, 16, 19 4 3 Visa Electron 16 4026, 417500, 4405, 4508, 4844, 4913, 4917 3 Two notes on reading this table.","title":"How Many Digits Is a Credit Card Number?"},{"content":"Generating synthetic card numbers is legal. Using card data to obtain something you have not paid for is not. The line falls between the two, and it falls on intent and use, not on the numbers themselves.\nThat is why payment processors publish their own test card numbers, why PCI DSS requires synthetic data in test environments rather than merely permitting it, and why this tool exists at all. It is also why using a generated number to start a subscription is fraud even though the attempt will fail.\nThis page is general information, not legal advice. Laws differ by jurisdiction and change over time; for a specific situation, consult a qualified lawyer.\nWhy synthetic test data is not just legal but required The stronger position is not that generating test numbers is permitted. It is that using real card data instead would put you in breach of rules you are already subject to.\nPCI DSS prohibits live PANs in pre-production environments. Requirement 6.5.5 in version 4, formerly 6.4.3, states that live account numbers are not used for testing or development. Testing a checkout with real customer card data is not a shortcut, it is a compliance failure — the PCI guide covers the scope rules in full.\nData protection law points the same way. Copying a production database into staging moves personal data into an environment that is typically less protected, while every obligation that attached to it in production follows it there.\nThe processors themselves publish test numbers. Stripe, Adyen, PayPal, and Braintree all distribute sets of card numbers specifically so that developers do not use real ones. Synthetic card data is the industry norm, not a workaround — the reference collects the published sets.\nThe format is a public standard. ISO/IEC 7812 defines how a card number is structured, and the Luhn checksum has been in the public domain since its patent expired. There is nothing confidential about the arithmetic.\nA card number generator is a test data utility, in the same category as a random name generator or a fake IBAN generator. The format it implements is a published standard, and the output it produces is required by compliance frameworks that would otherwise force developers to use real customer data.\nThere is a practical corollary that matters more than the abstract argument. In an audit or a due diligence review, someone will eventually ask where your test data came from. \u0026ldquo;It was generated from a public format specification, in the browser, from a cryptographic random source\u0026rdquo; is a complete answer that closes the question. \u0026ldquo;It\u0026rsquo;s a slice of last year\u0026rsquo;s production table, anonymised\u0026rdquo; opens several more: anonymised how, by whom, verified by what, and where are the other copies.\nThe distinction also holds when something goes wrong. A test fixture leaked from a repository is an embarrassment if it is synthetic and a notifiable data breach if it is not. That difference costs nothing to secure in advance and cannot be retrofitted afterwards, which is the practical reason the requirement exists in the first place rather than a bureaucratic one.\nWhere it becomes illegal The offence is never the number. It is what someone does with it:\nAttempting to obtain goods or services you have not paid for Using card data to start a free trial, subscription, or discount you are not entitled to Bypassing an age, identity, or payment verification control Deceiving anyone with fabricated card data Presenting or selling generated numbers as genuine cards Using anybody else\u0026rsquo;s card details, synthetic or real, without authorisation One point deserves emphasis because it is widely misunderstood:\nIn most jurisdictions the offence is attempting to obtain something by deception, and it is complete at the attempt. It does not require the attempt to succeed. A declined transaction is still an attempted fraud, and the declined attempt is logged.\n\u0026ldquo;It didn\u0026rsquo;t work anyway\u0026rdquo; is not a defence. It is a description of the evidence, and the record of the attempt is generally more durable than the transaction would have been.\nJurisdiction reference Each entry links to the official text or an authoritative reproduction.\nJurisdiction Law Covers United States 18 U.S.C. § 1029 Producing, using, or trafficking in counterfeit access devices United States 18 U.S.C. § 1030 Unauthorised access to protected computer systems United Kingdom Fraud Act 2006, ss. 1–2 Fraud by false representation United Kingdom Computer Misuse Act 1990 Unauthorised access to computer material European Union Directive (EU) 2019/713 Fraud and counterfeiting of non-cash means of payment Türkiye TCK m. 245 Misuse of bank or credit cards Türkiye TCK m. 158 Aggravated fraud, including use of banking instruments Canada Criminal Code s. 342 Credit card theft, forgery, and unauthorised use Australia Criminal Code Act 1995 Dishonestly obtaining or dealing in personal financial information Most other jurisdictions have equivalent provisions; the absence of a country from this table means only that its statute was not verified for this page, not that the conduct is permitted there.\nNote what these laws target: counterfeiting, unauthorised use, and obtaining by deception. None of them prohibits computing a number that satisfies a published checksum — which is what a generator does.\nThe age and identity verification question Some sites ask for a card as a proxy for age verification, and a share of the searches that reach this page are about exactly that.\nUsing a generated number there fails technically, because the check runs an authorisation against an issuer that has no record of the number. It is also an attempt to circumvent an access control, which is a separate matter from the fraud element and is treated as its own offence in several jurisdictions.\nIf the underlying problem is that you do not want to hand a card to a site you do not trust, that is a reasonable concern with a real answer: a virtual card with a spend limit, covered in the free trial guide. If the underlying problem is that you are below the age the site requires, no tool solves that, and the verification exists for reasons that generally hold up.\nResearchers, educators, and security testing Synthetic data is the right tool for teaching payments, demonstrating validation, and building training material, and none of that raises a legal question at all.\nTesting against systems is different, and the distinction is ownership:\nYour own systems — no permission needed beyond your employer\u0026rsquo;s own policies. Someone else\u0026rsquo;s systems — written authorisation is required, whether through a bug bounty programme\u0026rsquo;s published scope or a penetration testing agreement. Unauthorised access statutes apply whether or not any damage results. Responsible disclosure — if you find something without looking for it, report it through the vendor\u0026rsquo;s channel and stop testing. \u0026ldquo;For educational purposes\u0026rdquo; is not a defence in any jurisdiction. What determines the outcome is what was done and to whose systems, not how it was labelled.\nAttacking a live payment endpoint to see what happens is also, incidentally, the traffic pattern described in the card fraud guide — indistinguishable from the real thing at the receiving end, and treated accordingly.\nWhat this site does to stay on the right side of the line Transparency about our own position, since this page is partly an argument about it:\nNo card checking. There is no function here that tests whether a number is live, and there never will be. Your own code never needs that answer. No BIN lists. We publish no mapping between prefixes and institutions, in either direction, because that data\u0026rsquo;s primary non-commercial use is targeting. No issuer-targeted generation. The tool produces network-valid prefixes, not a named bank\u0026rsquo;s ranges. Prohibited uses are enumerated, not implied — the terms list them explicitly. There is a route to report misuse — contact us, and we act on reports. Nothing here is derived from real cardholder data, and no such data is stored. Numbers come from crypto.getRandomValues() in your browser, as the generator documents. If you are unsure The practical test is short. Are you testing something you own or are authorised to test? Then this is ordinary engineering work. Is anyone else\u0026rsquo;s system, account, or verification control involved? Then get permission first, in writing.\nIn a corporate setting, ask your legal or compliance team before running anything against a payment system — they will have an answer, and it takes an email. For a specific situation with real consequences, ask a qualified lawyer in the relevant jurisdiction.\nAgain: this page is general information, not legal advice. Statutes are cited to help you find the right text, not to tell you how it applies to you.\nThe statutes cited above were last checked against provider documentation on 4 August 2026. Providers do change what they publish — the official link beside each claim is authoritative. Frequently Asked Questions Is it legal to generate credit card numbers? Yes. A generator computes a number that satisfies a published checksum defined by a public standard, which is arithmetic rather than an offence. Payment processors publish their own test numbers for the same purpose, and PCI DSS requires synthetic data in test environments rather than merely permitting it. The output is test data, not a payment instrument. Is it illegal to use a fake card number on a website? If you are using it to obtain a service, bypass a control, or deceive someone, yes — that is fraud in essentially every jurisdiction, and the offence is generally complete at the attempt whether or not it succeeds. If you are typing it into a payment form you built, to check that your own validation works, that is ordinary software testing. Can I get in trouble for using a card generator? For testing your own software, no. For attempting a transaction, bypassing an age or identity check, or presenting the numbers as genuine cards, yes. The realistic outcome for a single failed attempt is not prosecution but an account ban, a flagged device, and a payment-provider blocklist entry — all of which outlast whatever you were trying to sign up for. Is it legal to use test cards for age verification? No. Beyond failing technically — the check runs a real authorisation — deliberately circumventing an access control is a distinct offence in several jurisdictions, on top of any fraud element. If the concern is handing a card to a site you do not trust, a virtual card with a spend limit solves that properly. Do I need permission to test payment systems? For your own systems, no. For anything belonging to someone else — a live checkout, a production API, another company\u0026rsquo;s gateway — you need written authorisation, through a bug bounty programme\u0026rsquo;s scope or a penetration testing agreement. Unauthorised access statutes apply regardless of whether damage occurs, and describing the work as research is not a defence. Is this legal advice? No. This page is general information written for developers, not advice on any specific situation. Laws differ by jurisdiction, change over time, and turn on facts a web page cannot know. For a real question about a real situation, consult a qualified lawyer in the relevant jurisdiction. ","permalink":"https://ccgenerator.org/guides/is-generating-test-card-numbers-legal/","summary":"Generating synthetic card numbers is legal. Using card data to obtain something you have not paid for is not. The line falls between the two, and it falls on intent and use, not on the numbers themselves.\nThat is why payment processors publish their own test card numbers, why PCI DSS requires synthetic data in test environments rather than merely permitting it, and why this tool exists at all. It is also why using a generated number to start a subscription is fraud even though the attempt will fail.","title":"Is Generating Test Card Numbers Legal?"},{"content":"The Luhn algorithm doubles every second digit from the right, subtracts 9 from any result above 9, sums the lot, and checks whether the total divides by 10. It catches mistyped digits and nothing else — the full explanation covers why it works and what it misses.\nThis page is the reference implementation, in four languages, executed against a shared set of test vectors before publication.\nThe JavaScript version also ships as a package. isLuhnValid, luhnCheckDigit, brand detection and a synthetic card generator built on the same network rules are published together as @ccgenerator/test-cards — zero dependencies, no install scripts, MIT, with the source on GitHub. It exists for test suites — generate('visa') in a fixture instead of a hard-coded number — not as a production checkout dependency; for a fifteen-line function, the FAQ below still applies.\nThe shared test vectors Use the same set everywhere. Half the value of a checksum function is knowing it fails on the right inputs, and the last three cases below are the ones that catch naive code.\nVALID 4539148803436467 Visa, 16 digits 5425233430109903 Mastercard, 16 digits 374245455400126 American Express, 15 digits 6011111111111117 Discover, 16 digits 4222222222222 Visa, 13 digits 30569309025904 Diners Club, 14 digits INVALID 4539148803436460 last digit altered 1234567812345678 arbitrary digits \u0026#34;\u0026#34; empty input \u0026#34;abc\u0026#34; no digits at all \u0026#34;0\u0026#34; a single zero The single zero deserves a note, because it is not obvious. A lone 0 genuinely satisfies the checksum — the sum is zero and zero is divisible by ten — so an implementation that guards only against an empty string still returns true for it. Every function below therefore requires at least two digits. A real card number requires far more than that, and the length rules per network belong in a separate check alongside this one.\nWhy these vectors The valid set is not arbitrary. It covers four networks and four different lengths — 13, 14, 15 and 16 digits — because the single most common Luhn bug is a loop that iterates in the wrong direction, and that bug is invisible unless your fixtures include an odd-length number. A suite built only from 16-digit Visa and Mastercard numbers will pass against an implementation that is wrong for every American Express card in production.\nThe invalid set covers three different failure modes rather than three examples of one. An altered final digit tests the checksum itself. A run of arbitrary digits tests that you are not accidentally accepting anything well-formed — remembering that roughly one random string in ten passes Luhn by chance, so a single random vector is a weak test and you should not be surprised when one occasionally has to be replaced. Empty input, non-numeric input and the lone zero test the guards rather than the arithmetic, and those are the three that catch real bugs in code review.\nProperty-based testing Fixed vectors prove specific cases. If you want stronger coverage for very little effort, assert the round trip instead: generate a random payload, compute its check digit, append it, and assert the validator accepts the result — then alter any single digit and assert it rejects. A few hundred iterations of that exercises both functions against each other across every length you care about, and it fails loudly on the direction bug that fixed vectors can miss. It also documents the relationship between the two functions better than prose does, since the check digit is part of the number\u0026rsquo;s structure rather than a separate artefact.\nJavaScript and TypeScript Iterating from the end with charCodeAt avoids allocating an array or a substring per digit:\nfunction luhnValid(input) { const digits = String(input).replace(/[^0-9]/g, \u0026#39;\u0026#39;); if (digits.length \u0026lt; 2) return false; let sum = 0; let double = false; for (let i = digits.length - 1; i \u0026gt;= 0; i--) { let d = digits.charCodeAt(i) - 48; if (double) { d *= 2; if (d \u0026gt; 9) d -= 9; } sum += d; double = !double; } return sum % 10 === 0; } The TypeScript signature is the only change needed — the body is identical:\nexport function luhnValid(input: string | number): boolean { const digits = String(input).replace(/[^0-9]/g, \u0026#39;\u0026#39;); if (digits.length \u0026lt; 2) return false; // …as above } A Vitest or Jest suite over the shared vectors:\nimport { describe, expect, it } from \u0026#39;vitest\u0026#39;; import { luhnValid } from \u0026#39;./luhn\u0026#39;; const VALID = [\u0026#39;4539148803436467\u0026#39;, \u0026#39;5425233430109903\u0026#39;, \u0026#39;374245455400126\u0026#39;, \u0026#39;6011111111111117\u0026#39;, \u0026#39;4222222222222\u0026#39;, \u0026#39;30569309025904\u0026#39;]; const INVALID = [\u0026#39;4539148803436460\u0026#39;, \u0026#39;1234567812345678\u0026#39;, \u0026#39;\u0026#39;, \u0026#39;abc\u0026#39;, \u0026#39;0\u0026#39;]; describe(\u0026#39;luhnValid\u0026#39;, () =\u0026gt; { it.each(VALID)(\u0026#39;accepts %s\u0026#39;, (n) =\u0026gt; expect(luhnValid(n)).toBe(true)); it.each(INVALID)(\u0026#39;rejects %s\u0026#39;, (n) =\u0026gt; expect(luhnValid(n)).toBe(false)); it(\u0026#39;ignores spaces and dashes\u0026#39;, () =\u0026gt; expect(luhnValid(\u0026#39;4539 1488-0343 6467\u0026#39;)).toBe(true)); }); Python Note the digit filter. str.isdigit() is the obvious choice and the wrong one: it returns True for Arabic-Indic and other Unicode digit characters, which int() will then happily convert — so a number typed on a non-Latin keyboard passes a check your regex-based validator elsewhere rejects. An explicit ASCII range is unambiguous.\ndef luhn_valid(number: str) -\u0026gt; bool: digits = [ord(c) - 48 for c in str(number) if \u0026#34;0\u0026#34; \u0026lt;= c \u0026lt;= \u0026#34;9\u0026#34;] if len(digits) \u0026lt; 2: return False checksum = 0 for i, d in enumerate(reversed(digits)): if i % 2 == 1: d *= 2 if d \u0026gt; 9: d -= 9 checksum += d return checksum % 10 == 0 import pytest from luhn import luhn_valid VALID = [\u0026#34;4539148803436467\u0026#34;, \u0026#34;5425233430109903\u0026#34;, \u0026#34;374245455400126\u0026#34;, \u0026#34;6011111111111117\u0026#34;, \u0026#34;4222222222222\u0026#34;, \u0026#34;30569309025904\u0026#34;] INVALID = [\u0026#34;4539148803436460\u0026#34;, \u0026#34;1234567812345678\u0026#34;, \u0026#34;\u0026#34;, \u0026#34;abc\u0026#34;, \u0026#34;0\u0026#34;] @pytest.mark.parametrize(\u0026#34;number\u0026#34;, VALID) def test_accepts_valid(number): assert luhn_valid(number) @pytest.mark.parametrize(\u0026#34;number\u0026#34;, INVALID) def test_rejects_invalid(number): assert not luhn_valid(number) PHP ord() on a string offset is the direct equivalent of the JavaScript version, and preg_replace handles the separators users paste in:\n\u0026lt;?php function luhn_valid(string $number): bool { $digits = preg_replace(\u0026#39;/[^0-9]/\u0026#39;, \u0026#39;\u0026#39;, $number); $len = strlen($digits); if ($len \u0026lt; 2) return false; $sum = 0; $double = false; for ($i = $len - 1; $i \u0026gt;= 0; $i--) { $d = ord($digits[$i]) - 48; if ($double) { $d *= 2; if ($d \u0026gt; 9) $d -= 9; } $sum += $d; $double = !$double; } return $sum % 10 === 0; } \u0026lt;?php use PHPUnit\\Framework\\TestCase; final class LuhnTest extends TestCase { public function validProvider(): array { return [[\u0026#39;4539148803436467\u0026#39;], [\u0026#39;5425233430109903\u0026#39;], [\u0026#39;374245455400126\u0026#39;], [\u0026#39;6011111111111117\u0026#39;], [\u0026#39;4222222222222\u0026#39;], [\u0026#39;30569309025904\u0026#39;]]; } /** @dataProvider validProvider */ public function testAcceptsValid(string $number): void { $this-\u0026gt;assertTrue(luhn_valid($number)); } public function testRejectsSingleZero(): void { $this-\u0026gt;assertFalse(luhn_valid(\u0026#39;0\u0026#39;)); } } The PHP version also ships as a package. The two functions above, plus brand detection and a synthetic card generator built on the same network rules, are published as ccgenerator/test-cards — PHP 8.1+, zero runtime dependencies, MIT, source on GitHub. It carries the same strlen($digits) \u0026lt; 2 guard as the snippet above, for the same reason.\ncomposer require --dev ccgenerator/test-cards For Laravel it adds a test_card validation rule, a Faker provider for model factories and two Artisan commands; for Symfony, a #[TestCardNumber] constraint and the matching console commands. Like the npm package it exists for test suites — TestCards::generate('visa') in a fixture instead of a hard-coded number — not as a production checkout dependency. For a fifteen-line function, the FAQ below still applies.\nRuby def luhn_valid(number) digits = number.to_s.gsub(/[^0-9]/, \u0026#39;\u0026#39;) return false if digits.length \u0026lt; 2 sum = 0 double = false digits.reverse.each_char do |c| d = c.ord - 48 if double d *= 2 d -= 9 if d \u0026gt; 9 end sum += d double = !double end (sum % 10).zero? end require \u0026#39;minitest/autorun\u0026#39; class LuhnTest \u0026lt; Minitest::Test VALID = %w[4539148803436467 5425233430109903 374245455400126 6011111111111117 4222222222222 30569309025904].freeze INVALID = [\u0026#39;4539148803436460\u0026#39;, \u0026#39;1234567812345678\u0026#39;, \u0026#39;\u0026#39;, \u0026#39;abc\u0026#39;, \u0026#39;0\u0026#39;].freeze def test_accepts_valid VALID.each { |n| assert luhn_valid(n), \u0026#34;expected #{n} to be valid\u0026#34; } end def test_rejects_invalid INVALID.each { |n| refute luhn_valid(n), \u0026#34;expected #{n} to be invalid\u0026#34; } end end Generating a check digit Validating and generating are the same arithmetic with the doubling parity flipped, because the payload is one digit shorter than the finished number. Getting this wrong produces a plausible digit that is simply incorrect, and it is the most common bug in hand-written Luhn code.\nfunction luhnCheckDigit(payload) { const digits = String(payload).replace(/[^0-9]/g, \u0026#39;\u0026#39;); if (!digits) throw new Error(\u0026#39;empty payload\u0026#39;); let sum = 0; let double = true; // starts true — the payload has no check digit for (let i = digits.length - 1; i \u0026gt;= 0; i--) { let d = digits.charCodeAt(i) - 48; if (double) { d *= 2; if (d \u0026gt; 9) d -= 9; } sum += d; double = !double; } return (10 - (sum % 10)) % 10; } def luhn_check_digit(payload: str) -\u0026gt; int: digits = [ord(c) - 48 for c in str(payload) if \u0026#34;0\u0026#34; \u0026lt;= c \u0026lt;= \u0026#34;9\u0026#34;] if not digits: raise ValueError(\u0026#34;empty payload\u0026#34;) total = 0 for i, d in enumerate(reversed(digits)): if i % 2 == 0: # doubles from the rightmost payload digit d *= 2 if d \u0026gt; 9: d -= 9 total += d return (10 - total % 10) % 10 Both were checked by stripping the final digit from each valid vector and confirming the function returns it: 453914880343646 → 7, 542523343010990 → 3, 37424545540012 → 6, 601111111111111 → 7, 3056930902590 → 4. That round trip is the test worth writing, because it exercises validation and generation against each other.\nThe bugs these functions usually ship with Empty input treated as valid. With no digits the sum is 0, and 0 % 10 == 0 is true. A length guard is the fix, and it has to be at least 2 — an empty check alone still lets \u0026quot;0\u0026quot; through. Iterating from the left. Luhn works right to left. A left-to-right implementation is correct on even-length numbers and wrong on odd-length ones, so it passes every test written with 16-digit cards and fails on 15-digit American Express in production. Parsing without filtering. parseInt on a whole string rather than a character, or forgetting to strip the spaces and dashes people paste, produces silently wrong results rather than errors. Converting the number to an integer. A 19-digit card number exceeds a 64-bit signed integer, and JavaScript loses precision above Number.MAX_SAFE_INTEGER. Card numbers are strings from input to storage — the sum itself never exceeds about 171, so the accumulator can be any integer type. Unicode digits. Python\u0026rsquo;s isdigit() accepts Arabic-Indic and other non-ASCII digits and int() converts them; JavaScript\u0026rsquo;s \\d matches ASCII only. The two languages disagree about the same input, so pin the character range explicitly. Missing the UnionPay exception. Some UnionPay ranges are not Luhn-valid at all. A hard reject on a failed checksum declines legitimate cards, so warn rather than block — the check is advisory, and the issuer\u0026rsquo;s answer is authoritative. Performance Luhn is O(n) with n at most 19, which makes a single check sub-microsecond in every language here. Write it for readability.\nIf you are validating millions of rows in a batch, the only thing worth changing is allocation: reading character codes by index, as all four implementations above do, avoids building an intermediate array per number. That is the difference between roughly a million checks per second in a scripting language and several times that — a distinction that matters in a migration job and nowhere else.\nDo not optimise this function. It will not be your bottleneck; the database write next to it will be.\nHow these were verified Every snippet on this page was executed against the shared vectors before publication:\nLanguage Runtime used JavaScript Node.js 22 Python CPython 3.9 PHP PHP 8.5 Ruby Ruby 2.6 All four accept the six valid vectors and reject all five invalid ones, including the single zero. The check-digit functions were verified by the round trip described above. Paste any of the valid numbers into the validator to confirm independently, or generate more with the card number generator — brand detection is the companion problem, and the one you will reach for next.\nThe implementations above were last checked against provider documentation on 4 August 2026. Providers do change what they publish — the official link beside each claim is authoritative. Frequently Asked Questions Which language should I use to validate card numbers? Whichever one your form already runs in, and then again on the server. Luhn is a dozen lines in every language and the implementations here are equivalent — there is no performance or correctness reason to prefer one. The meaningful decision is not the language but running the check in both places, because anything the browser validates can be bypassed. Should I validate on the client or the server? Both. Client-side is for immediate feedback when someone mistypes a digit, which is the entire purpose of the checksum. Server-side is the one you can trust, since the client-side check is advisory and easily skipped. Neither replaces the payment provider\u0026rsquo;s authorisation, which is the only check that establishes whether an account exists. Is there a library for this? Several, and for a fifteen-line function a dependency is usually the wrong trade. Every package you add is a supply-chain surface on your payment page specifically. If you do use one, prefer a maintained library with minimal transitive dependencies, and keep your own test vectors so you notice if its behaviour changes. Does Luhn validation slow down my form? No. The algorithm is linear in the number of digits and there are at most nineteen of them, so a single check costs well under a microsecond in any of these languages. If you are validating millions of rows in a batch job the allocation pattern starts to matter, but in a form it is unmeasurable next to a single DOM update. How do I test my implementation? With the shared vectors on this page. They cover 13, 14, 15 and 16-digit numbers across four networks, a number with a single altered digit, a random string, empty input, non-numeric input, and a single zero — which is the case naive implementations silently accept because a checksum of zero is divisible by ten. ","permalink":"https://ccgenerator.org/guides/luhn-algorithm-code-examples/","summary":"The Luhn algorithm doubles every second digit from the right, subtracts 9 from any result above 9, sums the lot, and checks whether the total divides by 10. It catches mistyped digits and nothing else — the full explanation covers why it works and what it misses.\nThis page is the reference implementation, in four languages, executed against a shared set of test vectors before publication.\nThe JavaScript version also ships as a package.","title":"Luhn Algorithm Code in Four Languages"},{"content":"A Mastercard number is 16 digits and begins in one of two ranges: 51–55, or 2221–2720. Both are ordinary issuance, both carry a Luhn check digit, and the three-digit CVC2 on the back is not part of the number.\nThe second range is the interesting one, and not only because so much validation code predates it. Its boundaries were chosen by arithmetic, and that arithmetic explains the whole change.\nIf you need numbers to test against, the Mastercard generator produces them on both ranges.\nThe format at a glance Property Value Prefixes 51–55, 2221–2720 Length 16 digits, fixed Check digit Luhn, final position Security code CVC2, 3 digits Code location Signature panel, back of card Grouping 4-4-4-4 Fixed length is worth noting because Mastercard is the exception among the major networks. Visa allows three lengths, JCB four, Maestro eight. Mastercard allows one, so a length === 16 check is correct here — and reusing that rule elsewhere is where the trouble starts. The length rules by network cover which networks tolerate it.\nWhy the 2-series has those exact boundaries Mastercard ran out of room in 51–55 and needed a second block. What is rarely explained is why the replacement is 2221–2720 and not some rounder-looking span.\nCount the issuer identification numbers each range yields.\nThe original block fixes the first two digits to one of five values — 51, 52, 53, 54, 55 — and leaves the rest free. With a six-digit BIN that is four free digits, so 5 × 10,000 = 50,000 BINs.\nThe new range fixes the first four digits to one of 500 values, since 2720 − 2221 + 1 = 500, and leaves two free at six digits: 500 × 100 = 50,000 BINs.\nRange Fixed digits Free digits (6-digit BIN) BINs 51–55 2 4 50,000 2221–2720 4 2 50,000 Identical. The relationship holds at eight digits too — 5,000,000 each — because widening the BIN adds the same two digits to both sides.\nSo the 2-series was not an arbitrary allocation inside MII 2. It was sized to exactly double Mastercard\u0026rsquo;s issuing capacity, and the boundaries fall where they do because 500 four-digit blocks is what it takes to match five two-digit ones. Once you see that, 2720 stops looking like a strange number to stop at.\nThe range sits under Major Industry Identifier 2, originally earmarked for airlines — which is why a 2-series card looks so unlike a payment card to code that was written when the first digit still implied an industry.\nThe pattern, briefly A numeric range is not a string prefix, so 2221–2720 decomposes into five alternatives:\nconst MASTERCARD = /^(?:5[1-5]\\d{4}|222[1-9]\\d{2}|22[3-9]\\d{3}|2[3-6]\\d{4}|27[01]\\d{3}|2720\\d{2})\\d{10}$/; The decomposition, the boundary cases either side of 2221 and 2720, and the detection order that keeps Mastercard from colliding with Maestro are all covered in the brand detection guide. The short version: test 2220… and 2721… and confirm both are rejected, because a range check that passes on the middle and fails at the edges is the normal outcome of writing one by hand.\nStripe publishes 2223 0031 2200 3222 as its 2-series test card, and its testing documentation is a convenient source for a number your gateway will actually recognise.\nWhat the change asks of your data, not just your regex Fixing the pattern is the visible half. The rest of the work is in places that do not throw errors:\nStored BIN prefixes. Any table keyed on a two-digit or six-digit Mastercard prefix needs new rows, not edited ones — the old range did not move. Routing rules, interchange estimates, and surcharge logic all read from those tables, and a missing row produces a default rather than a failure.\nAnalytics and reporting. Dashboards that segment by card brand using your own detection will show a growing \u0026ldquo;unknown\u0026rdquo; bucket rather than a broken chart. That bucket is the symptom, and it is easy to read as noise for months.\nFraud rules. Rules written against 5* prefixes silently stop applying to a share of Mastercard traffic. Neither the rule nor the transaction reports anything unusual.\nFixture data. A test suite whose Mastercard numbers all start with 54 proves nothing about the new range. This is the cheapest thing on the list to fix and the one most often left.\nThe common thread is that none of these fail loudly. The 2-series does not break payments — cards on it authorise normally — it breaks the things your own code inferred from the prefix, which is why the change can be years old and still be finding new victims.\nProduct families, and what the number does not say Mastercard Standard, World, and World Elite are tiers of the same product. Mastercard Debit and Prepaid are issued on the same ranges as credit. Business, Purchasing, and commercial products have their own BIN assignments but no distinguishing format.\nNone of it is visible in the number. Tier, funding type, country, and issuer all come from a BIN database, not from the digits — the number identifies the network and stops there.\nThis trips people up more with Mastercard than with most networks, because the tiers are heavily marketed and the interchange difference between a Standard consumer card and a World Elite one is real money to a merchant. The temptation is to infer the tier from the prefix, and it does not work: two cards on adjacent BINs can be different products, and the same product spans BINs that share no visible pattern. If your pricing depends on the distinction, it depends on licensed data, and building it on prefix heuristics means quietly mispricing a fraction of transactions with no error to alert you.\nMaestro and Cirrus Two related marks that are not Mastercard:\nMaestro is operated by Mastercard as a separate scheme: BIN ranges 50 and 56–69, lengths from 12 to 19 digits, debit-only funding, and a security code that some issuers omitted entirely. The variable length is what breaks systems — any fixed-length rule excludes valid Maestro cards — and its broad 6… range overlaps Discover and UnionPay, which is why detection order matters. The Maestro page covers that range in full.\nCirrus is an ATM network, not a card scheme. The mark indicates where the card can be used to withdraw cash. It has no BIN range, no format implications, and nothing for your payment code to detect — it appears here only because it shares the branding and is regularly mistaken for a third scheme.\nHistory The naming has changed more often than the format. The network began in 1966 as the Interbank Card Association, a group of banks formed to compete with BankAmericard. Its cards were branded Master Charge from 1966, renamed MasterCard in 1979, and restyled as Mastercard — lower-case c — in the 2016 rebrand that also simplified the interlocking-circles mark.\nThrough all of it the 5 prefix remained, which is why a card issued in 1979 and one issued in 2016 are indistinguishable by format. The 2-series is the first structural change to Mastercard numbering in the scheme\u0026rsquo;s history, and it changed the prefix without touching the length, the check digit, or anything else. Mastercard\u0026rsquo;s developer documentation is the current reference for its APIs and BIN guidance.\nCommon integration mistakes ^5[1-5] as a complete pattern. It was correct until 2017 and is now wrong for a growing share of cards. This is the most common Mastercard-specific bug in production. Never testing the 2-series. A fixture set of 5424… numbers exercises none of the new range. Add a 2-series number and the boundary cases around it. Committing to a brand on the first digit. A leading 5 narrows things quickly; a leading 2 identifies nothing until four digits are typed. Detection that guesses early shows the wrong logo and then corrects itself. Merging Maestro into Mastercard. Different ranges, different lengths, different funding. Code that treats them as one is wrong about both. A four-character security code field. If the field widened for American Express, it has to shrink back to three for Mastercard — the validator is a quick way to confirm your form handles the switch. Frequently Asked Questions What number does a Mastercard start with? Either 51 through 55, or 2221 through 2720. The second range is newer — Mastercard began issuing on it in 2017 after the original block filled up — and it is ordinary issuance rather than a special product. Code that only recognises 51-55 was complete when it was written and is not any more. How many digits is a Mastercard number? Sixteen, always. Unlike Visa, which permits 13, 16 and 19, Mastercard uses a single fixed length on both of its ranges. A strict length check of exactly 16 is correct for Mastercard specifically — just do not reuse that rule for other networks, where it will reject valid cards. Why does the 2-series range stop at 2720? Because 2221-2720 is 500 four-digit blocks, which yields exactly the same number of issuer identification numbers as the original 51-55 block. At six digits both give 50,000 BINs and at eight digits both give 5,000,000. The range was not chosen arbitrarily; it was sized to double the available space. Is Maestro the same as Mastercard? No. Maestro is operated by Mastercard but is a separate scheme with its own BIN ranges of 50 and 56-69, a length range of 12 to 19 digits rather than a fixed 16, and debit-only funding. Treating the two as one thing produces code that is wrong about both, most visibly on length validation. What is Cirrus? An ATM network rather than a card scheme. The Cirrus mark on a card indicates where it can be used to withdraw cash, not how the number is structured or how a purchase is routed. Nothing in a card number identifies Cirrus, and it is not something your payment code needs to detect. What is the CVC2 on a Mastercard? The three-digit security code printed on the signature panel. CVC2 is Mastercard\u0026rsquo;s brand name for it; Visa calls the equivalent CVV2 and American Express uses a four-digit CID. The issuer computes it under keys that never leave its hardware security module, so it cannot be derived from the card number. ","permalink":"https://ccgenerator.org/guides/mastercard-number-format/","summary":"A Mastercard number is 16 digits and begins in one of two ranges: 51–55, or 2221–2720. Both are ordinary issuance, both carry a Luhn check digit, and the three-digit CVC2 on the back is not part of the number.\nThe second range is the interesting one, and not only because so much validation code predates it. Its boundaries were chosen by arithmetic, and that arithmetic explains the whole change.\nIf you need numbers to test against, the Mastercard generator produces them on both ranges.","title":"Mastercard Number Format Explained"},{"content":"Checkout is where a bug costs money directly. This is the checklist we would run against a card payment form before shipping it — grouped by what breaks, with the test data each group needs.\nTwo things it assumes: that you are using generated test numbers for the form-level checks and your gateway\u0026rsquo;s sandbox cards for the processor-level ones, and that you are testing on a real mobile device somewhere in the process, not only in a desktop emulator.\nA copy-paste version of the whole thing is at the bottom.\n1. Card number field 13, 14, 15, 16 and 19-digit numbers are all accepted Input is type=\u0026quot;text\u0026quot;, never type=\u0026quot;number\u0026quot; — the latter strips leading zeros and renders spinner arrows inputmode=\u0026quot;numeric\u0026quot; for a numeric keypad on mobile autocomplete=\u0026quot;cc-number\u0026quot; so browsers and password managers can fill it Spaces and dashes are stripped or accepted, not rejected Paste works, including a number pasted with its formatting The mask follows the length: 4-4-4-4, 4-6-5, 4-6-4, 4-4-4-4-3 maxlength accommodates 19 digits plus separators Letters and symbols are blocked or silently stripped The Luhn check runs on blur, not on every keystroke A failed Luhn check warns but does not block submission The same validation runs server-side The lengths are the ones that catch people — which network uses which is the reference, and the Luhn guide covers why the checksum is advisory rather than authoritative.\nTest data: the generator for individual cases, the bulk generator for a fixture file.\n2. Card brand detection The logo appears as soon as the prefix is unambiguous No logo is shown while the prefix is still ambiguous A 2-series Mastercard is recognised American Express is recognised and the security code field widens to four digits Maestro, Discover, JCB, UnionPay and Diners Club are recognised An unrecognised prefix is accepted rather than blocked Clearing the number clears the logo Changing brand changes the mask Detection that commits too early shows the wrong logo and then corrects itself, which reads as a bug on the one field where customers are already careful. The brand detection guide has boundary-tested patterns, and the Mastercard page covers the 2-series specifically.\n3. Expiry date Month is validated as 01–12 A past date is rejected The current month is accepted — cards expire at the end of their month, not the start Both two-digit and four-digit years are handled The MM/YY separator is inserted automatically Dates more than ten years out are accepted autocomplete=\u0026quot;cc-exp-month\u0026quot; and cc-exp-year are set The third item is the one that reaches production. A rule requiring the expiry to be strictly later than today rejects every card in its final month — a working card, refused, with the customer told to try another.\n4. Security code Four digits on American Express, three on everything else The field length updates when the detected brand changes Only digits are accepted autocomplete=\u0026quot;cc-csc\u0026quot; is set Help text and any diagram show the correct location — Amex prints it on the front The code is never written to form state persistence, localStorage, logs, analytics or error reports A missing code is handled for cards that do not carry one Why a security code cannot be derived from the number explains the storage rule, and the CVV generator emits both lengths. The Amex generator is the fastest way to exercise the four-digit branch.\n5. Cardholder name Accented characters are accepted: ö, ü, ç, é, ñ, ø, å Cyrillic, Greek and Arabic scripts are handled or explicitly rejected with a clear message Hyphens and apostrophes are accepted — O\u0026rsquo;Brien, Jean-Luc Very long names do not overflow or truncate silently Single-word names are accepted; not every culture uses a surname autocomplete=\u0026quot;cc-name\u0026quot; is set Encoding survives intact all the way to the database — UTF-8 end to end This section is skipped more often than any other and it costs international customers directly. The identity generator produces names with characters worth testing against.\n6. Billing address and AVS Postal codes are validated per country, with no assumption of five digits Postal codes are stored as strings, never integers — leading zeros are real State or province is required or optional according to the country An AVS response of G — issuer does not participate — is not treated as a failure A billing address different from the shipping address works Address autocomplete does not prevent manual entry The AVS item matters for international traffic: a foreign issuer that does not participate in address verification returns a code meaning \u0026ldquo;cannot check\u0026rdquo;, and code that treats anything other than a full match as fraud declines those customers wholesale.\n7. Submission and processing Double-clicking submit does not create two payments — disable the button and send an idempotency key A loading state is visible while the request is in flight Network failure is handled with a message the customer can act on Timeouts are handled, and the outcome is checked rather than assumed Slow connections show progress rather than appearing frozen The browser back button after payment does not resubmit Refreshing the page does not charge twice 8. Error handling The decline message is human — \u0026ldquo;Your bank declined this payment\u0026rdquo; — not a raw code The decline reason is never shown to the customer; \u0026ldquo;lost card\u0026rdquo; and \u0026ldquo;stolen card\u0026rdquo; must not reach the screen Cart and form contents survive a failure, minus the card number Retry is possible but rate-limited Repeated failures from one source are blocked Errors are announced to screen readers via aria-live The second item is both a safety and an accuracy question: those codes are often wrong, and when they are right, displaying them tells the wrong person something useful. Why cards get declined covers the categories, and the card fraud guide covers why repeated failures need a limit.\n9. 3-D Secure The frictionless flow completes The challenge flow completes A cancelled challenge returns the customer to a usable state A soft decline is retried with authentication rather than shown as a failure The challenge iframe renders correctly on a mobile viewport The webhook arriving before the browser returns is handled The 3-D Secure guide has the full sixteen-item matrix, including the exemption paths and the race condition.\n10. Security and compliance The page is served over HTTPS, with no mixed content Card fields live in hosted fields or an iframe, keeping the PAN out of your DOM A Content Security Policy is enforced on the payment page Third-party scripts on checkout are minimised and carry Subresource Integrity No PAN appears in application logs — verified by grepping the logs, not by reading the code No security code is written anywhere at all The error tracker\u0026rsquo;s payloads contain no card data Analytics events contain no card data Browser autofill does not populate unexpected fields The PCI DSS guide lists the ten places card data lands without anyone deciding to store it, and tokenisation is how you stop holding it at all.\n11. Accessibility Every field is reachable and operable by keyboard Labels are real \u0026lt;label\u0026gt; elements, not placeholder text Error messages are associated with their field via aria-describedby Focus order follows the visual order Contrast ratio is at least 4.5:1, including on error states The form has been tested end to end with a screen reader Decorative card artwork is aria-hidden 12. Mobile Tested on a real device, not only an emulator The numeric keypad opens for number fields Autofill works, including card scanning on iOS Fields stay visible when the keyboard is open Touch targets are at least 44×44 px Landscape orientation does not break the layout An emulator gets you the layout. It does not get you the keyboard behaviour, the autofill prompt, the scan-card affordance, or the way a real thumb hits a 32-pixel target.\n13. Automation There is an end-to-end test for the critical path Test data is version-controlled and deterministic Negative cases are included, not only the happy path Tests do not depend on a live gateway — mock it or use the sandbox The suite runs in CI on every change The bulk generator produces deterministic fixture sets, and test data management covers keeping them healthy. When a test genuinely needs a processor response, the sandbox card reference has the numbers.\nThe whole list, to copy ## Card number field - [ ] 13, 14, 15, 16 and 19-digit numbers accepted - [ ] type=\u0026#34;text\u0026#34;, not type=\u0026#34;number\u0026#34; - [ ] inputmode=\u0026#34;numeric\u0026#34; - [ ] autocomplete=\u0026#34;cc-number\u0026#34; - [ ] Spaces and dashes stripped or accepted - [ ] Paste works with formatted numbers - [ ] Mask follows length (4-4-4-4, 4-6-5, 4-6-4, 4-4-4-4-3) - [ ] maxlength covers 19 digits plus separators - [ ] Letters and symbols blocked or stripped - [ ] Luhn check runs on blur - [ ] Failed Luhn warns, does not block - [ ] Validation repeated server-side ## Brand detection - [ ] Logo appears when the prefix is unambiguous - [ ] No logo while ambiguous - [ ] 2-series Mastercard recognised - [ ] Amex recognised, security code field widens to 4 - [ ] Maestro, Discover, JCB, UnionPay, Diners recognised - [ ] Unrecognised prefix accepted, not blocked - [ ] Clearing the number clears the logo - [ ] Brand change updates the mask ## Expiry date - [ ] Month validated 01-12 - [ ] Past dates rejected - [ ] Current month accepted - [ ] Two and four-digit years handled - [ ] MM/YY separator inserted automatically - [ ] Dates 10+ years out accepted - [ ] autocomplete=\u0026#34;cc-exp-month\u0026#34; / \u0026#34;cc-exp-year\u0026#34; ## Security code - [ ] 4 digits on Amex, 3 elsewhere - [ ] Field length updates with detected brand - [ ] Digits only - [ ] autocomplete=\u0026#34;cc-csc\u0026#34; - [ ] Help text shows correct location (Amex: front) - [ ] Never persisted anywhere - [ ] Missing code handled where a card has none ## Cardholder name - [ ] Accented characters accepted - [ ] Non-Latin scripts handled or clearly rejected - [ ] Hyphens and apostrophes accepted - [ ] Very long names handled - [ ] Single-word names accepted - [ ] autocomplete=\u0026#34;cc-name\u0026#34; - [ ] UTF-8 intact to the database ## Billing address and AVS - [ ] Postal code validated per country - [ ] Postal code stored as a string - [ ] State/province required per country rules - [ ] AVS \u0026#34;G\u0026#34; not treated as failure - [ ] Billing separate from shipping works - [ ] Autocomplete does not block manual entry ## Submission - [ ] Double-click does not double-charge - [ ] Loading state visible - [ ] Network failure handled - [ ] Timeout handled - [ ] Slow connection shows progress - [ ] Back button safe after payment - [ ] Refresh does not charge twice ## Error handling - [ ] Human decline message, no raw codes - [ ] Decline reason never shown to the customer - [ ] Cart and form survive failure - [ ] Retry possible but rate-limited - [ ] Repeated failures blocked - [ ] Errors announced via aria-live ## 3-D Secure - [ ] Frictionless flow completes - [ ] Challenge flow completes - [ ] Cancelled challenge recoverable - [ ] Soft decline retried with authentication - [ ] Challenge iframe correct on mobile - [ ] Webhook-before-redirect handled ## Security and compliance - [ ] HTTPS, no mixed content - [ ] Card fields in hosted fields or an iframe - [ ] CSP enforced on the payment page - [ ] Third-party scripts minimised, SRI applied - [ ] No PAN in logs (verified by grep) - [ ] No security code stored anywhere - [ ] No card data in error tracker payloads - [ ] No card data in analytics - [ ] Autofill does not populate unexpected fields ## Accessibility - [ ] Keyboard operable throughout - [ ] Real \u0026lt;label\u0026gt; elements - [ ] Errors linked via aria-describedby - [ ] Logical focus order - [ ] Contrast at least 4.5:1 - [ ] Screen reader tested end to end - [ ] Decorative card art aria-hidden ## Mobile - [ ] Tested on a real device - [ ] Numeric keypad opens - [ ] Autofill and card scanning work - [ ] Fields visible with keyboard open - [ ] Touch targets at least 44x44 px - [ ] Landscape layout intact ## Automation - [ ] E2E test for the critical path - [ ] Test data version-controlled and deterministic - [ ] Negative cases included - [ ] No dependency on a live gateway - [ ] Runs in CI Ninety-three items. Most teams pass the first two sections and fail somewhere between five and twelve, which is roughly the order in which the failures reach customers.\nFrequently Asked Questions What should I test first on a payment form? Length handling and brand detection, because they fail for whole categories of customer at once rather than intermittently. A form that assumes 16 digits rejects every American Express card, and detection written before 2017 treats every 2-series Mastercard as unknown. Both are invisible if your fixtures are all 16-digit Visa numbers, and both are cheap to fix once you have seen them. Which test cards should I use for a payment form? Generated numbers for anything your own code decides — field lengths, masks, brand detection, checksum validation, error states — and your gateway\u0026rsquo;s published sandbox cards for anything requiring a response from the processor. Generated numbers cannot produce an approval, a decline or a 3-D Secure challenge, because no issuer stands behind them. Should a failed Luhn check block submission? No. Warn beside the field and leave the submit button live. New BIN ranges appear, some UnionPay ranges are not Luhn-valid at all, and losing a legitimate customer costs far more than one wasted authorisation attempt. The payment provider\u0026rsquo;s answer is authoritative; your checksum is a courtesy that catches typos. Why should the current month be accepted as an expiry date? Because a card expires at the end of its stated month, not the beginning. A validation rule that requires the expiry to be strictly after today rejects every card in its final month of validity — a real customer with a genuinely working card, told to use a different one. It is one of the most common date-handling bugs in checkout. How do I test that card data is not reaching my logs? Grep the logs rather than reading the code. Submit a payment with a known test number, then search your application logs, your error tracker\u0026rsquo;s stored payloads, and your analytics events for those digits and for the security code. Assert it in CI against real logger output, not a mock — the leak is almost always something logging a whole request body rather than a deliberate write. ","permalink":"https://ccgenerator.org/guides/payment-form-testing-checklist/","summary":"Checkout is where a bug costs money directly. This is the checklist we would run against a card payment form before shipping it — grouped by what breaks, with the test data each group needs.\nTwo things it assumes: that you are using generated test numbers for the form-level checks and your gateway\u0026rsquo;s sandbox cards for the processor-level ones, and that you are testing on a real mobile device somewhere in the process, not only in a desktop emulator.","title":"Payment Form Testing Checklist"},{"content":"The PayPal sandbox is a separate environment with its own accounts, its own credentials, and no real money. It is not your live account in a test mode — and that difference is where most first attempts go wrong.\nThis page covers setting it up, the cards and triggers it recognises, how Braintree differs, webhooks, and the places where the sandbox does not behave like production. For the same numbers alongside every other processor, the test card reference is the cross-gateway summary.\nWhat the sandbox actually is A parallel copy of PayPal. Sandbox accounts live in the Developer Dashboard, not in PayPal proper, so your normal login does not work and your live client ID and secret are different values from your sandbox ones. Money moves between sandbox accounts and nowhere else.\nTwo credentials pairs, two sets of endpoints, one integration. Almost every \u0026ldquo;the sandbox is broken\u0026rdquo; report resolves to a live client ID pointed at a sandbox endpoint or the reverse — worth checking before anything else, exactly as a test card failing in production is usually the wrong key rather than the wrong card.\nCreating sandbox accounts You need two, and the Dashboard\u0026rsquo;s accounts page creates both:\nA business account — the merchant. This is where your sandbox client ID and secret come from, and it receives the payments in your tests.\nA personal account — the buyer. This is the login you use in the PayPal popup during a test checkout, and it is worth setting a balance on it when you create it. A sandbox buyer with no funds behaves exactly like a real one with no funds, which produces a failure that looks like an integration bug and is not.\nEach sandbox account has a generated email address and a password you can view or change in the Dashboard. Note both somewhere your team can find them — a shared test account whose password only one person knows is a recurring small tax on everyone else.\nSandbox test cards For card payments that do not go through the PayPal login, the sandbox recognises a published set of numbers. The card selects the brand; it does not select the outcome.\nCard number Brand 4012 8888 8888 1881 Visa 4005 5192 0000 0004 Visa 2223 0000 4840 0011 Mastercard 3714 496353 98431 American Express 3646 1510 0000 39 Diners Club 6304 0000 0000 0000 Maestro 3636 5000 0000 0260 JCB 6200 6800 0000 0004 UnionPay Generated numbers do not work here and are not meant to. Use the generator for your own form\u0026rsquo;s validation layer, and these for anything that reaches PayPal.\nRejection triggers This is PayPal\u0026rsquo;s genuinely unusual design, and the thing most worth knowing on this page. The outcome is selected by the cardholder name, not by the card number:\nTrigger value Simulates CCREJECT-REFUSED Card refused CCREJECT-IF Insufficient funds CCREJECT-EC Expired card CCREJECT-LS Lost or stolen card CCREJECT-SF Suspected fraud CCREJECT-CVV_F Security code failure CCREJECT-IRC Invalid card CCREJECT-IA Invalid account CCREJECT-BANK_ERROR Generic decline The values are case-sensitive and go in the first name or name-on-card field. Every other sandbox of this kind — Stripe, Adyen, Braintree — picks the outcome some other way, so a team arriving from one of those will look for decline cards that do not exist.\nSource: PayPal — Card testing.\nTesting the Checkout integration The JavaScript SDK renders the buttons and hands you an order to capture server-side. The shape of a minimal integration:\npaypal.Buttons({ createOrder: (data, actions) =\u0026gt; actions.order.create({ purchase_units: [{ amount: { value: \u0026#39;10.00\u0026#39;, currency_code: \u0026#39;USD\u0026#39; } }], }), onApprove: async (data) =\u0026gt; { // Capture on YOUR server, never in the browser — the browser can lie. const res = await fetch(`/api/orders/${data.orderID}/capture`, { method: \u0026#39;POST\u0026#39; }); const details = await res.json(); if (details.status === \u0026#39;COMPLETED\u0026#39;) showSuccess(details); }, onError: (err) =\u0026gt; { // Fires for SDK and network failures, not for a declined card. reportToMonitoring(err); }, }).render(\u0026#39;#paypal-button-container\u0026#39;); Three things to test that this snippet makes easy to skip. onCancel — the buyer closing the popup is the single most common non-success path and it is not an error. onError versus a declined capture — they are different branches and only one of them means \u0026ldquo;try another card\u0026rdquo;. And the capture call itself failing after onApprove succeeded, which leaves an approved order with no capture and is the state that produces support tickets.\nThe Checkout integration guide and the SDK reference document the full callback set.\nBraintree, which is the same company and a different product Braintree is PayPal-owned with its own sandbox, its own dashboard, and its own conventions. If your integration is Braintree, PayPal\u0026rsquo;s triggers do not apply.\nThe useful difference is that the transaction amount selects the processor response:\nAmount Result 0.01 – 1,999.99 Authorised and settled 2,000.00 – 2,999.99 Processor declined 3,000.00 – 3,000.99 Failed 5,001.00 Gateway rejected — incomplete application That is the cleanest decline mechanism in any sandbox. You change one number in a test fixture and the same card produces a different outcome, which makes decline paths easy to parameterise rather than requiring a table of cards. Braintree also publishes card numbers that decline on verification, such as 4000 1111 1111 1115.\nSource: Braintree — Testing.\nNegative testing scenarios Success paths get tested because they are the ones people demo. These are the ones that reach real customers:\nThe buyer cancels. They close the popup or click cancel. This fires onCancel, not onError, and it is not a failure — the cart should survive intact and the customer should be able to try again without re-entering anything.\nInsufficient funds. Use CCREJECT-IF for a card flow, or a sandbox buyer account with a balance below the order total for a wallet flow. The two produce different responses, and code that handles only one of them will surprise you.\nExpired card. CCREJECT-EC. Worth testing separately from a generic decline, because the right customer-facing message differs: an expired card is worth telling someone about, where a generic refusal is not.\nA payment left pending. Some payments do not resolve immediately. Your order state machine needs a pending state that is neither success nor failure, and the webhook that later resolves it needs to move the order without double-fulfilling.\nRefunds, full and partial. A partial refund against a captured payment is where amount arithmetic goes wrong, especially with tax and shipping split across line items. Test that the refunded total can never exceed the captured total, including across several partial refunds.\nDisputes. The sandbox can simulate a dispute so you can exercise the webhook and the internal state change. Even if your process is manual, the event should be recorded rather than dropped.\nEach of these has a customer-visible consequence, and none of them is exercised by a successful test payment.\nWebhooks in the sandbox Sandbox webhooks are configured per application in the Developer Dashboard, and the Dashboard includes a simulator that fires a chosen event type at your endpoint without a real transaction. That is useful for wiring, and it is not sufficient — a simulated event is not identical to one produced by an actual order, so exercise both.\nVerify the signature on every delivery. PayPal\u0026rsquo;s verification is a server-side API call rather than a local HMAC, which means your handler depends on PayPal being reachable to validate a message from PayPal:\n// Verify before trusting the payload. This is an API call, not a local check. const verification = await fetch( \u0026#39;https://api-m.sandbox.paypal.com/v1/notifications/verify-webhook-signature\u0026#39;, { method: \u0026#39;POST\u0026#39;, headers: { \u0026#39;Content-Type\u0026#39;: \u0026#39;application/json\u0026#39;, Authorization: `Bearer ${accessToken}` }, body: JSON.stringify({ auth_algo: req.headers[\u0026#39;paypal-auth-algo\u0026#39;], cert_url: req.headers[\u0026#39;paypal-cert-url\u0026#39;], transmission_id: req.headers[\u0026#39;paypal-transmission-id\u0026#39;], transmission_sig: req.headers[\u0026#39;paypal-transmission-sig\u0026#39;], transmission_time: req.headers[\u0026#39;paypal-transmission-time\u0026#39;], webhook_id: process.env.PAYPAL_WEBHOOK_ID, webhook_event: req.body, }), } ).then((r) =\u0026gt; r.json()); if (verification.verification_status !== \u0026#39;SUCCESS\u0026#39;) { return res.status(400).send(\u0026#39;signature verification failed\u0026#39;); } // PayPal retries. Record event id and return early if already handled. if (alreadyHandled(req.body.id)) return res.sendStatus(200); Test the failure branch deliberately: alter one header and confirm the request is rejected, then deliver the same event twice and confirm the order is fulfilled once. Both are covered in the webhooks documentation.\nSandbox limitations, honestly The sandbox is a good environment and it is not production:\nSome features behave differently or are missing. Newer products in particular reach the sandbox later than the live platform. Not every country and currency combination is supported. A market that works live may have no sandbox equivalent, and the failure looks like a configuration error. The sandbox has its own outages, independent of production, and they are not always announced promptly. An integration that worked yesterday and fails today with no code change is worth checking against status before debugging. Timing differs. Settlement, disputes and some asynchronous events do not run on production\u0026rsquo;s timetable. The practical conclusion: a green sandbox run means your integration is correct, not that it will work live. Before launch, run one small real transaction and refund it. That step catches the account configuration problems no sandbox can model.\nIt is worth doing that final check with a colleague\u0026rsquo;s card rather than your own, from a different device and network. A merchant testing their own checkout while signed in to their own business account exercises a path no customer will ever take, and several classes of problem — account linkage, currency handling, risk rules applied to first-time buyers — only appear when the buyer is genuinely someone else.\nCommon mistakes Live credentials against sandbox endpoints, or the reverse. Check the keys before anything else; it is the cause more often than not. Using your real PayPal login for the buyer. Sandbox buyers are separate accounts created in the Developer Dashboard. Forgetting to fund the buyer account. A balance-based flow fails for a reason that is not your code. A country mismatch. A sandbox business account in one country and a test flow assuming another produces behaviour that is correct and confusing. Testing webhooks only in the sandbox. Configure and verify them in production too, before the first real order rather than after. Trying generated card numbers. They pass your form and stop at PayPal — the payment form checklist covers which layer each kind of number belongs to, and the Stripe reference is the comparison if you work with both. The card numbers, triggers and amount ranges above were last checked against provider documentation on 4 August 2026. Providers do change what they publish — the official link beside each claim is authoritative. Frequently Asked Questions What is the PayPal sandbox? A parallel copy of PayPal with its own accounts, its own credentials, and no real money. Sandbox accounts are created in the Developer Dashboard rather than being your live account in a test mode, which is the first thing that surprises people: your normal PayPal login does not work there, and the client ID and secret are different values entirely. How do I force a declined payment in the PayPal sandbox? By typing a trigger value into the cardholder name field. CCREJECT-REFUSED forces a refusal, CCREJECT-IF insufficient funds, CCREJECT-EC an expired card, CCREJECT-LS lost or stolen, CCREJECT-SF suspected fraud, and CCREJECT-CVV_F a security code failure. The values are case-sensitive. This is unusual — most sandboxes select the outcome with the card number — and it catches people who assume PayPal works like Stripe. Can I use generated card numbers in the PayPal sandbox? No. The sandbox recognises its own published numbers and rejects everything else, because the outcome is scripted rather than computed from the digits. Generated numbers are the right tool for your own form\u0026rsquo;s validation and the wrong tool the moment a request leaves your application. How is Braintree testing different from PayPal\u0026#39;s? Braintree is PayPal-owned but a separate product with its own sandbox and conventions. The most useful difference is that Braintree selects the processor response by transaction amount rather than by card or name — anything up to 1,999.99 is authorised, 2,000.00 to 2,999.99 is processor-declined, and 5,001.00 is gateway-rejected. That makes it the cleanest way to test a decline without changing the card on file. Do I need to add balance to a sandbox buyer account? For PayPal-balance flows, yes — a personal sandbox account with no funds behaves like a real one with no funds, and a test that should succeed will fail for a reason that has nothing to do with your code. Set the balance when you create the account in the Developer Dashboard rather than debugging it later. Does the sandbox behave exactly like production? No, and planning around that is part of using it. Some features behave differently or are unavailable, certain country and currency combinations are not supported, and the sandbox has its own outages. Treat a green sandbox run as evidence your integration is correct, not as proof it will work live — a small real transaction, refunded, is the last step. ","permalink":"https://ccgenerator.org/guides/paypal-sandbox-testing/","summary":"The PayPal sandbox is a separate environment with its own accounts, its own credentials, and no real money. It is not your live account in a test mode — and that difference is where most first attempts go wrong.\nThis page covers setting it up, the cards and triggers it recognises, how Braintree differs, webhooks, and the places where the sandbox does not behave like production. For the same numbers alongside every other processor, the test card reference is the cross-gateway summary.","title":"PayPal Sandbox Testing: Setup and Cards"},{"content":"PCI DSS is written for organisations, not for engineers, which is why most developers meet it as a list of things someone in compliance says they cannot do. This page covers the parts that actually change how you write code: which data you may store, which you may never store, what \u0026ldquo;reducing scope\u0026rdquo; means in practice, and why your test environment is not allowed to contain real card numbers.\nThis is general technical information, not compliance advice. The authoritative source is the PCI Security Standards Council, and a real compliance programme needs a Qualified Security Assessor.\nWhat PCI DSS is The Payment Card Industry Data Security Standard is published by the PCI Security Standards Council, founded by Visa, Mastercard, American Express, Discover, and JCB.\nIt is not a law. It is a contractual condition of accepting card payments, which in practice makes it more immediate than most regulation: the consequences of non-compliance are financial penalties, liability for the cost of a breach, and ultimately losing the ability to take card payments at all. There is no regulator to appeal to, only your acquirer.\nThe current standard is PCI DSS v4, with v4.0.1 the revision published in the Council\u0026rsquo;s document library. Version 3.2.1 has been retired, and the future-dated requirements introduced with v4 are now in force. Requirement numbering changed between the two versions — the rule about test data, for instance, moved from 6.4.3 to 6.5.5 — so a Stack Overflow answer citing a requirement number may be pointing at the right rule under the wrong index.\nThe data categories This table is the part worth committing to memory. Everything else follows from it.\nData Storage permitted? Must be protected if stored? Cardholder Data Primary Account Number (PAN) Yes Yes — rendered unreadable Cardholder name Yes Yes Expiry date Yes Yes Service code Yes Yes Sensitive Authentication Data Full magnetic stripe or chip track data Never after authorisation — CAV2 / CVC2 / CVV2 / CID Never after authorisation — PIN and PIN block Never after authorisation — Sensitive Authentication Data may not be retained after authorisation — not encrypted, not hashed, not in a log file, not \u0026ldquo;temporarily\u0026rdquo;. The prohibition is absolute. This is the single rule most likely to be violated by accident, because security codes end up in application logs, error tracker payloads, and support screenshots without anyone deciding to store them.\nThe distinction is easier to remember through what each field is for. A PAN identifies an account, which is why it can legitimately persist. A security code proves that whoever is using the card is holding it at that moment, which is why it has no purpose after authorisation and no justification for existing afterwards. Ours is a random value of the right length precisely because a real one cannot be derived from the number — see the CVV generator for what that means when you need test input.\nWhere card data accidentally lands Almost nobody decides to store card data improperly. It arrives through infrastructure built for other purposes:\nLocation How it gets there Prevention Application logs Logging the whole request body Redact by field name at the logger, not the call site Error trackers Exception context carries form data Configure denyUrls and scrub payment fields in the SDK Analytics events Form values sent as event properties Never pass raw input as event data localStorage / sessionStorage Persisting form state for UX Exclude payment fields from any state persistence Database backups An unencrypted PAN column, copied off-site Encrypt the field, not just the disk Support tickets Customers paste details; agents screenshot Auto-redact card-shaped strings on ingest Session replay tools Input fields recorded by default Mask all inputs, then allowlist — never the reverse Crash dumps and core files Raw memory contents Disable dumps on payment services CDN and proxy logs Query strings and POST bodies Never put card data in a URL; audit access logs Git history One test fixture with a real card, committed once Pre-commit secret scanning; treat history as permanent The last two deserve emphasis because they are rarely discussed. Session replay tools record input fields unless configured otherwise, and the default is usually to capture. Git history is worse: a card number committed once and deleted in the next commit is still in the repository, in every clone, on every developer\u0026rsquo;s laptop, and in your CI cache. Rotating that out means rewriting history across every fork.\nReducing scope — the only real strategy Every system that stores, processes, or transmits cardholder data is in scope. The most effective compliance strategy is not to secure more systems; it is to have fewer systems touch the data.\nIn order of effectiveness:\nHosted payment page or redirect. The customer enters card details on the provider\u0026rsquo;s page. The data never reaches your infrastructure at all. Narrowest possible scope. Hosted fields or iframes — Stripe Elements, Braintree Hosted Fields, Adyen Components. The input fields live in the provider\u0026rsquo;s iframe, so card data never enters your DOM even though the form looks like yours. Tokenisation. The provider stores the PAN and hands you a token that is meaningless outside their system. Tokens are not cardholder data, so storing them keeps you out of scope — covered in the tokenisation guide. Network segmentation. Where card data genuinely must be handled, isolate those systems so the rest of your estate is not dragged in with them. Encryption at rest with your own vault. Broadest scope, highest cost, and the option to choose only when the first four are impossible. Each step down that list adds systems, audits, and cost. The corresponding self-assessment questionnaires make the trade explicit:\nIntegration SAQ Roughly Redirect or hosted payment page A Shortest Hosted fields on your own page A-EP Moderate, and your page\u0026rsquo;s scripts are in scope Card data handled by your systems D Longest by a wide margin Your acquirer decides which questionnaire applies. It is worth asking before you choose an integration pattern rather than after.\nOne nuance in the middle row catches teams out. Hosted fields keep card data out of your DOM, but every script on the page containing them can still alter that page — swap the iframe, overlay a fake field, or read what the customer types before the real field receives it. That is the mechanism behind digital skimming attacks, and it is why v4 added explicit expectations around managing and monitoring the scripts on payment pages. If your checkout loads a tag manager, a chat widget, an A/B testing snippet, and three analytics libraries, you have four vendors who can modify your payment page, and the compliance question is whether you can say what each of them is doing today.\nRequirement 3 — protecting stored data The parts a developer implements:\nSensitive Authentication Data is not retained after authorisation. Absolute, as above. PAN is masked when displayed — a maximum of the first six and last four digits, and only where a role has a documented need for more than the last four. Stored PAN is rendered unreadable by one of: a one-way hash with a salt, truncation, a token, or strong cryptography with proper key management. That salt is not optional, and the reason is arithmetic. The search space for a card number is small: a known BIN, a known length, and a Luhn-valid final digit leave only the account identifier free — often seven or eight digits, which is trivially brute-forceable against an unsalted hash. Hashing a PAN without a salt produces something that looks protected and is not. The structure guide works through why so few digits are actually unknown.\nRequirement 6 — secure development Requirement 6 is where PCI DSS reads most like a normal engineering standard: secure coding practices and training, code review or automated security testing before release, protection against known classes of vulnerability — the OWASP Top Ten is the usual reference — change management with separated environments, and keeping dependencies patched.\nIt also contains the requirement this site exists to help with.\nTest environments — why synthetic data is required Production data may not be used for testing or development. This is not a recommendation; it is a requirement — Requirement 6.5.5 in version 4, previously 6.4.3 in version 3.2.1 — and it exists because test environments are consistently less protected than production: looser access control, shared credentials, data copied to laptops, screenshots in tickets.\nThat leaves two options. Mask or remove the card data before it moves, which is work you must repeat correctly on every refresh forever. Or generate synthetic data that never contained anything real, which is repeatable and cannot leak what it never held.\nWhat a realistic test data set needs:\nSynthetic PANs across every network you accept — the generator for individual cases, the bulk generator for fixture files and load tests. Gateway sandbox cards for anything requiring a processor response — approvals, declines, 3-D Secure. The test card reference collects them, and the Stripe set is documented in full. Synthetic names and addresses, because a production dump is not only about card numbers — the identity generator covers the rest of the row. Deliberately invalid data for negative paths: broken check digits, wrong lengths, expired dates. The validator is a quick way to confirm a fixture fails the way you intended. The single most common violation in this whole area is copying a production database dump into staging. It is done for good reasons — realistic data finds real bugs — and it moves the most sensitive data you hold into the least protected environment you run.\nThis also intersects with data protection law. A production dump in staging is still personal data under the GDPR, with the same lawful basis requirements and the same breach obligations, sitting in an environment that is usually easier to compromise. Two regimes, one bad habit.\nWhat developers most often get wrong Logging the entire request body, payment fields included. Sending form data to an error tracker as exception context. Copying a production dump into staging. Keeping the CVV in session \u0026ldquo;just until the retry\u0026rdquo;. Using a real card in a test fixture — and committing it. Hashing a PAN without a salt. Leaving input recording on in a session replay tool. Masking the PAN in the interface while storing it in full in the database. Every one of these is an accident of convenience rather than a decision, which is why they survive code review: nothing in the diff looks like a compliance decision.\nA practical developer checklist No card data in application logs — verified by grepping logs, not by reading code Payment fields scrubbed in the error tracker SDK No card data in analytics or product telemetry Session replay masks all inputs by default No card data in localStorage, sessionStorage, or cookies Card data never appears in a URL or query string CVV never persisted anywhere, including caches and session stores Stored PAN encrypted, tokenised, truncated, or salted-hashed Display masking applied at the API boundary, not only in the UI Test and staging environments contain synthetic data only Test fixtures generated, never derived from production Pre-commit secret scanning covers card-shaped strings Database backups encrypted, with access logged Crash dumps disabled on services that handle payments Dependency scanning running in CI Integration pattern and its SAQ confirmed with your acquirer The test data management guide covers how to keep such a fixture set healthy over time, and the payment form checklist covers what to assert once you have one.\nWhere to get authoritative answers The PCI Security Standards Council — the standard itself, plus the SAQs and the Prioritized Approach The document library for the current version and its summary of changes The Qualified Security Assessor directory when you need a formal opinion Your payment provider\u0026rsquo;s compliance documentation, which will tell you which SAQ its integrations map to Your acquirer, who ultimately determines your validation requirements Again: this page is technical background, not compliance advice. Requirement numbers change between versions, interpretations vary by acquirer, and only a QSA can tell you where your specific systems stand.\nThe requirement numbers and version details above were last checked against provider documentation on 4 August 2026. Providers do change what they publish — the official link beside each claim is authoritative. Frequently Asked Questions Can I store credit card numbers? Yes, if you have a documented business need and you render the number unreadable wherever it is stored — through strong encryption with proper key management, a one-way hash with a salt, truncation, or a token. The better question is whether you should. Every system holding a PAN is inside your compliance scope, and the cheapest PAN to protect is the one your servers never receive. Can I store the CVV? No. The security code is Sensitive Authentication Data, and it may not be retained after authorisation under any circumstances — not encrypted, not hashed, not temporarily, not in a log. The prohibition is absolute, and it is the rule most often broken by accident rather than decision, because CVVs reach logs and error trackers without anyone choosing to store them. Do I need to be PCI compliant if I use Stripe? Yes, but the obligation is much smaller. Using a hosted payment page or hosted fields means card data never touches your servers, which reduces you to the shortest self-assessment questionnaire rather than removing you from scope. What remains is real: your integration, your redirects, and the scripts running on your payment page are all still yours to secure. Can I use real card data in my test environment? No. PCI DSS states that live PANs are not used in pre-production environments — Requirement 6.5.5 in version 4, previously 6.4.3 in version 3.2.1. The reasoning is practical: test systems have looser access control, shared credentials, data copied to laptops, and screenshots in tickets. Synthetic test data is the prescribed alternative. How much of a card number can I display? At most the first six and the last four digits, and that is a ceiling rather than a target. Most interfaces show only the last four, which is enough for a customer to recognise which card they used. Anything beyond first-six-and-last-four needs a documented business justification for that specific role. What is a SAQ? A Self-Assessment Questionnaire — the form a merchant completes to attest to its compliance, with a different version for each integration pattern. A redirect or hosted payment page maps to SAQ A, the shortest; hosted fields on your own page map to SAQ A-EP; handling card data directly maps to SAQ D, which is by far the longest. Your acquirer decides which applies to you. ","permalink":"https://ccgenerator.org/guides/pci-dss-for-developers/","summary":"PCI DSS is written for organisations, not for engineers, which is why most developers meet it as a list of things someone in compliance says they cannot do. This page covers the parts that actually change how you write code: which data you may store, which you may never store, what \u0026ldquo;reducing scope\u0026rdquo; means in practice, and why your test environment is not allowed to contain real card numbers.\nThis is general technical information, not compliance advice.","title":"PCI DSS for Developers: What You Can Store"},{"content":"Stripe publishes a set of card numbers that only exist inside its test environment. Each one triggers a specific, documented outcome — an approval, a particular decline, a 3-D Secure challenge — so you can exercise every branch of your payment code without a bank being involved.\nThey are not generic dummy numbers. They are recognised by Stripe and by nothing else, which is exactly what makes them useful and exactly why numbers from anywhere else, including our generator, do not work with them.\nThis page is the deep version. For the same numbers alongside PayPal, Braintree, Adyen, Square, and Authorize.Net, the test card numbers reference is the cross-gateway summary, and the PayPal sandbox guide is the equivalent deep dive for PayPal and Braintree — which select outcomes by cardholder name and transaction amount rather than by card number.\nTest mode and live mode Stripe environments are selected by the API key, not by the request:\nTest mode Live mode Secret key sk_test_… sk_live_… Publishable key pk_test_… pk_live_… Test cards Recognised Rejected Real cards Rejected Charged Money moves No Yes The Dashboard has a toggle that switches which set of data you are looking at; the API has no such toggle, only the key. This single fact explains most confused bug reports in this area — \u0026ldquo;the test card stopped working\u0026rdquo; is almost always a live key in the environment, and \u0026ldquo;my real card was declined in staging\u0026rdquo; is the same mistake in the other direction.\nOn key handling: a test key is lower-risk than a live key, not zero-risk. It can read your test data, create objects, and in some integrations reveal your business structure. Keep both out of the repository, out of client-side bundles, and out of CI logs. Stripe\u0026rsquo;s API keys documentation covers rotation and restricted keys, which are worth using for anything running unattended.\nSuccess cards by brand Any future expiry and any CVC of the correct length work with all of these. The number alone determines the outcome.\nCard number Brand CVC PaymentMethod token 4242 4242 4242 4242 Visa 3 digits pm_card_visa 4000 0566 5566 5556 Visa (debit) 3 digits pm_card_visa_debit 5555 5555 5555 4444 Mastercard 3 digits pm_card_mastercard 2223 0031 2200 3222 Mastercard (2-series) 3 digits — 5200 8282 8282 8210 Mastercard (debit) 3 digits pm_card_mastercard_debit 5105 1051 0510 5100 Mastercard (prepaid) 3 digits pm_card_mastercard_prepaid 3782 822463 10005 American Express 4 digits pm_card_amex 6011 1111 1111 1117 Discover 3 digits pm_card_discover 3056 9300 0902 0004 Diners Club 3 digits pm_card_diners 3566 0020 2036 0505 JCB 3 digits pm_card_jcb 6200 0000 0000 0005 UnionPay 3 digits pm_card_unionpay The 2-series Mastercard is the one to keep in your fixtures deliberately. Brand detection written before 2017 classifies it as unknown, and it is the single most common card-type bug still shipping — the BIN and IIN guide explains why that range exists.\nThe right-hand column matters for server-side tests. Raw card numbers in your backend code put that code in PCI scope; the pm_card_* tokens produce the same results without a PAN ever touching your server, so prefer them anywhere you are not specifically testing the input form.\nDecline cards This is the section worth copying into a fixture file. Each number produces a real error object, not a simulated one.\nCard number Error code Decline code 4000 0000 0000 0002 card_declined generic_decline 4000 0000 0000 9995 card_declined insufficient_funds 4000 0000 0000 9987 card_declined lost_card 4000 0000 0000 9979 card_declined stolen_card 4000 0000 0000 6975 card_declined card_velocity_exceeded 4000 0000 0000 0069 expired_card — 4000 0000 0000 0127 incorrect_cvc — 4000 0000 0000 0119 processing_error — 4242 4242 4242 4241 incorrect_number — That last number deliberately fails the Luhn checksum. It exists to test the branch where your own validation should have rejected the input before Stripe ever saw it — if it reaches the API, your client-side check has a gap.\nNever show a decline code to the customer lost_card and stolen_card are the reason this deserves its own heading.\nThose codes are information from the issuer to the merchant. Displayed to the person at the checkout, they are either wrong — plenty of legitimate cards decline for reasons the code describes badly — or actively harmful, because telling someone holding a card that it is reported stolen is a safety problem, and telling a fraudster the same thing is a free diagnostic.\nMap every decline to one of two customer-facing messages: try a different payment method, or contact your bank. Log the real code for yourself. Stripe\u0026rsquo;s decline codes reference documents which are retriable and which are not — that distinction belongs in your retry logic, not in your copy.\n3-D Secure test cards Card number Behaviour 4000 0000 0000 3220 Always requires a 3DS2 challenge, then succeeds 4000 0027 6000 3184 Requires authentication on all transactions 4000 0084 0000 1629 Requires authentication, then declines afterwards 4000 0025 0000 3155 Requires authentication unless set up for off-session use 4000 0000 0000 3055 Supports authentication but does not require it 4242 4242 4242 4242 Supports 3DS but is not enrolled — no challenge appears 3782 822463 10005 No 3DS support at all 4000 0084 0000 1629 is the important one. Code that treats a completed challenge as a completed payment breaks here, and that assumption is common enough that it is worth an explicit test. Authentication proves who the cardholder is; it does not commit the issuer to approving anything. The 3-D Secure testing guide covers the flow in full.\nTesting individual fields Expiry — any future month and year. To exercise your own expiry validation, a past date is rejected client-side before Stripe is involved; to see the API\u0026rsquo;s expired_card error, use 4000 0000 0000 0069 with a future date. CVC — any three digits, four on American Express. Omitting it entirely makes Stripe skip the check, which means a CVC test that passes with no CVC sent is not testing anything. Postal code and AVS — any value succeeds by default; Stripe documents specific cards for triggering address and postal-code check failures. As with CVC, omitted values are skipped rather than failed. Cardholder name — free text on Stripe, unlike PayPal\u0026rsquo;s sandbox where the name selects the outcome. Beyond cards Card testing is not the whole surface. Stripe documents separate test values for SEPA Direct Debit, iDEAL, Bancontact, ACH direct debit, and the rest of its payment method catalogue — each with its own success and failure identifiers. If your checkout offers anything other than cards, those paths need the same treatment; the testing documentation has a method selector at the top of the page for exactly this.\nTesting webhooks Webhooks are where integrations most often break in production while passing every test, because the local development loop skips them entirely.\nThe Stripe CLI closes that gap. It forwards real test-mode events to a local port and prints a signing secret scoped to that session:\nstripe listen --forward-to localhost:3000/webhook # → Ready! Your webhook signing secret is whsec_... (^C to quit) # In another terminal, fire a specific event on demand: stripe trigger payment_intent.succeeded Verify the signature on every request. The raw request body is required — parsed JSON will not verify, which is the most common cause of a handler that works with stripe trigger and fails against real deliveries:\nimport Stripe from \u0026#39;stripe\u0026#39;; import express from \u0026#39;express\u0026#39;; const stripe = new Stripe(process.env.STRIPE_SECRET_KEY); const app = express(); app.post( \u0026#39;/webhook\u0026#39;, express.raw({ type: \u0026#39;application/json\u0026#39; }), // raw body, not express.json() (req, res) =\u0026gt; { let event; try { event = stripe.webhooks.constructEvent( req.body, req.headers[\u0026#39;stripe-signature\u0026#39;], process.env.STRIPE_WEBHOOK_SECRET ); } catch (err) { return res.status(400).send(`Webhook signature failed: ${err.message}`); } // Stripe retries on non-2xx and can deliver the same event twice. // Record event.id and return early if you have already handled it. if (alreadyHandled(event.id)) return res.json({ received: true }); if (event.type === \u0026#39;payment_intent.succeeded\u0026#39;) { fulfil(event.data.object); } markHandled(event.id); res.json({ received: true }); } ); Two properties to test explicitly: a tampered signature must be rejected, and the same event delivered twice must fulfil the order once. Stripe\u0026rsquo;s webhook documentation sets out the delivery and retry guarantees you are coding against.\nTest clocks for subscriptions Subscription bugs live in the future — a renewal that fails, a trial that converts, a dunning sequence that never fires. Waiting a month to find out is not a test strategy.\nTest clocks let you attach a customer to a simulated clock and advance it. A year of billing cycles runs in a few seconds, with real invoices, real webhook events, and real failure behaviour. Combine one with 4000 0000 0000 9995 on the second renewal and you can watch your dunning flow work before a customer ever meets it. It is the least-used feature in this list and the one that finds the most bugs.\nCommon mistakes Test card against a live key. The card is fine; the key is wrong. Check which key the environment actually loaded before debugging anything else. Sending a generated number to Stripe. It passes your form and dies at the API, because no issuer stands behind it — why test cards fail on real systems covers the mechanism. Only testing the happy path. The decline table exists so that your error handling is exercised. A checkout tested only with 4242… has never run its own failure branch. Not testing webhooks. Your fulfilment logic almost certainly lives there. Skipping it means the least-tested code owns the most important step. Trusting the client-side confirmation. Fulfil on payment_intent.succeeded from a verified webhook, not on the browser reporting success — the browser can close, lie, or be replayed. Never testing 3DS. Authentication is mandatory in the EEA and increasingly common elsewhere. An untested challenge flow is an untested checkout. For the input layer that sits in front of all of this — field lengths, brand detection, masking, and bulk fixtures from the bulk generator — the payment form testing checklist covers what to assert before a request ever reaches Stripe.\nThe card numbers, error codes and CLI commands above were last checked against provider documentation on 4 August 2026. Providers do change what they publish — the official link beside each claim is authoritative. Frequently Asked Questions What is Stripe\u0026#39;s basic test card number? 4242 4242 4242 4242, a Visa that succeeds. Pair it with any future expiry date and any three-digit CVC — the number alone decides the outcome, so there is no combination to memorise. It is the most widely recognised test number in payments, and it works only inside Stripe\u0026rsquo;s test mode. Do Stripe test cards work in live mode? No, and that is deliberate. Test numbers are recognised only by test-mode API keys; send one to a live key and Stripe rejects it outright. The reverse is also true — a real card used against a test key does nothing. The environment is selected by the key, not by the card, which is why a test card \u0026lsquo;failing\u0026rsquo; in production almost always means the wrong key is loaded. How do I test a declined payment on Stripe? Use the card documented for the decline you want. 4000 0000 0000 0002 returns a generic decline, 4000 0000 0000 9995 returns insufficient funds, 4000 0000 0000 0069 returns an expired card, and 4000 0000 0000 0127 returns an incorrect CVC. Each one produces the real error object your code will see in production, which is the point — testing only the success path leaves your error handling unexercised. Which Stripe test card triggers 3-D Secure? 4000 0000 0000 3220 always requires a 3DS2 challenge and succeeds once authenticated. For the case that breaks naive code, use 4000 0084 0000 1629: it requires authentication and then declines anyway, proving that a completed challenge is not an approved payment. Can I use generated card numbers with Stripe? Only for your own form. A generated number passes Luhn and brand detection in the browser, so it exercises your input handling correctly, but Stripe\u0026rsquo;s API rejects it the moment it arrives because it is not in the test-card set and there is no issuer behind it. Use generated numbers to test your form and Stripe\u0026rsquo;s numbers to test Stripe. How do I test Stripe webhooks locally? With the Stripe CLI. Run stripe listen \u0026ndash;forward-to localhost:3000/webhook and it forwards live test-mode events to your machine, printing a signing secret to use for signature verification. stripe trigger payment_intent.succeeded fires a specific event on demand. Verify the signature on every request and make your handler idempotent — Stripe retries, so the same event will arrive twice. ","permalink":"https://ccgenerator.org/guides/stripe-test-card-numbers/","summary":"Stripe publishes a set of card numbers that only exist inside its test environment. Each one triggers a specific, documented outcome — an approval, a particular decline, a 3-D Secure challenge — so you can exercise every branch of your payment code without a bank being involved.\nThey are not generic dummy numbers. They are recognised by Stripe and by nothing else, which is exactly what makes them useful and exactly why numbers from anywhere else, including our generator, do not work with them.","title":"Stripe Test Card Numbers: Complete Reference"},{"content":"Test data is where compliance, reproducibility and test reliability meet. Copy production data and you have moved personal data into a less protected environment. Generate it randomly at run time and your tests become non-reproducible. This page covers the middle path.\nWhy production data in test is the wrong default It is the easiest option, which is why it is the common one. Two separate regimes make it a bad idea, and they apply independently.\nPCI DSS states that live account numbers are not used for testing or development — Requirement 6.5.5 in version 4, previously 6.4.3. There is no threshold and no exception for \u0026ldquo;just a few rows\u0026rdquo;; the PCI guide covers what else follows from having card data in a system.\nData protection law applies to everything else in that dump. A production copy in staging is still personal data under the GDPR, with the same lawful basis, the same retention limits, and the same breach notification duties — in an environment that typically has looser access control, shared credentials, copies on laptops, and screenshots in tickets.\nThat last sentence is the practical argument. The regulatory position and the engineering position agree here: test environments are less protected than production by design, because protecting them properly would make them useless for testing. Putting your most sensitive data in your least defended environment is the trade nobody would make deliberately.\nFour approaches, compared Approach Compliance Reproducibility Realism Effort Copy production Bad Good Best Low Mask or anonymise production Depends entirely on quality Good Good High Generate synthetic Good Good, with a seed Needs design Medium Hand-written fixtures Good Best Poor coverage High to maintain Most teams end up with the third, supported by a little of the fourth for the cases that matter most.\nThe masking trap Masking looks like the best of both worlds and frequently is not, because the failure mode is silent. Replacing names and email addresses leaves the rest of the row intact, and rare combinations identify people even when every obvious identifier is gone — a postcode, a date of birth and a gender is enough to single out individuals in a surprisingly large share of cases. The UK ICO\u0026rsquo;s guidance on anonymisation is worth reading before committing to this route.\nDone properly, masking is a real engineering project with ongoing maintenance as the schema changes. Done casually, it produces a dataset that is legally personal data while everyone involved believes it is not. Synthetic data has no re-identification risk at all, because there is nobody to re-identify.\nDesigning synthetic data that finds bugs Synthetic data that does not resemble the real world will not find real bugs. Six things to design in deliberately:\nDistribution. The mix of card networks, countries and order sizes should approximate your actual traffic. A suite that is half American Express when your traffic is mostly Visa spends its effort on a path your users rarely take.\nExtremes. The shortest and longest name you will accept, a 12-digit and a 19-digit card, a single-word name, an order with one item and one with two hundred.\nInternational cases. Accented characters, non-Latin scripts, postcodes that are not five digits, countries with no state field. The identity generator produces these deliberately.\nNegative cases. A broken checksum, an expired date, a security code of the wrong length. Validation you have never watched fail is validation you have not tested.\nBoundaries. A card expiring in the current month, the minimum and maximum order amount, the exact threshold of any rule you have.\nTime. Generate dates relative to now. A fixture pinned to 12/25 becomes an expired-card fixture on a date nobody chose, and the resulting failure looks like a code regression.\nFor card-specific fixtures, the bulk generator handles the distribution and negative-case shares directly, and the payment form checklist lists what each of them is for.\nDeterminism and seeding Random data makes flaky tests, and flaky tests destroy a team\u0026rsquo;s trust in the suite faster than bugs do. The fix is a seeded generator: the same seed produces the same sequence, therefore the same data, therefore the same result.\n// A small seeded PRNG. Same seed in, same sequence out — every run, every machine. function mulberry32(seed) { return function () { seed |= 0; seed = (seed + 0x6d2b79f5) | 0; let t = Math.imul(seed ^ (seed \u0026gt;\u0026gt;\u0026gt; 15), 1 | seed); t = (t + Math.imul(t ^ (t \u0026gt;\u0026gt;\u0026gt; 7), 61 | t)) ^ t; return ((t ^ (t \u0026gt;\u0026gt;\u0026gt; 14)) \u0026gt;\u0026gt;\u0026gt; 0) / 4294967296; }; } // Take the seed from the environment so CI can pin it and a developer can // reproduce a failure with the value printed in the log. const seed = Number(process.env.TEST_SEED ?? 20260804); const random = mulberry32(seed); console.log(`test data seed: ${seed}`); // print it on every run, especially failures const pick = (list) =\u0026gt; list[Math.floor(random() * list.length)]; Three rules that make seeding actually pay off:\nPrint the seed on every run. A failure you cannot reproduce is a failure you will close as flaky. Pin the seed in CI, and run a scheduled job with fresh seeds to catch what the pinned one never generates. Record the settings, not just the seed. A seed fixes the sequence of random numbers, not the code consuming them — change the generator options and the same seed yields a different set. That is correct behaviour and it surprises people. Fixtures and factories Both, for different jobs:\nFixtures are fixed files, committed to the repository and reviewed like code. Their strength is that the input is exactly what it was last time, which is what a regression test needs. Their weakness is maintenance: a schema change means editing files.\nFactories build objects at run time from sensible defaults, letting a test override the one field it cares about. Their strength is expressiveness — buildOrder({ total: 0 }) says what the test is about. Their weakness is that the other twenty fields are decided somewhere else, so a factory change can alter tests that never mentioned the field.\nThe rule of thumb: fixtures for the scenarios you must never break, factories for everything else. The mistake is picking one and forcing it everywhere.\nData lifecycle Where it lives. Small fixture sets belong in the repository, next to the tests. Large ones belong in an artefact store with a version, referenced by the test setup. When it is refreshed. Set a cadence, because a fixture set slowly diverges from the schema and from reality until one day it tests nothing. Cleanup. Every test run should leave the database in a known state, whether by transaction rollback, truncation, or a fresh schema per run. No leakage between environments. Staging data should not appear in development and neither should reach production. Never move test data into production. Synthetic records that arrive in a production database get treated as real by reports, exports, support tooling and marketing lists, and there is rarely a reliable way to tell them apart afterwards. The traffic is one way. Test data in CI Isolate per build. A database or schema per run, so parallel jobs cannot collide on the same rows. Version the seed script with the code it seeds. A seed script that drifts from the schema is a broken build waiting for a slow week. Namespace parallel runs. Where full isolation is too expensive, prefix generated identifiers per worker so two runs never claim the same record. Watch the seeding time. A setup step that takes two minutes on a suite that runs a hundred times a day is three hours of machine time daily, and it is the first thing to profile when CI feels slow. A practical setup For a checkout suite, concretely:\nCards. A committed fixture file of a few hundred generated numbers, covering every network you accept, both American Express and 2-series Mastercard, all five lengths, and a deliberate share of Luhn-invalid rows for negative tests. Generated once with a recorded seed, with the seed in a comment at the top of the file so it can be rebuilt.\nIdentities. Names and addresses generated per test from a factory, seeded from the same run seed, so international characters and unusual postcodes appear throughout rather than only where someone remembered to add them.\nGateway responses. Your provider\u0026rsquo;s sandbox cards, not generated ones — approvals, declines and 3-D Secure challenges need a real processor response, which the sandbox reference collects. Mock the provider entirely for unit tests and use the sandbox for the end-to-end path.\nStored cards. Provider tokens rather than card numbers, exactly as in production — tokenised flows have their own failure modes and should be exercised the way they actually run.\nNothing in that setup contains a real person\u0026rsquo;s data, every part of it is reproducible from a recorded seed, and none of it needs a compliance conversation before a new developer can run the suite on their laptop. That combination is the whole point.\nThe last property is the one that quietly decides whether any of this survives contact with a deadline. A test data strategy that requires an approval, a VPN, or a request to another team will be routed around the first time someone is in a hurry, and what they route around it with is a copy of production. Making the compliant path the fastest path is not a nicety; it is the only version of this that holds up over a year.\nFrequently Asked Questions Can I copy production data into my test environment? Not if it contains card data — PCI DSS states that live account numbers are not used in pre-production environments. Beyond cards, a production dump is still personal data under the GDPR wherever it sits, carrying the same lawful basis, retention and breach obligations in an environment that is usually less protected. The copy is the risk, not the use you make of it. Is masked production data safe to use? Only if the masking is good, and good is harder than it looks. Replacing names while leaving postcode, date of birth and gender intact can still identify individuals, because rare combinations are unique even when every obvious identifier is gone. Masking is a real engineering project with a real failure mode; synthetic data has no re-identification risk because there is nobody to re-identify. How do I make generated test data reproducible? Seed the random number generator and record the seed. Same seed, same sequence, same data, same test result. Print the seed in your test output so a failure can be reproduced locally, and remember that a seed only identifies a data set alongside the settings that produced it — change the generator or its options and the same seed yields something different. What is the difference between a fixture and a factory? A fixture is a fixed file, committed and reviewed, which makes it right for regression tests where the exact input matters. A factory builds data at run time from defaults you override per test, which makes it right for unit tests where you care about one field and not the other twenty. Most suites need both, and the mistake is picking one and forcing it everywhere. Should test data ever be moved into production? No, and it is worth having a rule about it rather than a habit. Synthetic records that reach a production database get treated as real by everything downstream — reports, exports, support tooling, marketing lists — and there is rarely a reliable way to distinguish them afterwards. The traffic goes one way only. ","permalink":"https://ccgenerator.org/guides/test-data-management-qa/","summary":"Test data is where compliance, reproducibility and test reliability meet. Copy production data and you have moved personal data into a less protected environment. Generate it randomly at run time and your tests become non-reproducible. This page covers the middle path.\nWhy production data in test is the wrong default It is the easiest option, which is why it is the common one. Two separate regimes make it a bad idea, and they apply independently.","title":"Test Data Management for QA Teams"},{"content":"3-D Secure moves the fraud liability from the merchant to the issuer and, since PSD2, is mandatory for most consumer card payments in the European Economic Area and the UK. It is also the part of a checkout most likely to be under-tested, because it involves a redirect or an iframe, an issuer-controlled screen, and a set of outcomes that a happy-path test never reaches.\nWhat 3-D Secure actually does It asks the issuing bank to confirm that the person paying is the cardholder, through a step the bank controls rather than one you build.\nThe commercial reason to adopt it is the liability shift. On an authenticated transaction, a later fraud-related chargeback is the issuer\u0026rsquo;s loss rather than yours. That is the trade every merchant is actually making: some friction at checkout in exchange for not carrying fraud losses.\nFour parties are involved. Your server or gateway acts as the 3DS Server, sending the authentication request to a Directory Server run by the card network, which routes it to the Access Control Server operated by the issuer. The ACS decides what happens next, and your code\u0026rsquo;s job is to handle every answer it can give.\n3DS1 redirected everyone to an issuer page asking for a static password. It worked and it cost conversions. 3DS2 — EMV 3-D Secure — sends around 150 data points about the device, session and transaction so the issuer can make a risk decision without interrupting anyone.\nFrictionless and challenge Two outcomes, and you must test both.\nFrictionless. The issuer judges the risk acceptable from the data alone and authenticates without showing the customer anything. This is the majority of 3DS2 traffic in production, which is exactly why it is a trap: a team that tests 3DS by making a payment and seeing it succeed has usually tested only this path.\nChallenge. The issuer wants more: a one-time code, an approval in the banking app, a biometric prompt. The customer leaves your interface for a screen you do not control, and comes back — or does not.\nEverything difficult about 3DS lives in the second flow. It is where the layout breaks on mobile, where the customer abandons, where the back button produces an undefined state, and where the webhook race condition below appears.\nPSD2 and SCA Strong Customer Authentication requires two factors from different categories: something the customer knows, something they have, something they are. It applies in the EEA and the UK when both the cardholder\u0026rsquo;s issuer and the merchant\u0026rsquo;s acquirer are in the region — the European Banking Authority publishes the regulatory technical standards behind it.\nThe exemptions are what make SCA workable, and each is a scenario worth testing:\nExemption Condition Low value Under €30, subject to cumulative counters — five consecutive or €100 total since the last authentication Transaction Risk Analysis Available when the acquirer\u0026rsquo;s fraud rate is below defined thresholds, with the ceiling depending on the rate Trusted beneficiary The cardholder has added the merchant to a list held by their issuer Recurring, fixed amount Same amount, same merchant — authentication on the first payment only Merchant-initiated transaction Out of scope entirely, given prior agreement with the cardholder Corporate cards Payments made through secure corporate processes One property matters more than any individual row: an exemption is a request, not a decision. You flag the transaction as exempt, and the issuer may honour it or may authenticate anyway. Code that assumes an exemption request means no authentication will break the first time an issuer disagrees, which is a routine occurrence rather than an exceptional one.\nSoft declines When an issuer refuses a payment specifically because it was not authenticated, that is a soft decline. It commonly follows an exemption request the issuer chose not to honour.\nThe correct response is to retry the same payment with full authentication. The customer sees a challenge and the payment completes. What a surprising number of checkouts do instead is treat the response as an ordinary decline, show \u0026ldquo;your card was declined\u0026rdquo;, and lose a sale the issuer was willing to approve.\nThis is the single most valuable path on this page to test deliberately, because it is invisible in every happy-path test and it costs money on every occurrence. Not every decline means the card cannot pay, and distinguishing the categories is what separates a checkout that recovers from one that does not.\nTesting 3DS by gateway Every provider triggers authentication with its own cards, and the mechanics differ enough that experience with one does not transfer.\nStripe publishes a full matrix, and these are reproduced from its authentication flow documentation:\nCard number Behaviour 4000 0000 0000 3220 Always requires a 3DS2 challenge, then succeeds 4000 0027 6000 3184 Requires authentication on every transaction 4000 0084 0000 1629 Requires authentication, then declines afterwards 4000 0025 0000 3155 Requires authentication unless set up for off-session use 4000 0000 0000 3055 Supports authentication but does not require it 4242 4242 4242 4242 Supports 3DS but is not enrolled — no challenge appears 4000 0084 0000 1629 is the one to keep. It authenticates successfully and then declines, which breaks any code treating a completed challenge as a completed payment. The full Stripe reference has the rest of its set.\nFor the other providers, use their own documentation rather than a number copied from anywhere else — including here. Their 3DS card sets could not be verified against the providers\u0026rsquo; published pages while writing this, so reproducing them would be guesswork:\nAdyen — testing documentation, which pins a specific expiry and security code its examples expect Braintree — 3-D Secure overview, with its own sandbox conventions distinct from PayPal\u0026rsquo;s; the PayPal sandbox guide covers how the two differ Checkout.com — 3-D Secure documentation Mollie — testing documentation What does not work anywhere is a generated number. The generator produces structurally valid cards with no issuer behind them, and authentication requires a real issuer directory to route to — the request has nowhere to go. The test card reference collects the published sets across processors.\nThe full test matrix Success paths\nFrictionless authentication succeeds Challenge is presented and the customer answers correctly An exemption is requested and honoured A previously authenticated card is charged off-session without a new challenge Failure paths\nThe customer cancels the challenge The customer enters an incorrect code The challenge times out The ACS is unreachable — the issuer\u0026rsquo;s system is down An exemption is requested and refused, producing a soft decline that must be retried with authentication The card does not support 3DS at all Authentication succeeds and the authorisation is declined anyway Interface and infrastructure\nThe challenge iframe renders correctly on a mobile viewport The cart survives a redirect and a return The browser back button during a challenge leaves a defined state Closing the tab mid-challenge does not orphan the order The webhook arriving before the customer\u0026rsquo;s browser returns is handled Double capture is prevented by an idempotency key Sixteen cases, of which most teams test two. The mobile viewport item is worth singling out: the challenge is rendered by the issuer inside an iframe you do not control, and a fixed height that works on a desktop can clip the submit button on a phone — where most of your customers are.\nThe webhook race condition This one deserves its own section because it produces bug reports that read as impossible.\nThe customer completes the challenge. The issuer notifies your gateway, which fires a webhook to your server. Meanwhile the customer\u0026rsquo;s browser is being redirected back to your success page. These two things race, and the webhook usually wins.\nTwo failure modes follow. If your success page reads order status from your own database and the webhook has not been processed yet, the customer sees \u0026ldquo;pending\u0026rdquo; or an error for a payment that has actually succeeded. If instead your success page trusts a parameter the browser brought back, you have a security hole — that parameter is attacker-controlled.\nThe correct pattern:\nThe webhook is the source of truth for fulfilment. Nothing ships because a browser said so. The success page polls or subscribes for the order\u0026rsquo;s status rather than asserting it. Show a brief confirming state — a spinner and \u0026ldquo;confirming your payment\u0026rdquo; — instead of a premature success or failure. Make the webhook handler idempotent, because the same event will arrive more than once. Test it by deliberately delaying your webhook processing and confirming the success page degrades into the confirming state rather than into an error. Then test the opposite ordering, where the browser returns first and the webhook is slow, since both orderings occur in production and only one of them is the one you happened to observe while developing.\nCommon mistakes Testing only the frictionless flow, because it is the one that happens by default. Never testing the soft decline retry, and losing recoverable sales silently. Not testing the challenge on a mobile viewport. Trusting a client-side result rather than the webhook. Ignoring the race condition and shipping a success page that lies in either direction. Requesting no exemptions at all, adding friction — and losing conversion — for nothing. Assuming a requested exemption will be granted. Flagging merchant-initiated transactions incorrectly, so recurring charges are challenged when nobody is there to answer. Measuring the impact 3DS affects conversion, and a challenge always costs some abandonment. The numbers worth tracking:\nChallenge rate — what share of authentications interrupt the customer Challenge completion rate — how many who see one get through it Post-3DS authorisation rate — authentication is not approval Exemption acceptance rate — how often issuers honour your requests The tension is straightforward: fewer challenges means better conversion and more chargeback exposure, and the balance depends on your fraud rate and your margin. What you should not do is guess. Measure the four rates above, change one thing, and watch them — the payment form checklist covers the layers below this one, which need to be solid before any of these numbers mean anything.\nThe Stripe card numbers and gateway references above were last checked against provider documentation on 4 August 2026. Providers do change what they publish — the official link beside each claim is authoritative. Frequently Asked Questions What is 3-D Secure? An authentication step run by the card issuer during an online payment, to establish that the person paying is the cardholder. Its commercial point is the liability shift: when a payment is authenticated successfully, responsibility for a fraudulent-transaction chargeback moves from the merchant to the issuer. That shift, rather than the security itself, is why most merchants adopt it. What is the difference between 3DS1 and 3DS2? 3DS1 redirected every customer to an issuer-hosted page and asked for a static password, which was slow and cost conversions. 3DS2 sends around 150 data points about the device, the transaction and the customer\u0026rsquo;s history, letting the issuer approve low-risk payments without showing anything at all. Most 3DS2 authentications are now invisible to the customer. Is 3-D Secure mandatory? In the European Economic Area and the UK, strong customer authentication is required for most consumer card payments where both the cardholder\u0026rsquo;s bank and the merchant\u0026rsquo;s acquirer are in the region, and 3DS is how card payments satisfy it. Elsewhere it is optional, and merchants weigh the liability shift against the conversion cost of a challenge. What is a frictionless flow? An authentication the customer never sees. The 3DS2 data is sent to the issuer, the issuer judges the risk low enough, and the payment is authenticated with no challenge screen. It is the common case in production, which is exactly why testing only the frictionless path leaves the challenge flow unexercised. What is a soft decline? An issuer refusing a payment specifically because it was not authenticated, rather than because the account cannot pay. It typically follows an exemption request the issuer declined to honour. The correct response is to retry the same payment with authentication, not to show the customer a failure — and a checkout that treats a soft decline as a hard one loses a sale it had already won. How do I test 3-D Secure? With your gateway\u0026rsquo;s own 3DS test cards, which trigger frictionless, challenge, failed-authentication and error paths deliberately. Generated card numbers cannot produce any of it, because authentication involves a real issuer directory. Test the challenge on a mobile viewport as well as a desktop one — the challenge is an issuer-controlled iframe and it is where layout problems hide. ","permalink":"https://ccgenerator.org/guides/3d-secure-testing/","summary":"3-D Secure moves the fraud liability from the merchant to the issuer and, since PSD2, is mandatory for most consumer card payments in the European Economic Area and the UK. It is also the part of a checkout most likely to be under-tested, because it involves a redirect or an iframe, an issuer-controlled screen, and a set of outcomes that a happy-path test never reaches.\nWhat 3-D Secure actually does It asks the issuing bank to confirm that the person paying is the cardholder, through a step the bank controls rather than one you build.","title":"Testing 3-D Secure and SCA"},{"content":"The Luhn algorithm is a checksum that catches typing mistakes in a number. You double every second digit from the right, subtract 9 from any result above 9, sum everything, and check whether the total is divisible by 10. If it is, the number is well-formed. If it is not, someone mistyped a digit.\nThat is the whole thing. It is not encryption, it does not prove a card exists, and it holds no secret — which is exactly why it works everywhere, and why understanding its limits matters as much as understanding the arithmetic.\nA worked example, step by step Take the number 4539 1488 0343 6467. It is a synthetic Visa-format number of the kind our generator produces: correctly structured, issued by nobody.\nVerifying a complete number When a number already includes its check digit, the last digit takes part in the sum like any other. Doubling starts one position to its left and alternates from there.\nNumber: 4 5 3 9 1 4 8 8 0 3 4 3 6 4 6 7 Position (from right): 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 Double every second digit from the right (even positions): 8 5 6 9 2 4 16 8 0 3 8 3 12 4 12 7 Subtract 9 from any value above 9: 8 5 6 9 2 4 7 8 0 3 8 3 3 4 3 7 Sum: 8+5+6+9+2+4+7+8+0+3+8+3+3+4+3+7 = 80 80 mod 10 = 0 → the number is well-formed Two details in that table are worth pausing on. First, doubling applies to the even positions counted from the right, which means the check digit itself is never doubled. Second, subtracting 9 from a doubled value above 9 gives the same answer as adding its two digits: 16 becomes 7 either way, and 12 becomes 3. Implementations use the subtraction because it is one operation instead of two, not because it is a different rule.\nCalculating the check digit Generating is the same arithmetic run backwards. You have the payload — a network prefix plus an account identifier — and you need the digit that will make the total come out even at ten. Because the check digit occupies position 1, doubling now starts at the rightmost payload digit rather than skipping it.\nUsing the first fifteen digits of the example, 453914880343646:\nPayload: 4 5 3 9 1 4 8 8 0 3 4 3 6 4 6 Position (from right): 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 Double every second digit, starting at the rightmost (odd positions): 8 5 6 9 2 4 16 8 0 3 8 3 12 4 12 Subtract 9 from any value above 9: 8 5 6 9 2 4 7 8 0 3 8 3 3 4 3 Sum: 8+5+6+9+2+4+7+8+0+3+8+3+3+4+3 = 73 Check digit = (10 − (73 mod 10)) mod 10 = (10 − 3) mod 10 = 7 Seven is exactly the digit the original number ends in, and the two sums are consistent with each other: 73 + 7 = 80, the total from the verification above.\nNotice which positions got doubled. In the verification the check digit sat at position 1 and was skipped; here the payload is one digit shorter, so doubling starts immediately at the rightmost digit. The same physical digits end up doubled in both runs — but only because the routine flipped its starting parity to compensate for the missing digit. Feed a payload that already contains a check digit into the generation routine and you get a plausible-looking digit that is simply wrong. This is the most common bug in hand-written Luhn code, and it is invisible if you only ever test with one card length.\nThe outer mod 10 in step four exists for one case: when the sum is already a multiple of ten, 10 − 0 gives 10, which is not a digit. Wrapping it back to 0 handles that cleanly.\nWhy doubling every second digit? A checksum is only as good as the errors it detects, and the design of Luhn is a direct response to the two mistakes humans actually make when copying digits: getting one digit wrong, and swapping two neighbours.\nSingle-digit substitutions are always caught. Changing any digit changes its contribution to the sum. For an undoubled position the contribution moves by the same amount as the digit. For a doubled position it moves by twice that, or by twice minus 9 after the reduction. In neither case can the change be a multiple of 10 unless the digit did not change at all, so the total stops being divisible by ten and the check fails.\nAdjacent transpositions are almost always caught. This is what the doubling buys. If every digit contributed equally, 12 and 21 would produce identical sums and the swap would slip through. Alternate doubling makes each position\u0026rsquo;s weight depend on where it sits, so swapping two neighbours changes the total — except in one case. Swapping 0 and 9 produces the same sum in both orders, because doubling 9 and reducing gives 9, and doubling 0 gives 0. 09 ↔ 90 is the documented blind spot, and it is the only one.\nWhat it cannot catch. Two errors that cancel each other out — one digit up by 3 and another down by 3 in an undoubled position, say — leave the total unchanged. And, critically:\nOne in ten random 16-digit strings passes a Luhn check.\nThat figure follows directly from the design. The check digit has ten possible values and exactly one of them is correct, so a random final digit is right a tenth of the time. It is the mathematical reason Luhn cannot function as a fraud control, and it is worth keeping in mind whenever a site tells you a generated number is \u0026ldquo;valid\u0026rdquo;.\nWhat Luhn validation does not tell you Luhn says Luhn does not say The digits are internally consistent The card exists No single digit was mistyped The card is active Most adjacent transpositions are absent The card has funds The number is well-formed The number belongs to anyone The gap between those columns is where most of the confusion about test card numbers lives. A payment form that accepts a number has confirmed its shape. An issuing bank that approves an authorisation has confirmed an account, a balance, and its own risk rules. Nothing on this site can do the second thing, and the FAQ goes into why in more detail — but the arithmetic above is the reason. Every number our validator marks as passing is passing a format test, and the tool says so.\nWhere Luhn is used besides card numbers Payment cards are the best-known application, not the only one. The algorithm shows up wherever a number is read aloud, typed from a form, or copied from a label:\nIMEI — the 15-digit identifier burned into every GSM handset Canadian Social Insurance Number (SIN) Israeli identity number (Teudat Zehut) South African identity number US National Provider Identifier (NPI), used for healthcare providers National Drug Codes and various product and shipment numbers The pattern is consistent: none of these uses Luhn as a security measure. Each uses it to stop a call-centre operator or a data-entry clerk from silently corrupting a record.\nIt is worth noting what these numbers have in common beyond the checksum. All of them are identifiers that get transcribed by hand at some point in their life — read off a screen, dictated over a phone, copied from a sticker onto a form. Numbers that only ever move between machines do not need Luhn, because machines do not transpose digits. The algorithm is a piece of human-factors engineering that happens to be expressed in arithmetic.\nImplementation Two functions cover everything. luhnValid verifies a complete number; luhnCheckDigit computes the missing final digit for a payload. Note the difference in how double is initialised — that single line is the parity distinction the worked example above illustrates.\n/** * Validate a number against the Luhn checksum. * @param {string} input - digits, optionally with spaces or dashes * @returns {boolean} */ function luhnValid(input) { const digits = String(input).replace(/\\D/g, \u0026#39;\u0026#39;); if (digits.length === 0) return false; let sum = 0; let double = false; for (let i = digits.length - 1; i \u0026gt;= 0; i--) { let d = digits.charCodeAt(i) - 48; if (double) { d *= 2; if (d \u0026gt; 9) d -= 9; } sum += d; double = !double; } return sum % 10 === 0; } /** * Compute the check digit for a payload that does not include one. * @param {string} payload - digits without the final check digit * @returns {number} the digit that completes the number */ function luhnCheckDigit(payload) { const digits = String(payload).replace(/\\D/g, \u0026#39;\u0026#39;); let sum = 0; let double = true; for (let i = digits.length - 1; i \u0026gt;= 0; i--) { let d = digits.charCodeAt(i) - 48; if (double) { d *= 2; if (d \u0026gt; 9) d -= 9; } sum += d; double = !double; } return (10 - (sum % 10)) % 10; } Both iterate from the end of the string and read digits with charCodeAt, which avoids allocating a substring per digit and sidesteps the parseInt trap described below. Ports of these two functions to Python, PHP, Java, C#, Go, and SQL are collected in the code examples guide.\nSeven common implementation mistakes Starting from the wrong end. Luhn works right to left. An implementation that doubles from the left produces correct answers on even-length numbers and wrong ones on odd-length numbers. Tested only against 16-digit Visa and Mastercard numbers, it looks perfect — then fails on every 15-digit American Express card in production. Extracting digits with parseInt. parseInt(str, 10) parses the whole string from the given position onward, not one character. Use Number(str[i]), charCodeAt, or a character-level parse. Not stripping separators. Users type 4539 1488 0343 6467, and paste it with non-breaking spaces and dashes. Strip everything that is not a digit before you start. Treating an empty string as valid. With no digits, sum is 0 and 0 % 10 === 0 is true, so an empty input passes. Check the length first — this bug survives code review remarkably often because the arithmetic is correct. Skipping length validation entirely. 18 passes the Luhn check. So do thousands of other short numbers. Luhn tells you nothing about whether the input is the right size for a card; pair it with the per-network length rules in the length reference. Forgetting the UnionPay exception. Some UnionPay ranges do not satisfy the Luhn checksum at all. Code that hard-rejects a failed check will decline legitimate cards. Using floating-point arithmetic. Parsing a 19-digit number into a JavaScript Number exceeds Number.MAX_SAFE_INTEGER and silently loses precision. Keep card numbers as strings from input to storage — always. Mistakes 1 and 4 are the ones that reach production, because both pass a test suite built from 16-digit examples.\nWhere to run the check in your application Run it client-side for immediate feedback: flagging a typo before submission saves a round trip and is the entire reason the algorithm exists. Then run it again on the server, because anything the browser validates can be bypassed.\nBut be careful how you act on a failure. Warn, do not block. A new BIN range, an unusual length, or a UnionPay card can break your assumptions, and losing a legitimate customer costs far more than one extra authorisation call. Show a message next to the field, keep the submit button live, and let the gateway make the final call.\nKeep the wording human, too. \u0026ldquo;Please check your card number\u0026rdquo; is useful. \u0026ldquo;Luhn validation failed\u0026rdquo; tells the customer nothing they can act on and leaks your implementation into the user interface. If you need worked examples to test the message against, the test card number reference has numbers for every network, and the BIN generator covers prefix-level cases.\nWhere the algorithm came from Hans Peter Luhn, a researcher at IBM, filed for a patent on a \u0026ldquo;computer for verifying numbers\u0026rdquo; in 1954. US Patent 2,950,048 — Computer for Verifying Numbers1 was granted in 1960 and has long since expired, which is why the method is free for anyone to implement — a large part of why it became ubiquitous.\nThe formula was later standardised as ANSI X4.13 and is specified for payment card identifiers in ISO/IEC 7812-1:2017 — Identification cards: Identification of issuers2, the standard that also defines the issuer identification number and the 12-to-19-digit length range covered in the card number structure guide. For the wider history and the formal proof of its error-detection properties, the Wikipedia entry on the Luhn algorithm is a good starting point.\nSeventy years on, an algorithm designed for punched cards and telephone operators still runs in every checkout form on the internet — because the problem it solves, people mistyping digits, has not changed at all.\nFrequently Asked Questions What is the Luhn algorithm? The Luhn algorithm is a checksum formula that detects typing mistakes in an identification number. You double every second digit from the right, subtract 9 from any result above 9, add everything up, and check whether the total is divisible by 10. It was patented by Hans Peter Luhn at IBM in the 1950s and is now used on payment cards, IMEI numbers, and several national identity numbers. Does passing the Luhn check mean a credit card is real? No. Luhn is a formatting check, not a lookup. Roughly one in ten random digit strings of the right length passes it purely by chance, and every number produced by a test-card generator passes it by construction. Only the issuing bank can say whether a number corresponds to an account, and it answers that question through an authorisation request, not through arithmetic. Which cards use the Luhn algorithm? Visa, Mastercard, American Express, Discover, JCB, Diners Club, Maestro, and Troy all place a Luhn check digit in the final position, as specified by ISO/IEC 7812-1. UnionPay is the practical exception: some UnionPay ranges do not satisfy the Luhn checksum, which is why hard-rejecting a failed Luhn check can decline legitimate cards. What errors does the Luhn algorithm not catch? It catches every single-digit substitution and nearly every transposition of two adjacent digits, with one documented exception — swapping 09 for 90 leaves the checksum unchanged. It also misses compensating errors, where two digits change in ways that cancel out, and it cannot detect a number that was never valid to begin with. Is the Luhn algorithm secure? No, and it was never intended to be. The formula is public, it uses no key, and it is trivially reversible: anyone can compute a valid check digit in a few lines of code. It exists to catch human error at the point of entry. Treating it as a fraud control is a category mistake. How do I calculate a Luhn check digit? Double every second digit starting from the rightmost digit of the payload, subtract 9 from any doubled value greater than 9, sum all the values, then take (10 − sum mod 10) mod 10. The final modulo handles the case where the sum is already a multiple of 10, in which case the check digit is 0. ","permalink":"https://ccgenerator.org/guides/luhn-algorithm/","summary":"The Luhn algorithm is a checksum that catches typing mistakes in a number. You double every second digit from the right, subtract 9 from any result above 9, sum everything, and check whether the total is divisible by 10. If it is, the number is well-formed. If it is not, someone mistyped a digit.\nThat is the whole thing. It is not encryption, it does not prove a card exists, and it holds no secret — which is exactly why it works everywhere, and why understanding its limits matters as much as understanding the arithmetic.","title":"The Luhn Algorithm: Card Number Checksums"},{"content":"Every Visa card number begins with 4, carries a Luhn check digit in the final position, and is 13, 16 or 19 digits long — almost always 16. The three-digit CVV2 on the back is computed by the issuer and is not part of the number.\nThat is the format. What makes Visa interesting is the first digit, which Visa owns outright in a way no other network does, and the two lengths that are not 16.\nThis is the reference; if you need numbers to test with, the Visa card generator produces them.\nThe format at a glance Property Value Prefix 4 — the entire range Lengths 13, 16, 19 Check digit Luhn, final position Security code CVV2, 3 digits Code location Signature panel, back of card Grouping 4-4-4-4 at 16 digits Why 4, and why it matters ISO/IEC 7812 divides the first digit — the Major Industry Identifier — into ten categories, and assigns 4 to banking and finance. Visa holds all of it.\nThat sounds like trivia and has a practical consequence. Compare what identifying each network takes:\nNetwork Digits needed Visa 1 American Express 2 (34, 37) Mastercard 2 for the classic range, 4 for the 2-series Discover 2 to 6, across four separate ranges Diners Club 2 to 4, across three Visa is the only major network identifiable from a single character with no ambiguity, no overlap, and no boundary conditions. In progressive brand detection — showing the right logo as someone types — Visa is the case that resolves on keystroke one, while a Mastercard number may need four before you can be certain.\nThe corollary is that the leading 4 tells you the network and nothing else. It does not tell you the issuing bank, the country, the product, or whether the card is debit or credit. For any of that you need a BIN lookup, because none of it is encoded in the digits.\nThe three lengths 16 digits is the standard and covers nearly everything issued today.\n13 digits is legacy. Visa issued them before 16 became the norm, and the specification still permits them — which means a validator built on ^4\\d{15}$ rejects a format Visa has never withdrawn. The account identifier is simply shorter; the arithmetic is identical.\n19 digits is the extended format, appearing on some products and in some markets. It is the length that causes damage, because the failure is silent rather than loud: a field capped at 16 characters truncates on entry, and a VARCHAR(16) column truncates on write with no error. The row saves and the stored number is wrong. The length rules across networks cover how to size fields and columns once for every card you accept.\nProduct families, and what the number does not reveal Visa is a family of products sharing one prefix:\nVisa Classic, Gold, Platinum, Signature, Infinite — tiers, distinguished by BIN assignment rather than by anything in the format Visa Debit — same 4, same lengths, indistinguishable from credit by format Visa Electron — issued on 4026, 417500, 4405, 4508, 4844, 4913, 4917 V PAY — a Europe-only chip-and-PIN product, also on 4 Visa Purchasing, Corporate, Fleet — commercial products on separate BIN ranges Electron is the one worth understanding, because the difference is behavioural rather than structural. Electron transactions require an online authorisation with a real-time balance check and do not permit going overdrawn, which is why the product was widely issued on accounts where an overdraft was not on offer. Nothing about that shows up in the number\u0026rsquo;s shape — a valid Electron number such as 4026 1738 4512 9037 is a perfectly ordinary 16-digit Visa number, and only the prefix marks it out.\nThe general rule holds across all of them: the number identifies the network, and the BIN database identifies everything else.\nThe security code Visa\u0026rsquo;s is called CVV2: three digits, printed on the signature panel on the back of the card, and not part of the card number. Mastercard\u0026rsquo;s equivalent is CVC2 and American Express\u0026rsquo;s is a four-digit CID on the front — same mechanism, different brand names and, in Amex\u0026rsquo;s case, a different length.\nTwo properties matter when you build a form. The code is never derivable from the number: the issuer computes it from the account number, expiry and service code under a pair of keys that never leave its hardware security module, which is precisely the security property it exists to provide. And it must never be retained after authorisation — not encrypted, not hashed, not in a log. It proves the card was in someone\u0026rsquo;s hand at the moment of entry, and storing it destroys the only thing it was for.\nFor a Visa form specifically, that means a fixed three-character field is safe only if you accept Visa alone. The moment American Express is in scope, the field\u0026rsquo;s length has to follow the detected brand.\nValidation rules for your form const VISA = /^4\\d{12}(?:\\d{3})?(?:\\d{3})?$/; // 13, 16 or 19 digits // Visa Electron sits inside the Visa range on specific prefixes. const VISA_ELECTRON = /^(?:4026|417500|4405|4508|4844|4913|4917)\\d{12}$/; function isVisa(pan) { const digits = String(pan).replace(/\\D/g, \u0026#39;\u0026#39;); return VISA.test(digits) \u0026amp;\u0026amp; luhnValid(digits); } Three things that pattern gets right and most do not. It accepts all three lengths rather than only 16. It is anchored at both ends, so it cannot match a prefix of some longer string. And it pairs the format test with a checksum test rather than treating either as sufficient — 4026 0000 0000 0000 matches the Electron prefix pattern above and fails Luhn, which is exactly the case that shows why both checks are needed.\nCases worth having in your suite:\nNumber Expected 4222222222222 valid, 13 digits 4539148803436467 valid, 16 digits 4532015112830366187 valid, 19 digits 4539148803436460 invalid — check digit altered 453914880343646 invalid — 15 digits 5539148803436467 not Visa All of the valid numbers above are synthetic and Luhn-valid; paste them into the validator to confirm.\nHistory Visa began as BankAmericard, launched by Bank of America in Fresno, California in 1958 — the first successful general-purpose consumer credit card. The programme was licensed to other banks through the 1960s, spun out into a member-owned association in 1970, and renamed Visa in 1976, a name chosen to be pronounceable in every market it operated in.\nThe 4 assignment dates from the standardisation of card numbering, when the ISO framework allocated the first digit by industry and the banking category was divided between the networks that existed. Visa\u0026rsquo;s share of it has never changed since, which is why a Visa number issued in 1980 and one issued this year share their first digit and their check-digit rule, differing only in length and in what the middle digits encode. Visa\u0026rsquo;s own numerics documentation covers the current assignment rules, including the migration to eight-digit BINs.\nCommon integration mistakes Assuming 16 digits. ^4\\d{15}$ is the single most copied Visa regex and it rejects both the 13-digit and 19-digit formats. Truncating 19 digits. An input maxlength of 16 or 19, or a VARCHAR(16) column, corrupts the number without raising anything. Size for 19 digits, or 23 characters if you keep the spaces. Treating Visa Electron as a separate network. It is a Visa product on Visa prefixes; routing it as its own brand produces a card your gateway does not recognise. Inferring debit or credit from the number. Nothing in the format carries it, and code that guesses will be wrong for a substantial share of cards. Storing the number as an integer. Nineteen digits exceeds a 64-bit signed integer, and leading digits are meaningful — card numbers are strings from input to storage. The first two account for most Visa-specific bug reports, and both are invisible until a customer with an unusual card tries to pay. Neither shows up in analytics either, because a customer whose valid card is rejected at the form does not file a ticket — they leave, and the event is recorded as an abandoned checkout rather than a defect.\nFrequently Asked Questions Why do all Visa cards start with 4? Because Visa holds the entire Major Industry Identifier 4, which ISO/IEC 7812 assigns to banking and finance. It is the only major network with a single-digit prefix: Mastercard needs two ranges, Discover needs four, and Diners needs three, while Visa needs one digit. That makes Visa the one network you can identify from the first character with no ambiguity at all. How many digits is a Visa card number? Sixteen in almost every case, but Visa\u0026rsquo;s specification permits 13, 16 and 19. The 13-digit format is legacy and rare, and 19-digit numbers appear on some products. Validation that requires exactly 16 rejects both, which is the most common Visa-specific bug in payment forms. What is Visa Electron and is it a different network? No — it is a Visa product, not a separate scheme, issued on a handful of specific prefixes including 4026, 4508, 4844, 4913 and 4917. What distinguishes it is authorisation behaviour rather than format: Electron transactions require an online balance check and do not permit overdraft, which is why it was widely issued on accounts without credit facilities. Can I tell if a Visa card is debit or credit from the number? No. Visa debit and Visa credit both begin with 4 and are indistinguishable by format — nothing in the digits encodes funding type. That information lives in a commercially compiled BIN database. If your routing or surcharge logic depends on it, you need a lookup service, not a regex. What is the CVV2 on a Visa card? The three-digit code printed on the signature panel on the back. Visa\u0026rsquo;s brand name for it is CVV2; Mastercard calls its equivalent CVC2 and American Express calls its four-digit version CID. The issuer computes it from the card number, expiry and service code using keys that never leave its hardware security module, so it cannot be derived from the number by anyone else. Do 19-digit Visa numbers really exist? Yes, and they are the length that breaks systems silently. A 19-digit number entered into a field capped at 16 characters is truncated on entry, and stored in a VARCHAR(16) column it is truncated on write with no error raised. Size inputs and columns for 19 digits even if you have never seen one. ","permalink":"https://ccgenerator.org/guides/visa-card-number-format/","summary":"Every Visa card number begins with 4, carries a Luhn check digit in the final position, and is 13, 16 or 19 digits long — almost always 16. The three-digit CVV2 on the back is computed by the issuer and is not part of the number.\nThat is the format. What makes Visa interesting is the first digit, which Visa owns outright in a way no other network does, and the two lengths that are not 16.","title":"Visa Card Number Format Explained"},{"content":"Every credit card generator on the internet runs the same three steps: pick a prefix that matches a card network, fill the middle with random digits, calculate the Luhn check digit. That is the whole algorithm. It is about fifteen lines of code, it has been public for decades, and no site has a better version of it.\nWhich means the differences between generators are not technical. A site advertising \u0026ldquo;real\u0026rdquo;, \u0026ldquo;working\u0026rdquo;, or \u0026ldquo;live\u0026rdquo; numbers is not running a superior algorithm — it is describing an output that is not possible, usually to get you to click something.\nThe algorithm, in full There is nothing to withhold here, and showing it is the point:\nfunction generateCard(prefix, length) { let digits = prefix; while (digits.length \u0026lt; length - 1) { digits += Math.floor(Math.random() * 10); } return digits + luhnCheckDigit(digits); } function luhnCheckDigit(partial) { let sum = 0, double = true; for (let i = partial.length - 1; i \u0026gt;= 0; i--) { let d = Number(partial[i]); if (double) { d *= 2; if (d \u0026gt; 9) d -= 9; } sum += d; double = !double; } return (10 - (sum % 10)) % 10; } generateCard(\u0026#39;453914\u0026#39;, 16); // e.g. 4539142588796633 That is it. Every generator does this. The only implementation differences that mean anything are whether the randomness is cryptographic, whether the prefix ranges are current, and whether the output happens in your browser or on someone\u0026rsquo;s server.\nNotice what the code does not contain: no network request, no database, no lookup, no key. There is nowhere in those fifteen lines for an account to come from, which is a more convincing argument than any assurance about intent. The check-digit half is explained line by line in the Luhn algorithm guide.\nBrowser or server: the one difference that matters to you Of the three implementation differences above, the location is the one with consequences for the person using the tool.\nA generator that runs entirely in your browser takes no input and sends nothing anywhere. You can verify that yourself in about ten seconds: open your browser\u0026rsquo;s network tab, press generate, and watch for requests. If none appear, the numbers were produced on your machine and nobody else has seen them or knows you asked.\nA generator that produces numbers on a server knows every request you made, when, and from which address. For random digits that is not sensitive in itself — but it is a log that did not need to exist, held by an operator whose other choices you have no visibility into. The same logic applies to any tool asking you to paste a number in for checking: whatever you paste is now on somebody\u0026rsquo;s server.\nWhat \u0026ldquo;real\u0026rdquo; and \u0026ldquo;working\u0026rdquo; mean in these listings The vocabulary in this category is doing a lot of work. Decoded:\nClaim What it implies What it actually is \u0026ldquo;Real credit card generator\u0026rdquo; Numbers belong to real accounts The same random digits as everyone else \u0026ldquo;Working card numbers\u0026rdquo; Numbers complete purchases Numbers that pass a Luhn check \u0026ldquo;Live CC generator\u0026rdquo; Numbers are verified active A marketing word, and often a fraud-tool signal \u0026ldquo;Valid credit card generator\u0026rdquo; Numbers are usable Valid means correctly formatted, nothing more \u0026ldquo;With money / with balance\u0026rdquo; Numbers carry funds Impossible — a number carries nothing The fourth row is the one worth internalising. \u0026ldquo;Valid\u0026rdquo; is technically correct on any of these sites, including this one: the numbers really do satisfy the checksum. It is correct in the way that a grammatically perfect sentence about a country that does not exist is correct. Our own card validator reports validity in exactly this sense and says so on the page, because the word without that qualifier is the single biggest source of confusion in this space.\nThe last row is not a marketing exaggeration but a category error. A card number is a pointer, not a container — money sits in an account at a bank, and the digits are only a reference to it.\nWhat these sites are actually monetising If the product cannot be what it claims, something else is being sold. In rough order of how often you will meet it:\nAd impressions. Most generator sites run on advertising, this one included. That is a normal way to fund a free tool. What is not normal is inflating the claim to buy traffic: the promise of \u0026ldquo;working\u0026rdquo; numbers converts far better than \u0026ldquo;correctly formatted test data\u0026rdquo;, and some operators simply price that trade honestly and take the lie.\nSoftware downloads. Sites offering a generator to install. The file is the actual product, and the standard payloads are information-stealing trojans, crypto miners, and adware. This audience is a particularly good target, because someone who thought they were downloading a fraud tool is unlikely to file a report.\n\u0026ldquo;Checker\u0026rdquo; registrations. Tools that offer to test whether a number is live. These exist to sort stolen card lists into working and dead, and requiring an account puts the user\u0026rsquo;s own details into that operation\u0026rsquo;s hands.\nSurvey and CAPTCHA walls. \u0026ldquo;Complete this offer to reveal the number.\u0026rdquo; This is affiliate fraud with the card number as bait; there is nothing behind the wall.\nData collection. Forms that ask you to enter card details, personal information, or an email address \u0026ldquo;to verify\u0026rdquo;. The input is the output.\nIf a generator asks you to download anything, disable your antivirus, complete a survey, or create an account, close the tab. Card number generation runs in a browser in milliseconds. There is nothing to install, and no reason for anyone to need your details in order to give you random digits.\nHow to tell a legitimate tool from a fraud front This is a skill worth having, and it generalises well beyond this category.\nGood signs:\nStates plainly that the numbers are test data and cannot be used for payment Runs in the browser with nothing to download Requires no account and no email address Explains what it does and what it does not do Has a privacy policy, terms, and a real contact route Points you to gateway sandbox cards for anything it cannot do itself Has no \u0026ldquo;check if live\u0026rdquo; function of any kind Bad signs:\nClaims of \u0026ldquo;working\u0026rdquo;, \u0026ldquo;live\u0026rdquo;, \u0026ldquo;with balance\u0026rdquo;, or \u0026ldquo;with money\u0026rdquo; A card checking or verification feature A download or installer of any kind Survey walls, CAPTCHA gates, or a registration requirement Redirects to a Telegram or Discord channel Publishes BIN lists or issuer-to-prefix mappings No contact details, no legal pages, no named operator The sixth bad sign is the least obvious and one of the most reliable. A BIN list has almost no use in testing — you generate against the prefixes your own routing table contains — but it is directly useful as targeting data for card testing attacks. Publishing one tells you who the intended audience is.\nWhy anyone needs a generator at all Given all of the above, the reasonable question is why this category exists in a legitimate form. It does, for reasons that are entirely about software testing:\nPCI DSS discourages live cardholder data in test environments. If your staging database, your fixtures, or your bug reports contain real card numbers, you have expanded your compliance scope into places that were never designed for it. Synthetic data is the prescribed alternative rather than a shortcut — the PCI Security Standards Council publishes the requirement text, and the PCI guide for developers covers what it means in practice.\nSandbox cards are too few. A gateway publishes perhaps twenty numbers. If you need five hundred rows of realistic test data for a load test or a data-migration rehearsal, the bulk generator is the tool for it and Stripe\u0026rsquo;s set is not.\nFormat coverage needs variety. Brand detection, length validation, and input masking have to be tested against 15-digit Amex, 16-digit Visa, 19-digit UnionPay, and the 2-series Mastercard range. Sandbox sets rarely cover all of them.\nNegative testing needs deliberately broken data. A number that fails Luhn on purpose is the only way to prove your validation rejects it, and no processor publishes one for that.\nWhat we do and do not do here This site runs the algorithm above, in your browser, using crypto.getRandomValues() instead of Math.random() — with a documented fallback to Math.random() only where the Web Crypto API is unavailable, which on any current browser it is not.\nIt does not check cards. It does not publish BIN lists. It does not ask you to install anything or create an account, and it does not claim the output is anything other than test data.\nIf that seems like a low bar, it is — and it is worth noticing how many sites in this category do not clear it. What we are and how we handle corrections and sourcing are both written down, which is itself one of the signs in the checklist above.\nFrequently Asked Questions Is there a difference between credit card generators? Not in what they produce. Every one of them picks a network prefix, fills the middle with random digits, and calculates a Luhn check digit — the same fifteen lines of public code. The differences that do exist are about how the tool behaves: whether the randomness is cryptographic, whether the prefix ranges are current, whether generation happens in your browser or on someone\u0026rsquo;s server, and whether the site is honest about what the output is. What does \u0026#34;valid\u0026#34; mean on these sites? Correctly formatted, and nothing more. A valid number satisfies the Luhn checksum and matches a network\u0026rsquo;s prefix and length rules, which is a statement about arithmetic rather than about any account. The word is technically accurate and routinely used to imply something it does not mean, which is why it is worth reading as \u0026ldquo;well-formed\u0026rdquo; every time you see it. Are credit card generators safe to use? A browser-based one that asks for nothing is about as risky as a calculator — it takes no input from you and sends nothing anywhere. The danger is not in the generation, it is in the delivery: sites that require a download, a survey, an account, or a disabled antivirus are not distributing card numbers, they are distributing something else. Why do some generators ask me to download software? Because the download is the product. Generating card numbers takes milliseconds of JavaScript and there is no computation that requires a native application. When an installer is on offer, the common payloads are information-stealing trojans, crypto miners, and adware — and the audience for this search is unusually unlikely to report an infection. Can any generator produce a working card? No, and no future one will either. A number only works if a bank has linked it to a funded account in its own records, and no algorithm can create that record. The generators claiming otherwise are not running better code; they are describing an output that cannot exist, generally to get a click. What is a card checker and why should I avoid them? A checker tests whether a card number is live, usually by attempting small authorisations against real merchants. It exists to sort stolen card lists into working and dead, which is why no legitimate testing tool has one — your own software never needs to know whether a stranger\u0026rsquo;s card is active. A generator that also offers checking is telling you plainly what it is for. ","permalink":"https://ccgenerator.org/guides/what-fake-credit-card-generators-actually-do/","summary":"Every credit card generator on the internet runs the same three steps: pick a prefix that matches a card network, fill the middle with random digits, calculate the Luhn check digit. That is the whole algorithm. It is about fifteen lines of code, it has been public for decades, and no site has a better version of it.\nWhich means the differences between generators are not technical. A site advertising \u0026ldquo;real\u0026rdquo;, \u0026ldquo;working\u0026rdquo;, or \u0026ldquo;live\u0026rdquo; numbers is not running a superior algorithm — it is describing an output that is not possible, usually to get you to click something.","title":"What Credit Card Generators Actually Do"},{"content":"A card number is not random. The first digit says which industry issued it, the first six to eight identify the issuing institution, the digits after that identify your account within that institution, and the last one is a checksum. The structure is defined by a public standard, ISO/IEC 7812, and it is the same on every payment card in the world.\nKnowing which digits mean what changes how you write validation code, how you size a database column, and how you decide what is safe to print in a log. It also settles a surprising number of arguments about what a card number does and does not reveal.\nThe anatomy, visually Here is a 16-digit number broken into its four parts. The number is synthetic — it follows the format correctly and belongs to nobody.\n4 5 3 9 1 4 8 8 0 3 4 3 6 4 6 7 │ └──────────┬─────────┘ └────────┬──────┘ │ │ │ │ │ │ │ │ └─ Check digit (Luhn) │ │ └─────────── Individual Account Identifier │ └───────────────────────────────── IIN / BIN (digits 1–8) └─────────────────────────────────────────────── MII (Major Industry Identifier) The formal name for the whole string is the Primary Account Number, almost always written as PAN. It is worth adopting the term: PCI DSS, gateway API references, and acquirer documentation all use PAN precisely because \u0026ldquo;card number\u0026rdquo; is ambiguous between the printed number, the token that replaced it, and the account behind both.\nNote that the MII is not a separate field. It is simply the first digit of the IIN, called out separately because it carries meaning on its own.\nThe same layout at a different length Nothing above is specific to 16 digits. Here is a 15-digit American Express number — the canonical test PAN that Amex itself publishes — split the same way:\n3 7 8 2 8 2 2 4 6 3 1 0 0 0 5 │ └──────┬──────┘ └───────┬───────┘ │ │ │ │ │ │ │ │ └─ Check digit (Luhn) │ │ └─────────────── Individual Account Identifier (8 digits) │ └───────────────────────────────── IIN / BIN (6 digits) └─────────────────────────────────────────── MII 3 — travel and entertainment Same four parts, same order, same check digit rule. Only the middle section changed size, absorbing the difference between a 15-digit total and a 16-digit one. That is the property worth internalising: the layout is fixed, the account identifier is elastic, and any code that assumes otherwise is assuming something the standard never promised.\nIt is also worth saying plainly that all of this is public. ISO/IEC 7812 is a published standard, network prefix ranges appear in every acquirer\u0026rsquo;s integration documentation, and the Luhn formula has been in the public domain since its patent expired. There is nothing confidential in the structure of a card number — the security of a card has never rested on the layout being secret, which is why explaining it costs nobody anything.\nThe first digit — Major Industry Identifier The MII was assigned when the standard was written, in an era when card issuance was expected to spread across industries rather than concentrate in banking. Several ranges still reflect that original intent more than current reality.\nMII Industry Card networks in this range 0 ISO/TC 68 and other assignments — 1 Airlines — 2 Airlines and other future assignments Mastercard (2221–2720), Mir 3 Travel and entertainment American Express, Diners Club, JCB 4 Banking and financial Visa 5 Banking and financial Mastercard (51–55), Maestro 6 Merchandising and banking Discover, UnionPay, Maestro 7 Petroleum and other assignments — 8 Healthcare, telecommunications, other UnionPay (81) 9 National standards body assignment Troy (9792), RuPay Two rows deserve a second look.\nMII 2 is where Mastercard expanded. The 51–55 space filled up, so in 2017 Mastercard began issuing in the 2221–2720 range, which sits under an MII originally earmarked for airlines. Any brand-detection code written before that migration and never revisited will classify a 2-series Mastercard as unknown — a real and still-common bug.\nMII 9 is reserved for assignment by national standards bodies, which is how domestic card schemes get their space without going through the international allocation process. Troy, Türkiye\u0026rsquo;s national scheme, begins with 9792 for exactly this reason, and India\u0026rsquo;s RuPay occupies part of the same range. If you have wondered why Troy numbers look nothing like Visa or Mastercard numbers, this is the answer: they were allocated by a different authority under a different part of the standard.\nDigits 1–8 — the IIN / BIN The Issuer Identification Number identifies the institution that issued the card. In payment engineering it is nearly always called the BIN, for Bank Identification Number — an older term that the standard replaced but the industry never stopped using. Treat IIN and BIN as synonyms in practice.\nThe IIN was six digits for decades. ISO/IEC 7812-1:2017 extended it to eight, because six digits allow only a million issuer assignments and the space was running out. The allocation is managed by the ISO Registration Authority, a role held by the American Bankers Association.\nFor a developer, the extension has one immediate consequence: code that slices the first six characters to identify an issuer is now wrong for any card in the extended ranges. The two lengths coexist — some issuers hold six-digit IINs, others hold eight — so you cannot simply change 6 to 8 either. The lookup has to handle both, which is the subject of the BIN and IIN guide.\nWhat a BIN can tell you, given the right data: the network, the issuing bank, the country of issuance, whether the card is credit, debit, or prepaid, and its product level. What it cannot tell you: any of that, without a licensed BIN database. None of it is encoded in the digits. The number is an index into commercial data, and the data is what carries the meaning. The BIN lookup tool shows the difference between what the prefix implies structurally and what an actual database would resolve.\nThe middle — Individual Account Identifier Everything between the IIN and the check digit is the issuer\u0026rsquo;s own account identifier. Its length is whatever is left over:\naccount identifier length = total length − IIN length − 1 On a 16-digit card with an eight-digit IIN, that leaves 16 − 8 − 1 = 7 digits. On a 15-digit American Express card with a six-digit IIN, it leaves 8. The field has no fixed size, and nothing about its length is standardised across issuers.\nTwo things about this section are commonly misunderstood.\nIt is not your bank account number. There is no relationship — not an encoding, not a hash, not a truncation. The issuer maintains an internal mapping from card numbers to accounts, and that mapping is private to the issuer. Nobody holding your card number can derive your account number, your IBAN, or your sort code from it.\nIt is not stable. Because the card number points at your account rather than containing it, the issuer can hand you a new number whenever it needs to — after a reported loss, after a breach at a merchant, or at natural expiry — while your account, balance, and history carry on untouched. That indirection is the whole design, and it is also why a stolen card number is a smaller problem than a stolen bank account number.\nThe last digit — check digit The final digit is a Luhn checksum over everything before it. It catches single mistyped digits and almost every transposition of two adjacent digits, which is precisely the class of error a human makes reading a number off a card.\nIt proves nothing else. Roughly one in ten random digit strings passes a Luhn check, so a number can be perfectly well-formed and correspond to no account anywhere. The arithmetic, the reference implementation, and the errors it misses are covered in the Luhn algorithm guide; the card validator runs the same check against a number you paste in.\nHow long is a PAN? ISO/IEC 7812 permits 12 to 19 digits. Networks picked their formats inside that range and have mostly stayed put.\nLength Networks 12–19 Maestro 13 Visa (legacy) 14 Diners Club (classic) 15 American Express 16 Visa, Mastercard, Discover, JCB, UnionPay, Troy 19 Visa (some), Discover, JCB, UnionPay, Maestro Sixteen digits dominates so heavily that it gets hard-coded into validation rules, database columns, and input masks by developers who have never held a 15-digit Amex or a 19-digit UnionPay card. The per-network detail, including which prefixes actually occur at each length, is in the length reference.\nWhat is not in the card number The negative space is as informative as the structure. A PAN does not contain:\nA name. Cardholder name is a separate field, and on virtual cards it may not exist at all. A balance or credit limit. Those live in the issuer\u0026rsquo;s ledger, not in the digits. An expiry date. Separate field, printed separately, sent separately. A CVV. Separate value, computed by the issuer from the PAN and expiry using keys only the issuer holds. A credit-or-debit flag. That comes from a BIN database, not from the number. A country. Also BIN data. The MII does not encode geography. An account number. As above — the mapping is internal to the issuer. If you need any of those facts, you need a source other than the number. Inferring them from digit patterns is how validation code acquires assumptions that break the first time an unusual card arrives. The generator exposes this clearly: it produces structurally correct numbers with no issuer behind them, which is exactly what a format test needs and exactly what an authorisation test cannot use.\nStoring and displaying a PAN If a card number reaches your systems at all, PCI DSS applies. The practical rules:\nMasking. Display no more than the first six and the last four digits. Most interfaces show only the last four, which is enough for a customer to recognise a card and not enough to reconstruct one. The PCI Security Standards Council publishes the current requirement text.\nStorage. If you store a PAN it must be rendered unreadable — strong cryptography, with key management to match. The better answer is not to store it: let your processor tokenise, keep the token, and stay out of scope entirely.\nLogging. A PAN must never reach application logs, error trackers, analytics events, or a bug report screenshot. This is where card data leaks in practice — not through a database breach but through a stack trace containing the full request body.\nSchema. Use VARCHAR(19) at minimum. Two failure modes are worth naming because both are silent:\nVARCHAR(16) truncates 19-digit cards. The row saves without error and the number is now wrong. An integer column drops leading zeros and overflows: a 19-digit value exceeds the range of a 64-bit signed integer. Card numbers are strings from input to storage, always. A minimal masking helper:\nfunction maskPan(pan) { const d = String(pan).replace(/\\D/g, \u0026#39;\u0026#39;); if (d.length \u0026lt; 8) return \u0026#39;••••\u0026#39;; return `${\u0026#39;•\u0026#39;.repeat(d.length - 4)}${d.slice(-4)}`; } // 4539148803436467 → ••••••••••••6467 // 378282246310005 → •••••••••••0005 The length guard matters: without it, a short or empty input would produce a \u0026ldquo;mask\u0026rdquo; that reveals most of what it was given. The full compliance picture — what puts a system in scope, what takes it out, and what auditors actually ask for — is in the PCI DSS guide for developers.\nFrequently Asked Questions What does the first digit of a credit card mean? It is the Major Industry Identifier, and it says which category of business the number was issued for. 4 and 5 are banking and financial, which is why Visa starts with 4 and most Mastercards start with 5. 3 is travel and entertainment, covering American Express, Diners Club, and JCB. 6 is merchandising and banking, used by Discover and UnionPay. 9 is reserved for national standards bodies, which is how Türkiye\u0026rsquo;s Troy scheme ended up at 9792. What is a PAN? PAN stands for Primary Account Number — the formal name for the long number on the front of a card. You will see the term throughout PCI DSS and payment gateway documentation, where \u0026ldquo;card number\u0026rdquo; is too vague to be useful. A PAN is 12 to 19 digits under ISO/IEC 7812 and always ends in a Luhn check digit. Is my bank account number in my card number? No. The middle section is an account identifier assigned by the issuer within its own numbering scheme, and it has no relationship to your bank account number, your IBAN, or your sort code. This is why a replacement card carries a completely different number while your account stays exactly the same — the card number points at your account through the issuer\u0026rsquo;s internal mapping, it does not contain it. Why do card numbers have different lengths? Because each network chose its own format within the range ISO/IEC 7812 allows, which is 12 to 19 digits. American Express settled on 15, classic Diners Club on 14, and most other networks on 16. Maestro is the awkward one: it spans the full 12-to-19 range. Any validation that hard-codes 16 digits will reject legitimate cards. Can you tell the country from a card number? Not from the digits themselves. Country, issuing bank, card type, and card level all come from looking the leading digits up in a BIN database — commercial data that is compiled and licensed, not encoded in the number. The number tells you the network with reasonable confidence and nothing else with certainty. How much of a card number can I display? PCI DSS caps it at the first six and the last four digits, and even that is the maximum rather than a recommendation. Most interfaces show only the last four, which is enough for a customer to identify which card they used and not enough to reconstruct the number. Anything beyond first-six-and-last-four requires a documented business justification. ","permalink":"https://ccgenerator.org/guides/credit-card-number-structure/","summary":"A card number is not random. The first digit says which industry issued it, the first six to eight identify the issuing institution, the digits after that identify your account within that institution, and the last one is a checksum. The structure is defined by a public standard, ISO/IEC 7812, and it is the same on every payment card in the world.\nKnowing which digits mean what changes how you write validation code, how you size a database column, and how you decide what is safe to print in a log.","title":"What Every Digit in a Card Number Means"},{"content":"A CVV cannot be worked out from a card number. Not with a formula, not with a lookup, not with a tool. The value is produced by the issuing bank using two cryptographic keys that never leave the bank\u0026rsquo;s hardware security module, and without those keys there is no calculation to run.\nThat is not an obstacle someone has failed to solve yet. It is the entire design. The card number is printed on the card and passes through dozens of systems; the CVV exists precisely to be the one value that cannot be worked out from the rest.\nThe CVV generator page walks through the issuer\u0026rsquo;s calculation step by step and the four common misconceptions about it. This guide takes the other half: why the impossibility is structural rather than incidental, the four different values that all get called \u0026ldquo;the CVV\u0026rdquo;, what your gateway actually tells you about one, and why plenty of legitimate payments never ask for it at all.\nWhat the digits are for A security code answers one narrow question: is the person entering these details holding the physical card?\nIn a card-present transaction the chip answers that question cryptographically. Online or over the phone there is no chip, so the merchant falls back on something printed on the card and nowhere else — not in the magnetic stripe, not in the chip, not in a receipt, not in the data a terminal transmits. Someone who copied a stripe or intercepted a transaction has the number and the expiry. They do not have the code, unless they photographed the card or the cardholder typed it into something they should not have.\nThat is also why the code must never be retained after authorisation. A stored CVV converts the one piece of evidence that a card was physically present into just another database column, and its entire value depends on that not happening.\nCVV1, CVV2, iCVV and dCVV Four different values, one family, and confusing them causes real integration bugs:\nValue Where it lives Used for CVV1 / CVC1 Encoded in the magnetic stripe Card-present swipe transactions CVV2 / CVC2 / CID Printed on the card Card-not-present — online and phone iCVV Stored in the EMV chip Chip transactions; deliberately differs from CVV1 dCVV Generated per transaction Contactless and digital wallets; changes every time The iCVV design decision is the interesting one. If the chip carried the same value as the magnetic stripe, then data read from a chip transaction could be written onto a blank stripe and used as a counterfeit card — chip data would become a recipe for cloning the older technology. Making them different by design severs that path, and it is why a terminal that validates chip data against stripe expectations rejects perfectly good cards.\ndCVV extends the same idea one step further. Rather than a static value that is identical on every transaction, a device generates a fresh code each time, so intercepting one is worth nothing. This is what Apple Pay and Google Pay use alongside device tokens, and it is the direction the whole mechanism is moving — see the tokenisation guide for the surrounding architecture. EMVCo publishes the specifications these values are defined in.\nWhy it is unforgeable, structurally The single most common misconception is that the CVV algorithm is a secret. It is not. It is documented in hardware security module manuals and implemented in commercial card-management software.\nThat is not a weakness — it is the design working correctly, and it has a name. Kerckhoffs\u0026rsquo;s principle holds that a cryptographic system should remain secure even if everything about it except the key is public knowledge. A scheme whose safety depends on nobody learning the steps is not secure, merely unexamined. The CVV mechanism follows the principle exactly: publish the algorithm, protect the keys.\nThe useful contrast is with the Luhn checksum, which sits on the other end of the same card:\nLuhn check digit Security code Input The card number alone Number, expiry, service code, and a secret key Who can compute it Anyone Only the key holder What it detects Typing mistakes Someone who does not have the card Reversible from output Yes No A checksum contains no secret, which is why anyone can generate one and why it stops nothing. A security code is closer to a message authentication code: the whole point is that possessing the message does not let you produce the tag. Both values sit on the same card, three centimetres apart, and they are opposite kinds of object — which the card number structure guide sets out in full.\nWhat your gateway tells you about a CVV Developers meet the security code mostly through a result field, and the values are less binary than expected. Across processors you will see roughly:\nResult Meaning What it usually means for you Match The issuer verified the code Proceed No match The issuer says it is wrong Decline, or trigger a step-up Not processed The issuer did not check it Decide deliberately — this is not a pass Not present No code was sent Your own form probably has a gap Unsupported The issuer does not check codes More common than you would think Stripe surfaces this as cvc_check on the charge object; other gateways use different names for the same states. The two worth writing code for are the middle rows. \u0026ldquo;Not processed\u0026rdquo; and \u0026ldquo;unsupported\u0026rdquo; are not approvals, and treating them as matches quietly removes the check from a share of your traffic. Whether you accept them is a risk decision your fraud rules should make explicitly rather than one your parsing makes by accident.\nNote also that a CVV result is advisory. The issuer can approve a payment whose code did not match, and it can decline one whose code did — authorisation and verification are separate answers arriving in the same response.\nWhy some payments never ask for a CVV This surprises people who assume the code is mandatory. It is not, and the reasons are routine:\nRecurring payments. The code is collected on the first transaction and cannot be retained, so renewals run without it as merchant-initiated transactions.\nStored cards. A card on file is a token, and the token was never accompanied by a retrievable code. One-click checkout works precisely because the merchant kept the thing it is allowed to keep and discarded the thing it is not.\nSome Maestro cards. Certain Maestro products carry no printed code at all, which is why a form that hard-requires three digits blocks them outright.\nDigital wallets. Apple Pay, Google Pay, and similar authenticate the user on the device and present a dynamic cryptogram instead. Asking for a static code would add nothing.\nSome MOTO transactions. Mail-order and telephone-order flows have their own rules, which vary by acquirer and region.\nThe pattern behind all five: the code proves physical possession at the moment of entry, and each of these flows has either already established that or replaced it with something stronger. Strong customer authentication, covered in the 3-D Secure guide, is that stronger thing — which is why the CVV has quietly become the weakest of the checks a modern checkout runs.\nAuditing your own logs for it PCI DSS prohibits retaining the security code after authorisation, and the leak is almost never deliberate — it arrives through logging the whole request body. That makes it testable. A cheap assertion, worth running in CI against whatever your logger produces:\n// Fail the build if a payment payload ever reaches the logs intact. const FORBIDDEN = /\\b(cvv2?|cvc2?|cid|security[_-]?code)\\b\\s*[:=]\\s*[\u0026#34;\u0026#39;]?\\d{3,4}/i; test(\u0026#39;payment logs never contain a security code\u0026#39;, async () =\u0026gt; { await submitPayment({ number: \u0026#39;4242424242424242\u0026#39;, cvc: \u0026#39;123\u0026#39;, exp: \u0026#39;12/34\u0026#39; }); const written = await readCapturedLogs(); expect(written).not.toMatch(FORBIDDEN); expect(written).not.toMatch(/4242424242424242/); // the PAN, while you are here }); Point it at your real logger output rather than a mock, and run it against the error tracker payload too — exception context is the second most common escape route. The wider set of rules is in the PCI DSS guide for developers, and the standard itself is published by the PCI Security Standards Council.\nWhat our generator produces A random number of the correct length for the network: three digits, or four when the card is American Express. Nothing is derived from the card number it appears beside, because nothing can be.\nIt exists so your form has something of the right shape to validate — field length, input mask, the four-digit branch. For anything that needs a processor to actually verify a code, use your gateway\u0026rsquo;s sandbox values instead; several processors treat the code as a trigger for specific results, so an arbitrary one will not behave as you expect.\nFrequently Asked Questions Can you calculate a CVV from a card number? No. The value is produced by the issuing bank from the card number, expiry date and service code, encrypted under a pair of Card Verification Keys that live inside the bank\u0026rsquo;s hardware security module. Every input except those keys is printed on the card; the keys are what make the result unforgeable, and they never leave the HSM. Without them there is no calculation to run, and no tool can supply them. What does CVV stand for? Card Verification Value. Each network brands it differently — CVV2 at Visa, CVC2 at Mastercard, CID at American Express and Discover, CAV2 at JCB, CVN2 at UnionPay — but they are the same idea under different names. In code the only difference that matters is the length: four digits on American Express, three everywhere else. Why is the American Express code 4 digits? Because American Express specified it that way, and its cards are 15 digits rather than 16 for the same reason: the network defined its own format before the industry converged on a common one. There is no security advantage to the extra digit worth speaking of. What matters practically is that a hard-coded three-character validation rule rejects every Amex card that reaches it. Why does my saved card not ask for a CVV? Because the merchant cannot store it. The code is captured on the first transaction, sent for authorisation, and must then be discarded — so a saved card has a token and no code to re-send. Subsequent charges run as merchant-initiated transactions against that token, which is why recurring billing, one-click checkout, and most digital wallets never prompt for it again. Is a CVV ever stored? Only by the issuer, which has to hold the keys to verify it, and by organisations supporting issuing services. For everyone else PCI DSS prohibits retaining it after authorisation — not prohibits storing it unencrypted, prohibits storing it at all. A data set containing security codes therefore came from a non-compliant system, or from phishing or skimming that captured the code as it was typed. ","permalink":"https://ccgenerator.org/guides/what-is-cvv-and-why-it-cannot-be-derived/","summary":"A CVV cannot be worked out from a card number. Not with a formula, not with a lookup, not with a tool. The value is produced by the issuing bank using two cryptographic keys that never leave the bank\u0026rsquo;s hardware security module, and without those keys there is no calculation to run.\nThat is not an obstacle someone has failed to solve yet. It is the entire design. The card number is printed on the card and passes through dozens of systems; the CVV exists precisely to be the one value that cannot be worked out from the rest.","title":"What Is a CVV and Why Can't It Be Calculated?"},{"content":"A card number is an address, not a wallet. Sixteen digits identify an account at a bank; they do not contain, store, or represent money any more than a house number contains a house. When you pay with a card, no value travels with the number — the number tells the network which bank to ask, and the bank moves the money from an account it holds.\nA generated number points at no account. There is nothing for the bank to look up, so there is nothing to move. Adding a \u0026ldquo;balance\u0026rdquo; to a generated number is not difficult; it is meaningless, like writing a dollar amount on a street sign.\nWhat actually happens when you pay The gap between what people imagine and what occurs is where the confusion lives. The real sequence:\nThe card is read or entered. The merchant\u0026rsquo;s system collects the number, expiry, and security code. It goes to the acquirer — the merchant\u0026rsquo;s own bank or payment processor. The acquirer routes it to the network. Visa, Mastercard, or another scheme reads the leading digits to work out which institution issued the card. That routing step is what the BIN is for. The issuer decides. It locates the account, checks the balance or credit line, runs its fraud scoring, and answers yes or no — typically in under two seconds. Authorisation. On approval, the amount is held against the account. No money has moved. Settlement. Hours or days later, transactions are batched and the funds actually transfer between banks. Funding. The merchant receives the net amount, minus fees. Money never travels in the card number. It moves between bank accounts during settlement, days after the number was used. The number\u0026rsquo;s only job was to say which account.\nThe authorisation-versus-settlement split explains several things people find odd. A pending charge that vanishes was authorised and never captured. A hotel hold that outlasts your stay is an authorisation nobody released. A final amount different from the one you approved is a capture for less than was authorised — routine for restaurants adding a tip and for shipping charges calculated later. Payment APIs expose this directly; Stripe\u0026rsquo;s PaymentIntent lifecycle is the same two steps under different names. Central banks describe the underlying clearing systems in more detail — the Federal Reserve and the ECB both publish overviews.\nWhere the money actually sits Card type Funds come from Credit card A credit line the issuer extends to you Debit card Your deposit account at the bank Prepaid card A pooled account the issuer holds, with your balance tracked against it Virtual card The underlying account it was issued against The prepaid row is the instructive one, because it is the case that comes closest to a card \u0026ldquo;holding\u0026rdquo; money — and even there the funds sit in a pooled account at a bank while your balance is a ledger entry against it. The card number identifies which entry. Cut the card in half and the balance is unaffected; you have destroyed the pointer, not the money.\nThis is also why a replacement card carries a new number while your balance stays exactly where it was, and why a stolen card number is a smaller problem than a stolen bank account. The indirection is the design.\nThe credit row deserves a note of its own, because it is the case where there is no balance anywhere. A credit card does not draw on money you hold; it draws on a line the issuer has agreed to extend, and the funds used in a purchase are the bank\u0026rsquo;s until you repay them. That is why a credit card can be declined while your current account is full, why the limit and the balance are separate numbers moving in opposite directions, and why \u0026ldquo;how much is on this card\u0026rdquo; is a question with no answer for a credit product. What exists is an agreement about how much the issuer will lend, checked afresh on every authorisation.\nWhatever the type, the pattern holds: the digits are an identifier, and the arrangement they point at — a deposit, a credit line, a ledger entry — is where the value lives. Nothing in a card number can be read, decoded, or recalculated to reveal any of it, which is also why nothing in the number encodes a balance or a limit.\nWhy a \u0026ldquo;generator with money\u0026rdquo; cannot exist Follow the requirements through:\nFor a generator to put funds behind a number, that number would first have to be linked to a real account. Creating accounts and issuing cards against them requires a licence from a card scheme, a banking relationship, and identity verification on the customer. The organisations that can do all of this are called banks — a generator is a page of JavaScript.\nAnd then someone has to actually pay the money in. Funds are not created by assigning them; every balance in the system corresponds to money that somebody deposited, lent, or transferred. A site cannot conjure a balance any more than it can conjure the account.\nIf a website could add funds to a card number for free, it would not be running a website. The claim is not a technical exaggeration; it is describing something with no mechanism behind it.\nThe same reasoning covers every variant of the question. There is no unclaimed pool of funded numbers, no leftover test balance, no bank error to exploit — because a number is not a container in the first place.\nWhat sites claiming otherwise are doing Briefly, since it is covered in full elsewhere: pages promising funded card numbers are selling ad impressions against an impossible claim, distributing downloads that are themselves the product, or running survey walls with nothing behind them. The business model of card generator sites goes through the categories and how to tell them apart.\nThe legitimate versions of \u0026ldquo;a card with money on it\u0026rdquo; If what you actually want is a card carrying a balance, several ordinary products do exactly that:\nPrepaid cards. Bought in a shop or online, loaded with whatever you put on them, usable anywhere the network is accepted. No bank account required, which is the point — they exist for people who do not have one or do not want to use it online.\nGift cards. Prepaid value for a specific merchant, useful when the spend is going there anyway.\nVirtual cards. A real number issued against your existing account, disposable and limit-capped — the practical options are set out here, including which banks and providers offer them in which regions.\nDigital wallet balances. PayPal, Wise, Revolut, and similar hold a balance you can spend directly, often with a card attached to it.\nFintech accounts for people without a bank. Providers vary by region — Cash App and Chime in the US, Monzo and Starling in the UK, Papara and similar in Türkiye — and most are free to open with full identity verification, which takes minutes rather than a branch appointment.\nEvery one of these is a real account holding real money. That is not a limitation of the list; it is the only way a balance can exist at all.\nWhat a generated number is genuinely for Testing software. A synthetic number exercises a payment form\u0026rsquo;s validation, brand detection, field lengths, and masking without any bank being involved, which is precisely what you want when the thing under test is your own code. The generator produces them, and when you need a processor to actually respond — an approval, a decline, a 3-D Secure challenge — gateway sandbox cards are the right tool, because generated numbers cannot produce those responses.\nThe absence of a balance is not a missing feature. It is the entire reason the numbers are safe to publish, commit to a repository, and paste into a bug report.\nFrequently Asked Questions Can a credit card generator add money to a card? No, and the reason is structural rather than technical. Putting funds behind a number requires an account at a licensed institution, a customer relationship that passed identity checks, and someone actually paying the money in. Organisations able to do all three are called banks. A generator produces digits; it has no account to attach them to and no funds to attach. Where is the money on a credit card? In an account at the issuing bank — never in the number. A credit card draws on a credit line the issuer extends to you, a debit card on your deposit account, a prepaid card on a pooled account where your balance is tracked as a ledger entry. In every case the digits are a reference to a record held somewhere else. What is the difference between authorisation and settlement? Authorisation is the issuer confirming in real time that the account exists and can cover the amount, and placing a hold on it. No money moves at that point. Settlement is the transfer itself, usually batched and completed hours or days later. This is why a pending charge can disappear, why a hold can outlast a cancelled order, and why the amount finally taken can differ from the amount authorised. How do prepaid cards work? You load funds, and the issuer records your balance against a pooled account it holds at a bank. The card number identifies your entry in that ledger, exactly as a debit card number identifies your deposit account. Even in the case that comes closest to a card carrying money, the money is at the bank and the number is only a pointer to it. Can I get a card with money on it for free? Not with funds someone else paid for — that is what a fraudulent transaction is. What you can get easily is a card that holds money you put there: a prepaid card from a shop, a virtual card from your bank, or an account with a fintech provider, most of which are free to open and need no existing bank account. The card is free; the balance is yours. ","permalink":"https://ccgenerator.org/guides/why-generated-cards-have-no-balance/","summary":"A card number is an address, not a wallet. Sixteen digits identify an account at a bank; they do not contain, store, or represent money any more than a house number contains a house. When you pay with a card, no value travels with the number — the number tells the network which bank to ask, and the bank moves the money from an account it holds.\nA generated number points at no account.","title":"Why a Card Number Cannot Carry a Balance"},{"content":"A test card number passes your form and then gets rejected the moment it reaches a payment provider. That is expected behaviour, and understanding exactly where the rejection happens is useful — both for developers debugging a sandbox setup, and for anyone wondering whether a generated number could ever go through.\nThe short version: your form validates the number\u0026rsquo;s shape. The payment provider validates its existence. Those are entirely different checks, performed by entirely different systems, and only the second one determines whether money moves.\nThe four layers of card validation Every card number passes through up to four independent checks. They run in different places, answer different questions, and fail for different reasons.\nLayer Where it runs What it checks Can a generated number pass? 1. Format Browser (JavaScript) Length, digits only, input mask Yes 2. Checksum Browser or server Luhn check digit Yes 3. BIN validation Gateway or processor Prefix exists in a real BIN table, network supported Sometimes 4. Authorisation Issuing bank Account exists, is active, has funds, code matches, not blocked Never Layer 1 — format. Is this 13 to 19 digits, with separators stripped, matching the expected pattern for the detected brand? Pure string handling, no knowledge of payments required. Any generated number passes by construction.\nLayer 2 — checksum. Does the final digit satisfy the Luhn formula? Also arithmetic, also local, and also something a generator satisfies deliberately — computing that digit is the last step of generating the number. Worth remembering that roughly one in ten random strings passes this check anyway.\nLayer 3 — BIN validation. Now the number leaves your application. The gateway reads the leading digits and asks whether they fall in a range assigned to a network it supports and an issuer it can route to. This is the interesting layer, because a generated number can pass it: prefixes are public, and a generator that uses real network ranges produces numbers whose first six digits genuinely belong to somebody. What a BIN identifies is an institution, not an account — so passing here means only that the number is addressed correctly.\nLayer 4 — authorisation. The request reaches the issuing bank, which looks the number up in its own records. There is no record. The transaction is declined, and no amount of formatting can change that, because the check is a database lookup at an institution that never issued the card.\nLayers 1 and 2 are yours. Layer 3 is your gateway\u0026rsquo;s. Layer 4 belongs to a bank you have no relationship with, and it is the only one that decides whether money moves.\nThat split determines where your effort belongs. The first two layers exist to save a customer a round trip when they mistype a digit — they are a user-experience feature, and treating them as a security control is the mistake behind most of the confusion on this page. The last two are the actual controls, and you do not implement either of them. Which means the practical question in any integration is not \u0026ldquo;how thoroughly do I validate a card number\u0026rdquo;, but \u0026ldquo;how gracefully do I handle the answer somebody else gives me\u0026rdquo; — a question almost entirely about error paths, and the reason the failure-path section below is longer than it looks like it should be.\nWhere each provider draws the line The rejection looks slightly different depending on who is processing it:\nStripe — Stripe.js validates format client-side. Once the number reaches the API through a PaymentIntent, you get invalid_number or a card_declined with a decline code. The decline codes reference lists which are retriable. PayPal — adding a card triggers a verification authorisation against the issuer, which fails immediately. Errors surface through the Orders API error reference. Adyen — checks against its own BIN data and returns Refused with a refusal reason; the refusal reasons list maps each to a cause and a recommended action. Braintree — distinguishes processor_declined from gateway_rejected, which is a useful split: the first came from the bank, the second never left Braintree. The authorisation responses reference covers both. Google Play and the App Store — run a verification authorisation when a payment method is added, on top of account-level fraud checks. Google documents the common causes of a rejected payment method. Different names, one mechanism. Every provider eventually asks a bank, and the bank\u0026rsquo;s answer is the same in all five cases.\nA rejected attempt still leaves a trace This is the part most people get wrong, and it matters more than the decline itself.\nA declined attempt is not a non-event. Payment providers log every attempt with the card number, IP address, device fingerprint, and account. Repeated failed attempts from one source are the signature of a card testing attack — the automated probing of stolen card lists — and providers respond to that pattern automatically.\nThe consequences are usually account-level: rate limiting, a review flag, a requirement to re-verify identity, or suspension. On some platforms the block attaches to the device fingerprint and the payment method as well, which means it follows you to a new account.\nNote what this means for the intent behind the search. Someone trying generated numbers on a real checkout produces exactly the traffic pattern that fraud systems are built to detect, at exactly the endpoints that are monitored most closely. The outcome is not a successful payment; it is a flagged account and an automated report that nothing generated here can ever complete anyway.\nCommon developer causes of rejection If you are debugging rather than experimenting, the cause is usually in this table:\nSymptom Likely cause Test card declined in sandbox A generated number instead of the gateway\u0026rsquo;s own test card Works in sandbox, fails in production Live keys with a test card — expected; use a real card invalid_number on a valid-looking card Length or brand not enabled on that gateway account Card accepted, charge fails later Deferred authorisation; the number never existed Amex rejected everywhere American Express not enabled on the merchant account 2-series Mastercard rejected Brand detection regex still only covers 51–55 Random failures on long numbers A 19-digit PAN silently truncated by a VARCHAR(16) column The last row is the nastiest, because nothing errors. The row saves, the number is quietly wrong, and the failure surfaces later as an unexplained decline for a subset of customers — usually the ones on UnionPay and some Discover products. The card number structure guide covers the length range that column has to accommodate.\nThe second row is worth stating plainly too: a test card failing in production is not a bug to fix. It is the sandbox boundary working. The fix is a real card and a small amount.\nWhat to use instead Layers 1 and 2 — your own form. Generated numbers are exactly right, because those layers never contact anyone. The generator covers every network, and the validator shows what a checksum check does and does not prove. Layers 3 and 4 — the gateway. Use your provider\u0026rsquo;s published sandbox cards. The test card reference collects them across processors, and the Stripe set is documented in full. Production verification. A real card, a small amount, refunded afterwards. There is no synthetic substitute for this last step, and skipping it is how integrations ship with a broken capture path. Testing the failure paths Most teams test that a payment succeeds. Almost none test what happens when it does not, which is where real users end up:\nThe message shown after a decline — \u0026ldquo;Your bank declined this payment\u0026rdquo; is enough; never surface the raw decline code, which is often wrong and occasionally unsafe. Whether the cart survives a failed payment, or the customer has to start again. Retry logic and its rate limit, so a legitimate retry is possible and a loop is not. Network timeouts, and whether your idempotency key prevents a double charge. Partial success: authorisation succeeded, capture failed. Webhooks arriving late, twice, or out of order. The payment form testing checklist covers the assertions for each, and the 3-D Secure guide covers the authentication paths that sit between layers 3 and 4.\nThe gateway behaviour and error codes above were last checked against provider documentation on 4 August 2026. Providers do change what they publish — the official link beside each claim is authoritative. Frequently Asked Questions Why does my test card work in sandbox but not in production? Because the environment is chosen by your API key, not by the card. A sandbox recognises its provider\u0026rsquo;s published test numbers and responds with scripted results; production routes the same number to a real issuer, which has no record of it. A test card working in production would mean the sandbox boundary had failed — the rejection is the system behaving correctly. Can a fake card number ever be accepted by PayPal? It can pass the format check on the form, and it will fail the moment PayPal attempts to verify it. Adding a card runs a verification authorisation against the issuing bank, and a generated number has no issuer to answer. Repeating the attempt is worse than useless: failed verifications are logged against your account and device, and that pattern is exactly what fraud systems watch for. What happens if I keep trying declined cards? Providers log every attempt with the card number, IP address, device fingerprint, and account. Repeated failures from one source are the signature of a card testing attack, and the automated response is rate limiting, a review flag, forced re-verification, or suspension. On some platforms the block attaches to the device and the payment method rather than only the account. Why does the card pass validation but fail the payment? Those are two different questions answered by two different systems. Your form checks the number\u0026rsquo;s shape — length, digits, Luhn check digit — using only what is in front of it. The issuing bank checks whether the account exists, is active, has funds, and matches the security code. A generated number is built to satisfy the first and cannot satisfy the second. Which test cards should I use for my gateway? The ones your provider publishes, always. Stripe, PayPal, Adyen, Braintree and the rest each recognise their own numbers and return scripted approvals, declines and 3-D Secure challenges; a number from a different provider is just a well-formed card with no special meaning. Use generated numbers only for the layers that never leave your own application. ","permalink":"https://ccgenerator.org/guides/why-test-cards-fail-on-real-payment-systems/","summary":"A test card number passes your form and then gets rejected the moment it reaches a payment provider. That is expected behaviour, and understanding exactly where the rejection happens is useful — both for developers debugging a sandbox setup, and for anyone wondering whether a generated number could ever go through.\nThe short version: your form validates the number\u0026rsquo;s shape. The payment provider validates its existence. Those are entirely different checks, performed by entirely different systems, and only the second one determines whether money moves.","title":"Why Test Cards Fail on Real Payment Systems"},{"content":"Every generator and validator on this site runs entirely in your browser and produces synthetic data only. Nothing here is a real card, a real account, or a real identity, and none of it can move money. Use it to exercise validation logic, populate staging fixtures, and demo checkout screens — then use your payment provider\u0026rsquo;s official sandbox cards when you need scripted approvals, declines, or 3-D Secure challenges.\nBy card network Pick a network when your test needs the right prefix and length for that brand\u0026rsquo;s detection rules.\nVisa test card generator — 16-digit numbers on Visa\u0026rsquo;s 4 prefix, the default choice for most form-validation tests.\nMastercard generator — numbers in both the classic 51–55 range and the newer 2221–2720 range, so you can check that your BIN detection covers both.\nAmerican Express generator — 15-digit numbers on the 34/37 prefixes, the usual way to find inputs that assume every card is 16 digits.\nTroy card generator — Türkiye\u0026rsquo;s domestic scheme, useful when testing localized checkout flows.\nAll networks at once — generate across every supported brand from a single form when you need a mixed data set.\nDiscover card generator — four separate BIN ranges, including the 622126–622925 block co-branded with UnionPay.\nJCB card generator — the 3528–3589 range, and why a plain ^35 check produces false positives.\nDiners Club card generator — 14-digit numbers, the shortest in circulation, with 4-6-4 grouping.\nMaestro card generator — 12 to 19 digits, the widest length range of any network.\nUnionPay card generator — the largest network by volume, and the reason a failed Luhn check should warn rather than block.\nBy card type Credit card numbers — the general-purpose generator linked above covers standard credit ranges for every supported network. Debit card numbers — Maestro and other debit-common formats, and why the digits never tell you debit from credit. Virtual card numbers — VCC-format test numbers, plus an honest account of where real virtual cards come from and what they can and cannot do. By data type Card numbers are rarely enough on their own — most checkout forms want a full record.\nFull card records — every generator emits the number, expiry date, and CVV together, so you can fill an entire payment form in one paste.\nBulk test data — up to 10,000 records with reproducible seeds and negative cases, exported as CSV, JSON, JSONL, SQL or TSV.\nBIN generator — supply a prefix and get Luhn-valid numbers that start with it, for BIN routing and 8-digit BIN migration testing.\nCVV generator — random security codes at the right length per network, and why a real CVV cannot be derived from a card number.\nTest identity generator — names, billing addresses and postcodes in eight country formats, for AVS and address validation testing.\nIBAN generator — synthetic IBANs with valid MOD-97 check digits in 33 country formats, plus a validator, for SEPA and bank transfer testing.\nDesign and UI Card mockup generator — watermarked card preview images at correct ISO 7810 proportions, for checkout UI prototypes and design work. Gateway sandbox cards Test card numbers by gateway — the official sandbox cards published by Stripe, PayPal, Braintree, Adyen, Square and Authorize.Net, with their decline codes and 3-D Secure cards. Use these when you are testing the processor rather than your own form. Validation tools Credit card validator — check the Luhn digit, detect the network from the prefix, and see the number broken into its parts. Format validation only, in your browser.\nBIN lookup — analyse a prefix against the public standards, and find out where licensed issuer data actually comes from.\nThe FAQ explains what a Luhn-valid number does and does not prove.\nBrowser extension Credit Card Generator for Chrome — the same generator and Luhn validator in the toolbar, plus a right-click action that fills the payment form on the page you are testing. Free, and it generates locally in the browser like everything else here. In your test suite A number you paste by hand is a number that is the same on every run. These packages run the same network rules as the generators above, so a test suite can draw a fresh card per case instead — the 15-digit Amex and the 19-digit Maestro that a hard-coded 4111 1111 1111 1111 never exercises.\n@ccgenerator/test-cards (npm) — generate(), validate() and brand detection for JavaScript and TypeScript. Zero dependencies, no install scripts, works in Node and the browser. Source on GitHub. ccgenerator/test-cards (Composer) — the same API for PHP 8.1+, with a test_card validation rule and Faker provider for Laravel, a #[TestCardNumber] constraint for Symfony, console commands for both, and seeded generation for fixtures that repeat. Source on GitHub. Both are MIT-licensed, make no network calls, and emit the same synthetic numbers this site does — nothing they produce will authorize anywhere.\nBefore you use any of this Passing the Luhn check means a number is well-formed, not that it exists. No generated number will ever authorize, and attempting to use one against a live processor is fraud, not testing — see the disclaimer and terms. For background on how these numbers are put together, start with the testing guides.\n","permalink":"https://ccgenerator.org/tools/","summary":"Every generator and validator on this site runs entirely in your browser and produces synthetic data only. Nothing here is a real card, a real account, or a real identity, and none of it can move money. Use it to exercise validation logic, populate staging fixtures, and demo checkout screens — then use your payment provider\u0026rsquo;s official sandbox cards when you need scripted approvals, declines, or 3-D Secure challenges.\nBy card network Pick a network when your test needs the right prefix and length for that brand\u0026rsquo;s detection rules.","title":"All Test Data Tools"},{"content":"What CC Generator is CC Generator is a free, browser-based tool that produces synthetic payment card data for software testing. It generates card numbers that satisfy the Luhn checksum and match the published length and prefix rules of eight card networks, along with matching expiry dates, CVV values, and cardholder names. It is built for the people who have to make card input work correctly — engineers building checkout flows, QA engineers testing them, and anyone teaching how card numbers are structured. Nothing it produces is a real card, and nothing it produces leaves your browser.\nWhy we built it Anyone who has built a payment form runs into the same wall.\nYou need to test card input. Not the payment itself — the input. Does the field mask correctly as digits are typed? Does it detect Visa from the first digit and switch the logo? Does it reject fifteen digits for a network that requires sixteen, and accept fifteen for American Express? Does your CSV export escape the field, and does your log scrubber redact it?\nYou cannot use a real card for this. Beyond the obvious security problem of scattering your own card number through test fixtures, git history, and CI logs, PCI DSS is explicit: live primary account numbers must not be used for testing or development. That rule exists precisely to keep production cardholder data out of non-production environments. Synthetic test data is not a convenience here — for anyone in scope of the standard, it is a compliance requirement.\nGateway sandbox cards only get you so far. Stripe, Adyen, PayPal and the rest publish test numbers, and they are the right tool for testing processor behaviour. But each list is short and fixed: a handful of numbers on one or two networks, each wired to a rehearsed outcome. If you need forty Mastercards to seed a fixture, a Diners Club number to check your 14-digit path, or a 19-digit Maestro to find where your column width breaks, the sandbox list does not have them.\nThat gap is what this tool fills. It sits earlier in the cycle: use it while you are testing your own code, then switch to your provider\u0026rsquo;s official test cards once you are testing theirs.\nHow the generator works No black box. Here is exactly what happens when you press Generate.\nNetwork rule selection Every card network owns ranges of Issuer Identification Numbers (IINs, often still called BINs) and specifies how long a full account number may be. The generator holds one rule per network:\nNetwork Prefixes Length CVV Visa 4 16 3 Mastercard 51–55, 2221–2720 16 3 American Express 34, 37 15 4 Troy 9792 16 3 Discover 6011, 65, 644–649 16 3 JCB 3528–3589 16 3 Diners Club 300–305, 36, 38, 39 14 3 Maestro 50, 56–69 16 or 19 3 Pick a network and the generator selects one prefix from its range and one permitted length. (The standards allow more variation than this — ISO/IEC 7812 permits PANs up to 19 digits, and Visa has historically issued 13- and 19-digit numbers — but these are the combinations the tool emits, chosen because they are what payment forms actually encounter.)\nRandom digit generation The digits between the prefix and the check digit are filled with uniform random values from the browser\u0026rsquo;s built-in generator, Math.random(). This is a fast pseudorandom source, not a cryptographically secure one — and deliberately so. Nothing here is a secret: these numbers protect nothing, authorise nothing, and have no value to an attacker who predicts them. Using a CSPRNG would suggest the output is security-sensitive, which would be misleading. What matters for test data is that values are well distributed and cheap to produce in bulk, which is what this gives you.\nLuhn check digit calculation The last digit is not random. It is computed so the whole number passes the Luhn checksum (ISO/IEC 7812 Annex B). The algorithm: append a placeholder 0, walk the digits right to left, double every second one, subtract 9 from any doubled result above 9, and sum everything. The check digit is whatever makes that sum a multiple of 10.\nWorked through with the partial number 453201234567890:\ndigits: 4 5 3 2 0 1 2 3 4 5 6 7 8 9 0 [0] doubled: ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ after: 8 5 6 2 0 1 4 3 8 5 3 7 7 9 0 [0] (6→12→3, 8→16→7) sum = 8+5+6+2+0+1+4+3+8+5+3+7+7+9+0+0 = 68 check digit = (10 − (68 mod 10)) mod 10 = 2 result = 4532012345678902 That final number is Luhn-valid. The generator verifies its own output before returning it, and retries if the check fails.\nSupporting fields Expiry date — a random month between 01 and 12, and a year one to five years from today. Always in the future, so it will not trip an \u0026ldquo;expired card\u0026rdquo; branch you did not mean to test. CVV/CVC — three random digits, or four for American Express. This value is completely random and is not derived from the card number, because it cannot be. A real CVV is computed by the issuer from the PAN, the expiry date, a service code, and a pair of secret DES keys that never leave the issuer. Without those keys, no one outside the bank can produce or verify a genuine CVV. Any site claiming otherwise is not doing what it says. Cardholder name — drawn from a small fixed pool of obviously synthetic names (Alex Tester, Jordan Example, Taylor Sandbox, and similar), so test data reads as test data in a log or a screenshot. Everything runs in your browser There is no server-side component. The generator is JavaScript delivered with the page; it makes no network request when you generate, and copy, JSON export, and CSV export are all assembled locally in memory. We never receive a number you generate, so we cannot log or analyse one.\nConfirm it in thirty seconds: open developer tools, go to the Network tab, clear it, and generate a card. Nothing appears. Disconnect from the internet after the page loads and the tool still works.\nWhat we deliberately do not do We do not store, distribute, or sell real card data. No dataset of real numbers exists here. Output is computed from randomness and a public checksum, never looked up. We do not run a card checker or BIN validation service. Submitting numbers to find out which ones are active against a real issuer is the defining function of card fraud tooling. We do not offer it and never will. We do not issue virtual cards. We are not a card issuer and hold no funds. We have no accounts, payments, or subscriptions. Nothing to sign up for, nothing to buy. We do not log or analyse generated data. It never reaches us in the first place. Who this is for Software engineers building payment integrations and checkout flows. QA engineers testing card entry, validation messages, and error paths. Automation engineers seeding fixtures for unit, integration, and end-to-end suites. Designers prototyping payment interfaces with realistic-looking placeholder data. Instructors teaching card number structure, IIN ranges, and checksum algorithms. Security researchers studying payment system behaviour with data that harms no one. If your work touches a card input field, this is meant for you. The FAQ covers the questions that come up most often.\nWho this is not for If you came here looking for a card that can actually buy something, or get past a paid signup, an age check, or an identity check — this tool is useless to you. Generated numbers are declined by every real payment system, because there is no issuer behind them. And attempting it is fraud regardless of whether it works. Our Disclaimer sets out the boundaries, and the FAQ answers the question directly.\nOur editorial standards Technical claims here are checked against primary sources — ISO/IEC 7812 for number structure, EMVCo and PCI SSC publications for payment mechanics, and providers\u0026rsquo; own documentation for anything provider-specific. Where a fact changes over time, such as an IIN range, we say so rather than presenting it as fixed, and we note substantive corrections on the page. Our editorial policy sets out how content is written, reviewed, and updated, and how to tell us we got something wrong. The editorial team page says who \u0026ldquo;we\u0026rdquo; are, and — just as important — which subjects we consider outside our competence and refuse to write about.\nIf you would rather see the business behind the site than the process, How This Site Works covers how it makes money, why nothing you generate leaves your browser, and how to verify both claims yourself.\nContact CC Generator is built and maintained by a small independent team of developers. We do not publish individual names, but we do answer email.\nGeneral: hello@ccgenerator.org\nFor corrections, privacy requests, abuse reports, or legal questions, the Contact page lists the right address. Or start at the generator if you came here to use the tool.\n","permalink":"https://ccgenerator.org/about/","summary":"What CC Generator is CC Generator is a free, browser-based tool that produces synthetic payment card data for software testing. It generates card numbers that satisfy the Luhn checksum and match the published length and prefix rules of eight card networks, along with matching expiry dates, CVV values, and cardholder names. It is built for the people who have to make card input work correctly — engineers building checkout flows, QA engineers testing them, and anyone teaching how card numbers are structured.","title":"About CC Generator"},{"content":" Test card only\nCredit Card Number Generator Generate dummy card details for development and QA. Nothing is stored or sent to a server.\nSingle card Bulk cards Card network Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Generate Card Card network All Mixed Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Quantity Generate Cards These numbers are dummy, Luhn-valid test values for software testing only. They are not real active cards and cannot be used for payments. Copy all Show JSON Copy JSON Export JSON Export CSV JSON output All Cards Visa Mastercard Amex Discover JCB Diners Maestro UnionPay Troy These are test numbers, not real cards Every number on this page is synthetic test data. It is generated by a formula, not issued by a bank. These numbers are not linked to any person, account, or balance. They carry no funds. They will be declined by every real payment processor. They only pass client-side format and checksum validation. Attempting to use card data to obtain goods, services, or trials you have not paid for is fraud in virtually every jurisdiction. Do not do it. Generation runs entirely in your browser. Nothing is sent to or stored on our servers. Intended use: payment form validation, checkout UI testing, QA test fixtures, and developer demos. For processor-specific behaviour (approvals, declines, refunds, 3-D Secure) use your gateway's official sandbox test cards.\nThis American Express card generator produces 15-digit, Luhn-valid Amex test numbers with 4-digit CID codes. An Amex card generator is worth having separately from the others for one reason: American Express differs from Visa and Mastercard in almost every dimension except the checksum, and those differences are the most frequently missed details in payment forms.\nAmerican Express card number format Property Value Differs from Visa/Mastercard? First digits (IIN) 34, 37 Yes Length 15 digits Yes — others use 16 Digit grouping 4-6-5 Yes — others use 4-4-4-4 Check digit Luhn (mod 10) No Security code name CID (Card Identification Number) Yes Security code length 4 digits Yes — others use 3 Security code location Front of the card Yes — others put it on the back Six of the seven rows differ. Only the checksum is shared.\nWhy Amex breaks payment forms Five failures, in rough order of how often they appear. Each one is reproducible with the generator above.\n1. Hard-coded 16-digit length // Rejects every American Express card ever issued if (cardNumber.length !== 16) return \u0026#39;Invalid card number\u0026#39;; Length is a property of the brand, not of cards in general. Derive it from the detected network — 15 for Amex, 16 for Mastercard, 13/16/19 for Visa.\nHow to test it: generate an Amex number here, paste it into your form, and confirm it is accepted.\n2. Fixed 3-digit security code field A maxlength=\u0026quot;3\u0026quot; on the security-code input truncates the last digit of a CID. The card is valid, the cardholder typed the right code, the payment fails, and nothing on screen explains why. This is the worst of the five because it is invisible.\nconst cvvLength = brand === \u0026#39;amex\u0026#39; ? 4 : 3; How to test it: generate an Amex card, copy the 4-digit CID, and check that all four digits survive being typed into the field.\n3. Wrong input mask A 4-4-4-4 mask renders a 15-digit number as 1234 5678 9012 345, which is not how the number is printed on the card. Amex groups 4-6-5: 1234 567890 12345. Users comparing the screen to the card in their hand will assume they mistyped.\nHow to test it: generate a number and compare your field\u0026rsquo;s grouping against the 4-6-5 formatter below.\n4. \u0026ldquo;The 3 digits on the back\u0026rdquo; help text The copy and the little card illustration next to the security-code field are wrong for Amex. The CID is four digits, on the front, to the right of the card number. Static help text sends every Amex customer looking at the wrong side of their card.\nHow to test it: switch your form to Amex and confirm the help text and illustration change with it. The CVV generator produces codes at the right length for each network, and explains why the code cannot be derived from a card number by anyone but the issuer.\n5. Brand detection that waits too long 34 and 37 are decisive after two keystrokes. A form that waits for four digits — or for the field to blur — before showing the Amex mark and resizing the CID field feels broken even when it eventually behaves correctly.\nHow to test it: type 37 and confirm the mark appears and the security-code field grows to four digits immediately.\nAmex regex and validation const AMEX = /^3[47]\\d{13}$/; // Grouping helper: 4-6-5 function formatAmex(n) { const d = n.replace(/\\D/g, \u0026#39;\u0026#39;).slice(0, 15); return [d.slice(0, 4), d.slice(4, 10), d.slice(10, 15)] .filter(Boolean).join(\u0026#39; \u0026#39;); } formatAmex(\u0026#39;374245455400126\u0026#39;); // \u0026#34;3742 454554 00126\u0026#34; formatAmex(\u0026#39;378282246310005\u0026#39;); // \u0026#34;3782 822463 10005\u0026#34; AMEX.test(\u0026#39;374245455400126\u0026#39;); // true — 15 digits, 37 prefix AMEX.test(\u0026#39;3742454554001260\u0026#39;); // false — 16 digits AMEX.test(\u0026#39;35282246310005\u0026#39;); // false — 35 is not Amex The pattern is short because Amex is the simplest network to match: two prefixes, one length, no ranges. Strip separators before testing — it matches digits only, and it checks shape rather than the checksum, so run a Luhn check as well.\nAmerican Express product lines Green, Gold, Platinum, Centurion — tiers of the same consumer product; all begin 34 or 37 and share the identical format Corporate and business cards — same format again Co-branded cards issued with airline and hotel partners — still 15 digits There is no product tier encoded in the number. In some markets Amex-branded cards are issued by a local bank under licence rather than by American Express itself, and even then the number format does not change. If you need to know the product or the issuer, that is a BIN table lookup — see the BIN and IIN guide.\nAmex acceptance and BIN routing One structural difference matters for integration work. Visa and Mastercard operate four-party models: they run the network, while banks issue the cards and acquire the merchants. American Express traditionally ran a three-party model in which it is the network, the issuer, and the acquirer at once — though it also licenses issuance to banks in many markets.\nThe practical consequence is that Amex acceptance is often a separate commercial arrangement. Some processors require a distinct Amex merchant account, settlement can run on a different timetable, and your routing logic may need to send 34/37 traffic somewhere other than the rest. Worth confirming before your first Amex transaction rather than after.\nOfficial Amex test numbers This generator Gateway sandbox card Passes client-side Luhn check Yes Yes Triggers Amex brand detection Yes Yes Produces a 4-digit CID Yes Yes Unlimited unique numbers Yes No — a handful of fixed numbers Returns an authorisation response No Yes Triggers specific decline codes No Yes Works with 3-D Secure flows No Yes Use this generator while you are fixing the five form problems above; switch to the gateway\u0026rsquo;s own numbers once the processor\u0026rsquo;s responses are what you are testing. Stripe and PayPal publish full tables, and we collect the equivalents on the test card numbers reference. Card numbering in general is defined by ISO/IEC 7812.\nThe other networks have their own pages — Visa, Mastercard, and Troy — while the all-network generator mixes Amex with 16-digit brands in one run, which is the fastest way to prove your form handles both shapes. The tool directory lists everything else, and the FAQ covers what a Luhn-valid number does and does not prove.\nFrequently Asked Questions How many digits does an American Express card have? 15, not 16. American Express is the most common card in circulation that does not use a 16-digit number, which is why a hard-coded length check of 16 rejects every Amex card. Why does Amex use a 4-digit security code? It is simply a different scheme design. American Express calls its code the CID and made it four digits; Visa\u0026rsquo;s CVV2, Mastercard\u0026rsquo;s CVC2, and most others are three. Nothing about the card number determines the code length, so your form has to derive it from the detected brand. Where is the CID on an Amex card? On the front, printed to the right of the embossed card number — not on the signature panel on the back, where Visa and Mastercard put theirs. Checkout help text and card illustrations that say \u0026ldquo;the three digits on the back\u0026rdquo; are wrong for every Amex customer who reads them. Do all Amex numbers start with 34 or 37? Yes. Both sit under the Major Industry Identifier 3, which covers travel and entertainment, so they share that leading digit with JCB and Diners Club. Two digits are enough to identify American Express specifically. Why does my checkout reject a valid Amex card? Almost always one of two things: a length check that requires 16 digits, or a security-code field with maxlength=\u0026ldquo;3\u0026rdquo; that silently truncates the 4-digit CID. Both fail on well-formed cards, and neither produces an error message the cardholder can act on. Is 3782 822463 10005 a real card? No. It is the most widely published American Express test number in the industry and appears in the documentation of nearly every payment gateway. It is Luhn-valid and deliberately not assigned to any account. Does Amex use the Luhn algorithm? Yes. The check digit rule is identical across Visa, Mastercard, American Express, and almost every other scheme — the mod-10 Luhn checksum. Length, grouping, and security code differ; the checksum does not. ","permalink":"https://ccgenerator.org/american-express-card-generator/","summary":"Test card only\nCredit Card Number Generator Generate dummy card details for development and QA. Nothing is stored or sent to a server.\nSingle card Bulk cards Card network Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Generate Card Card network All Mixed Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Quantity Generate Cards These numbers are dummy, Luhn-valid test values for software testing only. They are not real active cards and cannot be used for payments.","title":"American Express Card Generator (Amex)"},{"content":"Enter a card prefix and this tool builds Luhn-valid synthetic numbers that start with it. It is useful when you need test data in a specific format — for example, verifying that your BIN routing rules send a particular range to the right processor.\nThis tool does not look up, validate, or supply BIN numbers. It does not tell you which prefixes belong to real banks, and it does not check whether a generated number corresponds to anything. It takes the prefix you give it and completes the number.\nTest data only\nBIN Generator Enter a prefix. Each number keeps it, fills the middle at random, and closes with a valid Luhn check digit. Everything runs in your browser.\nCard prefix (1–8 digits) Total length 12 digits 13 digits 14 digits 15 digits 16 digits 17 digits 18 digits 19 digits Quantity Generate The prefix is used exactly as typed. This tool does not check what it belongs to, or whether it belongs to anything. These numbers are dummy, Luhn-valid test values for software testing only. They are not real active cards and cannot be used for payments. Copy all Show JSON Export JSON Export CSV JSON output All Cards Visa Mastercard Amex Discover JCB Diners Maestro UnionPay Troy These are test numbers, not real cards Every number on this page is synthetic test data. It is generated by a formula, not issued by a bank. These numbers are not linked to any person, account, or balance. They carry no funds. They will be declined by every real payment processor. They only pass client-side format and checksum validation. Attempting to use card data to obtain goods, services, or trials you have not paid for is fraud in virtually every jurisdiction. Do not do it. Generation runs entirely in your browser. Nothing is sent to or stored on our servers. Intended use: payment form validation, checkout UI testing, QA test fixtures, and developer demos. For processor-specific behaviour (approvals, declines, refunds, 3-D Secure) use your gateway's official sandbox test cards.\nWhat a BIN actually is The first digits of a card number are not random. They identify the institution that issued the card, and everything downstream — network selection, routing, interchange, fraud rules — reads them first.\nTwo names, one thing. IIN, the Issuer Identification Number, is what ISO/IEC 7812 calls it. BIN, the Bank Identification Number, is what the payments industry says. The standard prefers IIN because issuers are not always banks; in day-to-day work the terms are interchangeable, and a document that uses both is not making a distinction you need to track.\nThe very first digit is a field of its own, the Major Industry Identifier, which is why card numbers from different sectors do not collide:\nMII Industry 0 ISO/TC 68 and other industry assignments 1 Airlines 2 Airlines, financial and other future industry assignments 3 Travel and entertainment 4 Banking and financial 5 Banking and financial 6 Merchandising and banking/financial 7 Petroleum and other future industry assignments 8 Healthcare, telecommunications and other future assignments 9 For assignment by national standards bodies That last row is more than a footnote. It is why Türkiye\u0026rsquo;s domestic scheme Troy starts with 9792 — a national standards body assignment rather than a global network one. Card-detection code written against a fixed list of network prefixes tends to reject MII 9 entirely, which is the kind of bug that only shows up in one market. Our explainer on IINs and BINs goes through the rest of the structure.\nOne more thing the BIN does not tell you: how many businesses sit behind it. A single assignment is frequently sponsored by one licensed issuer and then sub-allocated to several programme managers, so cards carrying the same prefix can be branded by entirely different companies with different support paths and different product rules. This is normal in fintech issuing, and it is the practical reason the eight-digit extension mattered — the extra two digits are often what separates one programme from another inside a range that used to look like a single issuer.\nThe 6-to-8 digit BIN migration This is the open problem in this area, and the main reason a prefix-driven generator is worth having.\nISO/IEC 7812-1:2017 defined an eight-digit Issuer Identification Number. Visa and Mastercard adopted it, and from April 2022 both issue new assignments at eight digits only. The reason was arithmetic: six digits allow roughly 100,000 assignments worldwide, and the growth in issuing — particularly from fintechs and programme managers — was consuming what remained faster than the schemes could reclaim it. Eight digits takes the ceiling to about ten million.\nTwo properties of the change matter to anyone writing code:\nIt is an extension, not a renumbering. The first six digits of an existing assignment are unchanged; two more digits are appended to subdivide it. No cards were reissued. Six-digit assignments were not withdrawn. Both lengths are in circulation, and will be for years. Anything that handles BINs has to accept both. The failure mode follows directly. If your routing table keys on six digits, two issuers that now hold different eight-digit assignments inside the same six-digit range collapse into one entry, and every card from both goes wherever the first matching row points. It fails silently — the payments succeed, they just take the wrong route, carry the wrong interchange, or land at the wrong acquirer. Nobody files a bug for a payment that worked.\nWhat to do about it:\nWiden the BIN column in your schema. VARCHAR(8) at minimum, and store it as text — leading zeros are real and an integer column eats them. Confirm your BIN lookup provider returns eight-digit granularity, and that your client sends eight digits rather than truncating to six on the way out. Key routing rules on the longest matching prefix rather than a fixed width, so six and eight-digit rules can coexist in one table. Generate test numbers on eight-digit prefixes and assert that the right rule fires. That is what the tool above is for. Source: Visa — Preparing for the Eight-Digit BIN · Verified: 2026-08-03\nThe migration dates above were last checked against provider documentation on 3 August 2026. Providers do change what they publish — the official link beside each claim is authoritative. How BIN routing works When a payment is authorised, the BIN is read almost immediately and drives a chain of decisions:\nNetwork identification. The prefix says whether the card is Visa, Mastercard, Amex or a domestic scheme, which determines the rails the authorisation travels on. Acquirer selection. A merchant with more than one acquirer routes by BIN — domestic cards to a domestic acquirer, foreign cards to whoever prices them best. Done well this is a material saving; done on stale six-digit data it is a slow leak. Product rules. Funding type, commercial versus consumer, and issuing country all come from the BIN record rather than the digits, and each changes what you are allowed or obliged to do. The debit card generator covers the funding-type half of that in detail. Currency handling. The issuing country drives whether dynamic currency conversion is offered at all, and what the cardholder is shown if it is. None of those decisions is available from the number alone. Every one of them requires a lookup against a maintained database — the number supplies the key, nothing more.\nTesting scenarios Routing rules. Generate numbers on each prefix in your routing table and assert the expected acquirer comes back, including the fall-through case for a prefix you have no rule for. Eight-digit support end to end. Generate on eight-digit prefixes and follow the value through your form, your API, your database and your logs. Truncation to six usually happens in exactly one layer, and only a full pass finds it. Country-specific business rules. If a rule fires on an issuing country, drive it from your mocked lookup rather than the digits, and prove the rule does not accidentally key on the prefix. Pricing logic. Surcharge and interchange calculations should be driven by lookup output, with a defined answer for the unknown case. Lookup integration. Mock the response and test the failure paths — timeout, unknown BIN, malformed reply — which are the ones that reach production untested. A routing test looks like this:\n// Longest-prefix match, so six and eight-digit rules can coexist. const routes = [ { prefix: \u0026#39;41234567\u0026#39;, acquirer: \u0026#39;acquirer-eu\u0026#39; }, { prefix: \u0026#39;41234568\u0026#39;, acquirer: \u0026#39;acquirer-us\u0026#39; }, { prefix: \u0026#39;412345\u0026#39;, acquirer: \u0026#39;acquirer-legacy\u0026#39; }, ]; function routeFor(pan) { const match = routes .filter(r =\u0026gt; pan.startsWith(r.prefix)) .sort((a, b) =\u0026gt; b.prefix.length - a.prefix.length)[0]; return match ? match.acquirer : \u0026#39;default\u0026#39;; } // Generate PANs on each prefix above and assert the routing, including the // six-digit rule that must NOT swallow the eight-digit ones. test(\u0026#39;eight-digit rules win over the six-digit range they sit inside\u0026#39;, () =\u0026gt; { expect(routeFor(\u0026#39;4123456700000000\u0026#39;)).toBe(\u0026#39;acquirer-eu\u0026#39;); expect(routeFor(\u0026#39;4123456800000000\u0026#39;)).toBe(\u0026#39;acquirer-us\u0026#39;); expect(routeFor(\u0026#39;4123459900000000\u0026#39;)).toBe(\u0026#39;acquirer-legacy\u0026#39;); expect(routeFor(\u0026#39;4999999900000000\u0026#39;)).toBe(\u0026#39;default\u0026#39;); }); The third assertion is the one worth writing. A naive find over an unsorted table returns whichever rule appears first, and if that is the six-digit row the eight-digit rules never fire at all.\nWhat this tool deliberately does not do It does not supply BIN lists. We do not publish which prefix belongs to which institution, and there is no built-in set of prefixes to pick from. It does not validate a prefix. Whether what you typed is assigned to anyone is not checked, and that is a choice rather than an omission. It does not test whether a number is active. There is no function here that contacts an issuer or a network, and there never will be. It does not produce a specific institution\u0026rsquo;s cards. No generator can, because the thing that makes a number belong to an issuer is a record in their systems, not the digits. If you are looking for a tool that tells you whether a card number is active, this is not it, and we will not build it. That capability has no legitimate testing purpose — your own code never needs to know whether someone else\u0026rsquo;s card is active.\nFor the structure behind all of this, the all-network generator carries the format tables, Visa goes through one network in full, and the BIN lookup page explains what commercial databases actually return. When you need a processor\u0026rsquo;s own numbers rather than synthetic ones, use the test card numbers reference. The tool directory lists everything else, and the FAQ covers what a Luhn-valid number does and does not prove.\nFrequently Asked Questions What is a BIN? The Bank Identification Number: the leading digits of a card number that identify the institution which issued the card. Traditionally the first six digits, now increasingly the first eight. Payment systems use it to work out which network a card belongs to, which acquirer to route the authorisation through, and what product rules apply. What is the difference between BIN and IIN? Nothing, in practice. IIN — Issuer Identification Number — is the term ISO/IEC 7812 uses, and BIN is what the payments industry says. Some specifications prefer IIN because the issuer is not always a bank, but they refer to the same digits. If a document uses both, it is not drawing a distinction you need to worry about. How many digits is a BIN? Six historically, eight since the industry migrated. ISO/IEC 7812-1:2017 defined the eight-digit form, and from April 2022 Visa and Mastercard issue new assignments at eight digits only. Six-digit assignments were not withdrawn, so both lengths are in circulation and any code that handles BINs has to cope with both. Why is the industry moving from 6 to 8 digits? The six-digit space was running out. Six digits allow about 100,000 assignments across every issuer worldwide, and growth in fintech issuing consumed them faster than the schemes could reclaim them. Eight digits raises the ceiling to roughly ten million. The first six digits of an existing assignment stay the same, so the change is an extension rather than a renumbering. Can I find out which bank a BIN belongs to? Yes, through a commercial BIN database, and that is a legitimate need — routing an authorisation to the right acquirer, applying the correct interchange, or deciding whether to offer currency conversion all depend on it. We do not supply that data. Our BIN lookup page explains what those databases contain and how accurate they are in practice. Do generated BINs correspond to real banks? We have no idea, and neither does the tool. It completes whatever prefix you type without consulting anything. Some prefixes are public at network level — every Visa number starts with 4 — but whether the specific eight digits you entered are assigned to an institution is not something this page knows or reports. Can this tool tell me if a card is active? No, and deliberately so. Nothing on this page contacts an issuer, a network or any other system, and we will not add that. Determining whether someone else\u0026rsquo;s card is active has no legitimate testing purpose — your own code never needs to know it — and it is the defining function of card fraud tooling. Everything here is arithmetic performed in your browser. ","permalink":"https://ccgenerator.org/bin-generator/","summary":"Enter a card prefix and this tool builds Luhn-valid synthetic numbers that start with it. It is useful when you need test data in a specific format — for example, verifying that your BIN routing rules send a particular range to the right processor.\nThis tool does not look up, validate, or supply BIN numbers. It does not tell you which prefixes belong to real banks, and it does not check whether a generated number corresponds to anything.","title":"BIN Generator — Test Numbers from a Prefix"},{"content":"Enter the first digits of a card number and this page breaks down what the public standards say about them: which major industry the first digit belongs to, which card network the prefix falls into, and whether the length is valid for that network.\nIt does not name the issuing bank or the country. That information lives in commercial BIN databases, which are licensed products maintained from issuer registrations. We do not host one, and we would rather tell you that plainly than serve you stale or unsourced data. If you need issuer-level lookup for production routing, the established providers are listed below.\nPublic standards only\nCard Prefix Analyser Enter a prefix or a full number. Everything shown comes from published standards, not from a BIN database — no issuer name, no country.\nCard prefix or number Standards analysis only. This page does not identify the issuing bank, the country, or the card product — that data is licensed, and we do not host it. All Cards Visa Mastercard Amex Discover JCB Diners Maestro UnionPay Troy What a BIN tells you — and who knows it The useful way to think about a card prefix is as two layers of information with completely different availability.\nKnown from public standards — what the tool above reports\nFact Source Major industry, from the first digit ISO/IEC 7812-1 Card network Published IIN ranges Valid lengths for that network Network specifications Whether the check digit is correct The Luhn algorithm Known only from a BIN database — licensed data\nFact Why it is not derivable Issuing bank name A registration record, not a property of the digits Issuing country Assigned per range by the scheme, and reassignable Card type: debit, credit or prepaid Set by the issuer per product Card level: classic, gold, platinum, commercial Portfolio metadata Regulated or unregulated for interchange Depends on issuer and jurisdiction Nothing in the second table can be computed. Each row is something an organisation recorded and someone else licensed, which is why every honest answer to \u0026ldquo;what bank is this\u0026rdquo; involves a database and a subscription.\nHow the BIN system works ISO/IEC 7812-1 defines the Issuer Identification Number and the registration authority allocates ranges to card schemes and issuers. An issuer receiving a range subdivides it across its own products — a credit portfolio here, a debit portfolio there — and reports the structure back to the schemes, which distribute BIN files to acquirers and processors. That distribution chain is why your BIN data is always slightly behind reality: it is a copy of a copy, refreshed on a schedule.\nThe width of that identifier changed. Assignments made since April 2022 are eight digits rather than six, because the six-digit space was running out. The short version for this page is that a six-digit lookup key no longer resolves to a single product, and a lookup service that only accepts six digits is answering a question you did not ask.\nWhat BIN data is used for It is worth being concrete about why this is a normal piece of payments infrastructure rather than something exotic:\nAcquirer routing. A merchant with more than one acquirer sends domestic cards to a domestic acquirer and foreign cards to whoever prices them best. At volume this is a material cost difference. Interchange estimation. Fees vary by card type, level and region, so forecasting processing costs means knowing what mix of cards you take. Surcharge rules. Where surcharging is permitted at all, the rules usually differ between debit and credit — see the debit card generator for why the digits alone cannot answer that. Dynamic currency conversion. Whether to offer a cardholder their home currency depends on the issuing country. Fraud scoring input. A mismatch between card country and IP country is a signal, one among many. It is an input to a model, never a decision on its own. Authentication flow. Regional rules and issuer behaviour around strong customer authentication differ, and knowing the issuing region shapes what your checkout should expect. Analytics. Which issuers your customers bank with, and how approval rates differ between them, is genuinely actionable. Send the prefix, never the whole number One rule that matters more than any provider choice: when you call a lookup service, send the first six or eight digits and nothing else. A BIN is not cardholder data on its own, and a service that only ever sees a prefix cannot leak an account. Send the full primary account number instead — which several client libraries will happily do if you pass the raw input — and you have handed card data to a third party, widened your PCI scope to include them, and created a copy of something you are supposed to be minimising. Truncate before the call, not inside it, and assert that in a test. The same applies to your logs: the prefix is safe to record, the rest is not.\nWhere licensed BIN data comes from Providers, with honest notes and no affiliate links:\nYour payment provider\u0026rsquo;s own API. Start here. Stripe\u0026rsquo;s card object returns brand, a two-letter country, and funding as credit, debit, prepaid or unknown; Adyen and most other gateways return equivalents alongside the authorisation. That covers the majority of real routing and surcharge logic with no extra vendor, no extra latency and no extra thing to be down. The gap is the issuer name, which Stripe\u0026rsquo;s card object does not include — if you genuinely need that, you need a database. binlist.net — the long-standing free service, and the one to be careful with: it stopped updating in 2023 and directs users to a paid IIN List product. The endpoint still answers, which is exactly the trap, because stale data that returns confidently is worse than no data. Bincodes, BIN Database (bindb.com), Iin.lv, Neutrino API — commercial services with maintained files, priced per lookup or per subscription. Three questions to ask any provider before you commit: does it accept eight-digit BINs, how often is the underlying file refreshed, and what does it return when it does not know? A service that guesses rather than saying unknown will quietly corrupt every decision downstream.\nSource for the Stripe fields: Stripe API — the Card object · Verified: 2026-08-04\nProvider details above were last checked against provider documentation on 4 August 2026. Providers do change what they publish — the official link beside each claim is authoritative. What we deliberately do not provide A downloadable BIN list A bank name to prefix mapping, in either direction Any data about which ranges are worth attempting Card status checking of any kind Lists of BINs circulate in fraud communities as targeting data — a way to pick which issuer\u0026rsquo;s cards to attempt. Publishing one would serve that use far more than it would serve anyone building software. Commercial providers gate their data behind accounts and terms of use for the same reason.\nThe format-level question — is this number well-formed — has no such problem, and the card validator answers it in full.\nTesting BIN logic Your BIN handling needs tests, and those tests should not call a third party. Generate synthetic numbers on whatever prefixes your routing table contains with the BIN generator — which also covers the six-to-eight digit migration in detail — then mock the lookup itself:\n// Mock the BIN service so tests don\u0026#39;t depend on a third party const binFixtures = { \u0026#39;41234567\u0026#39;: { brand: \u0026#39;visa\u0026#39;, type: \u0026#39;credit\u0026#39;, country: \u0026#39;GB\u0026#39; }, \u0026#39;55123456\u0026#39;: { brand: \u0026#39;mastercard\u0026#39;, type: \u0026#39;debit\u0026#39;, country: \u0026#39;DE\u0026#39; }, }; jest.mock(\u0026#39;./binService\u0026#39;, () =\u0026gt; ({ lookup: (bin) =\u0026gt; Promise.resolve(binFixtures[bin] ?? null), })); The ?? null is the important part. Write a test for the null case and one for a timeout, then decide deliberately what your code does in each — because \u0026ldquo;the lookup did not answer\u0026rdquo; is a state you will reach in production, and code that only handles the happy path picks a behaviour for you at the worst moment.\nRelated tools and guides Generate full test records with the all-network generator, and check what a processor returns for its own sandbox cards with the test card numbers reference. The IIN and BIN explainer goes deeper into the structure. The tool directory lists everything else, and the FAQ covers what a Luhn-valid number does and does not prove.\nFrequently Asked Questions What is a BIN lookup? Taking the leading digits of a card number and finding out what they represent. Part of the answer comes from published standards — the industry the first digit belongs to, the network the prefix falls into, the lengths that network uses — and that is what this page does. The rest, meaning the issuing bank, the country and the card product, comes from a commercial database built on issuer registrations. Can I find out which bank issued a card? Through a licensed BIN database, yes. That data is compiled from issuer registrations and scheme files, maintained commercially, and sold under terms of use. It is not derivable from the digits themselves — the mapping between a prefix and an institution is a record someone keeps, not a calculation anyone can perform. Is BIN lookup legal? Yes. It is ordinary business practice in payments, used for acquirer routing, interchange estimation, surcharge rules, currency decisions and risk scoring. The data is licensed rather than secret, and the providers gate it behind accounts and terms precisely because bulk prefix lists have an obvious second use. Why does this tool not show the bank name? Because we do not host a BIN database and will not publish one. Free lists that circulate without a source are usually stale, incomplete, or compiled from data that was not anyone\u0026rsquo;s to share. We would rather tell you exactly what the public standards support and point you at licensed providers for the rest than serve you data we cannot stand behind. What is the difference between BIN and IIN? None in practice. IIN, the Issuer Identification Number, is the term in ISO/IEC 7812; BIN, the Bank Identification Number, is what the industry says. The standard prefers IIN because issuers are not always banks. A document using both is not drawing a distinction you need to act on. How accurate are free BIN databases? Variable, and usually worse than they look. Issuers reassign ranges, portfolios get sold, and BIN files are updated continuously by the schemes — a snapshot starts drifting immediately. Free sources also tend to be six-digit only, which no longer resolves to a single product now that assignments are made at eight digits. For anything that affects money, use a maintained commercial source or your processor. Does my payment provider already give me this data? Very likely, and this is the answer most people miss. Stripe\u0026rsquo;s card object returns the brand, the two-letter country and a funding value of credit, debit, prepaid or unknown, and other major gateways return equivalents. That covers most of what routing and surcharge logic actually needs, with no third-party integration and no extra failure mode. Check your provider\u0026rsquo;s card object before you buy a lookup service. ","permalink":"https://ccgenerator.org/bin-lookup/","summary":"Enter the first digits of a card number and this page breaks down what the public standards say about them: which major industry the first digit belongs to, which card network the prefix falls into, and whether the length is valid for that network.\nIt does not name the issuing bank or the country. That information lives in commercial BIN databases, which are licensed products maintained from issuer registrations. We do not host one, and we would rather tell you that plainly than serve you stale or unsourced data.","title":"BIN Lookup — Card Prefix Analyser"},{"content":"Bulk synthetic payment test data for QA teams and automation engineers: up to ten thousand records with reproducible seeds, a configurable share of deliberately broken rows, and export to the format your suite actually reads. Everything is generated in your browser and downloaded directly — no data is uploaded, and nothing is stored.\nTest data only\nBulk Test Card Generator Up to 10,000 synthetic records with reproducible seeds and negative cases. Generated in your browser and downloaded directly — nothing is uploaded.\nQuantity Network mix Realistic mix (60% Visa, 30% Mastercard, 10% Amex) Even across all networks Visa only Mastercard only American Express only Discover only JCB only Diners Club only Maestro only Troy only Invalid rows (broken Luhn) 0% — all valid 5% 10% 25% 50% Expired rows 0% — all in date 5% 10% 25% Seed (optional) Format CSV JSON JSONL SQL INSERT TSV Generate Generating…\nEvery row is synthetic test data. No number here is issued by a bank, carries a balance, or will authorise anywhere. Never load this into a production database. Copy Download Preview All Cards Visa Mastercard Amex Discover JCB Diners Maestro UnionPay Troy These are test numbers, not real cards Every number on this page is synthetic test data. It is generated by a formula, not issued by a bank. These numbers are not linked to any person, account, or balance. They carry no funds. They will be declined by every real payment processor. They only pass client-side format and checksum validation. Attempting to use card data to obtain goods, services, or trials you have not paid for is fraud in virtually every jurisdiction. Do not do it. Generation runs entirely in your browser. Nothing is sent to or stored on our servers. Intended use: payment form validation, checkout UI testing, QA test fixtures, and developer demos. For processor-specific behaviour (approvals, declines, refunds, 3-D Secure) use your gateway's official sandbox test cards.\nOutput formats Every format carries the same records; only the packaging differs. These samples are real output from the tool above, generated with the seed docs-sample.\nCSV\ncard_number,network,exp_month,exp_year,cvv,cardholder_name,luhn_valid,expired 5231698649355089,mastercard,09,2030,435,Quinn Placeholder,true,false 4391134838583520,visa,02,2030,005,Taylor Sandbox,true,false 4251988068019342,visa,08,2028,128,Quinn Placeholder,true,false 4374741431393462,visa,10,2027,995,Riley Dummy,false,false Look at the CVV on the second row: 005. Open this file in a spreadsheet application and that becomes 5, while the card numbers become floating-point values in scientific notation. Both are silent, and both produce test data that no longer tests anything. If a CSV has to go through a spreadsheet, import the columns as text rather than opening the file directly — or use JSON, where the values are quoted and the problem does not exist.\nJSON\n[ { \u0026#34;cardNumber\u0026#34;: \u0026#34;5231698649355089\u0026#34;, \u0026#34;network\u0026#34;: \u0026#34;mastercard\u0026#34;, \u0026#34;expMonth\u0026#34;: \u0026#34;09\u0026#34;, \u0026#34;expYear\u0026#34;: \u0026#34;2030\u0026#34;, \u0026#34;cvv\u0026#34;: \u0026#34;435\u0026#34;, \u0026#34;cardholderName\u0026#34;: \u0026#34;Quinn Placeholder\u0026#34;, \u0026#34;luhnValid\u0026#34;: true, \u0026#34;expired\u0026#34;: false } ] JSONL — one record per line, for streaming a large set without parsing it all at once:\n{\u0026#34;cardNumber\u0026#34;:\u0026#34;5231698649355089\u0026#34;,\u0026#34;network\u0026#34;:\u0026#34;mastercard\u0026#34;,\u0026#34;expMonth\u0026#34;:\u0026#34;09\u0026#34;,\u0026#34;expYear\u0026#34;:\u0026#34;2030\u0026#34;,\u0026#34;cvv\u0026#34;:\u0026#34;435\u0026#34;,\u0026#34;cardholderName\u0026#34;:\u0026#34;Quinn Placeholder\u0026#34;,\u0026#34;luhnValid\u0026#34;:true,\u0026#34;expired\u0026#34;:false} {\u0026#34;cardNumber\u0026#34;:\u0026#34;4391134838583520\u0026#34;,\u0026#34;network\u0026#34;:\u0026#34;visa\u0026#34;,\u0026#34;expMonth\u0026#34;:\u0026#34;02\u0026#34;,\u0026#34;expYear\u0026#34;:\u0026#34;2030\u0026#34;,\u0026#34;cvv\u0026#34;:\u0026#34;005\u0026#34;,\u0026#34;cardholderName\u0026#34;:\u0026#34;Taylor Sandbox\u0026#34;,\u0026#34;luhnValid\u0026#34;:true,\u0026#34;expired\u0026#34;:false} SQL\nINSERT INTO test_payment_methods (card_number, network, exp_month, exp_year, cvv, luhn_valid, expired) VALUES (\u0026#39;5231698649355089\u0026#39;, \u0026#39;mastercard\u0026#39;, \u0026#39;09\u0026#39;, \u0026#39;2030\u0026#39;, \u0026#39;435\u0026#39;, TRUE, FALSE), (\u0026#39;4391134838583520\u0026#39;, \u0026#39;visa\u0026#39;, \u0026#39;02\u0026#39;, \u0026#39;2030\u0026#39;, \u0026#39;005\u0026#39;, TRUE, FALSE); Note that every value is quoted as text. A card number in a numeric column loses leading zeros and precision, and the same applies to security codes — these are digit strings, not integers.\nTSV is the same as CSV with tab separators, which is the safer choice when a cardholder name might contain a comma.\nUsing bulk test data in your test suite Playwright\nimport cards from \u0026#39;./fixtures/test-cards.json\u0026#39;; test.describe(\u0026#39;checkout accepts all supported networks\u0026#39;, () =\u0026gt; { for (const card of cards.filter(c =\u0026gt; c.luhnValid)) { test(`accepts ${card.network} ${card.cardNumber.slice(0, 4)}...`, async ({ page }) =\u0026gt; { await page.goto(\u0026#39;/checkout\u0026#39;); await page.fill(\u0026#39;[name=cardNumber]\u0026#39;, card.cardNumber); await page.fill(\u0026#39;[name=cvv]\u0026#39;, card.cvv); await expect(page.locator(\u0026#39;[data-brand]\u0026#39;)).toHaveText(card.network); }); } }); pytest, with the negative half of the suite that most examples leave out:\nimport json import pytest with open(\u0026#39;fixtures/test_cards.json\u0026#39;) as f: CARDS = json.load(f) @pytest.mark.parametrize(\u0026#39;card\u0026#39;, [c for c in CARDS if c[\u0026#39;luhnValid\u0026#39;]]) def test_card_is_accepted(client, card): resp = client.post(\u0026#39;/validate-card\u0026#39;, json={\u0026#39;number\u0026#39;: card[\u0026#39;cardNumber\u0026#39;]}) assert resp.status_code == 200 assert resp.json()[\u0026#39;network\u0026#39;] == card[\u0026#39;network\u0026#39;] @pytest.mark.parametrize(\u0026#39;card\u0026#39;, [c for c in CARDS if not c[\u0026#39;luhnValid\u0026#39;]]) def test_invalid_card_is_rejected(client, card): resp = client.post(\u0026#39;/validate-card\u0026#39;, json={\u0026#39;number\u0026#39;: card[\u0026#39;cardNumber\u0026#39;]}) assert resp.status_code == 400 The luhn_valid flag is what makes both halves come from one file. Without it you would be maintaining two fixtures and hoping they stay in step.\nTest data management principles The tool is the easy part. These seven habits are what separate a fixture set that helps from one that quietly rots:\nNever use production card data in a test environment. PCI DSS requires it: version 4 states in Requirement 6.5.5 that live PANs are not used in pre-production environments, tightening the wording of what was Requirement 6.4.3 under version 3.2.1. Synthetic data is a compliance obligation, not a convenience. Version your fixtures. Commit the generated file rather than generating at test time. A suite that builds its own inputs on every run is a suite whose failures you cannot reproduce. Seed deterministically. Same seed, same data, same result. If you must generate at runtime, pin the seed in the repository and print it on failure. Include negative cases. Broken check digits, wrong lengths, expired dates, a three-digit code on an Amex number. Validation you have never seen fail is validation you have not tested. Cover every network you accept. At minimum one card per brand you take, and specifically American Express at fifteen digits and a 2-series Mastercard — the two cases hard-coded rules break on. Refresh expiry dates. A fixture pinned to 12/25 becomes an expired-card fixture on a date nobody chose, and the resulting failure looks like a code regression. Generate expiry relative to today, or regenerate the file on a schedule. Mask in logs, even for test data. The habit is what transfers. A logger that prints a full number in staging will print one in production the first time someone reuses the helper. What the seed actually buys you Reproducibility is worth more than it first appears, and it is the feature most bulk generators skip.\nThe obvious win is debugging. When a parameterised suite fails on row 4,127 of a generated set, a seed turns \u0026ldquo;it failed once in CI\u0026rdquo; into a set you can regenerate on your laptop and step through. Without one, you are reading a stack trace about data that no longer exists.\nThe less obvious win is review. A seeded fixture file produces a clean diff — regenerate with the same seed after changing a setting and the only rows that move are the ones the setting affected, so a reviewer can see what changed rather than a ten-thousand-line replacement. Put the seed in a comment at the top of the fixture, or in the filename, and the file documents how to rebuild itself.\nThe trap to avoid is treating a seed as a guarantee across versions. It fixes the sequence of random numbers, not the code that consumes them: change the network mix, the invalid share, or the generator itself, and the same seed yields a different set. That is correct behaviour, not a bug — but it means a seed identifies a set only alongside the settings that produced it. Record both.\nRealistic distribution Test data should look like your traffic. If seventy per cent of your real payments are Visa and half your fixtures are American Express, your suite spends its time on a path your users rarely take while under-covering the one they do — and the bugs it finds are weighted the same way.\nThe realistic mix option approximates a typical Western e-commerce split at sixty per cent Visa, thirty per cent Mastercard and ten per cent American Express. Treat that as a starting point, not a fact about your business: pull the actual distribution from your processor\u0026rsquo;s reporting and match it. If a tenth of your volume is a domestic scheme, a tenth of your fixtures should be too.\nLimits and performance Ten thousand records is the ceiling, and the reason is the browser rather than the arithmetic. Generation is chunked in batches of five hundred with the main thread released between each one, so the page stays responsive and the progress bar is honest — but the full set lives in memory and export serialises all of it into a single string. Past ten thousand, that serialisation is what starts to hurt, not the generating.\nIf you need more, two options. Generate several sets with different seeds and concatenate them, which also gives you a natural way to shard fixtures across test suites. Or lift the generation function out of this page — view source, take the seeded random function and the check-digit calculation, and run it in your own build script where there is no tab to freeze. The BIN generator does the same job for a single prefix, and the validator will confirm any row you are suspicious of.\nFor processor behaviour rather than format coverage, generated data is the wrong input entirely — the test card numbers reference lists the sandbox cards that produce real approvals, declines and 3-D Secure challenges.\nRelated tools and guides Generate single records with the all-network generator, or build the matching billing addresses, postcodes and contact details with the test identity generator — the two together give you a complete payment-form fixture rather than a column of numbers. Our test data management guide goes further into fixture strategy. The tool directory lists everything else, and the FAQ covers what a Luhn-valid number does and does not prove.\nFrequently Asked Questions How many cards can I generate at once? Ten thousand. The limit exists because everything runs in your browser tab — generation is chunked so it never freezes the page, but the whole set is held in memory and rendered into a single string on export. If you need more than that, generate several sets with different seeds and concatenate them, or move generation into your own build script with the npm or Composer package, which runs the same rules with no ceiling. Can I get the same set of cards again? Yes, that is what the seed field is for. The same seed with the same settings produces byte-identical output, on any machine and any browser, because the generator uses a seeded pseudo-random function rather than the system random source. Leave the field blank and one is chosen for you and displayed, so you can reproduce a set after the fact. Can I include invalid cards for negative testing? Yes. Set a percentage of rows to carry a deliberately wrong check digit, and every record is tagged with a luhn_valid flag so your fixtures can be split into positive and negative cases without re-deriving anything. A validation test suite that only contains valid input is only testing half of the behaviour. What format should I use for my test suite? JSON if your tests read fixtures directly, because it parses into objects with no work. JSONL if the set is large and you want to stream it. CSV or TSV for spreadsheets and data-loading tools. SQL when you are seeding a database directly. The format only affects packaging — the records themselves are identical. Are the generated cards unique? Within a single set, yes. Duplicates are detected and regenerated as the set is built. Across two separate runs with different seeds, collisions are possible but very unlikely at these volumes. Note that the last four digits are not unique and cannot be — with a thousand possible combinations, any set over a few dozen rows will repeat them, which is a useful property to test against. Can I use this data in a production database? No. Beyond the obvious — none of it will authorise — synthetic records in a production system are actively harmful, because someone will eventually find them and be unable to tell whether they represent real customers. Keep test data in test environments, and tag it at creation so it is identifiable if it ever escapes. ","permalink":"https://ccgenerator.org/bulk-credit-card-generator/","summary":"Bulk synthetic payment test data for QA teams and automation engineers: up to ten thousand records with reproducible seeds, a configurable share of deliberately broken rows, and export to the format your suite actually reads. Everything is generated in your browser and downloaded directly — no data is uploaded, and nothing is stored.\nTest data only\nBulk Test Card Generator Up to 10,000 synthetic records with reproducible seeds and negative cases.","title":"Bulk Credit Card Generator — CSV Export"},{"content":"CC Generator is run by a small independent team, and we read everything that comes in. There is no contact form here — the site is fully static, with no server to receive one — so email is the way to reach us. Pick the address that matches your subject and you will get to the right person faster.\nMost messages get a reply within 2–3 business days. Privacy requests and abuse reports have their own timelines, listed at the bottom of this page.\nWhere to write Subject Address General questions, feedback hello [at] ccgenerator [dot] org Privacy, data requests (GDPR/CCPA) privacy [at] ccgenerator [dot] org Legal, terms, takedown notices legal [at] ccgenerator [dot] org Reporting misuse or abuse abuse [at] ccgenerator [dot] org Technical bug reports bugs [at] ccgenerator [dot] org Corrections to guide content editorial [at] ccgenerator [dot] org Advertising and partnerships partners [at] ccgenerator [dot] org Before you write Some questions arrive often enough that the answer is already on the site, usually in more detail than an email reply would give:\n\u0026ldquo;Why don\u0026rsquo;t the generated cards work for payments?\u0026rdquo; — because there is no issuing bank behind them, so no one can authorise a transaction. The FAQ has the short answer and the Disclaimer walks through the full authorisation path. \u0026ldquo;How do I get a real virtual card?\u0026rdquo; — from a bank or a licensed provider that is authorised to issue them, not from a generator. We cannot help with that. \u0026ldquo;Is this legal?\u0026rdquo; — yes, for testing. Our Terms of Service set out exactly what is and is not permitted, and the Disclaimer explains where the line sits. \u0026ldquo;Do you store what I generate?\u0026rdquo; — no. Generation runs entirely in your browser and nothing is transmitted to us. The Privacy Policy explains how to verify that yourself in your browser\u0026rsquo;s developer tools. \u0026ldquo;Can you add support for a specific card network?\u0026rdquo; — quite possibly. Write to the bugs address above and tell us which network and which IIN/BIN ranges and lengths it uses. A link to the network\u0026rsquo;s published specification helps a lot. Reporting a technical error If the generator misbehaves, a useful bug report saves a round trip. Please include:\nBrowser and version (for example, Firefox 141 or Safari 18.2) Operating system and whether you are on desktop or mobile Which page you were on, and the URL Which settings were selected — card network, single or bulk mode, quantity What you expected to happen, and what actually happened Any console errors — open developer tools, look at the Console tab, and paste anything red A screenshot is welcome. If the problem involves specific generated output, paste it: it is synthetic test data, so there is nothing sensitive about sharing it.\nSend bug reports to the bugs address in the table above.\nReporting misuse If you have found this site referenced in a fraud attempt, a phishing campaign, or any other misuse, tell us at abuse [at] ccgenerator [dot] org. We take these reports seriously and will cooperate with legitimate law enforcement requests.\nInclude a URL, a screenshot, or a copy of the message if you can. We investigate every report, block access where we are able to, and respond to lawful requests from payment networks and law enforcement. This tool was built for engineers, and we would rather hear about misuse than not.\nCorrections and factual accuracy Payment standards change, and we get things wrong sometimes. If you spot an error in a guide, a BIN range, or a technical explanation, tell us at the editorial address — and please include a source if you have one, such as an ISO standard, an EMVCo or PCI SSC publication, or a card network\u0026rsquo;s own documentation.\nWe check reported errors against primary sources, correct what needs correcting, and note substantive changes on the page with the date. Our editorial policy describes how content is written, reviewed, and updated.\nLegal and takedown For copyright, trademark, or other legal notices, write to the legal address and include:\nYour name and the organisation you represent, if any The exact URL of the page or material at issue What right you hold and the basis for the claim Contact details we can reply to A statement that you believe in good faith the use is not authorised Complete notices get a substantive reply. We would usually rather fix a problem than argue about it, so tell us what outcome you are looking for.\nResponse times Type of message We aim to respond within Abuse and misuse reports 48 hours General questions, feedback, bug reports 2–3 business days Content corrections 5 business days Legal and takedown notices 5 business days Privacy and data requests 30 days (the GDPR and CCPA limit) We reply to every legitimate message. If a week has gone by with no answer, it is worth checking your spam folder and then writing again — occasionally a reply does not get through.\n","permalink":"https://ccgenerator.org/contact/","summary":"CC Generator is run by a small independent team, and we read everything that comes in. There is no contact form here — the site is fully static, with no server to receive one — so email is the way to reach us. Pick the address that matches your subject and you will get to the right person faster.\nMost messages get a reply within 2–3 business days. Privacy requests and abuse reports have their own timelines, listed at the bottom of this page.","title":"Contact"},{"content":"Building a checkout that shows a card preview as the user types? This tool renders a card mockup image from the values you enter, so you can prototype the component, check your layout, or drop a placeholder into a design.\nEvery image is watermarked as a test card and uses generic network styling rather than real brand marks. It is a UI asset, not a card.\nWatermarked mockup\nCard Mockup Generator Renders a card preview at correct ISO/IEC 7810 proportions, in your browser. Every image carries a test-card watermark and generic network styling.\nCard number Cardholder name Expiry Security code Network label Generic Network A Network B Debit Credit Colour Slate Indigo Teal Amber Rose Side Front Back Number display Masked — last 4 only Show all digits The watermark is part of the image and cannot be switched off. Network styling is generic — no real brand marks are used, because those are trademarks with their own licence terms. Images render in your browser and are never uploaded or stored. Download SVG Download PNG All Cards Visa Mastercard Amex Discover JCB Diners Maestro UnionPay Troy These are test numbers, not real cards Every number on this page is synthetic test data. It is generated by a formula, not issued by a bank. These numbers are not linked to any person, account, or balance. They carry no funds. They will be declined by every real payment processor. They only pass client-side format and checksum validation. Attempting to use card data to obtain goods, services, or trials you have not paid for is fraud in virtually every jurisdiction. Do not do it. Generation runs entirely in your browser. Nothing is sent to or stored on our servers. Intended use: payment form validation, checkout UI testing, QA test fixtures, and developer demos. For processor-specific behaviour (approvals, declines, refunds, 3-D Secure) use your gateway's official sandbox test cards.\nCard layout anatomy Payment cards are one of the most tightly standardised objects most people carry, which is good news if you are drawing one.\nGeometry. ISO/IEC 7810 defines the ID-1 format: 85.60 × 53.98 mm, 0.76 mm thick, with a corner radius specified as a range of 2.88 to 3.48 mm — 3.18 mm is the value normally quoted. Every payment card in the world uses it, which is why they all fit the same wallet slot and the same terminal. The ratio that follows is 1.586:1.\nThe front carries the EMV chip at a standardised position — roughly 19 mm from the left edge and 22 mm from the top — the contactless symbol, the primary account number, the expiry date, the cardholder name, and the network mark, usually bottom-right or top-right. Numbers were traditionally embossed for imprinting machines; most modern cards print them flat, and many now move them to the back entirely.\nThe back carries the magnetic stripe across the top, the signature panel, and the security code — printed on the panel for every network except American Express, which puts a four-digit code on the front. Issuer contact details usually sit below.\nFor a component, the only two numbers you need are the ratio and the radius:\n.card-preview { aspect-ratio: 1.586 / 1; border-radius: 3.7%; /* 3.18mm / 85.60mm */ } Expressing the radius as a percentage rather than pixels is the part people miss. A fixed border-radius: 12px looks right at one size and wrong at every other, and card previews are almost always responsive.\nBuilding a card preview component A few things worth getting right, roughly in the order they cause problems.\nFormat the number as it is typed. Group digits as the user goes, and use the detected brand to decide the grouping — 4-4-4-4 for most networks, 4-6-5 for American Express, 4-6-4 for a 14-digit Diners card. A preview that regroups mid-typing feels broken; one that never regroups is wrong for a third of cards.\nChange styling on brand detection, not on submit. The preview should react within the first few keystrokes, because that immediate feedback is the entire reason the component exists.\nFlip to the back when the security code gets focus. It is a genuinely useful affordance — it tells the customer where to look — and it is the one animation on a checkout page nobody objects to. Keep it short and respect prefers-reduced-motion.\nMark the preview as decorative. This is the accessibility point most implementations miss:\n\u0026lt;div class=\u0026#34;card-preview\u0026#34; aria-hidden=\u0026#34;true\u0026#34;\u0026gt; \u0026lt;div class=\u0026#34;card-preview__chip\u0026#34;\u0026gt;\u0026lt;/div\u0026gt; \u0026lt;div class=\u0026#34;card-preview__number\u0026#34;\u0026gt;•••• •••• •••• 4567\u0026lt;/div\u0026gt; \u0026lt;div class=\u0026#34;card-preview__meta\u0026#34;\u0026gt; \u0026lt;span\u0026gt;TEST CARDHOLDER\u0026lt;/span\u0026gt; \u0026lt;span\u0026gt;08/29\u0026lt;/span\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;/div\u0026gt; The preview duplicates information that already exists in the form fields. Left exposed, a screen reader announces every value twice — once as the field, once as the picture of the field — which turns a helpful visual into noise. aria-hidden=\u0026quot;true\u0026quot; on the container fixes it. The real content lives in the inputs, properly labelled.\nNever render the full number, even in preview. Last four digits are enough to reassure someone they typed the right card. Showing all sixteen puts the number on screen for anyone standing behind them, and screenshots of checkout pages end up in bug reports, support tickets and screen recordings far more often than anyone plans for. The tool above masks by default for the same reason.\nWhat breaks when real data arrives Card preview components are almost always built with one example: a sixteen-digit number and a short Latin name. Four inputs will break that layout, and all four are ordinary:\nA nineteen-digit number. Visa, Discover, UnionPay and Maestro all permit them. Three extra digits overflow a field sized for sixteen, or shrink the font to something unreadable. A fourteen-digit number. Diners Club classic cards. The opposite failure — a mask built for sixteen leaves a gap where digits should be. A long cardholder name. MARIA-ISABEL FERNÁNDEZ RODRÍGUEZ is a perfectly normal name and roughly twice the width of JANE SMITH. Decide in advance whether to truncate, shrink or wrap, because the default is usually to overflow silently. Non-Latin characters. Accented and non-Latin names have to render, not turn into boxes, and right-to-left names change the layout direction of the whole line. The test identity generator produces accented names for exactly this reason. Test the component with all four before it ships. Each takes seconds and each is the sort of thing that reaches production because nobody typed anything unusual.\nWhy we watermark every image A convincing card image has exactly one use beyond design work: making someone believe a card exists that does not. That shows up in marketplace scams, fake payment confirmations, and social engineering. So every image this tool produces carries a watermark that cannot be turned off, uses generic network styling rather than real brand marks, and defaults to a masked number.\nIf you need an unwatermarked card visual for a legitimate design deliverable, build it in your design tool with your own artwork. We are not the right source for that, and we would rather be useless for the bad case than convenient for it.\nTwo implementation details make that more than a promise. The watermark is drawn into the SVG itself rather than layered over a preview, so it is present in both the SVG and PNG exports — there is no code path that produces an image without it. And PNG export is capped at 1200 pixels wide: enough for any screen mockup, well short of print quality.\nBrand marks and trademark Visa, Mastercard, American Express and every other network mark is a registered trademark. The networks publish brand guidelines covering how their marks may be reproduced — minimum sizes, clear space, approved colourways, and which contexts require permission. Using them on something that could be mistaken for a real card is squarely outside what those guidelines allow.\nThis tool sidesteps the question by rendering a generic wordmark you choose from a short list. If your mockup genuinely needs a real network mark — a merchant site showing accepted payment methods, for instance, which is a normal and permitted use — get the artwork from the source and follow the terms:\nVisa Brand Center Mastercard Brand Center The same applies to bank names and logos, which this tool does not offer at all. A card mockup carrying a real bank\u0026rsquo;s identity is a different object from a design placeholder, whatever it was intended for.\nRelated tools and guides Populate a mockup with a properly formed number from the all-network generator, or take a Visa number if you want a specific brand\u0026rsquo;s shape. The validator confirms any number you paste in. The tool directory lists everything else, and the FAQ covers what a Luhn-valid number does and does not prove.\nFrequently Asked Questions What size is a credit card? 85.60 by 53.98 millimetres, defined as ID-1 in ISO/IEC 7810 — the same format as most national ID cards and driving licences. The corner radius is specified as a range from 2.88 to 3.48 mm, with 3.18 mm the usual nominal value, and the thickness is 0.76 mm. For screen work the number that matters is the aspect ratio: 1.586 to 1. Can I remove the watermark? No, deliberately. There is no control for it and no code path that omits it — it is drawn into the SVG on every render, so it survives both the SVG and PNG exports. A card image without one has a use we would rather not serve, and that is explained in full below. Can I use real Visa or Mastercard logos? Not from here. Network brand marks are registered trademarks with published usage guidelines, and using them on anything resembling a real product requires permission. This tool renders a generic wordmark instead. If your design genuinely needs a network mark, take it from the network\u0026rsquo;s own brand centre and follow their terms. Is the aspect ratio the same for all cards? Yes. Every payment card follows ID-1, which is why cards from different banks and networks stack neatly and fit the same wallet slots and terminals. Design and materials vary; geometry does not. That makes 1.586:1 a safe constant for any card component you build. Can I use these images in my app? As a mockup or prototype asset, yes — that is what they are for. As a representation of a real card in a production interface, no. If your app shows a customer their own card, render it from your own data with the last four digits and the brand you got from your processor, rather than pasting in a generated picture. Do you store the images I generate? No. The SVG is built in your browser from the values in the form, and export writes a file directly from that markup. Nothing is sent to a server, so there is nothing on our side to store — you can confirm it in your browser\u0026rsquo;s network tab while you type. ","permalink":"https://ccgenerator.org/credit-card-image-generator/","summary":"Building a checkout that shows a card preview as the user types? This tool renders a card mockup image from the values you enter, so you can prototype the component, check your layout, or drop a placeholder into a design.\nEvery image is watermarked as a test card and uses generic network styling rather than real brand marks. It is a UI asset, not a card.\nWatermarked mockup\nCard Mockup Generator Renders a card preview at correct ISO/IEC 7810 proportions, in your browser.","title":"Credit Card Mockup Generator — UI Previews"},{"content":" Test card only\nCredit Card Number Generator Generate dummy card details for development and QA. Nothing is stored or sent to a server.\nSingle card Bulk cards Card network Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Generate Card Card network All Mixed Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Quantity Generate Cards These numbers are dummy, Luhn-valid test values for software testing only. They are not real active cards and cannot be used for payments. Copy all Show JSON Copy JSON Export JSON Export CSV JSON output All Cards Visa Mastercard Amex Discover JCB Diners Maestro UnionPay Troy These are test numbers, not real cards Every number on this page is synthetic test data. It is generated by a formula, not issued by a bank. These numbers are not linked to any person, account, or balance. They carry no funds. They will be declined by every real payment processor. They only pass client-side format and checksum validation. Attempting to use card data to obtain goods, services, or trials you have not paid for is fraud in virtually every jurisdiction. Do not do it. Generation runs entirely in your browser. Nothing is sent to or stored on our servers. Intended use: payment form validation, checkout UI testing, QA test fixtures, and developer demos. For processor-specific behaviour (approvals, declines, refunds, 3-D Secure) use your gateway's official sandbox test cards.\nThis credit card number generator produces Luhn-valid dummy numbers across every card network the site supports, in one place. If you need a single brand, the network pages linked below are narrower; this page is the full reference — every prefix range, every length rule, and what each part of a card number actually encodes.\nHow to generate test card numbers Choose single or bulk mode. The Single card tab returns one number at a time. The Bulk cards tab produces a batch in one run. Pick a card network. Visa, Mastercard, Amex, Troy, Discover, JCB, Diners Club, or Maestro. In bulk mode, All draws from every network and Mixed uses the four most commonly tested — Visa, Mastercard, Amex, and Troy. Set how many numbers you need. Bulk mode accepts a quantity between 2 and 25. Generate. Each result carries a card number, an expiry month and year, a CVV or CVC of the correct length for that network, and a placeholder cardholder name. Copy or export. Copy one number, use Copy all for the batch, or take the whole set out with Export CSV or Export JSON. Card number formats by network This table is the published specification for each network, not a description of what this page emits — see the note underneath.\nNetwork IIN / BIN prefix Total length Check digit Security code Code length Visa 4 13, 16, 19 Luhn CVV2 3 Mastercard 51–55, 2221–2720 16 Luhn CVC2 3 American Express 34, 37 15 Luhn CID 4 Discover 6011, 622126–622925, 644–649, 65 16, 19 Luhn CID 3 JCB 3528–3589 16–19 Luhn CAV2 3 Diners Club Int\u0026rsquo;l 36, 38, 39, 300–305, 3095 14–19 Luhn CVV 3 Maestro 50, 56–69 12–19 Luhn CVC2 3 UnionPay 62, 81 16–19 Luhn* CVN2 3 Troy 9792 16 Luhn CVV 3 * UnionPay is the exception worth knowing about. Cards issued on some UnionPay BIN ranges do not carry a Luhn-valid check digit, so a validator that rejects every non-Luhn number will refuse legitimate UnionPay cards. If you accept UnionPay, treat the Luhn test as advisory for 62 and 81 rather than as a hard gate.\nWhat this generator emits. Where a network permits several lengths, the tool picks the one in general circulation: 16 digits for Visa, Mastercard, Discover, JCB, and Troy, 15 for American Express, 14 for Diners Club, and 16 or 19 for Maestro. UnionPay is documented here for reference but is not one of the picker\u0026rsquo;s options. If you need to exercise the rarer lengths — 13-digit Visa, 19-digit Discover — construct those by hand; the checksum calculation is the same.\nEach network also has its own page, which is the faster route when a test needs one brand: Visa, Mastercard, American Express, and Troy. Discover, JCB, Diners Club, Maestro and UnionPay have their own pages too, each covering the quirk that makes that network break code — the tool directory lists all nine.\nWhat each part of a card number means A card number is not an opaque blob of digits. It decomposes into four fields, and knowing which is which is what lets you write BIN routing that behaves:\n4 5 3 9 1 4 8 8 0 3 4 3 6 5 7 4 └──────┬────────┘ └───────────┬────────────┘ └┬┘ │ │ │ │ │ └── Check digit (Luhn) │ └──────────────────── Individual Account Identifier └───────────────────────────────────────────── IIN / BIN (first 6–8 digits) ↑ └─ MII (Major Industry Identifier), the first digit MII — Major Industry Identifier. The first digit alone tells you the issuing industry: 3 is travel and entertainment (Amex, Diners, JCB), 4 and 5 are banking and finance (Visa, Mastercard), 6 is merchandising and banking (Discover, Maestro, UnionPay). It is the coarsest possible classification and never sufficient on its own.\nIIN / BIN — Issuer Identification Number. Historically the first six digits, identifying the institution that issued the card. Under ISO/IEC 7812-1:2017 the IIN was extended to eight digits, because the six-digit space ran out. Both lengths are in circulation. Lookup code that slices number.substring(0, 6) and stops there will misattribute cards issued on eight-digit IINs — a live source of routing bugs.\nIndividual Account Identifier. Everything between the IIN and the final digit, identifying the specific account at that issuer. Its length is whatever the total length leaves over, which is why it varies from card to card.\nCheck digit. The last digit, computed with the Luhn algorithm over everything before it.\nFor the field-by-field detail see the guide to card number structure and the BIN and IIN reference.\nThe Luhn algorithm The Luhn checksum, standardised in ISO/IEC 7812-1 annex B, catches single-digit typos and most adjacent transpositions. Working right to left, double every second digit, subtract 9 from any result above 9, sum everything, and a valid number sums to a multiple of 10.\nFor 4539 1488 0343 6574 the digits sum to 80, which is divisible by 10, so the number passes. Here is the check as code:\nfunction isLuhnValid(number) { const digits = number.replace(/\\D/g, \u0026#39;\u0026#39;).split(\u0026#39;\u0026#39;).reverse().map(Number); const sum = digits.reduce((acc, d, i) =\u0026gt; { if (i % 2 === 0) return acc + d; const doubled = d * 2; return acc + (doubled \u0026gt; 9 ? doubled - 9 : doubled); }, 0); return sum % 10 === 0; } isLuhnValid(\u0026#39;4539 1488 0343 6574\u0026#39;); // true — spaces are stripped isLuhnValid(\u0026#39;4539 1488 0343 6575\u0026#39;); // false — check digit tampered isLuhnValid(\u0026#39;3056 930902 5904\u0026#39;); // true — 14-digit Diners Club The i % 2 === 0 test is where most hand-rolled implementations go wrong: after reversing, index 0 is the check digit itself and must not be doubled. Double the wrong alternating set and half of all valid numbers will fail. The full walkthrough, including the check-digit calculation lives in the guides.\nTesting scenarios this tool covers Input formatting. American Express groups as 4-6-5 over 15 digits; almost everything else is 4-4-4-4 over 16. Generate one of each and confirm your mask switches rather than forcing four-digit groups onto a 15-digit number.\nBrand detection. The logo should change off the first one to four digits, as the user types. Mastercard\u0026rsquo;s 2221–2720 range is the usual failure: detection written before 2017 only recognises 51–55.\nCVV field length. Four digits on Amex, three everywhere else. This is among the most frequently missed cases, and it is immediately visible to users when wrong.\nLength validation. Accept the full 12–19 range rather than hard-coding 16. A 19-digit Maestro number such as 5018 1234 5678 9012 344 is valid and will be rejected by a length === 16 check.\nLuhn rejection. Take any generated number, change the last digit, and confirm the form rejects it. A form that accepts both is not running the checksum at all.\nBulk data. Export 25 rows as CSV and run them through a database import or a fixture loader to check column mapping, encoding, and how leading zeros in the expiry month survive the round trip.\nPAN masking. Confirm that logs, error reports, and analytics payloads show only the last four digits. PCI DSS Requirement 3.3 covers masking of the primary account number when displayed; testing it with synthetic data keeps genuine card data out of the exercise entirely.\nBulk generation and export Bulk mode returns between 2 and 25 cards per run. Export CSV writes one row per card with these columns:\nCard type, Card number, Expiration month, Expiration year, CVV/CVC, Cardholder name, Status Export JSON writes the same records as an array of objects, which is usually the more convenient shape to drop straight into a fixtures file. Show JSON displays the payload in the page first if you just want to copy a fragment.\nCardholder names are obvious placeholders — Alex Tester, Jordan Example, Taylor Sandbox and similar — chosen so that a name from this tool can never be mistaken for a real person\u0026rsquo;s in a bug report or a screenshot. For larger fixture sets, the bulk generator produces up to ten thousand records at a time, with reproducible seeds and a configurable share of deliberately invalid rows.\nLimitations — what this tool does not do Being precise about this matters more than the feature list:\nIt does not validate against real BIN tables. A generated prefix obeys its network\u0026rsquo;s published rules, but the specific BIN may belong to no issuer at all. It does not simulate payment processor behaviour. No authorisation, no approval code, no decline reason. Nothing is submitted anywhere. It does not produce 3-D Secure or SCA flows. Those require a gateway that recognises the number and a directory server that will respond to it. It cannot tell you whether a card exists. No offline tool can. Existence is a fact held in an issuer\u0026rsquo;s database, not a property recoverable from the digits. When your test needs the processor\u0026rsquo;s behaviour rather than your own code\u0026rsquo;s, switch to your gateway\u0026rsquo;s published sandbox cards — Stripe and PayPal both document theirs in full, and we collect the equivalents on the test card numbers reference. The FAQ covers what a Luhn-valid number does and does not prove.\nFrequently Asked Questions How many digits should a credit card number have? Between 12 and 19, depending on the network. Visa, Mastercard, Discover, JCB, and Troy are usually 16; American Express is 15; Diners Club is commonly 14. ISO/IEC 7812 caps the total at 19 digits, which is why a well-written input field allows up to 19 rather than hard-coding 16. Why do some Visa cards have 13 digits and others 16? Visa\u0026rsquo;s specification permits 13, 16, and 19 digits. The 13-digit format is legacy and rare in the field today, but validation code that assumes exactly 16 will reject cards that are perfectly valid. This generator emits 16-digit Visa numbers, which is what nearly all issued Visa cards use. What is the difference between CVV, CVC, CID, and CVV2? They are the same idea under different brand names: Visa calls it CVV2, Mastercard CVC2, American Express CID, Discover CID, JCB CAV2, and UnionPay CVN2. What matters in code is the length — four digits on American Express, three on everything else. Can I use these numbers with Stripe or PayPal? Not for anything that returns an authorisation. Stripe and PayPal recognise their own published sandbox numbers and reject everything else, so use theirs to test approvals, declines, and 3-D Secure. Use these numbers to test your own form, validation, and fixtures. Does the generator produce the same number twice? It can, in the same way any random process can repeat itself, though the odds are remote across the account-identifier space. Numbers are drawn from the browser\u0026rsquo;s crypto.getRandomValues(), so batches are not derived from a seed or a sequence. If your tests need guaranteed-unique values, deduplicate after export. Are the BIN prefixes real? The prefixes follow the published IIN ranges assigned to each card network, so a generated Visa number starts with 4 the way an issued one does. But the specific 6- to 8-digit BIN may or may not correspond to an actual issuing bank, and the account portion is random. Nothing here is drawn from an issuer database. Can I generate a card for a specific bank? No, and deliberately so. Targeting a named issuer\u0026rsquo;s BIN would mean reproducing that issuer\u0026rsquo;s real prefix ranges, which is the point at which synthetic test data starts to resemble a tool for impersonating a specific bank. The generator picks network-valid prefixes only. Is bulk generation limited? Yes, to 25 numbers per run. Everything is generated in the browser, and the limit keeps the page responsive. For a larger fixture set, export a few batches and concatenate the CSV files. ","permalink":"https://ccgenerator.org/credit-card-number-generator/","summary":"Test card only\nCredit Card Number Generator Generate dummy card details for development and QA. Nothing is stored or sent to a server.\nSingle card Bulk cards Card network Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Generate Card Card network All Mixed Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Quantity Generate Cards These numbers are dummy, Luhn-valid test values for software testing only. They are not real active cards and cannot be used for payments.","title":"Credit Card Number Generator for Testing"},{"content":"Paste a card number and this tool tells you whether it is correctly formatted: whether the Luhn check digit is right, which network the prefix belongs to, and whether the length matches that network\u0026rsquo;s rules. Everything runs in your browser.\nIt does not tell you whether a card is real, active, or has funds. Nothing on the open internet can tell you that, and a tool that claimed to would be doing something illegal. We explain the difference below.\nRuns in your browser\nCard Number Validator Checks the Luhn check digit, the network prefix and the length. The number is never sent anywhere and is not stored.\nCard number Format validation only. A well-formed number is not a real card, and nothing here can tell you whether a card exists, is active, or has funds. All Cards Visa Mastercard Amex Discover JCB Diners Maestro UnionPay Troy These are test numbers, not real cards Every number on this page is synthetic test data. It is generated by a formula, not issued by a bank. These numbers are not linked to any person, account, or balance. They carry no funds. They will be declined by every real payment processor. They only pass client-side format and checksum validation. Attempting to use card data to obtain goods, services, or trials you have not paid for is fraud in virtually every jurisdiction. Do not do it. Generation runs entirely in your browser. Nothing is sent to or stored on our servers. Intended use: payment form validation, checkout UI testing, QA test fixtures, and developer demos. For processor-specific behaviour (approvals, declines, refunds, 3-D Secure) use your gateway's official sandbox test cards.\nA note if you are validating a real card number. This page runs entirely in your browser and the number you paste is never transmitted or stored. That said, browser extensions can read page content, so close the tab afterwards. For real card data, your bank\u0026rsquo;s own tools are the safer place.\nWhat this validator checks Four checks, and it is worth being explicit about the gap between what each one proves and what people assume it proves:\nCheck What it means What it does not mean Luhn check digit The last digit is mathematically consistent with the rest The number belongs to a real card Network prefix The number starts within a published IIN range The prefix is assigned to an active issuer Length The digit count matches that network\u0026rsquo;s rules The card was ever issued Character set Only digits, in a valid count Anything at all about the account The right-hand column is the whole story. Every check here is a statement about the digits. None of them reaches outside the page, because there is nothing outside the page to reach.\nValidator vs checker: why we only do one The two words get used interchangeably, and they describe completely different things:\nValidator (this page) \u0026ldquo;Checker\u0026rdquo; What it does Checks format and the Luhn checksum Tests whether a card is active How Arithmetic, offline, in your browser Sends the card to a payment network Legitimate Yes — every payment form does this No Whose card Test data you typed yourself Usually a stolen card list A validator answers a question about the number itself: is it well-formed? That is a pure arithmetic question, and it is exactly what every payment form runs before it submits anything — it saves the user a round-trip when they have simply mistyped a digit.\nA \u0026ldquo;checker\u0026rdquo; answers a question about someone\u0026rsquo;s account: is this card active? Answering that requires sending the card to a payment network, which means either attempting a small transaction or abusing an authorisation endpoint. When it is your own card, your bank\u0026rsquo;s app already tells you. When it is not your own card, running that check is unauthorised access, and the tools that do it exist to sort stolen card lists.\nWe build the first. We will not build the second.\nThe Luhn algorithm The rule is short enough to state completely. Walking right to left, double every second digit; if doubling takes a digit above nine, subtract nine. Sum everything. A valid number totals a multiple of ten.\nfunction validateLuhn(pan) { const digits = pan.replace(/\\D/g, \u0026#39;\u0026#39;); if (digits.length \u0026lt; 12 || digits.length \u0026gt; 19) { return { valid: false, reason: \u0026#39;length out of range (12-19)\u0026#39; }; } let sum = 0; let double = false; for (let i = digits.length - 1; i \u0026gt;= 0; i--) { let d = Number(digits[i]); if (double) { d *= 2; if (d \u0026gt; 9) d -= 9; } sum += d; double = !double; } return { valid: sum % 10 === 0, checksum: sum }; } Note that doubling starts at false, because the rightmost digit is the check digit and is never doubled. Getting that flag backwards is the classic Luhn bug, and it produces a function that passes exactly the numbers it should reject.\nTo tell a user what went wrong rather than just that something did, compute the digit the checksum expected. Here the flag starts at true, because the position the check digit will occupy is not part of the input:\nfunction expectedCheckDigit(panWithoutCheck) { let sum = 0; let double = true; for (let i = panWithoutCheck.length - 1; i \u0026gt;= 0; i--) { let d = Number(panWithoutCheck[i]); if (double) { d *= 2; if (d \u0026gt; 9) d -= 9; } sum += d; double = !double; } return (10 - (sum % 10)) % 10; } That second function is what turns \u0026ldquo;invalid card number\u0026rdquo; into \u0026ldquo;the last digit should be 4\u0026rdquo; — and it is also how every number from the all-network generator is completed.\nOne property worth knowing before you rely on it: Luhn catches every single-digit error and almost every transposition of adjacent digits, but it misses transposing 09 and 90. It is a typo filter with known gaps, not a proof of anything.\nImplementations in other languages Python:\ndef luhn_valid(pan: str) -\u0026gt; bool: digits = [int(c) for c in pan if c.isdigit()] checksum = 0 for i, d in enumerate(reversed(digits)): if i % 2 == 1: d *= 2 if d \u0026gt; 9: d -= 9 checksum += d return checksum % 10 == 0 PHP:\nfunction luhn_valid(string $pan): bool { $digits = preg_replace(\u0026#39;/\\D/\u0026#39;, \u0026#39;\u0026#39;, $pan); $sum = 0; $double = false; for ($i = strlen($digits) - 1; $i \u0026gt;= 0; $i--) { $d = (int) $digits[$i]; if ($double) { $d *= 2; if ($d \u0026gt; 9) { $d -= 9; } } $sum += $d; $double = !$double; } return $sum % 10 === 0; } The shape is identical in every language because the algorithm has no room for interpretation: iterate from the right, alternate the doubling, sum, take the total modulo ten. Java, C#, Go and Ruby versions follow the same structure, and the algorithm guide works through why it behaves the way it does.\nWhere Luhn validation belongs in your form Five pieces of advice that between them cover most of what goes wrong:\nRun it on blur, or when the expected length is reached — not on every keystroke. A number is invalid for almost its entire typing lifetime. Showing an error at digit four trains people to ignore your errors. Write the message for a person, not a specification. \u0026ldquo;Please check your card number\u0026rdquo; is right. \u0026ldquo;Invalid Luhn checksum\u0026rdquo; tells the user nothing they can act on, and it leaks implementation detail into your UI. Warn, do not block. Let the form submit anyway. Ranges change, new BINs appear, and the occasional card really does behave unexpectedly — a hard client-side block converts every one of those into an abandoned checkout for no gain. Validate server-side as well. Anything enforced only in the browser is not enforced. The client check is for the user\u0026rsquo;s benefit; the server check is for yours. Never treat it as fraud detection. Luhn catches typing errors. It says nothing about whether the card exists, who holds it, or whether the transaction is legitimate. That judgement belongs to your processor\u0026rsquo;s risk engine. The same reasoning applies to an unrecognised prefix, which is why this validator reports it as unknown rather than invalid. New BIN ranges are assigned continuously and any list of prefixes starts going stale the day it is written — Mastercard\u0026rsquo;s 2-series is the standing example, still rejected by validation written against ^5[1-5] years after those cards entered circulation. Detect the brand when you can, fall back gracefully when you cannot, and let the authorisation decide.\nFor which lengths and prefixes to accept per network, the Visa, Mastercard and American Express pages carry the format tables — Visa alone permits 13, 16 and 19 digits, which is the length rule most often written too narrowly.\nTesting your validation Two sources of input, for two different jobs. Generate synthetic numbers here or with the BIN generator to exercise your format rules, including deliberately broken cases: change one digit of a valid number and confirm your code rejects it and reports the expected digit. When you need the processor to respond rather than your own code, switch to the test card numbers reference — Stripe publishes a number that fails Luhn on purpose, 4242 4242 4242 4241, precisely so you can test the branch where your own validation should have caught the input first.\nThe tool directory lists everything else, and the FAQ covers what a Luhn-valid number does and does not prove.\nFrequently Asked Questions What does the Luhn algorithm check? That the final digit of a card number is arithmetically consistent with the digits before it. Every other digit is doubled from the right, digits over nine have nine subtracted, everything is added up, and the total must be a multiple of ten. It is a checksum designed in the 1950s to catch mistyped and transposed digits, and that is the whole of what it does. Does a Luhn-valid number mean the card is real? No. Luhn validity is a property of the digits, not evidence of an account. Any number can be made Luhn-valid by choosing the right last digit, which is exactly how every test number on this site is produced. A real card is Luhn-valid; a Luhn-valid number is very probably not a real card. Can this tool tell me if a card is active? No, and it never will. Answering that requires sending the number to a payment network, which means either attempting a transaction or abusing an authorisation endpoint. For your own card, your bank\u0026rsquo;s app already tells you. For anyone else\u0026rsquo;s, it is unauthorised access. Tools that offer this exist to sort stolen card lists, and we are not building one. Is my card number sent to your server when I validate it? No. The validation is arithmetic performed by JavaScript in your browser, and there is no network request involved. You do not have to take our word for it: open your browser\u0026rsquo;s developer tools, switch to the Network tab, and type a number into the field. Nothing is sent. The value is also not written to local storage, so a reload discards it. Why does my valid card fail Luhn validation here? Almost always a mistyped or transposed digit — that is precisely the error Luhn was designed to catch. When the check fails we show which digit the checksum expected, so comparing it against the card usually locates the mistake immediately. If the number is definitely correct, check that you have not dropped a leading digit when copying. Do all card networks use Luhn? Effectively all of them today. The check digit is part of ISO/IEC 7812, and Visa, Mastercard, American Express, Discover, JCB and UnionPay all issue Luhn-valid numbers. UnionPay is the interesting footnote: some cards issued in the mid-2010s did not carry a valid check digit, which is one reason a failed Luhn check should warn rather than block. Should I use Luhn validation in production? Yes, as a courtesy to the user, and never as a gate. Running it client-side saves someone a failed authorisation when they have simply mistyped a digit. Treating it as authoritative is the mistake: it tells you nothing about whether a card exists, and a hard block turns any edge case into a lost sale. Warn, allow submission, and let the processor make the real decision. ","permalink":"https://ccgenerator.org/credit-card-validator/","summary":"Paste a card number and this tool tells you whether it is correctly formatted: whether the Luhn check digit is right, which network the prefix belongs to, and whether the length matches that network\u0026rsquo;s rules. Everything runs in your browser.\nIt does not tell you whether a card is real, active, or has funds. Nothing on the open internet can tell you that, and a tool that claimed to would be doing something illegal.","title":"Credit Card Validator — Luhn Checker"},{"content":"This tool produces random 3- or 4-digit security codes for test data. It is worth being precise about what that means, because most people searching for a \u0026ldquo;CVV generator\u0026rdquo; want something else: a way to work out the CVV that belongs to a particular card number.\nThat is not possible. Not with this tool, not with any tool. A CVV is computed by the issuing bank from the card number, the expiry date, the service code, and two secret cryptographic keys that only the issuer holds. Without those keys there is no calculation to perform — and there is no shortcut, no leaked algorithm, and no lookup table. This is by design; it is the entire reason the code exists.\nTest data only\nCVV Generator Random security codes at the right length for the network you pick. Generated in your browser, from nothing but a random number source.\nNetwork Visa — CVV2, 3 digits Mastercard — CVC2, 3 digits American Express — CID, 4 digits Discover — CID, 3 digits JCB — CAV2, 3 digits UnionPay — CVN2, 3 digits Diners Club — CVV, 3 digits Troy — CVV, 3 digits Quantity Generate Codes may repeat. Three digits give a thousand possibilities, so a batch of any size will contain duplicates — that is what randomness looks like, not a bug. These are random digits for test data only. They are not the security code of any card, and no tool can produce that. Copy all Export CSV All Cards Visa Mastercard Amex Discover JCB Diners Maestro UnionPay Troy These are test numbers, not real cards Every number on this page is synthetic test data. It is generated by a formula, not issued by a bank. These numbers are not linked to any person, account, or balance. They carry no funds. They will be declined by every real payment processor. They only pass client-side format and checksum validation. Attempting to use card data to obtain goods, services, or trials you have not paid for is fraud in virtually every jurisdiction. Do not do it. Generation runs entirely in your browser. Nothing is sent to or stored on our servers. Intended use: payment form validation, checkout UI testing, QA test fixtures, and developer demos. For processor-specific behaviour (approvals, declines, refunds, 3-D Secure) use your gateway's official sandbox test cards.\nHow a real CVV is actually generated The process is not secret. It is documented in payment hardware manuals and implemented in every issuer\u0026rsquo;s card-management system. Knowing it does not help you derive anything, and seeing why is the most useful thing on this page.\nThe inputs\nThe primary account number — the card number itself The expiry date The service code, three digits that encode how the card may be used: whether it works internationally, whether a chip must be used where available, whether a PIN is required The keys\nA pair of Card Verification Keys, held in the issuer\u0026rsquo;s hardware security module The pair belongs to the issuer, typically per BIN range rather than per card They never leave the HSM. Not to an application, not to a backup, not to staff The process, at a level that explains without enabling\nThe account number, expiry and service code are concatenated into a fixed-width block. That block is encrypted under the key pair using Triple DES. Digits are filtered out of the result. The first three of them — four for American Express — are the security code. Every input except the keys is printed on the card. The keys are what make the code unforgeable. That is the whole security model: anyone can read your card number, but only your bank can compute the code that goes with it.\nCVV1, CVV2 and iCVV The same machinery produces three different values, and confusing them is a real source of integration bugs:\nCVV1 is encoded in the magnetic stripe. It travels with a swipe and proves the stripe is genuine rather than written by hand. CVV2 is the code printed on the card. It never appears in the stripe or the chip, which is precisely why quoting it is treated as weak evidence that someone held the card. iCVV lives in the EMV chip and is deliberately different from CVV1, so data lifted from a chip transaction cannot be replayed as a counterfeit magnetic stripe. What separates them is the service code fed into the calculation, not the algorithm. That detail is why a system that validates one of them against another\u0026rsquo;s expected value rejects perfectly good cards — and why \u0026ldquo;the CVV\u0026rdquo; is an ambiguous phrase in any specification that does not say which one it means.\nNetwork naming Network Name Digits Location Visa CVV2 3 Back, signature panel Mastercard CVC2 3 Back, signature panel American Express CID 4 Front, right of the card number Discover CID 3 Back JCB CAV2 3 Back UnionPay CVN2 3 Back Diners Club CVV 3 Back Troy CVV 3 Back The American Express row is the one that breaks forms. A field with maxlength=\u0026quot;3\u0026quot; silently truncates a valid CID, the payment fails verification, and the error surfaces as a generic decline that nobody traces back to the input. Length must follow brand detection, and brand detection has to run as the user types rather than on submit. Visa and Troy are three digits, as is everything else in the table.\nWhy you cannot derive a CVV Four beliefs come up repeatedly. All four are wrong, and each is wrong for a different reason.\n\u0026ldquo;There is an algorithm, it is just secret.\u0026rdquo; The algorithm is public. It is described in HSM documentation and implemented in commercial card-management software. Secrecy lives entirely in the keys, which is the correct place for it — a system whose security depends on the algorithm staying hidden is broken by definition. Knowing the steps gets you nowhere without the key pair.\n\u0026ldquo;There must be a formula, like Luhn.\u0026rdquo; No. Luhn is a checksum: it takes only the number as input, contains no secret, and anyone can compute it — which is why it catches typing errors and stops nothing else. A security code is closer to a message authentication code. It exists specifically so that possessing the number is not enough to produce it.\n\u0026ldquo;You could brute-force it.\u0026rdquo; Three digits is a thousand possibilities, which sounds tractable and is not. Issuers block a card after a handful of wrong codes, acquirers and networks rate-limit and score repeated attempts, and the pattern is one of the most heavily monitored signals in card fraud detection. Beyond the mechanics: attempting it against someone else\u0026rsquo;s card is unauthorised access, and it is a criminal offence in essentially every jurisdiction.\n\u0026ldquo;Leaked data sets contain CVVs.\u0026rdquo; PCI DSS prohibits storing the security code after authorisation — not \u0026ldquo;prohibits storing it unencrypted\u0026rdquo;, prohibits storing it at all. In version 4 this is Requirement 3.3.1, which was Requirement 3.2 under version 3.2.1. So a data set containing security codes came either from a non-compliant system or from phishing and skimming, where the code was captured as it was typed. In every case it is stolen data, and in most cases it is stale.\nWhat this generator is for Filling the security-code field in test card data, so a fixture is a complete record Testing that field length follows the detected brand — three digits, four for Amex Confirming the field accepts digits only, and rejects spaces and letters Producing bulk values for seeding test databases Proving the code never reaches your logs or your storage That last one is a compliance test, not a formality:\n// Assert that the security code never reaches your logs or your database it(\u0026#39;does not persist the security code\u0026#39;, async () =\u0026gt; { const cvv = \u0026#39;742\u0026#39;; await submitPayment({ number: TEST_PAN, expiry: \u0026#39;12/29\u0026#39;, cvv }); const stored = await db.payments.findLatest(); expect(JSON.stringify(stored)).not.toContain(cvv); const logs = await readAppLogs(); expect(logs).not.toContain(cvv); }); Use a distinctive value rather than a common one — 742 is easier to find in a haystack than 123, and a code that also appears as a substring of the test card number will give you a false failure. Run the same assertion against error reports and analytics payloads, which is where these values usually escape: not through the database, but through an exception handler that serialises the whole request body.\nCVV and PCI DSS The security code belongs to a category the standard calls sensitive authentication data, alongside PIN blocks and full magnetic-stripe contents. The rule is short: it may be handled during authorisation and must not be retained afterwards, and encryption does not create an exception. Only issuers and organisations supporting issuing services may hold it, because they are the ones who have to.\nThree practical consequences:\nStorage is the easy part. Almost nobody deliberately writes the code to a database. It escapes through logs, stack traces, crash reports, request-replay tooling and analytics. Redact at the boundary, not at each call site. Test environments are in scope for the habit, if not the audit. Never move real card data into staging. That is what synthetic values like the ones above are for, and the test card numbers reference covers the sandbox codes each gateway expects — some processors treat the code as a trigger, so an arbitrary value there will not behave as you assume. The best architecture never sees it. Hosted fields and client-side tokenisation keep the code inside the processor\u0026rsquo;s iframe, so it never reaches your servers and the question of retaining it never arises. PCI DSS for developers covers the scope rules in full. The standard itself is published by the PCI Security Standards Council.\nThe requirement numbering above were last checked against provider documentation on 3 August 2026. Providers do change what they publish — the official link beside each claim is authoritative. Related tools and guides Generate complete records — number, expiry and code together — with the all-network generator, or build numbers on a prefix of your own with the BIN generator. The tool directory lists everything else, and the FAQ covers what a Luhn-valid number does and does not prove.\nFrequently Asked Questions Can you generate the CVV for a specific card number? No. Nobody can, except the bank that issued the card. The code is computed from the card number, the expiry date and the service code under a pair of secret keys held inside the issuer\u0026rsquo;s hardware security module. Every input except those keys is printed on the card, and without them there is no calculation to perform. There is no leaked algorithm, no lookup table and no shortcut — that is the entire reason the code exists. What does CVV stand for? Card Verification Value, Visa\u0026rsquo;s name for it. Every network calls it something different: Mastercard says CVC2, American Express says CID, JCB says CAV2, UnionPay says CVN2. They are the same idea — a short value the issuer can check that is printed on the card rather than encoded in the number, so quoting it is weak evidence the card was physically in front of whoever typed it. Why does Amex use 4 digits? A design choice from when the schemes implemented card-not-present verification separately, and Amex also prints it on the front rather than the back. The practical consequence is that a form hard-coding a three-digit security code field rejects every American Express card, which is one of the most common checkout bugs there is. Length rules should follow the detected brand. What is the difference between CVV, CVV2, and iCVV? Three values computed the same way from different inputs, for three different channels. CVV1 is encoded in the magnetic stripe and proves the stripe is genuine. CVV2 is the code printed on the card, used for card-not-present payments. iCVV lives in the EMV chip and is deliberately different from CVV1, so that data copied out of a chip cannot be used to forge a working magnetic stripe. Is the CVV stored anywhere? Not by any compliant system after the payment is authorised. PCI DSS forbids retaining sensitive authentication data — the security code, PIN blocks and full stripe data — once authorisation completes, and encrypting it does not make it permitted. Issuers and issuing processors are the narrow exception. If you find security codes in a database, that system is out of compliance. Why do some payments not ask for a CVV? Because the code only proves something the first time. Recurring charges, saved cards and merchant-initiated transactions run without it, since the cardholder is not present to read it. Tokenised wallet payments replace the card number entirely and authenticate a different way, and some domestic debit schemes never required it. Its absence is not necessarily a red flag. Are the codes this tool generates real? They are real digits and completely arbitrary ones. The tool reads a random source and formats the output at three or four digits — there is no card number involved, and no relationship to any account. They are useful for filling a security-code field in a test, and useless for anything else. Can a merchant see my CVV? Momentarily, while the payment is being authorised, and then it must be discarded. A well-built checkout never lets the value touch its own servers at all, keeping it inside a hosted field owned by the payment processor. Where a merchant does handle it, it may pass it to the processor and must not write it to a database, a log file, an error report or an analytics event. ","permalink":"https://ccgenerator.org/cvv-generator/","summary":"This tool produces random 3- or 4-digit security codes for test data. It is worth being precise about what that means, because most people searching for a \u0026ldquo;CVV generator\u0026rdquo; want something else: a way to work out the CVV that belongs to a particular card number.\nThat is not possible. Not with this tool, not with any tool. A CVV is computed by the issuing bank from the card number, the expiry date, the service code, and two secret cryptographic keys that only the issuer holds.","title":"CVV Generator — Random Test Security Codes"},{"content":"A debit card number looks exactly like a credit card number. Same networks, same lengths, same Luhn check digit, same BIN ranges. Whether a card draws on a deposit account or a credit line is recorded in the issuer\u0026rsquo;s BIN table, not in the digits themselves. This generator produces synthetic numbers in those shared formats for testing.\nTest card only\nCredit Card Number Generator Generate dummy card details for development and QA. Nothing is stored or sent to a server.\nSingle card Bulk cards Card network Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Generate Card Card network All Mixed Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Quantity Generate Cards These numbers are dummy, Luhn-valid test values for software testing only. They are not real active cards and cannot be used for payments. Copy all Show JSON Copy JSON Export JSON Export CSV JSON output All Cards Visa Mastercard Amex Discover JCB Diners Maestro UnionPay Troy These are test numbers, not real cards Every number on this page is synthetic test data. It is generated by a formula, not issued by a bank. These numbers are not linked to any person, account, or balance. They carry no funds. They will be declined by every real payment processor. They only pass client-side format and checksum validation. Attempting to use card data to obtain goods, services, or trials you have not paid for is fraud in virtually every jurisdiction. Do not do it. Generation runs entirely in your browser. Nothing is sent to or stored on our servers. Intended use: payment form validation, checkout UI testing, QA test fixtures, and developer demos. For processor-specific behaviour (approvals, declines, refunds, 3-D Secure) use your gateway's official sandbox test cards.\nThe generator defaults to Maestro because it is the only network in the picker that was issued as debit and nothing else, which makes it the useful default for debit-specific tests. That is a convenience, not a guarantee: every other network here issues debit and credit products from overlapping ranges, and no generated number can promise a funding type.\nDebit vs credit: what the number does and does not tell you This is the part worth reading, because it is the assumption that breaks payment code most often.\nWhat the number does tell you\nThe card network — Visa, Mastercard, Maestro, and so on, from the prefix The number\u0026rsquo;s length, and whether it is well-formed Whether the Luhn check digit is correct The IIN/BIN, which identifies the issuing institution — but only if you look it up What the number does not tell you\nWhether the card is debit or credit Whether it is prepaid Whether it is a consumer or a commercial card The account balance, or whether the account exists at all The issuing country, which also requires a lookup The honest exceptions A few products were issued as debit only, on ranges reserved for them, and for those the prefix does imply the funding type:\nMaestro — debit-only, Mastercard\u0026rsquo;s European workhorse, now being retired Visa Electron — debit with mandatory balance checking, largely superseded V PAY — Visa\u0026rsquo;s European chip-only debit brand, also being phased out Some Mastercard debit ranges — reserved for debit products by specific issuers Notice what those exceptions have in common: two of the three are disappearing. As Maestro and V PAY are replaced by Debit Mastercard and Visa Debit, the debit products move onto the same ranges as their credit equivalents, and the prefix stops carrying the signal it used to. The general rule is not just still true, it is becoming more true: a definitive answer requires a BIN lookup.\nWhy the ranges overlap in the first place It is not an oversight. An issuer receives BIN ranges from the network and assigns products within them as its portfolio changes, so the same six-digit prefix can front a debit product this year and a credit product next year. The move from six-digit to eight-digit BINs under ISO/IEC 7812-1:2017 made this finer-grained — an eight-digit BIN often does map to a single product — but it also means any lookup keyed on six digits is now reading a prefix that may cover several different products. If your BIN table is a static file with six-digit keys, it was already approximate and is getting less accurate every year.\nIn code, the practical consequence is that one of these functions cannot be written and the other can:\n// ❌ Not possible. There is no property of the digits that encodes funding type, // so any implementation of this is a guess wearing a function signature. function isDebit(cardNumber) { /* … */ } // ✅ Ask something that maintains an issuer database. async function getCardType(bin) { const res = await fetch(`https://your-bin-service.example/lookup/${bin}`); if (!res.ok) return \u0026#39;unknown\u0026#39;; const { type } = await res.json(); // \u0026#34;debit\u0026#34; | \u0026#34;credit\u0026#34; | \u0026#34;prepaid\u0026#34; | \u0026#34;unknown\u0026#34; return type; } // And design for the answer you will actually get some of the time. const fundingType = await getCardType(pan.slice(0, 8)); const surcharge = fundingType === \u0026#39;credit\u0026#39; ? creditSurcharge : 0; The default in that last line is deliberate: when the lookup fails, charge nothing extra. A BIN lookup tool and our explainer on IINs and BINs cover what those databases actually contain.\nWhy the distinction matters If the funding type is unknowable from the number, it is fair to ask why anyone cares. Six places where it changes real behaviour:\nInterchange. Debit interchange is capped in several markets. In the US, Regulation II holds large issuers to 21 cents plus 0.05% of the transaction — a rule a district court vacated in August 2025, with the vacatur stayed pending appeal, so the cap still applies for now. In the EU the caps are 0.2% for consumer debit and 0.3% for consumer credit. Surcharging. Where surcharging is permitted at all, the rules usually differ by funding type — US card network rules bar surcharging debit outright. In the EU and UK, PSD2 bans surcharging consumer cards of either kind. Getting this wrong is a compliance problem, not a rounding error. Authorisation holds. A hold on a debit card reduces the cardholder\u0026rsquo;s available money immediately. On a credit card it consumes credit line. The same $200 pre-authorisation is an inconvenience in one case and a declined rent payment in the other, which is why release timing gets complaints on debit and not on credit. Partial authorisation. Debit cards support partial approvals more consistently — the issuer approves what the balance covers and leaves the rest for another tender. If your checkout treats a partial approval as a failure, you decline transactions you could have split. Retry strategy for subscriptions. Debit failures skew toward insufficient funds, which is a timing problem: retrying just after a typical payday recovers a meaningful share. Credit failures skew toward limits and expiry, where the same retry schedule just burns attempts and network fees. Authentication. SCA exemptions and issuer challenge behaviour are not uniform across products, so a flow tested only on credit cards can meet its first challenge in production. Our test card numbers reference lists the sandbox cards that force one. Debit card networks and formats Network Prefix Length Primarily debit? Status Maestro 50, 56–69 12–19 Yes Retiring — no new EEA cards since July 2023, in circulation until 2027 Visa Electron 4026, 417500, 4405, 4508, 4844, 4913, 4917 16 Yes Largely superseded by Visa Debit V PAY 4 16 Yes (Europe) Being phased out in favour of Visa Debit Visa Debit 4 16 Mixed — same range as credit Current Mastercard Debit 51–55, 2221–2720 16 Mixed Current Discover Debit 6011, 65 16 Mixed Current Troy Debit 9792 16 Mixed Current — see the Troy generator Maestro\u0026rsquo;s 12–19 digit range is the row to pay attention to. It is where validation breaks, and it will keep breaking until the last of those cards expires. For the equivalent ranges on the credit side, the Visa page carries the full format table.\nSources: Mastercard — BIN Lookup data elements, Adyen — Debit Mastercard replacing Maestro, Federal Reserve — Regulation II · Verified: 2026-08-03\nNetwork status and interchange figures above were last checked against provider documentation on 3 August 2026. Providers do change what they publish — the official link beside each claim is authoritative. Testing scenarios Variable length. Generate Maestro numbers at 12, 13, 16 and 19 digits and confirm each is accepted. This single test catches the hard-coded-16 bug that affects a surprising share of checkout forms. BIN lookup integration. Mock the lookup and assert three paths: debit, credit and unknown. The unknown path is the one nobody writes and everybody eventually hits. Insufficient-funds retry. Simulate the decline, then assert that your retry schedule differs from the one you use for a limit-based decline. Partial authorisation. Approve less than the requested amount and check that the remainder is collected rather than the whole transaction abandoned. Surcharge calculation. Confirm the fee follows the funding type, and that an unknown type produces no surcharge. Missing CVC. Some Maestro cards were issued without a printed security code, so a form that requires CVC unconditionally locks those cardholders out. What this generator cannot do It does not produce a card tied to a real bank account. It does not produce a card with a balance — see what these numbers actually are. It does not produce a specific bank\u0026rsquo;s debit card, and no generator can. It does not guarantee that a generated BIN is a debit BIN in the real world. The prefix ranges above describe the products, not any particular issuer\u0026rsquo;s assignment. For disposable numbers issued against a real account, that is a different thing entirely and the virtual card generator explains where those come from. The tool directory lists everything else, and the FAQ covers what a Luhn-valid number does and does not prove.\nFrequently Asked Questions Can you tell if a card is debit or credit from the number? No. Debit and credit cards share networks, lengths, prefixes and the Luhn check digit, and most issuers put both products in the same BIN ranges. The funding source lives in the issuer\u0026rsquo;s BIN record, not in the digits. The only reliable answer comes from a BIN lookup against a maintained database — and even that returns what the issuer last reported, which is why the lookup belongs behind a service you can update rather than a table you hard-code. Do debit cards use the Luhn algorithm? Yes, identically. Luhn is a property of the primary account number under ISO/IEC 7812, not of the product sitting behind it. A debit card number, a credit card number and a prepaid card number all fail the same way if a digit is mistyped, and all pass the same mod-10 check when they are well-formed. How many digits does a debit card have? Usually 16, because most debit cards are issued on Visa and Mastercard, which are 16-digit networks. Maestro is the exception that breaks validation: it used the full ISO/IEC 7812 range of 12 to 19 digits, so a Maestro card in circulation can be shorter or longer than anything else in your test data. What is Maestro? Mastercard\u0026rsquo;s debit-only network, launched in 1991 and mostly used in Europe. It matters to developers for two reasons: it was the one mainstream network with genuinely variable-length numbers, and it is being retired. Issuers in Europe could not issue new Maestro cards after 1 July 2023, and the last cards issued before that date expire by 2027 at the latest. Existing cards still authorise until then, so validation still has to accept them. Why does my form reject a 13-digit Maestro card? Because the length check hard-codes 16, which is the single most common card-validation bug. Maestro permits 12 to 19 digits and Visa permits 13, 16 and 19, so any length rule tighter than \u0026ldquo;12 to 19 digits, Luhn-valid\u0026rdquo; will reject cards that are perfectly real. Validate the checksum and the length range, and let the processor decide the rest. Do these generated debit numbers have money on them? No. They are synthetic numbers with no issuer, no account and no balance, and every payment processor declines them. They exist so you can exercise form validation, brand detection and test fixtures without touching real card data. How do I detect debit vs credit in my checkout? Call a BIN lookup service with the first six to eight digits and read the funding type it returns. Do it server-side, cache the result, and design the flow so it still works when the lookup is unavailable or returns unknown — because it will. If the distinction drives pricing, such as a surcharge, treat an unknown result as the option that cannot get you in regulatory trouble. ","permalink":"https://ccgenerator.org/debit-card-generator/","summary":"A debit card number looks exactly like a credit card number. Same networks, same lengths, same Luhn check digit, same BIN ranges. Whether a card draws on a deposit account or a credit line is recorded in the issuer\u0026rsquo;s BIN table, not in the digits themselves. This generator produces synthetic numbers in those shared formats for testing.\nTest card only\nCredit Card Number Generator Generate dummy card details for development and QA.","title":"Debit Card Generator — Test Debit Numbers"},{"content":"This Diners Club card generator produces Luhn-valid test numbers in the classic 14-digit format. That length is the whole reason the page exists: Diners Club is the shortest primary account number in circulation, and it is the single most reliable way to find out whether your checkout has hard-coded sixteen digits somewhere.\nTest card only\nCredit Card Number Generator Generate dummy card details for development and QA. Nothing is stored or sent to a server.\nSingle card Bulk cards Card network Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Generate Card Card network All Mixed Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Quantity Generate Cards These numbers are dummy, Luhn-valid test values for software testing only. They are not real active cards and cannot be used for payments. Copy all Show JSON Copy JSON Export JSON Export CSV JSON output All Cards Visa Mastercard Amex Discover JCB Diners Maestro UnionPay Troy These are test numbers, not real cards Every number on this page is synthetic test data. It is generated by a formula, not issued by a bank. These numbers are not linked to any person, account, or balance. They carry no funds. They will be declined by every real payment processor. They only pass client-side format and checksum validation. Attempting to use card data to obtain goods, services, or trials you have not paid for is fraud in virtually every jurisdiction. Do not do it. Generation runs entirely in your browser. Nothing is sent to or stored on our servers. Intended use: payment form validation, checkout UI testing, QA test fixtures, and developer demos. For processor-specific behaviour (approvals, declines, refunds, 3-D Secure) use your gateway's official sandbox test cards.\nDiners Club card number format Property Value BIN ranges 300–305, 3095, 36, 38, 39 Classic length 14 digits Newer products 16 digits, 19 permitted Check digit Luhn (mod 10) Security code 3 digits, on the back Grouping 4-6-4 The 14-digit problem Most payment forms are built around a mental model of sixteen digits in four groups of four. American Express dents that model at fifteen. Diners Club breaks it outright at fourteen, and the failures it produces are more varied than a simple rejection.\nThe length check. minlength=\u0026quot;15\u0026quot;, length === 16, or a regex ending in \\d{16} all refuse a valid card. This is the obvious failure and the easiest to fix.\nThe input mask. A 4-4-4-4 mask applied to fourteen digits produces 1234 5678 9012 34 — two orphaned digits in a group that never fills, and often a trailing space the user cannot delete. The correct grouping is 4-6-4:\nfunction groupDiners(number) { const d = number.replace(/\\D/g, \u0026#39;\u0026#39;); return [d.slice(0, 4), d.slice(4, 10), d.slice(10, 14)] .filter(Boolean) .join(\u0026#39; \u0026#39;); } groupDiners(\u0026#39;30569309025904\u0026#39;); // \u0026#34;3056 930902 5904\u0026#34; That is the same shape as the Amex formatter most codebases already have, with different offsets. If you have one and not the other, the fix is ten minutes.\nThe submit-button heuristic. Forms that enable submission once sixteen digits are present never enable it for a Diners cardholder. This one is invisible in testing unless somebody actually types a fourteen-digit number, which is precisely why it survives to production.\nThe truncation bug. A fixed-width database column or a substr(0, 16) somewhere in the pipeline does nothing visible to a fourteen-digit number, so this one usually surfaces the other way — as a nineteen-digit card silently losing its last three digits. Diners is the network that makes you look.\nNewer Diners products are issued at sixteen digits, which tempts people to treat the fourteen-digit format as historical. It is not: those cards remain valid until they expire and are reissued, and until then a checkout that cannot take them is turning away customers with no error you will ever see in a log.\nWhy 14 digits, and why it stayed Diners Club predates the standards everything else was built to. It launched in 1950 as the first general-purpose charge card, well before ISO/IEC 7812 defined how account numbers should be structured, and fourteen digits was simply enough for the account base it expected. The sixteen-digit convention arrived later with the bank card networks, and by then Diners had millions of numbers in the field.\nThat is the useful lesson, and it generalises past this one network: card number formats are not a design, they are an accumulation. Sixteen digits is a convention that most of the industry converged on, not a rule anybody wrote down and enforced. Visa permits thirteen and nineteen, American Express uses fifteen, Maestro spans twelve to nineteen, and Diners keeps fourteen — every one of those is a legacy decision that outlived the reasoning behind it.\nCode written against the convention rather than the specification works for years and then fails on a customer who cannot tell you why, because from their side the card is simply refused. Writing the length check against ISO/IEC 7812\u0026rsquo;s twelve-to-nineteen range costs nothing extra and never needs revisiting.\nWhere Diners Club is accepted Diners Club International is part of Discover Global Network, and the two together are accepted in more than 185 countries and territories. In practice that means a Diners card presented in the United States usually clears over Discover rails, and Discover\u0026rsquo;s other partnerships — including JCB — form the same kind of reciprocal web.\nThe brand\u0026rsquo;s centre of gravity is corporate travel and expense, which shapes who you will actually see using one. If you sell to business travellers, airlines, hotels or expense-managed B2B customers, Diners appears more often than its overall market share suggests. If you sell consumer goods online, it is rare — but the length handling still needs to be right, because the same code path serves American Express at fifteen digits.\nBrand detection regex const DINERS = /^3(0[0-5]\\d{11,14}|095\\d{10,13}|[689]\\d{12,16})$/; The alternation covers the three separate shapes: the 300–305 block, the 3095 block, and the 36/38/39 blocks. The digit counts differ per branch because the prefix lengths do — getting those wrong is how a detector ends up accepting thirteen-digit numbers that are not valid anywhere.\nWorth checking against neighbours in the same MII:\nDINERS.test(\u0026#39;30000000000004\u0026#39;); // true — 14-digit classic DINERS.test(\u0026#39;36000000000000\u0026#39;); // true — the common modern block DINERS.test(\u0026#39;3600000000000000\u0026#39;); // true — 16-digit product DINERS.test(\u0026#39;378282246310005\u0026#39;); // false — American Express, not Diners DINERS.test(\u0026#39;3566002020360505\u0026#39;); // false — JCB, not Diners The last two assertions are the ones to keep. 3 covers travel and entertainment, so Amex, JCB and Diners are neighbours, and a sloppy Diners expression will claim cards belonging to both.\nTesting scenarios Fourteen digits end to end. Type one into the real form, not just the unit test: mask, length validation, submit button state, and what the confirmation screen displays. Grouping. Confirm the mask switches to 4-6-4 when the brand is detected, and that deleting digits does not leave stray separators. Mixed-length fixtures. A test set containing fourteen, fifteen, sixteen and nineteen digit numbers will find every hard-coded length in one run. Storage width. Confirm the full number survives your database column and any API in between — test with nineteen digits, which is where truncation shows. Brand neighbours. Assert that Amex and JCB numbers are not detected as Diners. Official test numbers For sandbox testing, use the gateway\u0026rsquo;s published numbers. Stripe documents 3056 9300 0902 0004 and the 14-digit 3622 7206 271667, Braintree uses 3625 9600 0000 04, and Adyen documents 3600 6666 3333 44. The test card numbers reference collects them by gateway.\nDiners Club International\u0026rsquo;s own material is published at dinersclub.com, and the network relationship is documented on Discover Global Network.\nRelated tools and guides A fourteen-digit number run through the validator shows the length rule being applied correctly, which is a quick way to compare against whatever your own form does with the same input. The length reference tabulates every network\u0026rsquo;s permitted digit counts in one table — the fastest way to audit a length check against reality. The rest of the generators are in the tool directory, and the FAQ covers what the checksum proves.\nFrequently Asked Questions How many digits is a Diners Club card? Fourteen for the classic format, which is shorter than every other network — shorter even than American Express at fifteen. Newer and co-branded products are issued at sixteen digits, and nineteen is permitted. Both fourteen and sixteen-digit cards are in circulation, so validation has to accept both. Why does my form reject a 14-digit Diners Club card? Because the length rule assumes a minimum of fifteen or sixteen digits. It is the same class of bug as rejecting a thirteen-digit Visa, and Diners is the case that finds it most reliably. A card number length check should accept the ISO/IEC 7812 range of twelve to nineteen digits and let the Luhn checksum and the processor do the rest. How should a 14-digit number be grouped? As 4-6-4, not 4-4-4-4. A mask built for sixteen digits leaves a fourteen-digit number visually broken — trailing separators, digits in the wrong blocks, and a field that looks incomplete when it is not. Grouping should follow the detected brand, the same way it already does for American Express. What BIN ranges does Diners Club use? 300–305, 3095, 36, 38 and 39. The 36 block is the most common today. All of them sit under Major Industry Identifier 3, travel and entertainment, alongside American Express and JCB. Is Diners Club still issued? Yes. Diners Club International is part of Discover Global Network and continues to issue through partner banks in dozens of countries, with the two networks together accepted in more than 185 countries and territories. In the United States a Diners card commonly clears over Discover rails. Do these generated Diners Club numbers work for real payments? No. They are Luhn-valid and correctly formatted, which is exactly what you need to test length handling and input masks. No issuer has them on file, so any real processor declines them. ","permalink":"https://ccgenerator.org/diners-club-card-generator/","summary":"This Diners Club card generator produces Luhn-valid test numbers in the classic 14-digit format. That length is the whole reason the page exists: Diners Club is the shortest primary account number in circulation, and it is the single most reliable way to find out whether your checkout has hard-coded sixteen digits somewhere.\nTest card only\nCredit Card Number Generator Generate dummy card details for development and QA. Nothing is stored or sent to a server.","title":"Diners Club Card Generator — 14-Digit"},{"content":"Effective date: August 2, 2026\n1. Test Data Disclaimer Every number produced by this site is generated by an algorithm from random digits. It is not drawn from any database, leak, breach, or list of real cards. No real cardholder data of any kind exists on this website or on our servers.\nTo be precise about what \u0026ldquo;generated by an algorithm\u0026rdquo; means: when you press Generate, your browser picks a card network, reads its published length and prefix range, fills the remaining positions with random digits, then computes the final digit so the string satisfies the Luhn checksum. Expiry dates, CVV values, and names are produced the same way.\nThere is no lookup step and no source list. The site ships no dataset of card numbers because it does not need one: output is computed on the spot from randomness and a public formula. If two people generate the same number by coincidence, that is arithmetic, not a leak.\nNone of it reaches us either — generation runs entirely in your browser and the numbers are never transmitted to or logged by our servers. The Privacy Policy explains how to verify that with your browser\u0026rsquo;s developer tools.\n2. These Numbers Do Not Work for Payments Not \u0026ldquo;should not\u0026rdquo; — cannot. The reason is structural, not a restriction we chose to impose.\nAuthorisation requires an issuer, and there is no issuer. For a payment to be approved, the number must correspond to a live account on the books of the bank that issued it. The issuer is the only party that can say yes: it checks that the account exists, that the card is active and not reported lost, that the expiry date and security code match its records, and that the funds or credit line cover the amount. A number invented by a JavaScript function on your machine was never registered with any bank, so none of those checks can begin.\nLuhn is a typo check, not a security check. The Luhn algorithm is a checksum published in 1960 and standardised in ISO/IEC 7812. Its purpose is to catch a mistyped or transposed digit before a request is sent anywhere. It involves no secret, no key, and no contact with a bank — any competent programmer can compute a Luhn-valid number in a few lines of code, which is exactly what this site does. Passing the check tells you the string is well formed, and nothing more. Our guide to the Luhn algorithm works through the arithmetic.\nWhat actually happens if one is submitted. The merchant sends the details to its acquirer, which routes the request over the card network to the issuer identified by the number\u0026rsquo;s first digits. If that BIN maps to no issuer, routing fails. If it maps to a real issuer, that issuer looks up the account, finds nothing, and declines — typically \u0026ldquo;invalid card number\u0026rdquo; or \u0026ldquo;do not honour\u0026rdquo;. The attempt is logged, and repeated attempts look like card testing to fraud systems.\nThe short version: Luhn validity means \u0026ldquo;correctly formatted\u0026rdquo;, not \u0026ldquo;real\u0026rdquo;. A well formed address for a house that was never built is still an address, and the post still comes back. Our FAQ answers the questions that come up most often.\n3. No Affiliation CC Generator is independent. We are not affiliated with, endorsed by, sponsored by, or officially connected to Visa, Mastercard, American Express, Discover, JCB, Diners Club, Troy, UnionPay, Maestro, or any bank, card network, payment processor, gateway, or financial institution.\nAll product names, trademarks, and registered trademarks are the property of their respective owners. We use them only nominatively — to identify which published number format a generator produces. No endorsement or partnership is implied by their appearance here.\n4. Not Financial or Legal Advice The guides, explanations, and reference material on this site are educational. They are not financial, legal, accounting, tax, or regulatory compliance advice, and reading them creates no professional relationship.\nIn particular, nothing here is guidance on PCI DSS compliance. Whether your systems fall in scope depends on your architecture and your acquirer\u0026rsquo;s requirements — consult a Qualified Security Assessor (QSA) or your acquiring bank. Using synthetic test data is good practice, but does not by itself put a system out of scope.\n5. Accuracy of Technical Information BIN ranges, number lengths, network prefixes, and validation rules change: networks reassign ranges, add new ones, and retire old ones. We keep this site current as best we can, but make no warranty that any format or rule shown here reflects the current published specification at the moment you read it.\nFor anything that matters, verify against primary sources:\nISO/IEC 7812 — the standard defining the structure of issuer identification numbers and primary account numbers. EMVCo — https://www.emvco.com/ — chip, contactless, tokenisation, and 3-D Secure specifications. PCI Security Standards Council — https://www.pcisecuritystandards.org/ — PCI DSS and related standards for handling cardholder data. Your payment provider\u0026rsquo;s own documentation is the authority on how that provider behaves.\n6. Use Official Sandbox Cards for Gateway Testing The numbers here are for testing your own software: input validation, formatting, card brand detection, error states, and test fixtures. They are not tied to any processor\u0026rsquo;s sandbox, so they cannot exercise processor behaviour.\nTo test approvals, declines, reason codes, partial captures, refunds, chargebacks, or 3-D Secure challenge flows, use the official test cards your gateway publishes — Stripe, Adyen, PayPal, Braintree, Checkout.com, İyzico and others maintain their own, wired to rehearsed outcomes in their sandboxes. Each provider publishes its list in its own developer documentation.\n7. User Responsibility You are responsible for how you use anything generated here and for complying with the laws of your own jurisdiction. Laws on payment card data, computer misuse, and fraud differ by country, and some cover the possession or supply of card data in circumstances you might not expect.\nPermitted and prohibited uses are set out in the Terms of Service. If you are unsure whether a use is lawful where you are, take local legal advice first.\n8. Reporting Misuse We built this as an engineering tool and intend it to stay one. If you see this site promoted for fraud, referenced in a scam, embedded in a phishing page, or otherwise misused, tell us:\nEmail: abuse@ccgenerator.org\nInclude a link or screenshot if you can. We investigate every report, block access where we can, and cooperate with lawful requests from payment networks and law enforcement.\n9. External Links This site links to standards bodies, payment provider documentation, and other third-party resources. We do not control those sites and are not responsible for their content, accuracy, availability, or practices. A link is not an endorsement, and following one takes you outside the scope of our Terms of Service and Privacy Policy.\n10. Advertising This site displays advertising through Google AdSense, which is what keeps it free to use. Ads are selected and served by Google and its partners, not by us. We do not review, endorse, or vouch for advertised products or services, and an ad appearing here implies no relationship between the advertiser and CC Generator — any dealing with an advertiser is between you and them. Ads are kept visually separate from the generator and never styled to look like part of the tool.\nHow advertising cookies work, and how to opt out of personalised ads, is covered in the Privacy Policy.\n","permalink":"https://ccgenerator.org/disclaimer/","summary":"Effective date: August 2, 2026\n1. Test Data Disclaimer Every number produced by this site is generated by an algorithm from random digits. It is not drawn from any database, leak, breach, or list of real cards. No real cardholder data of any kind exists on this website or on our servers.\nTo be precise about what \u0026ldquo;generated by an algorithm\u0026rdquo; means: when you press Generate, your browser picks a card network, reads its published length and prefix range, fills the remaining positions with random digits, then computes the final digit so the string satisfies the Luhn checksum.","title":"Disclaimer"},{"content":"This Discover card generator produces Luhn-valid test numbers across the network\u0026rsquo;s published BIN ranges. Discover is worth a page of its own for one reason: it has the most fragmented prefix structure of any major network, and detection code written for it is wrong more often than for any other brand.\nTest card only\nCredit Card Number Generator Generate dummy card details for development and QA. Nothing is stored or sent to a server.\nSingle card Bulk cards Card network Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Generate Card Card network All Mixed Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Quantity Generate Cards These numbers are dummy, Luhn-valid test values for software testing only. They are not real active cards and cannot be used for payments. Copy all Show JSON Copy JSON Export JSON Export CSV JSON output All Cards Visa Mastercard Amex Discover JCB Diners Maestro UnionPay Troy These are test numbers, not real cards Every number on this page is synthetic test data. It is generated by a formula, not issued by a bank. These numbers are not linked to any person, account, or balance. They carry no funds. They will be declined by every real payment processor. They only pass client-side format and checksum validation. Attempting to use card data to obtain goods, services, or trials you have not paid for is fraud in virtually every jurisdiction. Do not do it. Generation runs entirely in your browser. Nothing is sent to or stored on our servers. Intended use: payment form validation, checkout UI testing, QA test fixtures, and developer demos. For processor-specific behaviour (approvals, declines, refunds, 3-D Secure) use your gateway's official sandbox test cards.\nDiscover card number format Property Value BIN ranges 6011, 622126–622925, 644–649, 65 Standard length 16 digits Extended length 19 digits Check digit Luhn (mod 10) Security code CID, 3 digits, on the back Grouping 4-4-4-4 Why Discover\u0026rsquo;s BIN ranges are the messiest Every other major network can be described in a sentence. Visa is 4. Mastercard is 51–55 plus 2221–2720. American Express is 34 and 37. Discover takes four blocks that have no relationship to each other, and each arrived for a different reason.\n6011 is the original. It is the range most developers know, and the one most detection code checks — which is exactly the problem, because it is now a minority of the cards in circulation.\n622126–622925 is a co-brand block shared with China UnionPay. Cards issued in it can route over either network depending on where the transaction happens. This is a real commercial arrangement rather than a numbering coincidence, and it has a precise consequence for code: a loose ^62 test will claim UnionPay cards outside the block, and a loose ^622 test will claim ones just outside its boundaries. The block starts at 622126 and ends at 622925, and both edges matter.\n644–649 and 65 were added later as the network grew. 65 in particular is the range that collides with Maestro, whose own block spans 56–69 — so a naive detector that checks Maestro first will classify a large share of Discover cards as Maestro. Order of evaluation is not a style preference here; it changes the answer.\nOn top of the ranges, Discover Global Network operates reciprocal acceptance with Diners Club, JCB and UnionPay. A Diners card presented in the United States is frequently processed over Discover rails. That does not change the digits, but it does mean \u0026ldquo;which network is this\u0026rdquo; and \u0026ldquo;which network will process it\u0026rdquo; are two different questions with two different answers.\nWhere Discover is accepted Domestic acceptance in the United States is near universal — Discover sits alongside Visa and Mastercard at essentially every merchant. Internationally the picture is different and worth understanding, because it drives whether you need to support the brand at all.\nOutside the US, Discover cards clear through partner networks rather than a Discover-branded acceptance footprint. Discover Global Network reaches most of the world through Diners Club International, together covering more than 185 countries and territories, plus alliances with UnionPay, JCB and various domestic schemes. For a merchant, the practical question is not \u0026ldquo;does Discover work in this country\u0026rdquo; but \u0026ldquo;does my acquirer route Discover, and at what cost\u0026rdquo;.\nIf your customer base is meaningfully American, supporting Discover is not optional. If it is entirely European, it is a low priority — but the detection code should still be correct, because a wrongly detected card fails in a way that looks like a bug in your form.\nBrand is not the same as routing network The partnerships make a distinction that most codebases collapse, and it is worth separating deliberately because it shows up in reconciliation rather than in checkout.\nThe brand is what the card says it is — what the cardholder sees, what logo you should display, what the digits encode. The routing network is which set of rails actually carried the authorisation, which depends on the merchant\u0026rsquo;s acquirer, the country, and the partner agreements in force.\nFor a Discover-branded card in the United States these are the same. For a Diners card in the United States, or a JCB card, or a UnionPay card in the co-brand block, they are not. Your checkout should key on brand: that is what determines the logo, the security-code rules and the input mask. Your finance reporting should key on the routing network, because that is what determines the interchange you actually paid.\nCode that uses one field for both produces reports that do not reconcile against the processor\u0026rsquo;s, and the discrepancy is small enough to be dismissed as rounding for a long time before someone traces it.\nBrand detection regex Discover is the one network where a short expression is guaranteed to be wrong:\nconst DISCOVER = /^(6011\\d{12}|65\\d{14}|64[4-9]\\d{13}|622(12[6-9]|1[3-9]\\d|[2-8]\\d\\d|9[01]\\d|92[0-5])\\d{10})$/; The 622 alternation is doing the work — it encodes the range 622126 to 622925 digit by digit, because a numeric comparison is not available inside a regular expression. Test it at the edges rather than in the middle:\nDISCOVER.test(\u0026#39;6221250000000000\u0026#39;); // false — one below the block DISCOVER.test(\u0026#39;6221260000000000\u0026#39;); // true — first number in the block DISCOVER.test(\u0026#39;6229250000000000\u0026#39;); // true — last number in the block DISCOVER.test(\u0026#39;6229260000000000\u0026#39;); // false — one above the block DISCOVER.test(\u0026#39;6440000000000000\u0026#39;); // true — 644-649 range DISCOVER.test(\u0026#39;6430000000000000\u0026#39;); // false — just outside it If you would rather express the ranges as numbers than as an alternation, parse the first six digits and compare — it is easier to read and far easier to get right. The regex is useful when you need a single-expression check, not because it is clearer.\nTesting scenarios All four ranges. Generate a card in each of 6011, 622126–622925, 644–649 and 65 and confirm your detector reports Discover for every one. Boundary values. The four numbers above are the tests that catch off-by-one errors in the co-brand block. They belong in your suite permanently. Detection order. Feed a 65 number to your full detection chain, not just the Discover expression, and confirm Maestro does not claim it first. 19-digit acceptance. Generate a nineteen-digit number and confirm the form accepts it. CID length. Three digits, not four. A shared field that keys length to the name \u0026ldquo;CID\u0026rdquo; rather than the brand will demand four and reject valid input. Official test numbers For sandbox testing where you need a processor to respond, use the gateway\u0026rsquo;s own numbers rather than generated ones. Stripe publishes 6011 1111 1111 1117 and 6011 0009 9013 9424 for Discover, Square uses 6011 0000 0000 0004, and Adyen documents 6011 6011 6011 6611. The test card numbers reference collects them by gateway with their decline codes.\nDiscover\u0026rsquo;s own developer material lives at Discover Global Network, which is also the authoritative source for acceptance and partner-network arrangements.\nRelated tools and guides If you are unsure which of the four ranges a number falls in, the validator reports the detected network and shows the prefix broken out from the rest of the digits. The IIN and BIN explainer covers why allocations fragment like this in the first place, and the brand detection guide carries the full expression set. All nine network generators are listed in the tool directory, and the FAQ explains the limits of a Luhn check.\nFrequently Asked Questions What BIN ranges does Discover use? Four separate blocks rather than one clean prefix: 6011, 622126–622925, 644–649, and 65. That fragmentation is the defining awkwardness of the network, and it is why a Discover check is longer than any other brand\u0026rsquo;s. Code that tests only for 6011 misses the majority of Discover cards in circulation. How many digits is a Discover card? Sixteen for the vast majority, with nineteen permitted under the specification and issued on some products. A length rule that accepts only sixteen will reject valid cards, which is the same mistake that catches people out on Visa. Why does the 622 range overlap with UnionPay? Because it is a co-brand block. Discover and China UnionPay have a reciprocal arrangement, and cards in 622126–622925 can route over either network depending on where they are used. The overlap is real rather than a numbering accident, which is why the boundaries of that block have to be checked precisely rather than matched with a loose 62 prefix. Is Discover accepted outside the United States? Increasingly, through partner networks rather than direct acceptance. Discover Global Network includes Diners Club International and works with UnionPay, JCB and several domestic schemes, so a Discover card often clears through a local partner abroad. Domestic US acceptance remains far broader than international. What is the security code on a Discover card called? The CID, three digits, printed on the back. Note that American Express also calls its code a CID but uses four digits on the front — same name, different rules, and a form that keys code length to the name rather than the brand will get one of them wrong. Do these generated Discover numbers work for real payments? No. They are Luhn-valid and correctly formatted, which is what makes them useful for testing your own validation and brand detection. They are not registered with any issuer, so every payment processor declines them. ","permalink":"https://ccgenerator.org/discover-card-generator/","summary":"This Discover card generator produces Luhn-valid test numbers across the network\u0026rsquo;s published BIN ranges. Discover is worth a page of its own for one reason: it has the most fragmented prefix structure of any major network, and detection code written for it is wrong more often than for any other brand.\nTest card only\nCredit Card Number Generator Generate dummy card details for development and QA. Nothing is stored or sent to a server.","title":"Discover Card Generator — Test Numbers"},{"content":"Last reviewed: August 2, 2026\nThis 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.\nOur scope We write about the mechanics of payment card data from a developer\u0026rsquo;s point of view. That means:\nPayment 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 \u0026ldquo;best card for X\u0026rdquo; 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.\nKeeping the subject narrow is deliberate. We would rather be reliable on a small topic than approximate on a large one.\nHow we source technical claims Sources are ranked, and higher tiers win when they conflict.\nTier 1 — Standards. The normative documents that define the formats themselves.\nISO/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.\nEMVCo 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.\nStripe 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.\nThe 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.\nWhat 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\u0026rsquo;s own documentation and linked back to it. We never invent a number and present it as a provider\u0026rsquo;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.\nReport an error to editorial [at] ccgenerator [dot] org. 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\u0026rsquo;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.\nReview and refresh cycle Payment standards drift, so pages are re-checked on a schedule rather than left alone until someone complains.\nPage type Reviewed Technical reference (BIN ranges, card formats, gateway test cards) Every 6 months Guide articles and explainers Annually Legal pages (privacy, terms, disclaimer) Annually, or when the law changes Each page shows when it was last reviewed. A review can conclude that nothing needed changing — in that case only the review date moves.\nAI use disclosure We would rather tell you this plainly than have you guess.\nWe 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.\nIn 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.\nAdvertising 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\u0026rsquo;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:\nReal 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 \u0026ldquo;loophole\u0026rdquo; 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.\nContact Corrections, sourcing questions, and comments on this policy:\neditorial [at] ccgenerator [dot] org 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.\n","permalink":"https://ccgenerator.org/editorial-policy/","summary":"Last reviewed: August 2, 2026\nThis 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.\nOur scope We write about the mechanics of payment card data from a developer\u0026rsquo;s point of view. That means:\nPayment 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.","title":"Editorial Policy"},{"content":"Every technical page on this site is written and reviewed by the CC Generator Editorial Team. This page exists so you know who that is, what we are qualified to write about, and what we are not.\nWho we are We are a small team of developers and QA engineers who build and test payment forms for a living. We publish under a team name rather than individual bylines. That is a deliberate choice, and we would rather say so plainly than invent a photogenic expert who does not exist: the accuracy of a page about the Luhn algorithm does not depend on whose face is next to it, and a fabricated author profile would be worth less than nothing.\nWhat that means in practice is that responsibility here is collective. No page ships without a second person checking the claims in it, and when something is wrong, it is the team that owns the fix — not an individual contributor who may have moved on.\nWhat we know well Our working experience is in payment integration and test automation, so that is what this site covers:\nCard number structure — how issuer identification numbers, account identifiers and check digits are laid out under ISO/IEC 7812, and how the networks differ. The Luhn algorithm — what it catches, what it misses, and the mistakes people make implementing it. Payment gateway testing — the sandbox environments and test card sets published by Stripe, PayPal, Adyen and others, and why a number that passes validation still fails at authorisation. Test data management — generating, scoping and disposing of synthetic data for QA environments without dragging real cardholder data into scope. The parts of PCI DSS a developer actually touches — what counts as cardholder data, why test numbers are not in scope, and where tokenisation moves the boundary. What we do not cover Knowing your limits is part of being trustworthy, so here is ours. We do not publish:\nFinancial advice. We will not tell you which card to apply for, how to manage debt, or what to do about your credit score. We are not licensed to, and we are not qualified to. Card comparisons or recommendations. No \u0026ldquo;best rewards card\u0026rdquo; content, no affiliate card links. Credit repair or lending guidance. Legal advice. We describe how laws such as the CFAA or PCI DSS are generally understood to apply to synthetic test data; that is background, not counsel. For your situation, ask a lawyer. Anything that helps someone commit fraud. Numbers generated here carry no balance and cannot authorise a transaction. That is the whole point, and we will not publish content that pretends otherwise. If a topic falls outside the list above, we link out to someone who does know rather than writing filler about it.\nHow we work Our full process is written up in the editorial policy: where claims come from, what gets verified before publishing, how often data-heavy pages are re-checked, and how corrections are handled. The short version is that technical claims are traced back to a primary source — a standards document or a payment provider\u0026rsquo;s own documentation — and pages that republish third-party data carry a visible date showing when that data was last checked.\nWe get things wrong sometimes. When we do, we correct the page and say what changed rather than quietly editing it.\nThe commercial side of the operation is written up separately in How This Site Works: advertising is the only revenue, there are no affiliate links anywhere, and nothing you generate ever leaves your browser. That page also explains how to verify each of those claims yourself.\nContact Corrections, disputed claims and \u0026ldquo;this code does not compile\u0026rdquo; reports go to editorial [at] ccgenerator [dot] org. We read every one. If you are reporting a factual error, a link to the primary source that contradicts us is the fastest way to get it fixed.\nFor anything else, the contact page lists the right address.\n","permalink":"https://ccgenerator.org/authors/editorial-team/","summary":"Every technical page on this site is written and reviewed by the CC Generator Editorial Team. This page exists so you know who that is, what we are qualified to write about, and what we are not.\nWho we are We are a small team of developers and QA engineers who build and test payment forms for a living. We publish under a team name rather than individual bylines. That is a deliberate choice, and we would rather say so plainly than invent a photogenic expert who does not exist: the accuracy of a page about the Luhn algorithm does not depend on whose face is next to it, and a fabricated author profile would be worth less than nothing.","title":"CC Generator Editorial Team"},{"content":"Most sites in this corner of the web are vague about what they are and how they make money. This page is the opposite: the business model, the technical setup, and the data we do not collect, in enough detail that you can check every claim on it yourself.\nHow this site makes money Advertising, and nothing else.\nThe plan is display advertising through Google AdSense. That is the entire revenue model. Specifically, there is:\nNo affiliate income. We do not link to card issuers, banks, VPNs, or \u0026ldquo;get a virtual card\u0026rdquo; services for commission. There are no affiliate links anywhere on this site. No paid placements. Nobody has paid to be mentioned in a guide, and no guide has been written because a company asked for it. No sponsored content. If that ever changes, it will be labelled on the page itself, not buried here. No data sales. We have nothing to sell, which the next section explains. No paid tier, no accounts, no email list. Advertising creates one obvious conflict of interest: more pages and more traffic means more revenue, which is a standing incentive to publish filler. Our editorial policy is where we commit to not doing that, and it names the specific things we will not publish regardless of traffic — along with where AI tooling is and is not used in drafting.\nHow the generator actually works Every generator on this site runs entirely in your browser, in JavaScript. When you click Generate:\nThe browser picks a network prefix from a table of published issuer identification number ranges. It fills the account identifier with random digits from your browser\u0026rsquo;s own random number source. It computes the final check digit so the number satisfies the Luhn checksum — the same arithmetic described in the Luhn algorithm guide. It writes the result into the page. No card number is ever sent to a server, because there is no server involved in generating one. There is no API call, no database, and no log of what you generated.\nYou do not have to take our word for this. Open your browser\u0026rsquo;s developer tools, switch to the Network tab, and click Generate. You will see no request go out. The generator source is plain, unminified-in-behaviour JavaScript served from this domain — you can read it in the Sources tab and follow exactly what it does with the digits.\nThat property is also why the numbers are useless for fraud: nothing here is connected to any issuer, so nothing here carries an account, a balance, or an authorisation path. The guide on why generated cards have no balance covers the mechanics.\nWhat we do not collect No accounts. There is nothing to sign up for, so there is no name, email or password to store. No generated data. What the generator produces never leaves your browser, so we could not log it even if we wanted to. No form submissions. There is no contact form; the contact page publishes email addresses instead, which keeps your message in your own mail client until you decide to send it. No third-party trackers before consent. Analytics and advertising scripts are blocked until you accept them in the cookie banner. Reject, and nothing loads — verifiable in the same Network tab. The privacy policy covers the full detail, including what Google\u0026rsquo;s advertising cookies do once you accept them.\nHow the content is produced Written and reviewed by the CC Generator Editorial Team, with technical claims traced back to a primary source — a standards document, or the payment provider\u0026rsquo;s own documentation. Pages that republish third-party data, such as gateway test card tables, carry a visible date showing when that data was last checked against the provider\u0026rsquo;s docs.\nWe use AI tooling in drafting and editing. We do not publish anything a human has not verified against the source, and the policy linked above states exactly where that line sits.\nWhat this site is not It is not a bank, an issuer, a payment processor, or a financial adviser. It generates structurally valid but entirely fake data for testing software. If you came here looking for a working card number, our answer to whether card numbers that work exist is honest and you will not like it.\nSomething on this page not matching what you observe is worth telling us about: editorial [at] ccgenerator [dot] org.\n","permalink":"https://ccgenerator.org/how-this-site-works/","summary":"Most sites in this corner of the web are vague about what they are and how they make money. This page is the opposite: the business model, the technical setup, and the data we do not collect, in enough detail that you can check every claim on it yourself.\nHow this site makes money Advertising, and nothing else.\nThe plan is display advertising through Google AdSense. That is the entire revenue model.","title":"How This Site Works"},{"content":"If you are testing a SEPA transfer, a direct debit mandate, or any bank transfer integration, you need IBANs with correct check digits. This tool produces synthetic IBANs in each country\u0026rsquo;s own format, with valid ISO 7064 MOD-97-10 check digits, and validates ones you paste in. None of them is attached to a real account.\nTest data only\nIBAN Generator and Validator Synthetic IBANs with correct ISO 7064 MOD-97-10 check digits, in each country's own format. Generated in your browser and linked to no account anywhere.\nCountry Quantity Generate Copy all Export CSV Validate an IBAN These IBANs have valid check digits and the right shape for the country, which is what makes them useful for testing. They identify no account, and no money can be sent to or from one. All Cards Visa Mastercard Amex Discover JCB Diners Maestro UnionPay Troy IBAN structure An IBAN is three fields glued together:\nTR33 0006 1005 1978 6457 8413 26 └┬┘ └┬┘ └──────────────┬───────┘ │ │ │ │ │ └── BBAN (Basic Bank Account Number) — country-specific │ └──────────────────── Check digits (ISO 7064 MOD-97-10) └──────────────────────── Country code (ISO 3166-1 alpha-2) The country code and check digits are universal. Everything after them is the BBAN, and its internal structure is decided by each country\u0026rsquo;s banking authority — typically a bank code, sometimes a branch code, the domestic account number, and in several countries a national check digit of its own that predates the IBAN entirely.\nThat is the key thing to understand: the IBAN did not replace domestic account numbering. It wrapped it. A German IBAN contains the same Bankleitzahl and account number a German transfer always used; a British one contains the same sort code and account number. Only the outer layer is international.\nHow the IBAN check digits work The algorithm is ISO 7064 MOD-97-10, and it runs in four steps:\nMove the first four characters — country code and check digits — to the end. Replace every letter with a number: A = 10, B = 11, through Z = 35. Read the result as one very large integer and take it modulo 97. A valid IBAN leaves a remainder of exactly 1. To produce check digits rather than verify them, put 00 in their place, run the same calculation, and subtract the remainder from 98.\nWhy it is stronger than Luhn Luhn catches single-digit errors and most adjacent transpositions. MOD-97-10 catches all single-character errors, all transpositions of adjacent characters, and the overwhelming majority of other common mistakes — the probability of a random error slipping through is about 1 in 97. That difference matters when a mistyped account number sends money to a stranger rather than just failing a form.\nThe comparison is worth holding onto when you work on both. A card number that fails Luhn validation is almost certainly mistyped, but a card number that passes tells you very little. An IBAN that passes MOD-97 is far stronger evidence that the characters are as the sender intended — still not evidence that the account exists, but a much narrower gap.\nThe BigInt trap function isValidIban(iban) { const s = iban.replace(/\\s+/g, \u0026#39;\u0026#39;).toUpperCase(); if (!/^[A-Z]{2}\\d{2}[A-Z0-9]{11,30}$/.test(s)) return false; const rearranged = s.slice(4) + s.slice(0, 4); const numeric = rearranged.replace(/[A-Z]/g, (c) =\u0026gt; c.charCodeAt(0) - 55); return BigInt(numeric) % 97n === 1n; } console.log(isValidIban(\u0026#39;GB82 WEST 1234 5698 7654 32\u0026#39;)); // true BigInt is not a stylistic choice here. Letters expand to two digits each, so a 31-character Maltese IBAN becomes a 45-digit integer — around twenty digits past what a JavaScript number represents exactly.\nHere is the failure, using the published Maltese example MT84 MALT 0110 0001 2345 MTLC AST0 01S. After rearranging and substituting letters, the numeric string is 45 characters long:\nNumber(numeric) % 97 returns 41 BigInt(numeric) % 97n returns 1 The first result is not an error. Nothing throws, nothing warns, and the function confidently returns false for a perfectly valid IBAN. The symptom that gives it away is that short IBANs validate correctly and long ones fail — which reads like a country-specific bug and sends people looking in entirely the wrong place. The same applies in any language where the default integer type is 64-bit: use arbitrary precision, or feed the digits through the modulo in chunks.\nIBAN length by country Country Code Length Country Code Length Albania AL 28 Italy IT 27 Austria AT 20 Latvia LV 21 Belgium BE 16 Lithuania LT 20 Bulgaria BG 22 Luxembourg LU 20 Croatia HR 21 Malta MT 31 Cyprus CY 28 Netherlands NL 18 Czechia CZ 24 Norway NO 15 Denmark DK 18 Poland PL 28 Estonia EE 20 Portugal PT 25 Finland FI 18 Romania RO 24 France FR 27 Slovakia SK 24 Germany DE 22 Slovenia SI 19 Greece GR 27 Spain ES 24 Hungary HU 28 Sweden SE 24 Iceland IS 26 Switzerland CH 21 Ireland IE 22 Türkiye TR 26 United Kingdom GB 22 Norway at 15 and Malta at 31 are the extremes, and the sixteen-character spread between them is the argument against every fixed-length assumption. The standard permits up to 34, so even Malta is not the ceiling — a country could be added tomorrow that is longer.\nSources: ISO 13616 / IBAN standard and the SWIFT IBAN Registry · Verified: 2026-08-04\nTesting SEPA and bank transfer flows Length validation per country. Derive the expected length from the country code rather than accepting anything in a range. The tool above rejects a German IBAN of 21 characters and says why, which is the behaviour to copy. Checksum validation. Run MOD-97 server-side as well as in the browser, with arbitrary precision arithmetic on both sides. BIC handling. Under the SEPA IBAN-only rule the BIC is generally not required for euro transfers. If your form demands one, check whether it actually needs it. Direct debit mandates. A mandate references the IBAN, so test what happens when a customer changes bank — the mandate has to be re-established, and a flow that silently keeps the old IBAN fails collection later, quietly. Error message quality. \u0026ldquo;Invalid IBAN\u0026rdquo; tells a customer nothing. \u0026ldquo;That IBAN is 21 characters; German IBANs are 22\u0026rdquo; tells them where to look. Five mistakes that account for most of it Assuming a fixed length. Covered above, and still the most common. Using a normal number type for MOD-97. Also covered, and the hardest to diagnose. Storing the IBAN with spaces. Display in groups of four; store and compare without them. Otherwise DE89 3704… and DE893704… are two different rows. Rejecting lowercase input. People type lowercase. Normalise to uppercase before validating rather than telling them off. Not validating the country code. Two letters that are not an ISO 3166-1 country cannot be a valid IBAN, and checking that first produces a much better error message than a checksum failure. IBAN and PCI DSS A useful boundary to be clear about: an IBAN is not in scope for PCI DSS. That standard governs payment card data — primary account numbers, security codes, magnetic stripe contents — and a bank account identifier is none of those. Building your bank transfer flow does not drag it into your cardholder data environment.\nIt is not unregulated, though. An IBAN attached to a person is personal data under GDPR, with the same obligations as any other customer record: a lawful basis, a retention period, and a breach notification duty if it leaks. That is precisely why synthetic IBANs belong in your test environment — the same reasoning as for the test identity generator, and a different compliance regime from the card side rather than a lighter one.\nRelated tools and guides For card rather than bank data, the all-network generator produces full records and the bulk generator does it at volume with reproducible seeds. The tool directory lists everything else, and the FAQ covers what a checksum does and does not prove. The payment form testing checklist covers the wider form.\nFrequently Asked Questions What does IBAN stand for? International Bank Account Number. It is a standardised way of writing an existing domestic account number so that it can be recognised across borders — the country code and check digits are wrapped around the account identifier your bank already uses. An IBAN does not replace your account number; it packages it. Are these IBANs real? No. They are structurally correct — the right length for the country, the right mix of letters and digits in the right places, and check digits that pass MOD-97 — but the bank and account portions are random within that shape. No financial institution has any of them on file. Can I receive money with a generated IBAN? No. An IBAN is a pointer to an account, and these point at nothing. A transfer to one will be rejected, usually at the sending bank\u0026rsquo;s validation step and otherwise by the receiving scheme. If a transfer somehow entered the system it would be returned as unmatched, not delivered somewhere convenient. How long is an IBAN? It depends entirely on the country: 15 characters in Norway, 31 in Malta, and most of Europe somewhere between. There is no universal length, and the standard caps it at 34. Any validation with a fixed length in it is wrong for most of the world. What is the difference between IBAN and BIC? The IBAN identifies the account; the BIC, also called the SWIFT code, identifies the bank. They answer different questions. Within SEPA the BIC has largely become unnecessary — the IBAN-only rule means the receiving institution can be derived from the IBAN itself — so a form that still demands a BIC for a euro transfer is asking for something the payment does not need. Why does my IBAN validation fail on long IBANs? Almost certainly because you are doing the modulo with a normal number type. A 31-character IBAN converts to a 45-digit integer, far beyond what a double holds exactly, so the arithmetic silently loses precision and the remainder comes out wrong. Use BigInt in JavaScript, or process the number in chunks. The symptom is distinctive: short IBANs validate fine and long ones fail for no visible reason. ","permalink":"https://ccgenerator.org/iban-generator/","summary":"If you are testing a SEPA transfer, a direct debit mandate, or any bank transfer integration, you need IBANs with correct check digits. This tool produces synthetic IBANs in each country\u0026rsquo;s own format, with valid ISO 7064 MOD-97-10 check digits, and validates ones you paste in. None of them is attached to a real account.\nTest data only\nIBAN Generator and Validator Synthetic IBANs with correct ISO 7064 MOD-97-10 check digits, in each country's own format.","title":"IBAN Generator — Test IBANs with Checksums"},{"content":"This JCB card generator produces Luhn-valid test numbers inside JCB\u0026rsquo;s 3528–3589 range. The network is straightforward in every respect except one, and that one catches almost everybody: JCB starts with 35, but not everything starting with 35 is JCB.\nTest card only\nCredit Card Number Generator Generate dummy card details for development and QA. Nothing is stored or sent to a server.\nSingle card Bulk cards Card network Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Generate Card Card network All Mixed Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Quantity Generate Cards These numbers are dummy, Luhn-valid test values for software testing only. They are not real active cards and cannot be used for payments. Copy all Show JSON Copy JSON Export JSON Export CSV JSON output All Cards Visa Mastercard Amex Discover JCB Diners Maestro UnionPay Troy These are test numbers, not real cards Every number on this page is synthetic test data. It is generated by a formula, not issued by a bank. These numbers are not linked to any person, account, or balance. They carry no funds. They will be declined by every real payment processor. They only pass client-side format and checksum validation. Attempting to use card data to obtain goods, services, or trials you have not paid for is fraud in virtually every jurisdiction. Do not do it. Generation runs entirely in your browser. Nothing is sent to or stored on our servers. Intended use: payment form validation, checkout UI testing, QA test fixtures, and developer demos. For processor-specific behaviour (approvals, declines, refunds, 3-D Secure) use your gateway's official sandbox test cards.\nJCB card number format Property Value BIN range 3528–3589 Standard length 16 digits Permitted length up to 19 digits Check digit Luhn (mod 10) Security code CAV2, 3 digits, on the back Grouping 4-4-4-4 JCB and the 35 prefix trap The Major Industry Identifier 3 covers travel and entertainment, which is why American Express, Diners Club and JCB all live there. Inside it, JCB holds 3528 through 3589 — a four-digit range, not a two-digit one.\nThat distinction is where the bug lives. A very large amount of production code does this:\nif (/^35/.test(number)) return \u0026#39;jcb\u0026#39;; // wrong It looks reasonable and it is wrong at both ends. 3500–3527 and 3590–3599 are outside JCB\u0026rsquo;s allocation. A card in those blocks gets labelled JCB, the wrong brand mark appears in the UI, and if brand drives any downstream logic — routing, surcharge, which acquirer sees the transaction — the wrong decision follows silently. The payment may still succeed, which is what makes it hard to notice.\nThe correct check is four digits deep:\nconst JCB = /^35(2[89]|[3-8]\\d)\\d{12,15}$/; And the boundary tests that prove it:\nJCB.test(\u0026#39;3527000000000000\u0026#39;); // false — one below the range JCB.test(\u0026#39;3528000000000000\u0026#39;); // true — first JCB block JCB.test(\u0026#39;3589000000000000\u0026#39;); // true — last JCB block JCB.test(\u0026#39;3590000000000000\u0026#39;); // false — one above the range Those four assertions take a minute to write and they are the whole story for this network. There is nothing else about JCB that is likely to break your code — no unusual length, no missing security code, no shared range fought over by two schemes. It is a well-behaved network with one sharp edge, and the edge is exactly four digits deep.\nWhy the trap survives code review The ^35 check is not written by careless people. It survives for three specific reasons worth naming, because recognising them is how you stop shipping the next one.\nIt passes every test written alongside it. Whoever wrote the check tested it with a JCB number, and it worked. The failure only appears with a card in 3500–3527 or 3590–3599, and nobody has one of those to hand.\nThe failure is a wrong label, not an error. A card detected as the wrong brand still submits, still authorises, and still completes. There is no exception, no log line, and no support ticket that says \u0026ldquo;the logo was wrong\u0026rdquo; — the customer paid and left.\nThe prefix table people copy is usually right about JCB and wrong about the boundary. Plenty of published brand-detection snippets list JCB as 35, because at two digits that is where the range starts. The four-digit precision gets lost in transcription, and the snippet gets copied onwards.\nThe fix is not more care. It is a boundary test in the suite, which turns a fact somebody has to remember into a fact the build enforces.\nWhere JCB is accepted JCB is Japan\u0026rsquo;s domestic network and a genuine third rail there, not a niche brand. Acceptance is broad across Korea, Taiwan, Thailand, Singapore and much of Southeast Asia, and JCB has spent years extending reach through partnerships rather than building acceptance directly everywhere.\nThe most useful of those for a developer to know about is the reciprocal arrangement with Discover: in the United States, JCB cards commonly clear over Discover rails. As with the other partnerships in Discover Global Network — which also covers Diners Club — the digits do not change. What changes is which network actually carries the authorisation, which is a routing fact rather than a formatting one.\nThe commercial question for a checkout is simple. Selling into Japan or Southeast Asia without JCB means turning away a real share of customers, and they do not usually tell you — they just leave. Selling only to Europe or North America makes JCB optional, though the detection should still be right.\nTesting scenarios The four boundary numbers. 3527, 3528, 3589 and 3590 prefixes, asserted against your detector. This is the test that matters for JCB. Full detection chain. Feed a JCB number through your whole brand-detection function, not just the JCB expression, and confirm no earlier rule claims it — a broad ^3 rule for the travel-and-entertainment MII will. CAV2 length. Three digits. If your code branches on the security code\u0026rsquo;s name rather than the brand\u0026rsquo;s rules, CAV2 must land in the three-digit path. Longer numbers. Generate a nineteen-digit number and confirm your length rule accepts it rather than assuming sixteen. Brand mark rendering. JCB\u0026rsquo;s logo is one that placeholder icon sets frequently omit; confirm the UI has an asset for it rather than falling back to a generic card. The missing brand asset One more JCB-specific detail that is not about digits at all. Icon sets bundled with checkout libraries frequently ship Visa, Mastercard, American Express and Discover, and stop there. JCB is among the first omissions, which means correct detection produces a broken image or a generic grey rectangle where a brand mark should be.\nThat matters more than it sounds in the Japanese market, where JCB is a primary network rather than an alternative one. A checkout that displays every other brand properly and shows a blank box for the customer\u0026rsquo;s own card reads as unfinished, and payment pages get very little benefit of the doubt. Check that your icon set covers all nine networks before you ship detection for them, and use the same list your detection function uses.\nOfficial test numbers For processor behaviour, use the gateway\u0026rsquo;s own sandbox numbers rather than generated ones. Stripe publishes 3566 0020 2036 0505 for JCB, and Adyen and Square both document 3569 9900 1009 5841. The test card numbers reference collects them by gateway alongside the decline codes each one triggers.\nJCB\u0026rsquo;s own developer and acceptance material is published at Global JCB, which is the authoritative source for the network\u0026rsquo;s range allocations and partner arrangements.\nRelated tools and guides To see whether a 35xx number really is JCB, paste it into the validator — it applies the four-digit range rather than the two-digit shortcut this page argues against. The brand detection guide sets out the expression for all nine networks together, which is where boundary mistakes are easiest to spot side by side. The tool directory lists the other generators, and the FAQ explains what a passing checksum does not tell you.\nFrequently Asked Questions What BIN range does JCB use? 3528 to 3589, which is narrower than it looks. The first two digits are 35, but 3500–3527 and 3590–3599 are not JCB. Matching on 35 alone claims about a third of the 35xx space that JCB does not own, which is the single most common JCB detection bug. How many digits is a JCB card? Sixteen in almost all cases, with the specification permitting up to nineteen. Sixteen is a safe default for test fixtures, but a length rule should accept the wider range rather than hard-coding one value. What is the security code on a JCB card called? CAV2, the Card Authentication Value, three digits on the back of the card. Functionally it behaves exactly like Visa\u0026rsquo;s CVV2 and Mastercard\u0026rsquo;s CVC2 — the different name has no effect on field length or handling. Where is JCB accepted? Domestically in Japan it is a primary network, with strong acceptance across Korea, Taiwan, Thailand and much of Southeast Asia. Outside Asia acceptance runs largely through partner networks, most notably a reciprocal arrangement with Discover that lets JCB cards clear on Discover rails in the United States. Should my checkout support JCB? If you sell into Japan or Southeast Asia, yes — it is a meaningful share of volume there and omitting it costs sales you will never see reported as failures. If your customers are entirely European or American, JCB is a low priority, but the detection logic should still be correct so a JCB card does not surface as an unhelpful validation error. Do these generated JCB numbers work for real payments? No. They are correctly formatted and Luhn-valid, which is what makes them useful for testing your own form and brand detection. No issuer has them on file, so any real processor declines them. ","permalink":"https://ccgenerator.org/jcb-card-generator/","summary":"This JCB card generator produces Luhn-valid test numbers inside JCB\u0026rsquo;s 3528–3589 range. The network is straightforward in every respect except one, and that one catches almost everybody: JCB starts with 35, but not everything starting with 35 is JCB.\nTest card only\nCredit Card Number Generator Generate dummy card details for development and QA. Nothing is stored or sent to a server.\nSingle card Bulk cards Card network Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Generate Card Card network All Mixed Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Quantity Generate Cards These numbers are dummy, Luhn-valid test values for software testing only.","title":"JCB Card Generator — Test JCB Numbers"},{"content":"This Maestro card generator produces Luhn-valid test numbers across Maestro\u0026rsquo;s range. The network is worth its own page for one property no other mainstream brand has: the number can be anywhere from twelve to nineteen digits long, which means every assumption your validation makes about length is testable against a single brand.\nTest card only\nCredit Card Number Generator Generate dummy card details for development and QA. Nothing is stored or sent to a server.\nSingle card Bulk cards Card network Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Generate Card Card network All Mixed Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Quantity Generate Cards These numbers are dummy, Luhn-valid test values for software testing only. They are not real active cards and cannot be used for payments. Copy all Show JSON Copy JSON Export JSON Export CSV JSON output All Cards Visa Mastercard Amex Discover JCB Diners Maestro UnionPay Troy These are test numbers, not real cards Every number on this page is synthetic test data. It is generated by a formula, not issued by a bank. These numbers are not linked to any person, account, or balance. They carry no funds. They will be declined by every real payment processor. They only pass client-side format and checksum validation. Attempting to use card data to obtain goods, services, or trials you have not paid for is fraud in virtually every jurisdiction. Do not do it. Generation runs entirely in your browser. Nothing is sent to or stored on our servers. Intended use: payment form validation, checkout UI testing, QA test fixtures, and developer demos. For processor-specific behaviour (approvals, declines, refunds, 3-D Secure) use your gateway's official sandbox test cards.\nMaestro card number format Property Value BIN ranges 50, 56–69 Length 12–19 digits Check digit Luhn (mod 10) Security code CVC2, 3 digits — absent on some cards Funding Debit only Status Retiring — no new EEA issuance since July 2023 Maestro breaks every length assumption Eight valid lengths. Not \u0026ldquo;sixteen, but occasionally nineteen\u0026rdquo; — genuinely eight, from twelve digits to nineteen, all in circulation at the same time.\nThat single fact invalidates a family of shortcuts that are otherwise almost safe:\nA fixed maxlength on the input truncates longer cards A submit button that enables at sixteen digits never enables for a twelve-digit card, and fires too early for a nineteen-digit one A 4-4-4-4 mask produces a ragged display at every length except sixteen A CHAR(16) column pads or truncates on the way in A \\d{16} regex rejects most of the range There is a second lockout that has nothing to do with length. Some Maestro cards were issued with no printed security code. A checkout that marks CVC required for every brand makes those cards impossible to use — the cardholder has nothing to type. The field should become optional when Maestro is detected, which is a brand-conditional rule most forms do not have. Some Maestro cards also never supported online transactions at all, being chip-and-PIN only; those will fail at the processor regardless of what your form does, and the honest response is a clear decline message rather than a validation error implying the customer typed something wrong.\nDetection order decides the answer Maestro claims 50 and the whole of 56–69. Discover holds 65 and 644–649, which sit inside that block, and UnionPay holds 62, also inside it. All three claims are legitimate — the ranges are co-allocated and the real network is determined by the issuer rather than the prefix alone.\nFor code, this means the order of your checks is not a style choice. It changes the output:\n// Order matters: check the specific ranges before Maestro\u0026#39;s broad one. function detect(n) { if (/^(6011|64[4-9]|65)/.test(n)) return \u0026#39;discover\u0026#39;; if (/^62/.test(n)) return \u0026#39;unionpay\u0026#39;; if (/^(5[1-5]|2[2-7])/.test(n)) return \u0026#39;mastercard\u0026#39;; if (/^(50|5[6-9]|6[0-9])/.test(n)) return \u0026#39;maestro\u0026#39;; return \u0026#39;unknown\u0026#39;; } Move the Maestro line up and every Discover and UnionPay card in the shared block is misidentified. The failure is quiet — brand marks are wrong, brand-conditional rules like CVC length or surcharge take the wrong branch, and nothing throws. A test that asserts a 65 number resolves to Discover and a 62 number to UnionPay, run through the whole chain rather than individual expressions, is the one that catches it.\nThe full Maestro expression, for a single-brand check:\nconst MAESTRO = /^(50|5[6-9]|6[0-9])\\d{10,17}$/; MAESTRO.test(\u0026#39;500000000000\u0026#39;); // true — 12 digits, shortest valid MAESTRO.test(\u0026#39;5000000000000000000\u0026#39;); // true — 19 digits, longest valid MAESTRO.test(\u0026#39;50000000000\u0026#39;); // false — 11 digits, too short MAESTRO.test(\u0026#39;5500000000000000\u0026#39;); // false — Mastercard\u0026#39;s block, not Maestro Where Maestro is accepted, and for how long Maestro was Mastercard\u0026rsquo;s European debit workhorse, strongest in Germany, the Netherlands, Belgium and across Central and Eastern Europe, and it appeared widely in point-of-sale acceptance where online acceptance was patchy.\nThat is changing on a published timetable. Issuers in the European Economic Area could not issue new Maestro cards after 1 July 2023, and Debit Mastercard is the replacement. Cards issued before the cutoff stay valid until they expire, which takes the last of them to 2027 at the latest.\nThe practical reading for a developer: Maestro is a shrinking share of traffic but not yet a zero one, and the length handling it forces you to get right is the same handling every other network benefits from. When the last Maestro card expires, the twelve-to-nineteen digit rule is still the correct rule — see the debit card generator for how the funding-type question outlives the brand.\nWhat to keep after Maestro is gone It is tempting to treat the retirement as permission to delete the special cases. Most of them should stay, and separating the two categories is worth doing deliberately.\nDelete when the last card expires: the Maestro branch in your brand-detection function, the Maestro logo asset, and any Maestro-specific copy in your checkout. These describe a brand that no longer exists.\nKeep permanently: the twelve-to-nineteen digit length rule, because it is what ISO/IEC 7812 permits and other networks use the wider parts of it. The brand-conditional security-code handling, because American Express still needs four digits and other products still vary. The detection-order discipline, because Discover and UnionPay continue to share ranges regardless of what happens to Maestro. And the habit of warning rather than blocking on validation failures, which never depended on Maestro at all.\nThe pattern generalises: a network retiring removes a brand, not the reasons the flexible rules existed. Code that hard-codes sixteen digits will still be wrong on the day the last Maestro card expires — it will just take longer to find out.\nTesting scenarios Every length. Generate twelve, thirteen, sixteen and nineteen digit numbers and run each through the form end to end. This one test finds most hard-coded lengths in a codebase. Detection order. Assert 65, 644 and 62 prefixes through the full chain, not the Maestro expression alone. Optional CVC. Confirm the security-code field becomes optional when Maestro is detected, and that submitting without it works. Mask behaviour. Type a twelve-digit number and a nineteen-digit one and watch the grouping; a fixed 4-4-4-4 mask will look broken at both. Column width. Nineteen digits, stored and read back, compared byte for byte. Official test numbers For processor behaviour rather than format coverage, use the gateway\u0026rsquo;s own numbers. Adyen documents 6771 7980 2100 0008 for Maestro, PayPal publishes 6304 0000 0000 0000, and Braintree uses the same. The test card numbers reference collects them by gateway with the decline codes each one produces.\nMastercard\u0026rsquo;s own guidance on the Maestro transition is published at Mastercard, and Adyen maintains a clear summary of the Debit Mastercard replacement.\nThe retirement timeline above were last checked against provider documentation on 4 August 2026. Providers do change what they publish — the official link beside each claim is authoritative. Related tools and guides Because the shared ranges make detection ambiguous, the validator is the quickest way to see which network a 6x number resolves to under a correctly ordered chain. The length reference lists what every network permits, which is the table to check a maxlength against. The tool directory has the remaining generators, and the FAQ covers the limits of checksum validation.\nFrequently Asked Questions How many digits is a Maestro card? Anywhere from twelve to nineteen. Maestro is the one mainstream network that used the full range ISO/IEC 7812 permits, which means eight different valid lengths rather than one. Any validation stricter than that range will reject real cards. Why does my form reject a 13-digit Maestro card? Because the length check hard-codes sixteen, which is the most common card-validation bug there is. Maestro is simply the network that finds it fastest. Validate the checksum and accept twelve to nineteen digits, then let the processor make the real decision. Do all Maestro cards have a CVC? No, and this one causes real lockouts. Some Maestro cards were issued without a printed security code at all. A checkout that marks the CVC field required for every brand makes those cards unusable, so the field should be optional when Maestro is detected. Why do Maestro and Discover ranges overlap? Because Maestro claims 56–69 as a broad block while Discover holds specific ranges inside it, notably 65 and 644–649. Both claims are legitimate. The consequence is that detection order decides the answer: check Discover\u0026rsquo;s specific ranges before Maestro\u0026rsquo;s broad one, or a large share of Discover cards will be labelled Maestro. Is Maestro being discontinued? Yes, gradually. Mastercard stopped new Maestro issuance in the European Economic Area from 1 July 2023, replacing it with Debit Mastercard. Cards issued before that date remain valid until they expire, which runs to 2027 at the latest — so validation still has to accept them for now. Do these generated Maestro numbers work for real payments? No. They are Luhn-valid and correctly formatted, which is what makes them useful for testing length handling and detection order. No issuer has them on file, so any real processor declines them. ","permalink":"https://ccgenerator.org/maestro-card-generator/","summary":"This Maestro card generator produces Luhn-valid test numbers across Maestro\u0026rsquo;s range. The network is worth its own page for one property no other mainstream brand has: the number can be anywhere from twelve to nineteen digits long, which means every assumption your validation makes about length is testable against a single brand.\nTest card only\nCredit Card Number Generator Generate dummy card details for development and QA. Nothing is stored or sent to a server.","title":"Maestro Card Generator — Test Numbers"},{"content":" Test card only\nCredit Card Number Generator Generate dummy card details for development and QA. Nothing is stored or sent to a server.\nSingle card Bulk cards Card network Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Generate Card Card network All Mixed Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Quantity Generate Cards These numbers are dummy, Luhn-valid test values for software testing only. They are not real active cards and cannot be used for payments. Copy all Show JSON Copy JSON Export JSON Export CSV JSON output All Cards Visa Mastercard Amex Discover JCB Diners Maestro UnionPay Troy These are test numbers, not real cards Every number on this page is synthetic test data. It is generated by a formula, not issued by a bank. These numbers are not linked to any person, account, or balance. They carry no funds. They will be declined by every real payment processor. They only pass client-side format and checksum validation. Attempting to use card data to obtain goods, services, or trials you have not paid for is fraud in virtually every jurisdiction. Do not do it. Generation runs entirely in your browser. Nothing is sent to or stored on our servers. Intended use: payment form validation, checkout UI testing, QA test fixtures, and developer demos. For processor-specific behaviour (approvals, declines, refunds, 3-D Secure) use your gateway's official sandbox test cards.\nThis Mastercard generator — often searched as a master card generator — produces Luhn-valid test numbers across both of Mastercard\u0026rsquo;s BIN ranges, not just the familiar one. That matters more than it sounds, and the section below explains why: a large amount of payment code in production today rejects legitimate Mastercards because it has never been updated for the 2-series.\nMastercard number format Property Value First digit (MII) 5 or 2 Legacy BIN range 51–55 2-series BIN range 2221–2720 (introduced 2017) Length 16 digits Check digit Luhn (mod 10) Security code name CVC2 Security code length 3 digits The 2-series problem Mastercard ran out of room. The 51–55 block had been the whole of the network\u0026rsquo;s issuance space since the beginning, and by the mid-2010s it was close to exhausted. Mastercard announced the 2221–2720 range in 2016 and issuers began putting cards on it in 2017. In six-digit BIN terms that is 222100 through 272099.\nThe 2-series is not a test range, not a special product, and not regional. It is ordinary issuance, and there are a great many such cards in circulation. But an enormous amount of validation code was written when ^5[1-5] was a complete description of Mastercard, and that code is still running.\nThe pattern that is wrong:\nconst MASTERCARD_WRONG = /^5[1-5]\\d{14}$/; The pattern that is right:\nconst MASTERCARD = /^(5[1-5]\\d{4}|222[1-9]\\d{2}|22[3-9]\\d{3}|2[3-6]\\d{4}|27[01]\\d{3}|2720\\d{2})\\d{10}$/; Why the 2-series needs five alternatives A numeric range is not a string prefix. 2221–2720 cannot be written as a simple character class, because the digits are constrained differently depending on what came before them. Splitting the range into blocks where each digit position has a clean rule gives this:\nSub-range Regex fragment 2221–2229 222[1-9] 2230–2299 22[3-9]\\d 2300–2699 2[3-6]\\d\\d 2700–2719 27[01]\\d 2720 2720 Each fragment matches four digits; the pattern above pads each to six with \\d and then requires the remaining ten, for a fixed total of 16.\nThe boundary tests it has to pass Range logic is where off-by-one errors live, so test the edges rather than the middle:\nconst cases = [ [\u0026#39;2220000000000000\u0026#39;, false], [\u0026#39;2221000000000000\u0026#39;, true], [\u0026#39;2720000000000000\u0026#39;, true], [\u0026#39;2721000000000000\u0026#39;, false], [\u0026#39;5050000000000000\u0026#39;, false], [\u0026#39;5100000000000000\u0026#39;, true], [\u0026#39;5599000000000000\u0026#39;, true], [\u0026#39;5600000000000000\u0026#39;, false], ]; cases.forEach(([n, want]) =\u0026gt; { const got = MASTERCARD.test(n); console.assert(got === want, `${n}: expected ${want}, got ${got}`); }); All eight pass against the corrected pattern. Run the same eight against MASTERCARD_WRONG and two of them fail — 2221… and 2720…, the two that represent real cards. That is the bug, reproduced in four lines.\nThese eight are shape assertions, so they use filler digits and are not Luhn-valid. To test shape and checksum together, generate numbers with the tool above: it draws from both ranges, so a batch will exercise the 51–55 and 2221–2720 paths through your detection code. Two Luhn-valid examples, one from each range:\n5-series 5425 2334 3010 9903 2-series 2221 0011 2233 4458 Mastercard product types Mastercard Standard / World / World Elite — tiers of the same credit product, no distinguishing pattern in the number Mastercard Debit — issued on the same ranges as credit Mastercard Prepaid — again, the same ranges Maestro — a separate scheme on its own BINs, covered below As with every network, the product type is not encoded in the number. Standard, World Elite, debit, and prepaid all look alike from the digits alone; that classification lives in the issuer\u0026rsquo;s BIN table. Routing or fee logic that needs it requires a BIN lookup service — see the BIN and IIN guide.\nTesting scenarios specific to Mastercard Both ranges, separately. Generate a batch and confirm your detection labels the 2221–2720 numbers as Mastercard, not as unknown. This is the test that catches the 2-series bug.\nFixed 16-digit length. Mastercard is always 16 digits, so unlike Visa a strict length === 16 check is correct here. Reusing Visa\u0026rsquo;s more permissive length rule is harmless; reusing Mastercard\u0026rsquo;s on Visa is not.\nCVC2 field length. Three digits. If your security-code field is fixed at four for American Express, Mastercard needs it to shrink back.\nBrand detection timing. A leading 5 narrows the field quickly, but a leading 2 does not identify anything on its own — you need four digits before you can say the card is a 2-series Mastercard. Detection that commits after one or two digits will show the wrong mark and then have to correct itself as the user keeps typing.\nInput mask. 4-4-4-4 at 16 digits, the same as Visa.\nLuhn rejection. Alter the final digit of a generated number and confirm the form rejects it.\nMastercard vs Maestro Maestro is operated by Mastercard but is a different scheme with different rules, and code that treats them as one thing will get both wrong:\nMastercard Maestro BIN ranges 51–55, 2221–2720 50, 56–69 Length 16 digits, fixed 12–19 digits Funding Credit, debit, prepaid Debit only Security code CVC2, 3 digits Often present, but some issuers omitted it The variable length is the part that breaks things: a Maestro number can be 12 digits or 19, so any length check narrower than that range will reject valid cards. The Maestro generator covers that range and the detection-order problem it creates with Discover and UnionPay, and the all-network generator includes Maestro in its picker.\nOfficial Mastercard test numbers Mastercard and every major gateway publish their own test numbers. Those are registered in the processor\u0026rsquo;s sandbox and return genuine authorisation responses; the numbers here do not.\nThis generator Gateway sandbox card Passes client-side Luhn check Yes Yes Triggers Mastercard brand detection Yes Yes Covers both BIN ranges Yes Rarely — usually a 5-series number only Unlimited unique numbers Yes No — a handful of fixed numbers Returns an authorisation response No Yes Triggers specific decline codes No Yes Works with 3-D Secure flows No Yes The third row is the one worth noting: gateway documentation still tends to give a single 5555… example, so a sandbox test suite can pass while the 2-series path has never been exercised at all. That is precisely the gap this generator fills.\nFor processor behaviour, use the official numbers — Stripe and PayPal document theirs in full, and we collect the equivalents on the test card numbers reference. Card number structure in general is covered by ISO/IEC 7812.\nOther networks have their own pages: Visa, American Express, and Troy. The tool directory lists everything else, and the FAQ covers what a Luhn-valid number does and does not prove.\nFrequently Asked Questions Do all Mastercard numbers start with 5? No, and this is the most consequential misconception about the network. Mastercard issues on two ranges: the legacy 51–55 block and the 2-series block from 2221 to 2720, which entered circulation in 2017. A card beginning with 2 can be a perfectly ordinary Mastercard. What is the 2-series BIN range? It is the block of Mastercard BINs from 2221 through 2720 — six-digit BINs 222100 to 272099. Mastercard announced it in 2016 and began issuing on it in 2017, after the 51–55 space ran short. It is not a special product or a test range; it is ordinary issuance. How many digits does a Mastercard number have? 16, in both BIN ranges. Unlike Visa, which permits 13, 16, and 19, Mastercard is fixed at 16 digits, so a length check for exactly 16 is correct here. What is CVC2? CVC2 is Mastercard\u0026rsquo;s name for the three-digit security code printed on the signature panel. Visa calls the same thing CVV2 and American Express calls it CID and uses four digits. The issuer computes it from the card number, the expiry date, and two secret keys, so it cannot be derived from the number by anyone else. Why does my form reject a valid Mastercard starting with 2? Almost certainly because your brand-detection pattern is still ^5[1-5], written before the 2-series existed. That pattern rejects every 2-series card. The fix is a regex that covers both ranges — there is one on this page, with the boundary tests it has to pass. Is 5555 5555 5555 4444 a real Mastercard? No. It is the most widely published Mastercard test number in the industry and appears in the documentation of nearly every payment gateway. It is Luhn-valid and deliberately not assigned to any account. If you find it in a data set, that data set is test data. What is the difference between Mastercard and Maestro? Maestro is a separate scheme operated by Mastercard, issued on its own BIN ranges (50 and 56–69) with a variable length of 12 to 19 digits rather than a fixed 16. It is a debit-only product, and in some markets it was issued without a security code at all. Detection and length rules written for Mastercard will not cover Maestro. ","permalink":"https://ccgenerator.org/mastercard-generator/","summary":"Test card only\nCredit Card Number Generator Generate dummy card details for development and QA. Nothing is stored or sent to a server.\nSingle card Bulk cards Card network Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Generate Card Card network All Mixed Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Quantity Generate Cards These numbers are dummy, Luhn-valid test values for software testing only. They are not real active cards and cannot be used for payments.","title":"Mastercard Generator — Test Numbers"},{"content":"Effective date: August 2, 2026 Last updated: August 2, 2026\n1. Introduction CC Generator (ccgenerator.org) is a free developer tool that produces Luhn-valid dummy payment card numbers for testing checkout forms, card brand detection, and QA fixtures. More about why the site exists is on our About page.\nThis Privacy Policy explains what the site collects, why, how long it is kept, and what you can do about it. It covers ccgenerator.org and its subdomains, and no other site you reach from here.\nThere is no account, no sign-up, no login, and nothing to pay for. You can use every feature of the generator without telling us who you are.\n2. The most important thing: we never see your generated card data This is the part most people actually care about, so it comes first.\nCard generation happens entirely inside your browser. When you press Generate Card, your browser runs JavaScript that has already been downloaded to your device. That script picks a card network rule, draws random digits using the browser\u0026rsquo;s built-in random number generator, calculates the final Luhn check digit, and writes the result into the page.\nAt no point does that process contact our servers. There is no API call, no background request, no analytics event carrying card data, and no logging of generated values. Copying a number and exporting to JSON or CSV are local too: export files are assembled in your browser\u0026rsquo;s memory and handed to your own download folder. Nothing is uploaded.\nYou do not have to take our word for it. You can verify this yourself in under a minute:\nOpen your browser\u0026rsquo;s developer tools (F12, or Cmd+Option+I on macOS). Switch to the Network tab and clear the existing entries. Generate a card, or generate twenty in bulk. Watch the Network tab. No request is made when you generate. You can also disconnect from the internet entirely after the page has loaded. The generator will keep working, because there is nothing on the other end for it to talk to.\nThe practical consequence: we could not hand over your generated card numbers to anyone — not to an advertiser, not to a data broker, not to a court — because we never had them. They existed only in your browser\u0026rsquo;s memory and disappeared when you closed the tab.\n3. Information we collect 3.1 Information you provide to us The only way to give us personal information is to send it deliberately — by emailing us or using our Contact page. We then receive whatever you include: usually your email address, your name if you sign it, and your message. We use it to answer you and nothing else.\nPlease do not send us real payment card details or other sensitive personal data. We have no use for them and no reason to hold them.\n3.2 Information collected automatically Like almost every website, ours records some technical information automatically:\nServer and CDN logs. Our static host records the requesting IP address, the requested URL, the HTTP status code, the timestamp, the referring page, and the browser user agent. These logs keep the site online and help detect abuse such as denial-of-service traffic. Analytics events. Google Analytics 4 records page views, approximate location derived from a truncated IP address, device type, browser and operating system, and the path you take through the site. See section 6. Advertising signals. Google AdSense and its partners may read and write cookies or similar identifiers to serve and measure ads. See section 5. 3.3 Information we explicitly do not collect We do not collect, receive, store, log, or transmit any of the following:\nCard numbers, CVV/CVC values, expiry dates, or cardholder names generated on this site. These never reach us. See section 2. Real payment card data of any kind. Your name, postal address, phone number, or date of birth. Bank account details, financial records, or credit history. Account credentials — there are no accounts. Biometric data, precise geolocation, or health information. We also do not buy data about our visitors from third parties.\n4. Cookies and similar technologies A cookie is a small text file a site stores in your browser. Some browser storage is not technically a cookie but works similarly; we treat both here.\n4.1 Strictly necessary Required for the site to work, and set by us. We use browser localStorage — not cookies — for two preferences: pref-theme, which remembers light or dark mode, and menu-scroll-position, which keeps the navigation menu where you left it. Both stay on your device, are never transmitted, and contain no identifier. Under the ePrivacy Directive these do not require consent.\n4.2 Analytics Google Analytics 4 sets cookies to distinguish one visitor from another and to measure session length, so we can see which pages are useful. Where consent is legally required, these are only set after you agree.\n4.3 Advertising Google and its advertising partners set cookies to select which ads to show, cap how often you see the same ad, and measure whether an ad worked. Details in the next section. Where consent is legally required, these are only set after you agree.\nYou can block or delete cookies at any time through your browser settings. Blocking analytics and advertising cookies will not stop the card generator from working.\n5. Google AdSense and third-party advertising This site is supported by advertising. We use Google AdSense. The following disclosures are required by Google and apply to your visit:\nGoogle, as a third-party vendor, uses cookies to serve ads on this site. Google\u0026rsquo;s use of the DoubleClick DART cookie enables it and its partners to serve ads to you based on your visit to this site and other sites on the internet. You may opt out of the use of the DART cookie for personalised advertising by visiting the Google ads settings page: https://www.google.com/settings/ads You may opt out of the use of cookies by third-party vendors and ad networks by visiting the Digital Advertising Alliance opt-out page: https://www.aboutads.info/choices/ Google\u0026rsquo;s advertising policies and a current list of how Google uses data in advertising are published at https://policies.google.com/technologies/ads Third-party vendors and ad networks other than Google may also serve ads here. We do not control the cookies those vendors set and we do not receive the personal data they collect. Opting out through the links above does not remove advertising — it makes it less personalised. Ads are never allowed to interfere with the generator or to be styled to look like part of the tool.\n6. Google Analytics We use Google Analytics 4 (GA4) to see how many people use the site and which pages they find. GA4 does not log full IP addresses — they are truncated and discarded during collection — and we have not enabled Google Signals or advertising-personalisation features inside Analytics.\nWe read this data in aggregate (\u0026ldquo;the Visa page had 4,000 visits last month\u0026rdquo;), never to build a profile of an individual, and we upload no user IDs or other identifiers to Google.\nIf you would rather not be counted at all, Google publishes an official browser add-on that blocks Analytics on every site you visit: https://tools.google.com/dlpage/gaoptout\n7. Legal bases for processing (GDPR) If you are in the European Economic Area or the United Kingdom, we process personal data on the following legal bases under Article 6 of the GDPR:\nData Purpose Legal basis IP address, user agent, request logs Serving the site, security, abuse and fraud prevention Legitimate interest (Art. 6(1)(f)) — keeping a free service available and secure Analytics cookies and GA4 events Understanding traffic and improving pages Consent (Art. 6(1)(a)) Advertising cookies and identifiers Serving and measuring ads that fund the site Consent (Art. 6(1)(a)) Email address and message content Replying to your enquiry Legitimate interest (Art. 6(1)(f)), or contract performance where you are asking about a service Theme and menu preferences in localStorage Remembering your display settings Legitimate interest (Art. 6(1)(f)) — strictly necessary for the interface you asked for Where consent is the basis, you can withdraw it at any time using the cookie preferences control on the site or by clearing cookies in your browser. Withdrawing consent does not affect processing that already happened.\n8. Your rights 8.1 If you are in the EEA or the UK (GDPR) You have the right to:\nAccess the personal data we hold about you. Rectify data that is inaccurate or incomplete. Erase your data (\u0026ldquo;right to be forgotten\u0026rdquo;). Restrict processing while a dispute is resolved. Portability — receive your data in a machine-readable format. Object to processing based on legitimate interest, including profiling for advertising. Withdraw consent at any time, without affecting past processing. Complain to your national data protection authority. You need not contact us first, though we would like the chance to fix the problem. In practice the only personal data we are likely to hold about you is an email you sent us and some short-lived log entries. Requests are free and answered within 30 days.\n8.2 If you are in California (CCPA/CPRA) You have the right to know what personal information is collected, to request deletion or correction, to opt out of the sale or sharing of personal information, and not to be discriminated against for exercising these rights.\nWe do not sell your personal information, and we have never sold it. We do not sell or share the personal information of anyone we know to be under 16.\nCalifornia law treats some third-party advertising cookies as \u0026ldquo;sharing\u0026rdquo; for cross-context behavioural advertising. To opt out of that, use the cookie preferences control on the site, the DAA opt-out at https://www.aboutads.info/choices/, or send a Global Privacy Control signal from your browser — we honour GPC.\n8.3 Other regions Brazil (LGPD). You have broadly equivalent rights to confirmation of processing, access, correction, anonymisation or deletion, portability, and information about sharing. Canada (PIPEDA). You may request access to your personal information, challenge its accuracy, and withdraw consent for analytics and advertising at any time. Elsewhere. If your local law gives you privacy rights we have not listed, write to us and we will apply them. 9. Data retention We keep data for as short a time as is practical:\nData Retention Server and CDN access logs 30 days, then deleted automatically Google Analytics 4 event data 14 months (the shortest retention GA4 offers), then deleted Emails you send us 24 months from the last message in the thread Generated card numbers Not applicable — never collected Advertising cookie lifetimes are set by Google and its partners, not by us; they are documented at https://policies.google.com/technologies/ads.\n10. International data transfers Our hosting provider, Google Analytics, and Google AdSense operate globally, so your data may be processed on servers in the United States or other countries whose data protection laws differ from those where you live.\nTransfers out of the EEA or the UK rely on the European Commission\u0026rsquo;s Standard Contractual Clauses (and the UK International Data Transfer Addendum where applicable), together with any adequacy decision covering the recipient — including the EU-US Data Privacy Framework, in which Google participates.\n11. Children\u0026rsquo;s privacy This site is a developer tool aimed at adults working in software. It is not directed at children. We do not knowingly collect personal information from children under 13 (COPPA, in the United States) or under 16 (GDPR, in the EEA), and we do not serve personalised advertising to anyone we know to be under those ages.\nIf you believe a child has provided us with personal information, email privacy@ccgenerator.org and we will delete it.\n12. Security The site is served over HTTPS/TLS only, with HTTP requests redirected. It is a static site: no application server, no database, no user table, no session store. That removes most of the attack surface a conventional web app has — there is no login to breach and no stored records to leak. Card generation is client-side, so there is no server-side copy of generated data to protect in the first place. Access to our hosting and analytics accounts is limited and protected by two-factor authentication. No system is perfectly secure, and we cannot guarantee data in transit over the public internet. What we can say is that the amount of personal data we hold is deliberately close to zero.\n13. Third-party links The site links to external resources — payment gateway sandbox documentation, standards bodies, and similar — and carries advertisements that link to advertisers\u0026rsquo; sites.\nOnce you follow a link away from ccgenerator.org, this policy no longer applies. We do not control those sites and are not responsible for their content, their privacy practices, or what they do with your data. Read their policies before giving them information.\n14. Changes to this policy We may update this policy when the site changes, when we add or remove a third-party service, or when the law requires it. The revised version is published on this page with a new \u0026ldquo;Last updated\u0026rdquo; date at the top.\nMaterial changes — for example a new category of data collection — will be announced with a notice on the site for at least 30 days before they take effect. Continuing to use the site after a change means you accept the updated policy. Previous versions are available on request.\n15. Contact us Questions, requests, or complaints about privacy:\nEmail: privacy@ccgenerator.org\nTell us what you are asking for and, if you are exercising a legal right, which right and which jurisdiction. We reply within 30 days. If a request is complex we will say so and may extend by a further 60 days, as GDPR and CCPA both allow.\nFor anything that is not a privacy matter, use the Contact page.\nSee also: Terms of Service · Disclaimer · About\n","permalink":"https://ccgenerator.org/privacy-policy/","summary":"Effective date: August 2, 2026 Last updated: August 2, 2026\n1. Introduction CC Generator (ccgenerator.org) is a free developer tool that produces Luhn-valid dummy payment card numbers for testing checkout forms, card brand detection, and QA fixtures. More about why the site exists is on our About page.\nThis Privacy Policy explains what the site collects, why, how long it is kept, and what you can do about it. It covers ccgenerator.","title":"Privacy Policy"},{"content":"Effective date: August 2, 2026\n1. Agreement to Terms These Terms of Service govern your use of ccgenerator.org (\u0026ldquo;CC Generator\u0026rdquo;, \u0026ldquo;the site\u0026rdquo;, \u0026ldquo;we\u0026rdquo;, \u0026ldquo;us\u0026rdquo;). By opening the site, generating test data, or using any feature, you agree to them. If you do not agree, stop using the site.\nThere is no account and nothing to pay, so these terms — read together with our Privacy Policy and Disclaimer — are the whole agreement between us. If you are using the site for a company, you confirm you may accept these terms on its behalf.\n2. What This Service Is CC Generator is a client-side test data utility. It produces synthetic card numbers that satisfy the Luhn checksum and the published format rules of major card networks. It is functionally equivalent to the test card numbers published by payment processors such as Stripe, Adyen, and PayPal, and is intended for the same purpose: verifying that software handles card input correctly.\nThat comparison defines the category this tool belongs to. Stripe publishes 4242 4242 4242 4242; Adyen and PayPal publish their own sandbox lists. Every provider does, because software that accepts card input has to be tested and nobody wants that done with a real card. Those published numbers are structurally identical to what this site produces: correct length, correct network prefix, correct Luhn check digit, no issuing bank behind them.\nThe difference is scope, not kind. A processor\u0026rsquo;s list is short and fixed, each number tied to a rehearsed outcome in its sandbox. This site generates as many format-correct numbers as you need across eight networks — useful earlier in development, when you are testing your own input handling rather than a processor\u0026rsquo;s responses. For processor-specific behaviour, use your gateway\u0026rsquo;s official sandbox test cards.\nEverything runs in your browser; we never receive the numbers you generate. See the Privacy Policy for the technical detail and how to verify it.\n3. What This Service Is Not To remove any ambiguity:\nWe are not a card issuer. We do not issue payment cards and have no ability to. We are not a virtual card (VCC) provider. We do not supply funded, prepaid, disposable, or single-use cards of any kind. We are not a payment processor. We do not process, authorise, settle, or refund transactions. We are not affiliated with any bank, card network, or financial institution. Visa, Mastercard, American Express, Discover, JCB, Diners Club, Maestro, and Troy are trademarks of their respective owners. We use those names descriptively, to identify which number format is generated. Nothing here implies endorsement, partnership, or approval. We do not — and cannot — produce working, funded, or usable cards. A number generated here has no issuing bank, no account, and no balance. It is a string of digits that satisfies a checksum, and it will be declined by every real payment system. If you arrived looking for a card that can spend money, no lawful service provides that, and this is not one.\n4. Acceptable Use The site exists for software testing, development, and education. The following uses are expressly permitted, for personal and commercial purposes alike:\nPayment form input validation testing — checking that your form accepts well-formed numbers, rejects malformed ones, and produces the right error messages. Checkout UI and UX development and QA — building and reviewing card entry screens, masked inputs, formatting behaviour, keyboard handling, and error states. Card brand detection and BIN routing logic testing — verifying that your code identifies the right network from a prefix and routes accordingly. Test fixture data for automated test suites — seeding unit, integration, and end-to-end tests with deterministic, safe values instead of real card data. Software demonstrations and training material — populating a demo checkout, a screen recording, a tutorial, or a sales walkthrough without exposing anyone\u0026rsquo;s real card. Teaching the Luhn algorithm and card number structure — classroom use, workshops, documentation, and articles about how card numbering works. Data masking and anonymisation testing — validating that your redaction, tokenisation, or log-scrubbing pipeline handles card-shaped strings correctly. Compliance and security exercises — checking that a system never stores or logs card numbers, without bringing real cardholder data into scope. The unifying principle: use the numbers to test software, not to obtain anything of value. Our FAQ answers common questions, and About explains why the site exists.\n5. Prohibited Use The following are strictly prohibited. Doing any of them ends your right to use the site immediately and may be a criminal offence where you live.\nAttempting any commercial transaction with a generated number — any purchase, payment, transfer, donation, or top-up, anywhere, for any amount. Attempting to obtain a free trial, subscription, or unauthorised access to any product or service by supplying a generated number where a real card is required. Circumventing age, identity, or payment verification systems, including any check that uses card data to confirm who or how old someone is. Deceiving any person or organisation, including presenting generated data as your own card, someone else\u0026rsquo;s card, or evidence of ability to pay. Presenting or selling these numbers as real card data, or incorporating them into any list, dataset, product, or service that is represented as containing genuine card details. Unauthorised automated access — scraping, mass automated requests, or any use that degrades the service for other people. Reasonable, occasional programmatic use for your own testing is fine; hammering the site is not. Any use that violates applicable law, including fraud, computer misuse, payment card legislation, data protection law, and sanctions rules. Reselling or rebranding the service as your own, or removing the notices that identify the output as test data. These numbers cannot be used for the prohibited purposes above — they are declined by every real payment system. But intent matters legally even when the attempt fails. Attempting to obtain goods, services, or trials through card data you are not entitled to use constitutes fraud in most jurisdictions, regardless of whether the attempt succeeds. If that is your goal, this is not the site you need, and no site can provide it lawfully.\nWe may block access to anyone we reasonably believe is using the site for a prohibited purpose, and we will cooperate with lawful requests from law enforcement.\n6. No Warranty The site is provided \u0026ldquo;as is\u0026rdquo; and \u0026ldquo;as available\u0026rdquo;, without warranty of any kind, express or implied, including any implied warranty of merchantability, fitness for a particular purpose, accuracy, or non-infringement.\nWe do not warrant that the site will be uninterrupted, secure, or error-free, that generated numbers will match any particular network specification or BIN range, or that any defect will be corrected. Card network rules change and output may not reflect the current rules. Verify anything that matters against your processor\u0026rsquo;s own documentation.\n7. Limitation of Liability To the fullest extent permitted by law, we are not liable for any indirect, incidental, special, consequential, exemplary, or punitive damages, or for any loss of profits, revenue, data, goodwill, or business opportunity, arising out of your use of or inability to use the site — even if we were advised such damages were possible.\nOur total aggregate liability for all claims relating to the site is limited to one hundred Turkish lira (₺100), reflecting that the service is free of charge.\nWhere a jurisdiction does not allow these exclusions, they apply to the maximum extent permitted. Nothing here excludes liability for death or personal injury caused by negligence, for fraud, or for anything else that cannot lawfully be excluded.\n8. Indemnification You agree to indemnify, defend, and hold harmless CC Generator, its operator, and anyone acting on its behalf against any claim, demand, loss, liability, damage, cost, or expense (including reasonable legal fees) arising out of or related to your breach of these terms, your misuse of the site, or your violation of any law or third-party right in connection with your use of the site or the data you generate with it.\n9. Intellectual Property The site\u0026rsquo;s source code, page content, layout, and branding are owned by us and protected by copyright. You may not copy, republish, or create derivative works from the site\u0026rsquo;s content for commercial redistribution without written permission. Ordinary use — reading, quoting with attribution, linking, and using the tool as intended — is welcome.\nWe claim no rights in the numbers you generate. They are sequences of digits produced by a public checksum formula. Use them however these terms permit, with no attribution required and no licence from us needed.\nThird-party names and marks referenced on the site belong to their owners, as noted in section 3.\n10. Third-Party Services The site uses Google AdSense to display advertising and Google Analytics to measure traffic, so your use is also subject to Google\u0026rsquo;s terms and policies. We do not control what those services do with the data they collect; the Privacy Policy explains what is collected and how to opt out.\nThe site links to external resources, including payment gateway documentation, and displays ads that link to third-party sites. We do not endorse and are not responsible for those sites or their practices.\n11. Availability and Changes to the Service We may change, suspend, restrict, or discontinue the site or any feature at any time, with or without notice, and may limit use or block access from particular addresses or regions to keep the service available and lawful. The site is free: we guarantee no level of availability and owe no refund or compensation if it is unavailable or discontinued.\n12. Governing Law These terms are governed by the laws of the Republic of Türkiye, without regard to conflict of law rules, and the courts and enforcement offices of İstanbul (Çağlayan) have exclusive jurisdiction over any dispute arising from them or from your use of the site.\nIf you are a consumer resident in the European Union or the United Kingdom, this does not deprive you of the protection of mandatory consumer law where you live, nor of the right to bring proceedings there.\n13. Severability If any provision is held invalid, unlawful, or unenforceable, it is severed to the minimum extent necessary and the rest stays in full force. Our failure to enforce a right is not a waiver of it.\n14. Changes to These Terms We may revise these terms when the site changes or the law requires it. The current version is always published here with its effective date at the top, and material changes are announced with a notice on the site before they take effect. Continuing to use the site after a revision means you accept it; if you do not, stop using the site.\n15. Contact Questions about these terms, or notice of a suspected violation:\nEmail: legal@ccgenerator.org\nFor anything else use the Contact page; privacy matters are handled at the address in the Privacy Policy.\n","permalink":"https://ccgenerator.org/terms/","summary":"Effective date: August 2, 2026\n1. Agreement to Terms These Terms of Service govern your use of ccgenerator.org (\u0026ldquo;CC Generator\u0026rdquo;, \u0026ldquo;the site\u0026rdquo;, \u0026ldquo;we\u0026rdquo;, \u0026ldquo;us\u0026rdquo;). By opening the site, generating test data, or using any feature, you agree to them. If you do not agree, stop using the site.\nThere is no account and nothing to pay, so these terms — read together with our Privacy Policy and Disclaimer — are the whole agreement between us.","title":"Terms of Service"},{"content":"Common questions about generating dummy card numbers, what Luhn validation does and does not prove, and where these numbers belong in a testing workflow. The short version: everything here is synthetic test data for exercising your own code, none of it can complete a payment, and attempting to use it for one is fraud rather than a technical challenge.\nIf you came here to use the tool rather than read about it, the card number generator is one click away, and the per-network pages — Visa, Mastercard, American Express, Troy — go into each format in detail.\nCredit card generator FAQ What these numbers are What they can and cannot do Legality and safety Technical details Using this for testing About this site What these numbers are Are these real credit cards? No. Every number produced here is synthetic test data. It is calculated by a formula rather than issued by a bank, it is not linked to a person, an account, or a balance, and it never existed on a piece of plastic. The numbers look correct because they follow the same public structural rules an issued card follows — a network prefix, an account body, and a Luhn check digit. Following the rules of the format is all they do. Nothing on this site is derived from any real cardholder\u0026rsquo;s data, and no such data is stored here. See the disclaimer for the full statement. What does \u0026#34;Luhn-valid\u0026#34; mean? Luhn-valid means the final digit of the number matches the Luhn checksum — the mod-10 formula most payment forms run in the browser to catch typing mistakes. It is a spell-check for digits, nothing more. Crucially, Luhn-valid means correctly formatted, not real. A number can pass the Luhn check and correspond to no account at any bank in the world, which is exactly the situation of every number on this site. Passing Luhn is necessary for a card number to be genuine, but nowhere near sufficient. The guides work through the algorithm step by step. Where do these numbers come from? From an algorithm running in your browser. The generator picks a prefix that belongs to the card network you selected, fills the middle digits with values drawn from crypto.getRandomValues(), then calculates the final digit so the whole number satisfies the Luhn checksum. That is the entire process. The numbers are not taken from a database, a breach, a leak, or a list, because no such source is involved at any point — there is nothing to draw from. You can confirm the generation is local by opening your browser\u0026rsquo;s Network tab and generating a card: no request is made. Are the BIN prefixes real? The prefixes follow the published IIN ranges assigned to each card network, so a generated Visa number begins with 4 and a generated Mastercard falls in 51–55 or 2221–2720, exactly as issued cards do. That is what makes them useful for testing brand detection. But the specific six- to eight-digit BIN may or may not correspond to an actual issuing bank, and everything after the prefix is random. The generator knows the network\u0026rsquo;s rules; it does not know any bank\u0026rsquo;s assignments, and it is not drawing on an issuer database. Can the same number be generated twice? In theory yes, in practice it is very unlikely. A 16-digit number with a six-digit prefix and a check digit leaves nine free digits, so there are on the order of a billion possibilities per prefix, and the digits come from a cryptographically secure random source rather than a seed or a counter. No uniqueness guarantee is offered, though. If your fixtures depend on distinct values — a unique database column, for instance — deduplicate after export rather than assuming. The bulk export makes that easy to check. What they can and cannot do Can I use these numbers to buy something? No, and please do not try. For a transaction to be approved, the number has to correspond to an active account at an issuing bank, which then authorises the payment. These numbers correspond to nothing, so every payment system will decline them. Beyond that: attempting to obtain goods or services you have not paid for using card data — synthetic or otherwise — is fraud in virtually every jurisdiction, and it remains an offence even when the attempt fails. This tool exists so developers can test their own software. The terms set out prohibited uses explicitly. Will these work for a free trial? No. Trial signups almost always verify the card with a small authorisation hold — often a one-unit charge that is immediately reversed — and these numbers are declined at exactly that step, because there is no issuer to approve them. There is no configuration or workaround that changes this; the number is not registered anywhere. Using card data to obtain a service you have not paid for is fraud regardless of the amount involved. If you are a developer who needs to test your own trial-signup flow, that is what your payment provider\u0026rsquo;s sandbox cards are for. Do they have any money on them? No. This is worth stating plainly because the assumption behind the question is itself mistaken: a card number never holds money. It is an identifier that points at an account held by a bank, and the balance lives in that account, not in the digits. These numbers point at no account at all, so there is no balance to speak of — not zero, but nothing. The same is true of any card number written down anywhere; the digits alone are just a reference, which is why possessing them is not the same as possessing funds. Can I use these with Stripe or PayPal? Only up to a point. Stripe\u0026rsquo;s client-side libraries validate format and checksum, so a generated number may well pass that first layer without complaint. The moment the request reaches the server it is rejected, because the number matches nothing in Stripe\u0026rsquo;s records. Both Stripe and PayPal publish their own test cards, which are recognised in their sandboxes and return scripted approvals, declines, and 3-D Secure challenges. Use theirs to test the processor; use these to test your own form before the processor is involved. Why does my payment gateway reject these numbers? Because a gateway does far more than run a checksum. It looks the leading digits up in its own BIN tables to identify the issuer, then routes an authorisation request to that issuer, which checks the account, the balance, and its own fraud rules before answering. A synthetic number fails at the first step — there is no issuer record to route to — so no authorisation is possible. This is not a bug or a strictness setting you can relax. It is the difference between validating a number\u0026rsquo;s shape and verifying that an account exists. Is the CVV real? No. A CVV is computed by the issuing bank from the card number, the expiry date, and a pair of secret keys that only the issuer holds. Because those keys never leave the bank, a valid CVV cannot be derived from a card number by us, by you, or by anyone other than the issuer — which is precisely the security property it exists to provide. The three- or four-digit value shown alongside each generated number is simply a random number of the right length for the network, so your form\u0026rsquo;s length validation has something to work with. Legality and safety Is this legal? Generating synthetic numbers and using them to test your own software is a standard engineering practice — payment processors publish their own test cards for the same purpose. It is more than merely permitted: PCI DSS discourages using live cardholder data in development and test environments, which makes synthetic test data the responsible option rather than a shortcut. What is illegal is using card data of any kind — synthetic or genuine — to obtain something you have not paid for, to defeat a verification control, or to deceive someone. The tool is lawful; that use of it is not. The terms list prohibited uses. Could I get in trouble for using this site? For testing software, no. Generating test data, pasting it into your own checkout form, and committing it to your own test fixtures is ordinary development work. For attempting to pay for something, bypass an age or identity check, or get past a verification step: yes. Fraud statutes in most jurisdictions cover the attempt, not only a successful outcome, so a declined transaction is no defence. The distinction is not subtle and it does not depend on where the numbers came from — it depends entirely on what you were trying to accomplish. Do you store what I generate? No, and you do not have to take our word for it. Generation runs entirely in your browser; the page holds no server-side component that could receive a card number. To verify it yourself, open your browser\u0026rsquo;s developer tools, switch to the Network tab, and generate a card — you will see no request leave the page. Nothing to store means nothing to leak, nothing to subpoena, and nothing to sell. The privacy policy describes what the site does collect, which is ordinary web analytics and nothing to do with generated values. Do you log my IP address? Standard server request logs exist, as they do for essentially every website, and they include IP addresses. They are retained for a limited period and used for security and troubleshooting. They cannot be linked to anything you generate, for the simple reason that generated card data never reaches the server in the first place — there is no record on our side associating a request with a card number, because no card number is ever transmitted. The privacy policy covers retention, analytics, and the consent controls in full. Technical details How many digits should a credit card number have? It depends on the network. American Express uses 15; Mastercard, Discover, JCB, and Troy use 16; Visa permits 13, 16, and 19; Diners Club is commonly 14; and Maestro ranges from 12 to 19. ISO/IEC 7812 caps a primary account number at 19 digits overall. The practical consequence is that a validation rule of length === 16 is wrong: it rejects every Amex card and every 19-digit Maestro. Derive the expected length from the detected brand instead. The all-network generator carries the full table. What is the difference between CVV, CVC, CID, and CVV2? They are the same concept under different brand names. Visa calls it CVV2, Mastercard calls it CVC2, American Express and Discover call it CID, JCB calls it CAV2, and UnionPay calls it CVN2. Only two differences matter in code. Length: American Express uses four digits, everyone else uses three. Location: Amex prints it on the front of the card, to the right of the number, while the others put it on the signature panel on the back — so checkout help text saying \u0026ldquo;the three digits on the back\u0026rdquo; is wrong for every Amex customer. What is a BIN? A BIN, or Bank Identification Number, is the leading portion of a card number that identifies the institution that issued it. Its formal name in ISO/IEC 7812 is the IIN, or Issuer Identification Number, and the two terms are used interchangeably. It was historically six digits, but the standard was revised in 2017 to extend it to eight because the six-digit space was running out. Both lengths are in circulation, so lookup code that takes the first six digits and stops will misattribute cards issued on eight-digit IINs. The guides cover the migration. Can I generate a card for a specific bank? No, and that is a deliberate design decision rather than a missing feature. Targeting a named issuer\u0026rsquo;s BIN would mean reproducing that bank\u0026rsquo;s real prefix assignments, which is a capability legitimate testing does not need and misuse very much does — it is the difference between \u0026ldquo;a number shaped like a Visa\u0026rdquo; and \u0026ldquo;a number that appears to come from this particular bank\u0026rdquo;. For testing, what you need is conformance to the network\u0026rsquo;s format, which is what the generator provides. Product tier and issuer are BIN-table facts, not properties recoverable from a generated number. Can I generate cards in bulk? Yes. Switch the generator to its Bulk cards tab and set a quantity between 2 and 25 per run. Each result carries a card number, an expiry month and year, a security code of the correct length for its network, and a placeholder cardholder name. You can copy the batch, display it as JSON, or export it directly as CSV or JSON for use as fixtures. The limit exists because generation happens in the browser and keeps the page responsive; for a larger set, export several batches and concatenate them. The generator has the full export options. Using this for testing Should I use these instead of my gateway\u0026#39;s sandbox cards? Use both, for different jobs. These numbers test your code: input masks, brand detection, length rules, security-code field sizing, checksum rejection, error states, and fixtures. They cannot test the processor, because they are registered nowhere. Your gateway\u0026rsquo;s sandbox cards test its behaviour: approvals, specific decline codes, refunds, voids, subscriptions, webhook delivery, and 3-D Secure challenges. Their weakness is that there are only a handful of them, so they are poor for exercising variety. The clean rule: unlimited synthetic numbers up to the point the request leaves your server, official test cards after it. What should I test with these numbers? The list that catches the most real bugs: input masking and digit grouping, including Amex\u0026rsquo;s 4-6-5; brand detection as the user types, not on blur; length validation across 13, 15, 16, and 19 digits; security-code field length switching between three and four; Luhn rejection, by altering a final digit and confirming the form refuses it; error and empty states; PAN masking in logs, error reports, and analytics payloads; and bulk import, by exporting a CSV and running it through your fixture loader. The tool directory covers the generators for each network. How do I use these in an automated test suite? Export a batch as JSON and commit it as a fixture — synthetic numbers are safe to keep in a repository in a way that anything resembling genuine cardholder data is not. Then reference them by network:\nimport cards from \u0026#39;./fixtures/test-cards.json\u0026#39;; test(\u0026#39;detects the brand as the user types\u0026#39;, async ({ page }) =\u0026gt; { await page.fill(\u0026#39;[data-test=card-number]\u0026#39;, cards.visa); await expect(page.locator(\u0026#39;[data-test=card-brand]\u0026#39;)).toHaveText(\u0026#39;Visa\u0026#39;); }); Keep one card per network in the fixture so the Amex case — 15 digits, four-digit CID — is always exercised alongside the 16-digit ones.\nAbout this site Who runs this site? ccgenerator.org is built and maintained as a developer testing tool, with the reasoning behind the project — why synthetic card data matters, what the site deliberately will not do, and how it is funded — set out on the about page. The editorial policy explains how the technical content here is researched, sourced, and corrected, including the standing rule that no page on this site publishes invented statistics, ratings, or reviews, and that real cardholder data is never used or referenced. How do I report a problem or a factual error? Please do. Card network rules change, BIN ranges are reassigned, and a page that was accurate two years ago may not be today — a wrong prefix range or a broken Luhn example undermines the whole point of the site. The contact page lists the right address for technical corrections, bug reports, and everything else. The editorial policy describes how corrections are handled once received, including when a page is updated in place and when the change is noted. Still stuck? The testing guides go deeper on card number structure and gateway sandboxes, the tool directory lists every generator on the site, and the contact page has the right address for technical questions and corrections — all three are in the footer.\n","permalink":"https://ccgenerator.org/faq/","summary":"Common questions about generating dummy card numbers, what Luhn validation does and does not prove, and where these numbers belong in a testing workflow. The short version: everything here is synthetic test data for exercising your own code, none of it can complete a payment, and attempting to use it for one is fraud rather than a technical challenge.\nIf you came here to use the tool rather than read about it, the card number generator is one click away, and the per-network pages — Visa, Mastercard, American Express, Troy — go into each format in detail.","title":"Test Card Generator FAQ"},{"content":"There are two kinds of test card number, and using the wrong one wastes hours. Generated test numbers, like the ones from our credit card generator, are synthetic — they pass client-side validation and brand detection, which is what you need while you are building a form. Gateway sandbox numbers are registered inside a specific processor\u0026rsquo;s test environment: they return real authorisation responses, trigger named decline codes, and drive 3-D Secure flows. This page collects the sandbox numbers. Use them when the thing you are testing is the processor, not your form.\nCard numbers on this page were last checked against provider documentation on 3 August 2026. Providers do change what they publish — the official link beside each claim is authoritative. These are test numbers, not real cards Every number on this page is synthetic test data. It is generated by a formula, not issued by a bank. These numbers are not linked to any person, account, or balance. They carry no funds. They will be declined by every real payment processor. They only pass client-side format and checksum validation. Attempting to use card data to obtain goods, services, or trials you have not paid for is fraud in virtually every jurisdiction. Do not do it. Generation runs entirely in your browser. Nothing is sent to or stored on our servers. Intended use: payment form validation, checkout UI testing, QA test fixtures, and developer demos. For processor-specific behaviour (approvals, declines, refunds, 3-D Secure) use your gateway's official sandbox test cards.\nWhich one do I need? What you are testing Use Input mask, digit grouping Generated numbers Card brand detection (logo switching) Generated numbers Length and Luhn validation Generated numbers CVV field length by brand Generated numbers Bulk test fixtures and database seeding Generated numbers Successful authorisation Gateway sandbox Specific decline codes (insufficient funds, expired, lost or stolen) Gateway sandbox 3-D Secure and SCA challenge flows Gateway sandbox Refunds, partial refunds, voids Gateway sandbox Disputes and chargebacks Gateway sandbox Subscriptions and recurring billing Gateway sandbox Webhook delivery Gateway sandbox Multi-currency behaviour Gateway sandbox The line is clean: anything that happens before the request leaves your server can be tested with generated numbers, and anything that depends on the answer coming back needs the processor\u0026rsquo;s own.\nStripe Stripe\u0026rsquo;s set is the most complete of any provider, and the one most people mean when they say \u0026ldquo;test card\u0026rdquo;. Any future expiry and any CVV of the right length work; the number alone decides the outcome.\nCard number Brand Behaviour 4242 4242 4242 4242 Visa Succeeds 4000 0566 5566 5556 Visa (debit) Succeeds 5555 5555 5555 4444 Mastercard Succeeds 2223 0031 2200 3222 Mastercard (2-series) Succeeds — use this to prove 2-series support 5200 8282 8282 8210 Mastercard (debit) Succeeds 3782 822463 10005 American Express Succeeds 6011 1111 1111 1117 Discover Succeeds 3056 9300 0902 0004 Diners Club Succeeds 3566 0020 2036 0505 JCB Succeeds 6200 0000 0000 0005 UnionPay Succeeds Every decline path has its own number, which is what makes this set worth copying into a fixture file rather than hand-typing:\nCard number Error code Decline code 4000 0000 0000 0002 card_declined generic_decline 4000 0000 0000 9995 card_declined insufficient_funds 4000 0000 0000 9987 card_declined lost_card 4000 0000 0000 9979 card_declined stolen_card 4000 0000 0000 0069 expired_card — 4000 0000 0000 0127 incorrect_cvc — 4000 0000 0000 0119 processing_error — 4000 0000 0000 6975 card_declined card_velocity_exceeded 4242 4242 4242 4241 incorrect_number — That last one is the only number on this page that deliberately fails the Luhn checksum — it exists to test the branch where your own validation should have caught the input first.\nFor authentication, 4000 0027 6000 3184 always requires a 3-D Secure challenge, 4000 0025 0000 3155 requires one unless the card is already set up for off-session use, and 4000 0082 6000 3178 authenticates successfully and then declines with insufficient_funds — the case that breaks naive code assuming authentication implies approval.\nSource: Stripe — Testing · Verified: 2026-08-03\nPayPal PayPal\u0026rsquo;s sandbox splits the work differently: the card number selects the brand, and the cardholder name selects the outcome. That is unusual enough to catch people out.\nCard number Brand 4012 8888 8888 1881 Visa 4005 5192 0000 0004 Visa 2223 0000 4840 0011 Mastercard 3714 496353 98431 American Express 3646 1510 0000 39 Diners Club 6304 0000 0000 0000 Maestro 3636 5000 0000 0260 JCB 6200 6800 0000 0004 UnionPay To force a failure, send one of these case-sensitive values in the cardholder name field: CCREJECT-REFUSED (card refused), CCREJECT-IF (insufficient funds), CCREJECT-EC (expired card), CCREJECT-LS (lost or stolen), CCREJECT-SF (suspected fraud), or CCREJECT-CVV_F (CVV failure). Sandbox credentials come from a business account created in the PayPal Developer Dashboard, not from your live account.\nSource: PayPal — Card testing · Verified: 2026-08-03\nBraintree Braintree is PayPal-owned but has its own sandbox and its own conventions. Cards select the brand; the transaction amount selects the processor response.\nCard number Brand Behaviour 4111 1111 1111 1111 Visa Succeeds 4005 5192 0000 0004 Visa Succeeds 5555 5555 5555 4444 Mastercard Succeeds 2223 0000 4840 0011 Mastercard (2-series) Succeeds 3782 822463 10005 American Express Succeeds 6011 0009 9130 0009 Discover Succeeds 3625 9600 0000 04 Diners Club Succeeds 3530 1113 3330 0000 JCB Succeeds 4000 1111 1111 1115 Visa Processor declined on verification 5105 1051 0510 5100 Mastercard Processor declined on verification Amounts do the rest: anything from $0.01 to $1,999.99 is authorised and settled, $2,000.00–$2,999.99 is processor-declined, $3,000.00–$3,000.99 fails outright, and $5,001.00 is gateway-rejected for an incomplete application. This is the cleanest way in any sandbox to test a decline without changing the card on file.\nSource: Braintree — Testing · Verified: 2026-08-03\nAdyen Adyen pins both the expiry and the security code, and its examples expect them. Use 03/2030 and CVC 737 — or 7373 for American Express — unless a specific test says otherwise.\nCard number Brand Expiry CVC 4111 1111 1111 1111 Visa 03/2030 737 5555 5555 5555 4444 Mastercard 03/2030 737 3700 0000 0000 002 American Express 03/2030 7373 6011 6011 6011 6611 Discover 03/2030 737 3600 6666 3333 44 Diners 03/2030 737 3569 9900 1009 5841 JCB 03/2030 737 6771 7980 2100 0008 Maestro 03/2030 737 8171 9999 2766 0000 UnionPay 10/2030 737 5127 8809 9999 9990 Bancontact 03/2030 737 4360 0000 0100 0005 Cartes Bancaires 03/2030 737 Adyen\u0026rsquo;s refusal model is worth understanding before you test against it. Rather than a flat \u0026ldquo;declined\u0026rdquo;, the API returns a refusalReason plus a refusalReasonCode, and its documentation maps which of those you are allowed to surface to a shopper and which you must not. Test the mapping, not just the boolean.\nSource: Adyen — Test card numbers · Verified: 2026-08-03\nSquare Square keys its error states on fields other than the card number, which makes it the easiest sandbox to misread. 4111 1111 1111 1111 with CVV 111 succeeds; the same card with CVV 911 fails CVV verification.\nCard number Brand CVV 4111 1111 1111 1111 Visa 111 5105 1051 0510 5100 Mastercard 111 6011 0000 0000 0004 Discover 111 3400 000000 00009 American Express 1111 3569 9900 1009 5841 JCB 111 The triggers: CVV 911 produces a CVV failure, postal code 99999 a postal-code failure, expiry 01/40 an expiration failure, card 4000 0000 0000 0002 a decline, and 4000 0000 0000 0010 a card-on-file authorisation decline.\nSource: Square — Sandbox payments · Verified: 2026-08-03\nAuthorize.Net Authorize.Net has the oldest test data set here, and one configuration detail that trips up nearly everyone: your sandbox account should be left in Live Mode. Transactions submitted in the separate \u0026ldquo;test mode\u0026rdquo; are not stored and return a transaction ID of zero, so anything you build on top of the response falls apart.\nCard number Brand 4111 1111 1111 1111 Visa 4007 0000 00027 Visa 5424 0000 0000 0015 Mastercard 2223 0000 1030 9703 Mastercard (2-series) 3700 0000 0000 002 American Express 6011 0000 0000 0012 Discover 3088 0000 0000 0017 JCB 3800 0000 0000 06 Diners Club Outcomes come from the billing ZIP and the card code. ZIP 46282 forces a decline, 46203 an invalid-AVS-data response, 46205 an address mismatch and 46201 an address-only match; card codes 900, 901 and 904 produce CVV match, no-match and not-processed respectively.\nSource: Authorize.Net — Testing guide · Verified: 2026-08-03\nOther gateways in brief iyzico publishes the most useful Turkish set, organised by issuing bank and including Troy cards — 9792 0300 0000 0000 for Troy credit and 9792 0200 0000 0001 for Troy debit — plus a long list of error generators such as 4111 1111 1111 1129 for insufficient funds and 4151 1111 1111 1112 for a failed 3-D Secure initialisation. See iyzico — Test cards.\nMollie does not really use card numbers as the control surface. Test mode replaces the checkout screen with a panel where you pick the final state directly, and its published cards — Visa 4543 4740 0224 9996, Mastercard 2223 0000 1047 9399, Amex 3782 822463 10005 — all resolve as Mastercard internally. See Mollie — Testing.\nRazorpay splits its tables into domestic Indian cards, international cards, subscription cards and EMI cards, and requires a full billing address alongside the number for international tests. See Razorpay — Test card details.\nCheckout.com publishes per-brand cards where the amount you send maps to the response code you want, and routes challenged 3-D Secure tests to a simulator page. See Checkout.com — Test cards.\nWorldpay issues test cards against your specific test merchant profile rather than publishing a single universal list, so pull them from your own account documentation.\nUniversal test card numbers These predate most of the gateways above and are recognised almost everywhere, which is exactly why they are the wrong tool for testing a specific processor\u0026rsquo;s behaviour. They are the right tool for seeding a database or exercising a form.\nNumber Brand Notes 4111 1111 1111 1111 Visa The most widely published test number in the industry 4012 8888 8888 1881 Visa Common in older documentation 5555 5555 5555 4444 Mastercard 5-series 5105 1051 0510 5100 Mastercard 5-series 2223 0031 2200 3222 Mastercard 2-series — test your 2-series support 3782 822463 10005 American Express 15-digit 3714 496353 98431 American Express 15-digit 6011 1111 1111 1117 Discover 16-digit 3530 1113 3330 0000 JCB 16-digit 3056 9309 0259 04 Diners Club 14-digit Every number in this table is Luhn-valid and deliberately unassigned to any account. If you find one in a data set, that data set is test data. You can confirm any of them with the card validator, and generate fresh equivalents per network from the Visa and Mastercard pages.\nBuilding a decline matrix in your test suite The value of the tables above is that each decline path has a stable number, so the scenarios become data rather than prose. A Stripe example:\nDECLINE_CARDS = { \u0026#34;generic_decline\u0026#34;: \u0026#34;4000000000000002\u0026#34;, \u0026#34;insufficient_funds\u0026#34;: \u0026#34;4000000000009995\u0026#34;, \u0026#34;lost_card\u0026#34;: \u0026#34;4000000000009987\u0026#34;, \u0026#34;stolen_card\u0026#34;: \u0026#34;4000000000009979\u0026#34;, \u0026#34;expired_card\u0026#34;: \u0026#34;4000000000000069\u0026#34;, \u0026#34;incorrect_cvc\u0026#34;: \u0026#34;4000000000000127\u0026#34;, \u0026#34;processing_error\u0026#34;: \u0026#34;4000000000000119\u0026#34;, \u0026#34;card_velocity_exceeded\u0026#34;: \u0026#34;4000000000006975\u0026#34;, } @pytest.mark.parametrize(\u0026#34;expected_code,number\u0026#34;, DECLINE_CARDS.items()) def test_decline_is_surfaced_to_the_customer(expected_code, number, checkout): result = checkout.pay(card=number, exp_month=12, exp_year=2030, cvc=\u0026#34;123\u0026#34;) assert result.status == \u0026#34;failed\u0026#34; assert result.decline_code == expected_code assert result.customer_message != \u0026#34;\u0026#34; # never show a raw decline code assert \u0026#34;4000\u0026#34; not in result.customer_message Eight cases, one table, and the moment a provider adds a decline reason you add a row rather than a test. Keep the numbers in one module so the six-month re-check has a single place to land.\n3-D Secure and SCA testing 3-D Secure 2 is the authentication layer that lets an issuer confirm a cardholder is present before approving a transaction. Under PSD2 in the European Economic Area and the UK, strong customer authentication is mandatory for most e-commerce payments, which turned 3-D Secure from an optional anti-fraud tool into a path your checkout must handle.\nTwo flows matter. In the frictionless flow the issuer approves on the risk data alone and the customer sees nothing. In the challenge flow they are asked for a one-time code or a banking-app confirmation, your page hands control to the issuer, and control comes back asynchronously. Code that only ever ran the frictionless path will break the first time a challenge appears in production.\nEvery gateway triggers challenges with a different card — Stripe\u0026rsquo;s 4000 0027 6000 3184 always challenges, Adyen and Checkout.com route to their own simulator pages, and iyzico carries dedicated cards for each mdStatus value. Test the exemption cases too: low-value transactions, transaction risk analysis and merchant whitelisting can all skip the challenge, so a flow that assumes authentication always happens is as wrong as one that assumes it never does. Our 3-D Secure testing guide walks through the full matrix.\nSetting up a sandbox account The pattern is the same nearly everywhere: register a developer account, and you get a pair of API keys — one test, one live — that select the environment. Stripe and Square ship both in a single dashboard with a toggle. PayPal and Braintree issue a separate sandbox business account with its own credentials. Adyen provisions a test company account on request. Authorize.Net has a dedicated sandbox portal at sandbox.authorize.net, distinct from the production login.\nNever commit test API keys to a public repository. Even test keys reveal your account structure, and several providers rate-limit or disable keys they find in public code.\nGenerated numbers vs sandbox numbers Generated numbers Gateway sandbox numbers Passes Luhn and format checks Yes Yes Triggers correct brand detection Yes Yes Available in bulk, instantly Yes No — fixed published set Works across every gateway Yes, as input No — one processor only Returns an authorisation response No Yes Triggers named decline codes No Yes Drives 3-D Secure flows No Yes Exercises refunds and disputes No Yes Common testing mistakes Using a test card with live keys. It fails at the network, and repeated attempts feed the card-testing fraud signals processors watch on your merchant account. Letting test numbers reach a production database. Seed data has a way of migrating. Tag it at creation so it can be found and removed later. Assuming sandbox behaviour equals production behaviour. The usual gap is 3-D Secure: sandboxes frequently skip a challenge that production will demand. Backdating the expiry to test an expired card. Most sandboxes reject a past date at validation, so you test your own form instead of the processor. Use the documented expired-card number instead. Sending a three-digit CVV with an American Express number. Amex uses a four-digit code, and a length check keyed to the brand is exactly the kind of bug a test suite should catch. Never testing 2-series Mastercard. The 2221–2720 range has been live since 2017 and validation written against ^5[1-5] still rejects it. 2223 0031 2200 3222 takes one line to add. Related pages and tools The tool directory lists every generator on the site, the FAQ covers what a Luhn-valid number does and does not prove, and our editorial policy explains the six-month re-check cycle this page sits in.\nFrequently Asked Questions What is a test card number? A card number that is deliberately not assigned to any real account, published so developers can exercise payment code without moving money. There are two families. Synthetic numbers satisfy the Luhn checksum and the network\u0026rsquo;s format rules, which is all a client-side form needs. Gateway sandbox numbers are registered inside one processor\u0026rsquo;s test environment and return real authorisation responses from it. Neither can be charged in production. Do Stripe test cards work with other gateways? Only by accident. A number like 4242 4242 4242 4242 is meaningful because Stripe\u0026rsquo;s test environment recognises it; send it to Adyen and it is just a well-formed Visa number with no special behaviour. The overlap you do see — 4111 1111 1111 1111 turning up almost everywhere — exists because that number predates most of these companies, not because the gateways coordinate. Always use the table for the processor you are actually calling. Can I use a test card in production? No, and trying is a bad idea beyond the obvious. Live keys route the number to the real card networks, where it fails as an unassigned account. Several processors count those failures toward the card-testing fraud signals they monitor, and a burst of them from your merchant account can trigger a review. Keep test numbers behind test keys. Why did my test card get declined in the sandbox? Usually one of four things: you used a number that is specifically documented to decline, you sent it with live rather than test credentials, you used an expiry date in the past, or you hit a trigger the gateway keys on something other than the number. Square decides on the CVV and postal code you send, Braintree on the transaction amount, PayPal on the cardholder name, and Authorize.Net on the billing ZIP — so an unmodified success card can still decline if another field carries a trigger value. What expiry date should I use with a test card? Any future date, unless the provider pins one. Stripe, Braintree and Square accept any future month and year. Adyen documents a specific expiry per card — 03/2030 on most of its set — and its examples are worth copying exactly. If you are testing the expired-card path, use a card documented to return that error rather than backdating a success card, because some sandboxes reject a past date at validation and never produce the processor response you wanted to see. What CVV should I use with a test card? Any value of the right length in most sandboxes: three digits for Visa, Mastercard, Discover and JCB, four for American Express. Two exceptions matter. Adyen publishes 737 (7373 for Amex) and expects it. Square treats the CVV as a trigger — 111 succeeds and 911 forces a CVV failure — so a random value there will not behave the way you assume. Are test card numbers the same across all payment providers? No. The handful that recur — 4111 1111 1111 1111, 5555 5555 5555 4444, 378282246310005 — are industry folklore that many providers happen to honour, but decline codes, 3-D Secure cards and error triggers are provider-specific and overlap almost not at all. Treat any shared number as a coincidence you should not depend on. Where do I find test cards for a gateway not listed here? Look for the processor\u0026rsquo;s developer documentation rather than a third-party list, and search within it for testing, sandbox, or test cards. The page you want almost always sits under a developer or docs subdomain and is public without an account. If a search result offers you test numbers for a gateway but does not link to that gateway\u0026rsquo;s own documentation, do not trust the numbers. ","permalink":"https://ccgenerator.org/test-card-numbers/","summary":"There are two kinds of test card number, and using the wrong one wastes hours. Generated test numbers, like the ones from our credit card generator, are synthetic — they pass client-side validation and brand detection, which is what you need while you are building a form. Gateway sandbox numbers are registered inside a specific processor\u0026rsquo;s test environment: they return real authorisation responses, trigger named decline codes, and drive 3-D Secure flows.","title":"Test Card Numbers — Sandbox Cards by Gateway"},{"content":"Payment forms need more than a card number. They need a billing address, a postcode that matches, a name on the card, and often a contact email and phone. This tool generates all of it as synthetic test data, so you can test address validation, AVS logic, and form behaviour without touching anyone\u0026rsquo;s real details.\nEverything here is invented, and the way it is invented matters. Names come from a generic word list. Email domains are reserved by RFC 2606 and can never be registered by anyone. Phone numbers are drawn from the ranges national regulators set aside for fiction, where such a range exists. Nothing corresponds to a real person.\nSynthetic test data\nTest Identity Generator Names, billing addresses and contact details for payment form testing. Generated in your browser from reserved ranges — nothing corresponds to a real person.\nCountry United States United Kingdom Canada Australia Germany France Türkiye Ireland Quantity Include card details Yes — full billing record No — address only Generate Every field is invented. Phone numbers come from ranges reserved for fiction where the regulator publishes one, and email domains are RFC 2606 reserved, so they can never belong to anyone. This is test data for your own forms — using it to register for a service is not what it is for. Copy JSON Export CSV All Cards Visa Mastercard Amex Discover JCB Diners Maestro UnionPay Troy These are test numbers, not real cards Every number on this page is synthetic test data. It is generated by a formula, not issued by a bank. These numbers are not linked to any person, account, or balance. They carry no funds. They will be declined by every real payment processor. They only pass client-side format and checksum validation. Attempting to use card data to obtain goods, services, or trials you have not paid for is fraud in virtually every jurisdiction. Do not do it. Generation runs entirely in your browser. Nothing is sent to or stored on our servers. Intended use: payment form validation, checkout UI testing, QA test fixtures, and developer demos. For processor-specific behaviour (approvals, declines, refunds, 3-D Secure) use your gateway's official sandbox test cards.\nHow the data is kept safe Three of the fields could plausibly collide with a real person\u0026rsquo;s details if generated carelessly, so each is drawn from something that cannot.\nEmail. Every address ends in example.com, example.net or example.org. RFC 2606 reserves those second-level domains permanently — nobody can register them, so no message sent to one can reach a person. A generator that invents plausible-looking domains instead is generating addresses that might belong to somebody.\nPhone. Where a regulator publishes a range reserved for drama and fiction, the tool uses it: 555-0100 to 555-0199 in the North American Numbering Plan, Ofcom\u0026rsquo;s 07700 900xxx and 020 7946 0xxx in the UK, and ACMA\u0026rsquo;s 0491 570 xxx for Australian mobiles. Those numbers are guaranteed never to be allocated. For Germany, France, Türkiye and Ireland no equivalent range is published, so the tool produces a correctly formatted number and says plainly that it is a format fixture rather than a guaranteed-unroutable one. That is a real limitation, and pretending otherwise would be worse than stating it.\nAddress. Street names are transparent placeholders and street numbers start in the thousands, which makes a collision with a deliverable address unlikely. Postcodes are format-valid because a postcode that fails your validation tests nothing.\nAddress Verification System (AVS) testing AVS is the part of this that developers get wrong most expensively.\nWhen a card is authorised, the processor passes the numeric parts of the billing address — the street number and the postcode — to the issuer, which compares them against its records and returns a code. The common codes:\nCode Meaning Y Street address and postcode both match A Street address matches, postcode does not Z Postcode matches, street address does not N Neither matches U Address information unavailable G Non-U.S. issuer, does not participate R Retry — system unavailable Many merchants decline transactions returning N, which is a defensible rule. The expensive mistake is declining G as well.\nG does not mean the address was wrong. It means the issuing bank is outside the AVS system and therefore never checked. AVS is largely a US and UK arrangement, and most issuers in the rest of the world do not participate at all. A rule that treats \u0026ldquo;no answer\u0026rdquo; as \u0026ldquo;wrong answer\u0026rdquo; declines a large share of your international customers, every time, with a generic failure message. From the inside it looks like international conversion is simply poor. U and R deserve the same care — unavailable and retry are not evidence of anything.\nNote also that not every processor exposes the raw letter codes. Stripe, for instance, normalises them into address_line1_check and address_postal_code_check fields with values of pass, fail, unavailable or unchecked. The underlying signal is the same; the shape your code branches on is not, so write your rules against your processor\u0026rsquo;s representation rather than the table above.\nTo exercise those branches, gateways publish cards that force particular results. Stripe\u0026rsquo;s 4000 0000 0000 0028 fails the line 1 check while the postcode passes, 4000 0000 0000 0010 fails both, and 4000 0000 0000 0044 returns both as unavailable — which is the one that tests your G-equivalent path.\nSource: Stripe — Testing · Verified: 2026-08-04\nThe test card numbers reference collects the equivalents for other gateways.\nAddress format differences by country Country Postcode format Example Notes United States 5 or 5+4 digits 90210, 90210-1234 ZIP+4 optional United Kingdom Alphanumeric, variable SW1A 1AA Space position matters Canada A1A 1A1 K1A 0B1 Letters and digits alternate Germany 5 digits 10115 Leading zeros exist France 5 digits 75001 Australia 4 digits 2000 Leading zeros exist, e.g. 0800 Türkiye 5 digits 34000 Ireland Eircode, alphanumeric D02 AF30 No fixed pattern historically Four mistakes account for most international checkout failures:\nStoring the postcode as an integer. 01234 becomes 1234, Australian 0800 becomes 800, and the UK and Canada do not survive the cast at all. Postcodes are strings that happen to contain digits. Requiring exactly five characters. This excludes the UK, Canada and Ireland outright. Making the state or province field mandatory. Many countries have no such division, and a required field with no valid answer is a dead end. Capping the address line at fifty characters. Long street names and building references exceed that regularly outside the US. GDPR and test data Synthetic test data is not personal data, which is precisely why you should use it. If you copy production customer records into a staging environment, those records remain personal data under GDPR — with the same lawful basis, retention, and breach notification obligations, in an environment that is usually less protected than production. Generating fresh synthetic data removes the problem rather than managing it.\nThe practical version: a staging database full of real customers is a breach waiting to be reported, and it is a breach of production data even though it happened in staging. Nobody budgets for that. Our test data guide goes further into how to keep the two apart.\nTesting scenarios AVS code handling. Assert a defined behaviour for every code, not just Y and N. The G, U and R branches are where revenue leaks. Postcode validation by country. The regex should change when the country select changes. Test that switching country after typing a postcode revalidates rather than keeping a stale result. Billing separate from shipping. Generate two records and confirm the AVS check uses the billing address, not whichever one was entered last. Address autocomplete. Confirm your form still works when the user ignores the autocomplete and types the address by hand, which a surprising share of people do. Accented characters. The name pool deliberately includes ö, ü, ç, é and ñ. Push a name like Günther Öztürk through the form, the API, the database and back onto the confirmation screen, and check the bytes survive every hop. Encoding bugs almost never show up in ASCII-only test data, which is exactly why they reach production. The same names are worth pushing through any card preview component you render — the card mockup generator covers where those layouts break. What this generator does not produce National identifiers of any kind — no social security, tax, passport or licence numbers Any data belonging to a real person Real, deliverable addresses Anything that would help pass an identity check A test identity is a set of well-formed strings for exercising a form. It is not an identity, and it will not satisfy any system that actually verifies who you are — those systems check against government and credit bureau records, which no generator can touch.\nThe reserved ranges and AVS test cards above were last checked against provider documentation on 4 August 2026. Providers do change what they publish — the official link beside each claim is authoritative. Related tools and guides Pair these records with numbers from the all-network generator, or produce both together at volume with the bulk generator, which carries the same fixture strategy advice. The validator checks any number you are unsure about, and the IBAN generator covers the bank transfer side — same synthetic-data reasoning, different payment rail. The tool directory lists everything else, and the FAQ covers what a Luhn-valid number does and does not prove.\nFrequently Asked Questions Are these real names and addresses? No. Names come from a generic word pool rather than any person database, street names are obvious placeholders like Example Street, and street numbers are drawn high on purpose to reduce the chance of matching a deliverable address. Postcodes are format-valid, which is the point — they have to be, or they would not test anything — but no record as a whole corresponds to a real person or a real household. Can I use this data to sign up for a service? No. Registering for a service with false details breaches its terms, and depending on the service and the jurisdiction it can be fraud. This data exists to exercise your own form: your validation, your address parsing, your AVS handling. It is input for code you control, not a way past someone else\u0026rsquo;s checks. Why are the phone numbers all 555? Because that block is reserved. In the North American Numbering Plan, 555-0100 through 555-0199 is set aside for fictional use and will never be assigned, which is why it turns up in films. The UK equivalents are Ofcom\u0026rsquo;s drama ranges — 07700 900000–900999 and 020 7946 0000–0999 — and Australia\u0026rsquo;s are ACMA\u0026rsquo;s, including 0491 570 xxx for mobiles. Using those ranges means a test fixture can never dial a stranger. What is AVS? The Address Verification Service. When a card is authorised, the processor sends the numeric parts of the billing address — typically the street number and the postcode — to the issuer, which compares them against its records and returns a code saying which parts matched. It is a fraud signal, not an authorisation decision, and how you react to each code is a business rule you write yourself. Do you generate social security or ID numbers? No, deliberately, and we will not add them. National identifiers, tax numbers, passport and licence numbers have no legitimate testing use that a format-valid placeholder of your own cannot serve, and generating them is squarely the shape of tooling built for identity fraud. Everything here is a billing detail, which is a different thing. Can I use this for GDPR-safe test data? That is the main reason to use it. Synthetic records are not personal data, so they carry no lawful basis to establish, no retention clock and no breach notification duty. Copying production customer records into staging keeps every one of those obligations, in an environment that is usually less well protected than production. ","permalink":"https://ccgenerator.org/fake-name-address-generator/","summary":"Payment forms need more than a card number. They need a billing address, a postcode that matches, a name on the card, and often a contact email and phone. This tool generates all of it as synthetic test data, so you can test address validation, AVS logic, and form behaviour without touching anyone\u0026rsquo;s real details.\nEverything here is invented, and the way it is invented matters. Names come from a generic word list.","title":"Test Identity Generator — Names, Addresses"},{"content":" Test card only\nCredit Card Number Generator Generate dummy card details for development and QA. Nothing is stored or sent to a server.\nSingle card Bulk cards Card network Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Generate Card Card network All Mixed Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Quantity Generate Cards These numbers are dummy, Luhn-valid test values for software testing only. They are not real active cards and cannot be used for payments. Copy all Show JSON Copy JSON Export JSON Export CSV JSON output All Cards Visa Mastercard Amex Discover JCB Diners Maestro UnionPay Troy These are test numbers, not real cards Every number on this page is synthetic test data. It is generated by a formula, not issued by a bank. These numbers are not linked to any person, account, or balance. They carry no funds. They will be declined by every real payment processor. They only pass client-side format and checksum validation. Attempting to use card data to obtain goods, services, or trials you have not paid for is fraud in virtually every jurisdiction. Do not do it. Generation runs entirely in your browser. Nothing is sent to or stored on our servers. Intended use: payment form validation, checkout UI testing, QA test fixtures, and developer demos. For processor-specific behaviour (approvals, declines, refunds, 3-D Secure) use your gateway's official sandbox test cards.\nThis Troy card generator produces 16-digit, Luhn-valid test numbers on the 9792 prefix. Troy is the network international checkout code most often forgets, and the failure is rarely a validation error — it is a card that passes every length and checksum rule and then renders as \u0026ldquo;unknown\u0026rdquo; or unsupported, so the customer is told their card will not work when it is perfectly good.\nWhat is Troy? Troy — Türkiye\u0026rsquo;nin Ödeme Yöntemi, Türkiye\u0026rsquo;s Payment Method — is the country\u0026rsquo;s domestic card scheme. It was established in 2016 within the Interbank Card Center (BKM), Bankalararası Kart Merkezi, and is issued by Turkish banks as debit, credit, and prepaid cards. Troy\u0026rsquo;s own site is the other primary source.\nThe motivation is the one behind every domestic scheme: keeping local transactions on local infrastructure, reducing the fees paid out to international networks, and holding a degree of payment sovereignty. Troy is not unusual in this — RuPay in India, UnionPay in China, Mir in Russia, and Elo in Brazil exist for much the same reasons.\nTroy card number format Property Value IIN / BIN prefix 9792 Length 16 digits Check digit Luhn (mod 10) Security code CVV, 3 digits Operator Bankalararası Kart Merkezi (BKM) Country Türkiye Launched 2016 Co-badging is the detail that matters for integration. Many Troy cards are issued carrying both the Troy logo and an international scheme logo. BKM is explicit that a card must also carry an international scheme logo to transact abroad; domestically the transaction runs on Troy. Troy cards have been accepted in the United States on the Discover network since 2017. So the same physical card can present as Troy or as an international scheme depending on where the transaction happens — and which logo your checkout displays is a business decision, not something the number can tell you.\nWhy Troy support matters for developers E-commerce sites selling into Türkiye will encounter Troy cards, and there are a great many of them in circulation. Most payment forms written outside Türkiye have never heard of the 9792 prefix. Brand detection falls through, the card-logo lookup renders a blank or a placeholder, and the customer sees an error implying their card is not supported. Turkish payment providers — iyzico, PayTR, Param, and Craftgate — all support Troy, so the integration path exists and needs testing. Domestic card transactions in Türkiye are subject to local processing requirements, so Troy is often not optional if you are operating there in any serious way. Troy brand detection Troy is trivial to detect — 9792 collides with nothing — so the work is remembering to add it at all:\nconst TROY = /^9792\\d{12}$/; function detectBrand(number) { const n = number.replace(/\\D/g, \u0026#39;\u0026#39;); if (/^4/.test(n)) return \u0026#39;visa\u0026#39;; if (/^3[47]/.test(n)) return \u0026#39;amex\u0026#39;; if (/^9792/.test(n)) return \u0026#39;troy\u0026#39;; if (/^220[0-4]/.test(n)) return \u0026#39;mir\u0026#39;; if (/^(5[1-5]|222[1-9]|22[3-9]|2[3-6]|27[01]|2720)/.test(n)) return \u0026#39;mastercard\u0026#39;; if (/^(6011|65|64[4-9])/.test(n)) return \u0026#39;discover\u0026#39;; return \u0026#39;unknown\u0026#39;; } Two things in that chain are worth more than the Troy line itself.\nThe Mastercard test is the long one for a reason. A shorter /^(5[1-5]|2[2-7])/ looks equivalent and is not: 2[2-7] covers 2200–2799, which is wider than Mastercard\u0026rsquo;s actual 2221–2720. It swallows Mir\u0026rsquo;s 2200–2204 range and labels those cards Mastercard, and it accepts 2721, which belongs to no one. The Mastercard page works through that range split in detail.\nOrder matters once ranges overlap. 9792 is unambiguous so Troy can sit anywhere, but the Mir check has to come before a loose Mastercard test, not after. With the corrected Mastercard pattern the ordering constraint disappears — which is the better fix.\nTesting Troy integration A Troy card generator is only useful for the first half of this list — the half that runs in your own code:\nType a generated number and confirm the Troy logo appears rather than a blank or \u0026ldquo;unknown\u0026rdquo;. Confirm a plain 16-digit length check accepts it — Troy needs no special length rule. Confirm the security-code field stays at 3 digits, as for Visa and Mastercard. For a co-badged card, decide and then test which brand your checkout displays and which network you route to. For authorisation, approvals, declines, and 3-D Secure, use the sandbox test cards your Turkish provider publishes. The numbers here exercise your form, not their gateway. Other national card networks Troy belongs to a category, and the same integration gap tends to apply across all of it:\nNetwork Country Prefix Length Troy Türkiye 9792 16 UnionPay China 62, 81 16–19 RuPay India 60, 65, 81, 82, 508 16 Mir Russia 2200–2204 16 Elo Brazil 4011, 4312, 5041, 6277, 6362 16 JCB Japan 3528–3589 16–19 Note the overlaps: RuPay\u0026rsquo;s 65 collides with Discover, its 81 with UnionPay, and Elo\u0026rsquo;s 4011 and 4312 sit inside Visa\u0026rsquo;s 4. Prefix alone cannot always resolve these — a production integration in those markets needs a BIN lookup rather than a regex chain. See the BIN and IIN guide. UnionPay and JCB generators are planned; both networks are already available in the picker on the all-network credit card generator.\nTo compare Troy\u0026rsquo;s behaviour against the international schemes, generate a Visa number or a 15-digit Amex number alongside it — Mastercard\u0026rsquo;s two ranges are covered in the brand-detection section above. The tool directory lists everything else, and the FAQ covers what a Luhn-valid number does and does not prove.\nFrequently Asked Questions What does Troy stand for? Troy is short for \u0026ldquo;Türkiye\u0026rsquo;nin Ödeme Yöntemi\u0026rdquo; — Türkiye\u0026rsquo;s Payment Method. It is the country\u0026rsquo;s domestic card scheme, established in 2016 within the Interbank Card Center (Bankalararası Kart Merkezi, BKM). Do all Troy cards start with 9792? The Troy BINs in general circulation sit under the 9792 prefix, and that is what this generator produces. As with any scheme, the authoritative answer for a specific card is a BIN table lookup rather than the prefix alone. Is Troy accepted outside Türkiye? Only through a co-badged card. A Troy card used abroad relies on an international scheme logo carried alongside the Troy logo — BKM states that a card must also carry an international scheme logo to transact outside Türkiye. Troy cards have been accepted in the United States on the Discover network since 2017. A Troy-only card works domestically. How many digits does a Troy card have? 16, with a Luhn check digit in the final position and a 3-digit security code — the same shape as Visa and Mastercard. Only the prefix differs, which is exactly why brand detection is where integrations fail rather than length validation. Which Turkish payment gateways support Troy? The major domestic providers do, including iyzico, PayTR, Param, and Craftgate. Each publishes its own sandbox and its own test cards, which are what you need once you are testing authorisation rather than your own form. Can I use a Troy test number from this page with a Turkish payment gateway sandbox? No. These numbers are not registered with any provider, so a sandbox will decline them at authorisation. Use them to check that your form detects Troy, accepts the number, and renders the right logo; use the provider\u0026rsquo;s own test cards for anything that returns a response. ","permalink":"https://ccgenerator.org/troy-card-generator/","summary":"Test card only\nCredit Card Number Generator Generate dummy card details for development and QA. Nothing is stored or sent to a server.\nSingle card Bulk cards Card network Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Generate Card Card network All Mixed Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Quantity Generate Cards These numbers are dummy, Luhn-valid test values for software testing only. They are not real active cards and cannot be used for payments.","title":"Troy Card Generator — Test Troy Card Numbers"},{"content":"This UnionPay card generator produces Luhn-valid test numbers on the network\u0026rsquo;s published ranges. UnionPay is the largest card network in the world by cards issued and by transaction volume, and it is also the network that produced the most useful counterexample in card validation — the reason a failed checksum should never be a hard block.\nTest card only\nCredit Card Number Generator Generate dummy card details for development and QA. Nothing is stored or sent to a server.\nSingle card Bulk cards Card network Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Generate Card Card network All Mixed Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Quantity Generate Cards These numbers are dummy, Luhn-valid test values for software testing only. They are not real active cards and cannot be used for payments. Copy all Show JSON Copy JSON Export JSON Export CSV JSON output All Cards Visa Mastercard Amex Discover JCB Diners Maestro UnionPay Troy These are test numbers, not real cards Every number on this page is synthetic test data. It is generated by a formula, not issued by a bank. These numbers are not linked to any person, account, or balance. They carry no funds. They will be declined by every real payment processor. They only pass client-side format and checksum validation. Attempting to use card data to obtain goods, services, or trials you have not paid for is fraud in virtually every jurisdiction. Do not do it. Generation runs entirely in your browser. Nothing is sent to or stored on our servers. Intended use: payment form validation, checkout UI testing, QA test fixtures, and developer demos. For processor-specific behaviour (approvals, declines, refunds, 3-D Secure) use your gateway's official sandbox test cards.\nUnionPay card number format Property Value Primary BIN range 62 Additional ranges reported in BIN references, including 81 Length 16–19 digits Check digit Luhn (mod 10) Security code CVN2, 3 digits, on the back Grouping 4-4-4-4 or 4-4-4-4-3 The Luhn exception Almost every piece of card-handling advice, including ours, says the same thing: a valid card number satisfies the Luhn checksum. UnionPay is where that sentence acquired an asterisk.\nSome UnionPay cards issued in the mid-2010s did not carry a valid check digit. This was not a data-entry problem or a myth passed around in forums — it was documented behaviour in a domestic range, and it broke validation libraries that treated Luhn as a hard gate. Current UnionPay cards do carry a valid check digit, so the exception is largely historical.\nThe lesson is not. Here is why it still matters even though the specific case has closed:\nLuhn is a typo filter, not an authority. It was designed in the 1950s to catch mistyped and transposed digits. It has never been a statement about whether an account exists, and it was never guaranteed to hold across every range every network would ever allocate.\nHard blocks convert edge cases into lost revenue. A client-side check that refuses to submit turns any unforeseen case — a new range, an unusual product, a network doing something its predecessor did not — into an abandoned checkout with no server-side record. You do not find out. You just have a slightly worse conversion rate forever.\nThe processor is the actual authority. It has the issuer relationship and the current range data. Your form has a checksum from 1954.\nSo: warn, allow submission, and let the authorisation answer. That is the right shape for every network, and UnionPay is simply the evidence that the shape matters. Our card validator takes the same position — it reports a failed check digit and tells you which digit was expected, rather than declaring the number invalid.\nThe same reasoning applies to ranges. A great deal of code checks ^62 and stops. UnionPay\u0026rsquo;s allocations are not confined to that block, and additional ranges including 81 appear in industry BIN references. Treat any hard-coded single-prefix check as a thing that will be wrong later, and prefer a lookup where the answer actually matters — the BIN lookup page covers what maintained data can tell you that the digits cannot.\nWhere UnionPay is accepted Domestically in mainland China, UnionPay was for years effectively the only card network, and its issued-card base is larger than any other scheme\u0026rsquo;s by a wide margin. That base travels: Chinese cardholders abroad carry UnionPay cards, which is why acceptance has spread through tourist-heavy merchant categories worldwide well ahead of general acceptance.\nInternationally, UnionPay reaches much of the world through partner arrangements rather than its own acceptance footprint everywhere — including a reciprocal relationship with Discover, whose 622126–622925 block is a shared co-brand range. JCB sits in a comparable web of partnerships.\nFor a merchant the decision is straightforward. Selling to Chinese customers, including travellers and diaspora, means supporting UnionPay or losing those transactions silently. Selling entirely elsewhere makes it lower priority — but the detection still has to be right, because a mis-detected card produces a confusing failure rather than a clean decline.\nWarn without being useless \u0026ldquo;Warn, do not block\u0026rdquo; is easy to state and easy to implement badly. A warning nobody reads is the same as no warning, and a warning that looks like an error is the same as a block.\nThree things make the difference:\nSay what to check, not what failed. \u0026ldquo;Please check your card number\u0026rdquo; points at the input. \u0026ldquo;Invalid checksum\u0026rdquo; points at your implementation and tells the customer nothing they can act on. Keep the submit button live. The warning is advice. If the button is disabled, you have built a block with extra steps, and the customer with the unusual card is stuck exactly as before. Log it server-side. A checksum failure that proceeds to authorisation and then succeeds is the most valuable signal you can collect here: it means your validation was wrong about a real card. Without the log you never learn that, because the payment worked and nobody complained. That third point is how the original UnionPay exception was found in the first place — not by reading a specification, but by noticing that numbers failing a local check were authorising fine.\nBrand detection regex const UNIONPAY = /^(62|81)\\d{14,17}$/; UNIONPAY.test(\u0026#39;6200000000000000\u0026#39;); // true — 16 digits UNIONPAY.test(\u0026#39;6200000000000000000\u0026#39;); // true — 19 digits UNIONPAY.test(\u0026#39;620000000000000\u0026#39;); // false — 15 digits, too short UNIONPAY.test(\u0026#39;6300000000000000\u0026#39;); // false — outside the range Detection order matters here as much as it does for Maestro, whose 56–69 block contains 62 entirely. Check UnionPay\u0026rsquo;s specific range before Maestro\u0026rsquo;s broad one, or every UnionPay card in your traffic is labelled Maestro — and since both are commonly debit products, the mistake is easy to miss in testing.\nTesting scenarios Both lengths. Generate sixteen and nineteen digit numbers and confirm the form, the API and the database all handle each without truncation. Detection order. Run a 62 number through the full brand-detection chain and assert UnionPay, not Maestro. Failed checksum handling. Feed a number with a deliberately wrong check digit and confirm your form warns rather than blocking submission. This is the behaviour the whole page argues for, and it deserves an explicit test. Range assumptions. Grep your codebase for hard-coded 62 checks and decide, deliberately, what happens to a UnionPay card outside them. Grouping. Nineteen digits do not divide into groups of four; confirm the mask handles the trailing group rather than dropping it. Official test numbers For processor behaviour, use the gateway\u0026rsquo;s own sandbox numbers. Stripe publishes 6200 0000 0000 0005 and 6200 0000 0000 0047 for UnionPay, PayPal documents 6200 6800 0000 0004, and Adyen uses 8171 9999 2766 0000 — which is itself a useful demonstration that the network is not confined to 62. The test card numbers reference collects them by gateway.\nUnionPay International\u0026rsquo;s own material is published at UnionPay International, the authoritative source for the network\u0026rsquo;s acceptance and range information.\nRelated tools and guides The Luhn algorithm guide works through the checksum itself and why it was never designed to carry the weight validation code puts on it — worth reading if this page\u0026rsquo;s argument was new to you. The brand detection guide sets out the ordering problem across all nine networks at once. The other generators are in the tool directory, and the FAQ answers the same question this page opens with, in one paragraph.\nFrequently Asked Questions What BIN range does UnionPay use? 62 is the range everyone knows and the one that covers the overwhelming majority of cards. UnionPay\u0026rsquo;s allocations are not limited to it, and industry BIN references list additional blocks including 81. The practical point for code is that a hard-coded check for 62 alone is incomplete, and will get more incomplete over time. How many digits is a UnionPay card? Sixteen to nineteen. Sixteen is the most common and nineteen appears on a meaningful share of cards, so a length rule fixed at sixteen will reject real ones. This is the same shape of problem as Visa\u0026rsquo;s 13, 16 and 19. Do all UnionPay cards pass the Luhn check? Today, effectively yes — current cards carry a valid check digit like every other network. The reason this question exists is historical: some cards issued in the mid-2010s did not, which made UnionPay the standing counterexample to \u0026ldquo;every card number is Luhn-valid\u0026rdquo;. The lesson survives the exception: a failed checksum should warn, not block. What is the security code on a UnionPay card called? CVN2, the Card Verification Number, three digits on the back. It behaves like Visa\u0026rsquo;s CVV2 and Mastercard\u0026rsquo;s CVC2. Note that some UnionPay debit products in the domestic Chinese market were not designed around card-not-present use at all, so a code may not be present or expected. Should my checkout support UnionPay? If you sell to Chinese customers, at home or travelling, it is not optional — UnionPay is the largest card network in the world by cards issued and by transaction volume. If your market is entirely elsewhere, it is lower priority, though the detection code should still be correct so a UnionPay card does not surface as an unexplained validation error. Do these generated UnionPay numbers work for real payments? No. They are correctly formatted and Luhn-valid, which makes them useful for testing your own validation and brand detection. No issuer has them on file, so any real processor declines them. ","permalink":"https://ccgenerator.org/unionpay-card-generator/","summary":"This UnionPay card generator produces Luhn-valid test numbers on the network\u0026rsquo;s published ranges. UnionPay is the largest card network in the world by cards issued and by transaction volume, and it is also the network that produced the most useful counterexample in card validation — the reason a failed checksum should never be a hard block.\nTest card only\nCredit Card Number Generator Generate dummy card details for development and QA.","title":"UnionPay Card Generator — Test Numbers"},{"content":"\u0026ldquo;Virtual credit card\u0026rdquo; means two different things, and you probably want one of them specifically.\nIf you need a real virtual card — a disposable number that draws on your actual bank balance, for safer online shopping or for keeping subscriptions under control — that comes from a bank or a card issuer, not from a generator. Where to get one is covered below, with no affiliate links and nothing sponsored.\nIf you need synthetic VCC-format numbers for testing — to build and verify a payment form, seed a test database, or write fixtures for a wallet UI — that is what the generator on this page produces.\nTest card only\nCredit Card Number Generator Generate dummy card details for development and QA. Nothing is stored or sent to a server.\nSingle card Bulk cards Card network Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Generate Card Card network All Mixed Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Quantity Generate Cards These numbers are dummy, Luhn-valid test values for software testing only. They are not real active cards and cannot be used for payments. Copy all Show JSON Copy JSON Export JSON Export CSV JSON output All Cards Visa Mastercard Amex Discover JCB Diners Maestro UnionPay Troy These are test numbers, not real cards Every number on this page is synthetic test data. It is generated by a formula, not issued by a bank. These numbers are not linked to any person, account, or balance. They carry no funds. They will be declined by every real payment processor. They only pass client-side format and checksum validation. Attempting to use card data to obtain goods, services, or trials you have not paid for is fraud in virtually every jurisdiction. Do not do it. Generation runs entirely in your browser. Nothing is sent to or stored on our servers. Intended use: payment form validation, checkout UI testing, QA test fixtures, and developer demos. For processor-specific behaviour (approvals, declines, refunds, 3-D Secure) use your gateway's official sandbox test cards.\nReal virtual cards: where they actually come from A real virtual card is issued against an account you already hold. The issuer creates a new number, links it to your existing balance or credit line, and lets you close it whenever you like. Three kinds of provider offer them.\nFrom a bank or neobank, bundled with your account\nProvider Region Notes Capital One (Eno) US Browser extension and app generate numbers at checkout; eligibility depends on the card product Citi Virtual Account Numbers US Still offered but materially restricted since 2025 — desktop web only, $25 minimum limit, fixed three-year expiry Revolut UK, Europe, US Disposable cards that regenerate their number after each transaction Wise Global Up to three active virtual cards per personal profile, free to create Monzo, Starling UK Virtual cards created in-app, usable for one merchant or one budget N26 Europe Virtual cards issued instantly alongside the physical card Most major Turkish banks Turkey Sanal kart is a standard mobile-banking feature; see our Troy card page for the domestic network these run on Independent services that sit on top of an account you already have\nPrivacy.com is the main one in the US. It connects to a bank account or debit card and issues cards you can lock to a single merchant, cap on a per-transaction, monthly or total basis, or set to close automatically after one charge. Merchant-locked cards decline anything charged by a different merchant, which is the feature most people actually want when they go looking for a \u0026ldquo;virtual card generator\u0026rdquo;.\nBusiness and corporate spend platforms\nRamp, Brex, BILL Spend \u0026amp; Expense (the platform formerly called Divvy), Airwallex and Payhawk all issue virtual cards per employee, per vendor or per subscription, with approval rules and accounting integration attached. If the problem you are solving is \u0026ldquo;who spent what on which SaaS tool\u0026rdquo;, this is the category to look at rather than a consumer card.\nProvider availability and limits above were last checked against provider documentation on 3 August 2026. Providers do change what they publish — the official link beside each claim is authoritative. What real virtual cards are good for Paying a site without ever handing over your primary card number One card per subscription, so cancelling is a matter of closing the card Spending caps and merchant locks that the issuer enforces, not you A breach at one merchant exposes one disposable number instead of your account What they are not A virtual card is not free money and it is not anonymous. It draws on your real account, it is issued in your name, and the transaction is recorded exactly like any other. It does not let you take a free trial without paying if the trial converts — it only makes the subsequent charge easy to stop.\nWhere they get awkward Worth knowing before you route everything through one, because these are the cases support queues fill up with:\nRefunds to a closed card. If you close a single-use card and then return the item, the refund is sent to a number that no longer accepts charges. Most issuers credit the parent account anyway, but it is slower and some merchants get stuck retrying. Deposits and pre-authorisations. Hotels, car rental and fuel pumps place a hold that is captured days later for a different amount. Single-use and tightly capped cards fail that pattern by design. Card-present pickup. Anywhere the merchant asks to see the physical card used for the booking — cinemas, some airlines, click-and-collect — a virtual number has nothing to show. Subscription rebilling after the card regenerates. Revolut-style disposable cards change their number after each transaction; a merchant storing the old one will fail the renewal, which is sometimes exactly what you wanted and sometimes not. Merchant identity drift. Merchant locks key on the acquirer\u0026rsquo;s descriptor, and companies change payment processors. A lock set two years ago can start declining a merchant you still want to pay. What this generator produces Synthetic numbers in VCC format: correct network prefix, correct length, valid Luhn check digit, and a plausible expiry and security code. They follow exactly the same rules as real virtual cards, for a reason worth stating plainly.\nThere is no such thing as a \u0026ldquo;virtual card number format\u0026rdquo;. A virtual card issued by Revolut is a normal Visa or Mastercard number, indistinguishable from a physical card\u0026rsquo;s number by looking at the digits. Some issuers use dedicated BIN ranges for virtual products, which a BIN lookup can sometimes reveal, but the number structure itself is identical.\nThis matters more than it sounds. Software that special-cases \u0026ldquo;virtual\u0026rdquo; numbers is chasing a distinction the digits do not carry, and it will misclassify real cards in production. If you want the format rules themselves, the all-network generator carries the comparison table, and the Visa page goes through one network in full.\nTesting scenarios for virtual card flows If you are building a product that issues or displays virtual cards, these are the flows a generated set covers well:\nFlow What to check Issuance UI New card appears in the list, number shown once, expiry rendered correctly Single-use consumption Card moves to a closed state after one charge and cannot be reused Merchant lock A charge from a second merchant is refused and surfaced clearly Spend limit A charge above the cap is refused; a charge at exactly the cap is not Freeze and unfreeze State survives a reload and is reflected everywhere the card appears Card list and masking Only the last four digits render; the full number never reaches logs The masking case is the one that bites hardest, because a bug there is a data-exposure bug rather than a display bug. Generating a batch up front makes it a fixture:\n// Seed a test wallet with multiple virtual cards const virtualCards = generateBatch({ network: \u0026#39;visa\u0026#39;, count: 5 }) .map((card, i) =\u0026gt; ({ id: `vc_test_${i}`, last4: card.number.slice(-4), masked: `•••• •••• •••• ${card.number.slice(-4)}`, expMonth: card.expMonth, expYear: card.expYear, status: \u0026#39;active\u0026#39;, spendLimit: 5000, })); // The number itself never enters the fixture that reaches your UI layer. // If a snapshot test ever contains 16 consecutive digits, that is the bug. Two details catch people out when they build these fixtures. The first is expiry: a virtual card\u0026rsquo;s expiry date is set by the issuer and is often shorter than a physical card\u0026rsquo;s, so fixtures hard-coded to a date five years out will not exercise the \u0026ldquo;expires soon\u0026rdquo; warning you probably built. Generate a spread — some cards expiring next month, some in three years. The second is that last4 is not unique. Issue enough cards and two will end in the same four digits, and any UI or lookup keyed on last-four alone breaks the first time it happens in production. A batch of twenty generated numbers will usually surface a collision, which is the cheapest possible way to find that bug.\nWhat generated numbers cannot cover is anything that needs an issuer to answer: authorisation, real decline reasons, lifecycle webhooks. For those, use your issuing platform\u0026rsquo;s sandbox — the same split described on our test card numbers reference.\nVirtual cards and PCI DSS scope A common misreading: issuing virtual cards does not reduce your PCI DSS scope. Scope follows the data. If your system stores, processes or transmits a primary account number, it is in scope whether that number belongs to a plastic card or a virtual one — the card being disposable changes nothing about how the digits are classified.\nWhat does reduce scope is not holding the number at all. Tokenization replaces the PAN with a reference that is useless outside your integration, and hosted fields keep the digits inside the processor\u0026rsquo;s iframe so they never touch your servers. How tokenization works and PCI DSS for developers cover the distinction properly. The rule of thumb: virtual cards are a control for the cardholder, tokenization is a control for the merchant, and confusing the two leads to an audit finding.\nWhat this tool will not do It does not produce a card with a spendable balance. It does not connect to any bank or issuer. It does not issue a real virtual card, and could not — issuing requires a licensed issuer and an account behind the number. It cannot be used for a free trial, a subscription, or any purchase. Attempting that is fraud, and it is covered explicitly in our terms. If a free trial is what you are actually after, there is a legitimate way to do it — with a real virtual card from an issuer, capped or merchant-locked so the renewal cannot surprise you.\nRelated tools and guides The tool directory lists every generator on the site, and the FAQ answers what a Luhn-valid number does and does not prove. To check a number you already have, the validator reports the check digit, the network and the length.\nFrequently Asked Questions What is a virtual credit card? A card number issued against an account you already hold, created on demand and usually disposable. It spends from the same balance or credit line as your physical card, but because the number is separate you can cancel it, cap it, or lock it to one merchant without touching the card in your wallet. It is issued by a bank or a card issuer, not generated by a website. Can I generate a working virtual credit card for free? No. A card number only works because an issuer has it in their records and an account stands behind it, and no generator can create that relationship. The tool on this page produces synthetic numbers in the correct format for testing software — they carry no balance and every payment processor declines them. If you want a real virtual card, open one with a bank or an issuer that offers them; several do so at no cost. Is a virtual card number different from a physical card number? Structurally, no. A Revolut virtual card is an ordinary Visa or Mastercard number with the same length, the same Luhn check digit and the same issuer prefix rules as a plastic card. Some issuers reserve particular BIN ranges for virtual products, which a BIN lookup can sometimes reveal, but you cannot tell by looking at the digits. Any code that treats virtual numbers as a separate format is built on an assumption that does not hold. Do virtual cards protect me from fraud? They limit the blast radius rather than preventing fraud. If a merchant is breached, the number that leaks is one you can close in seconds, and your real card keeps working. Merchant-locked cards go further by declining anything charged from a different merchant. What they do not do is protect you from a merchant you chose to pay, or from fraud that starts with your account credentials rather than your card number. Can I use a virtual card for a free trial? Yes, with a real virtual card from an issuer, and this is a common legitimate use — a card capped at a low limit or locked to one merchant makes an unwanted renewal easy to stop. Be clear about what that means, though: you are not getting the trial for free. If the trial converts and the card declines, you have cancelled the subscription, not obtained the service without paying. Using a generated number for the same purpose is simply a failed payment, and often a terms-of-service breach. Which banks offer virtual cards? In the US, Capital One through Eno and Citi through Virtual Account Numbers, alongside Privacy.com which connects to a bank account you already have. In the UK and Europe, Revolut, Monzo, Starling, N26 and Wise all issue them from their apps. In Turkey most major banks offer a sanal kart in mobile banking. Availability often depends on the specific product rather than the bank, so check your card\u0026rsquo;s benefits guide. Do these generated numbers work anywhere? They work anywhere that checks format and stops there — your own validation, a card-type detector, a test fixture, a UI mock-up. They fail everywhere that asks an issuer, which includes every real payment. That is the point of them: they exercise the parts of a checkout you wrote without touching the parts a bank owns. Can I test my virtual card issuing product with these? For the parts that do not require an issuer response, yes — card lists, masking, last-four display, expiry rendering, limit forms and freeze toggles are all easier to test with a deterministic set of numbers than with sandbox calls. For issuance, authorisation, merchant locking and lifecycle events, you need your issuing platform\u0026rsquo;s own sandbox, because those behaviours live on their side. ","permalink":"https://ccgenerator.org/virtual-credit-card-generator/","summary":"\u0026ldquo;Virtual credit card\u0026rdquo; means two different things, and you probably want one of them specifically.\nIf you need a real virtual card — a disposable number that draws on your actual bank balance, for safer online shopping or for keeping subscriptions under control — that comes from a bank or a card issuer, not from a generator. Where to get one is covered below, with no affiliate links and nothing sponsored.","title":"Virtual Credit Card Generator — VCC Numbers"},{"content":" Test card only\nCredit Card Number Generator Generate dummy card details for development and QA. Nothing is stored or sent to a server.\nSingle card Bulk cards Card network Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Generate Card Card network All Mixed Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Quantity Generate Cards These numbers are dummy, Luhn-valid test values for software testing only. They are not real active cards and cannot be used for payments. Copy all Show JSON Copy JSON Export JSON Export CSV JSON output All Cards Visa Mastercard Amex Discover JCB Diners Maestro UnionPay Troy These are test numbers, not real cards Every number on this page is synthetic test data. It is generated by a formula, not issued by a bank. These numbers are not linked to any person, account, or balance. They carry no funds. They will be declined by every real payment processor. They only pass client-side format and checksum validation. Attempting to use card data to obtain goods, services, or trials you have not paid for is fraud in virtually every jurisdiction. Do not do it. Generation runs entirely in your browser. Nothing is sent to or stored on our servers. Intended use: payment form validation, checkout UI testing, QA test fixtures, and developer demos. For processor-specific behaviour (approvals, declines, refunds, 3-D Secure) use your gateway's official sandbox test cards.\nThis Visa card generator produces Luhn-valid test Visa card numbers on the 4 prefix for payment form validation, checkout QA, and automated test fixtures. What follows is the part most tools in this category leave out: Visa\u0026rsquo;s actual format rules, why the 13/16/19-digit question breaks so many checkout forms, and where these numbers stop being useful.\nVisa card number format Property Value Major Industry Identifier (first digit) 4 IIN / BIN range 4 — every Visa number begins with it Standard length 16 digits Legacy length 13 digits (older cards, still valid) Extended length 19 digits (some Visa Electron and co-branded products) Check digit Luhn (mod 10) Security code name CVV2 Security code length 3 digits The 13/16/19-digit problem A common validation bug is hard-coding Visa numbers to 16 digits. ISO/IEC 7812 permits a primary account number of up to 19 digits, and Visa has issued 13-digit numbers historically and 19-digit numbers on some products. If your form rejects anything that is not 16 digits, it will reject cards that are perfectly valid — and the cardholder has no way to work around it.\nTest all three lengths. These are Luhn-valid and safe to paste into a test form:\n13 digits 4222 2222 2222 2 16 digits 4539 1488 0343 6467 19 digits 4532 0151 1283 0366 187 The generator above emits the 16-digit form, which is what nearly every issued Visa card uses. For the two rarer lengths, use the numbers above, or construct your own — the checksum arithmetic is identical at any length.\nVisa product types and their BIN ranges Visa is a family of products, not one card, and their BIN characteristics differ:\nVisa Classic / Credit — begins with 4, 16 digits, the default case Visa Debit — also begins with 4; nothing in the number distinguishes it from credit Visa Electron — issued on 4026, 417500, 4405, 4508, 4844, 4913, and 4917 Visa Purchasing / Corporate — separate commercial BIN ranges V PAY — a Europe-only chip-and-PIN product, also on 4 You cannot tell whether a Visa number is credit or debit from the number alone. That information lives in the issuer\u0026rsquo;s BIN table, not in the digits. If your routing logic needs to know — to apply different interchange handling, or to block credit funding on a payout flow — you need a BIN lookup service. See the BIN and IIN guide for how those tables are structured, and the BIN lookup tool when it ships.\nHow this Visa card generator builds test numbers Three steps, all in your browser:\nPrefix. The number starts with 4, Visa\u0026rsquo;s entire network prefix. Account body. The digits between the prefix and the final position are drawn from crypto.getRandomValues(), the browser\u0026rsquo;s cryptographically secure random source. Check digit. The last digit is computed so the whole number satisfies Luhn. Worked through for a real Visa payload:\nPartial number: 4539 1488 0343 646_ Step 1 — Double every second digit, from the rightmost payload digit leftwards: 4 5 3 9 1 4 8 8 0 3 4 3 6 4 6 ×2 ×2 ×2 ×2 ×2 ×2 ×2 ×2 8 5 6 9 2 4 16 8 0 3 8 3 12 4 12 Step 2 — Subtract 9 from any result above 9: 8 5 6 9 2 4 7 8 0 3 8 3 3 4 3 Step 3 — Sum: 8+5+6+9+2+4+7+8+0+3+8+3+3+4+3 = 73 Step 4 — Check digit = (10 − (73 mod 10)) mod 10 = (10 − 3) mod 10 = 7 Result: 4539 1488 0343 6467 The full Luhn walkthrough lives in the guides.\nTesting scenarios specific to Visa These are the cases a Visa card generator is actually good for — each one exercises your own code rather than a processor\u0026rsquo;s.\nLength flexibility. Feed the form all three lengths above and confirm each is accepted. This is the single highest-value test on this page.\nBrand detection on the first keystroke. The Visa mark should appear as soon as the user types 4, not on blur and not after 16 digits. Visa is the one network where a single digit is enough to decide.\nCVV2 field length. Three digits for Visa, four for American Express. If your CVV field is a fixed maxlength=3, Amex breaks; if it is fixed at 4, Visa accepts a code that is too long. The field has to react to the detected brand.\nInput mask. Visa groups as 4444 4444 4444 4444 at 16 digits. At 19 the grouping runs 4444 4444 4444 4444 444, and at 13 it is 4444 4444 4444 4 — masks that assume four even groups mangle both.\nLuhn rejection. Change the last digit of any generated number and confirm the form rejects it. A form that accepts both is not running the checksum.\nBIN routing. If Visa traffic goes to a particular acquirer, generate a batch and confirm the routing table picks it up on the leading 4.\nA brand-detection regex that handles every valid Visa length:\n// Visa brand detection — matches all three valid Visa lengths const VISA = /^4\\d{12}(\\d{3})?(\\d{3})?$/; const normalise = value =\u0026gt; value.replace(/\\D/g, \u0026#39;\u0026#39;); VISA.test(normalise(\u0026#39;4222 2222 2222 2\u0026#39;)); // 13-digit → true VISA.test(normalise(\u0026#39;4539 1488 0343 6467\u0026#39;)); // 16-digit → true VISA.test(normalise(\u0026#39;4532 0151 1283 0366 187\u0026#39;)); // 19-digit → true VISA.test(normalise(\u0026#39;4539 1488 0343 646\u0026#39;)); // 15-digit → false VISA.test(normalise(\u0026#39;5425 2334 3010 9903\u0026#39;)); // Mastercard → false The two optional three-digit groups are what admit exactly 13, 16, and 19 while rejecting everything between. Strip separators before testing — the pattern matches digits only. Note that this checks shape, not the checksum; run both.\nVisa\u0026rsquo;s own test card numbers Visa publishes test card numbers for merchants and processors through its developer programme, and every major gateway ships its own Visa test numbers. Those numbers are registered in the processor\u0026rsquo;s sandbox and return genuine authorisation responses. Ours do not.\nThis generator Gateway sandbox card Passes client-side Luhn check Yes Yes Triggers Visa brand detection Yes Yes Unlimited unique numbers Yes No — a handful of fixed numbers Returns an authorisation response No Yes Triggers specific decline codes No Yes Works with 3-D Secure flows No Yes The split is clean: use a Visa card generator like this one while you are testing your own code, and switch to the gateway\u0026rsquo;s numbers the moment the processor\u0026rsquo;s behaviour is what you are testing. Stripe and PayPal both publish full tables, and we collect the equivalents on the test card numbers reference.\nVisa card anatomy Taking 4539 1488 0343 6467 apart:\n4 5 3 9 1 4 8 8 0 3 4 3 6 4 6 7 └──────┬────────┘ └───────────┬────────────┘ └┬┘ │ │ │ │ │ └── Check digit (Luhn) │ └──────────────────── Individual Account Identifier └───────────────────────────────────────────── IIN / BIN (first 6–8 digits) ↑ └─ MII: 4 = banking and financial, and Visa\u0026#39;s network prefix The leading 4 does double duty — it is both the Major Industry Identifier for banking and finance and Visa\u0026rsquo;s entire scheme prefix. The next five digits complete the six-digit IIN identifying the issuing bank, though under ISO/IEC 7812-1:2017 that field is migrating to eight digits, so lookup code should not assume six. The nine digits after it are the account identifier, and the final 7 is the Luhn check digit computed above.\nFor a network-by-network comparison, the all-network credit card generator carries the full format table; Mastercard, American Express, and Troy have their own pages, and the tool directory lists everything else. The FAQ covers what a Luhn-valid number does and does not prove.\nFrequently Asked Questions Do all Visa cards start with 4? Yes. Every Visa card number begins with the digit 4, which is both its Major Industry Identifier and the whole of its network prefix. That makes Visa the simplest network to detect — one digit is enough. The reverse does not hold as neatly: a few other schemes also issue in ranges beginning with 4, so production BIN lookups check more than the leading digit. How many digits does a Visa card have? Usually 16. Visa\u0026rsquo;s specification also permits 13 digits, which appears on older cards, and 19 digits, used on some Visa Electron and co-branded products. Validation that accepts only 16 digits will reject cards that are perfectly valid. What is CVV2 and where is it on a Visa card? CVV2 is Visa\u0026rsquo;s name for the three-digit security code printed on the signature panel on the back of the card. It is computed by the issuer from the card number, the expiry date, and two secret keys, so it cannot be derived from the number by anyone else. The codes this generator shows are random three-digit values that only satisfy the length check. Can I tell if a Visa number is debit or credit? Not from the number. The digits encode the network and the issuer, not the funding source. Whether a card draws on a credit line or a deposit account is recorded in the issuer\u0026rsquo;s BIN table, so routing logic that needs to know requires a BIN lookup service. Will these Visa test numbers work on a real payment page? No. They pass client-side format and checksum validation, which is what makes them useful for testing your own form. They are not registered with any issuer, so a payment processor will decline them at authorisation. Why does my form reject a 13-digit Visa number? Almost always because the validation hard-codes a 16-digit length. ISO/IEC 7812 permits a primary account number of up to 19 digits and Visa has issued 13-digit numbers, so a length check should accept 13, 16, and 19 rather than a single value. Is 4111 1111 1111 1111 a real card? No. It is the most widely published Visa test number in the industry and appears in the documentation of nearly every payment gateway. It is Luhn-valid and deliberately not assigned to any account. If you find it in a data set, that data set is test data. ","permalink":"https://ccgenerator.org/visa-card-generator/","summary":"Test card only\nCredit Card Number Generator Generate dummy card details for development and QA. Nothing is stored or sent to a server.\nSingle card Bulk cards Card network Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Generate Card Card network All Mixed Visa Mastercard Amex Troy Discover JCB Diners Club Maestro UnionPay Quantity Generate Cards These numbers are dummy, Luhn-valid test values for software testing only. They are not real active cards and cannot be used for payments.","title":"Visa Card Generator — Test Visa Card Numbers"}]