This JCB card generator produces Luhn-valid test numbers inside JCB’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.

Test card only

Credit Card Number Generator

Generate dummy card details for development and QA. Nothing is stored or sent to a server.

Card network
These numbers are dummy, Luhn-valid test values for software testing only. They are not real active cards and cannot be used for payments.

JCB card number format

PropertyValue
BIN range3528–3589
Standard length16 digits
Permitted lengthup to 19 digits
Check digitLuhn (mod 10)
Security codeCAV2, 3 digits, on the back
Grouping4-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.

That distinction is where the bug lives. A very large amount of production code does this:

if (/^35/.test(number)) return 'jcb';    // wrong

It looks reasonable and it is wrong at both ends. 3500–3527 and 3590–3599 are outside JCB’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.

The correct check is four digits deep:

const JCB = /^35(2[89]|[3-8]\d)\d{12,15}$/;

And the boundary tests that prove it:

JCB.test('3527000000000000');   // false — one below the range
JCB.test('3528000000000000');   // true  — first JCB block
JCB.test('3589000000000000');   // true  — last JCB block
JCB.test('3590000000000000');   // 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.

Why 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.

It 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.

The 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 “the logo was wrong” — the customer paid and left.

The 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.

The 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.

Where JCB is accepted

JCB is Japan’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.

The 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.

The 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.

Testing 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’s name rather than the brand’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’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.

That 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’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.

Official test numbers

For processor behaviour, use the gateway’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.

JCB’s own developer and acceptance material is published at Global JCB, which is the authoritative source for the network’s range allocations and partner arrangements.

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.

Frequently Asked Questions

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.
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.
CAV2, the Card Authentication Value, three digits on the back of the card. Functionally it behaves exactly like Visa’s CVV2 and Mastercard’s CVC2 — the different name has no effect on field length or handling.
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.
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.
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.