Payment card number with expiry and security code

What it covers

Returns a payment card number with an expiry and a security code, for testing checkout forms, card validators and payment sandboxes. `source=synthetic` (the default) builds a Luhn-valid number on a real prefix of one of eight brands — Visa, Mastercard, Amex, Discover, JCB, Diners, Maestro, UnionPay; it is synthetic, may coincidentally match a real card, and nothing about it is chargeable. `stripe-test`, `adyen-test`, `braintree-test`, `payu-test` and `checkout-test` draw from that processor’s published test cards, each tagged with the `scenario` its number triggers in the sandbox (`success`, `declined`, `insufficient-funds`, `3ds-required`, …) and the processor’s own label in `processorScenario`; only scenarios triggered by the number alone are included. Where a processor pins the expiry or security code (Adyen, PayU) the record carries its values. `brands`, `source` and `scenario` are comma-separated pools; together with `edge` and the expiry params they narrow the pool, and a request nothing can serve is a 400 naming the sources and brands that could. The expiry params (months from now, or absolute months) collapse into one interval measured against the request time; a card expires on the last day of its month, and a contradictory combination is a 400.

A payment card number carries no national register behind it: its first digits (the IIN, or BIN) name the card network, and its last digit is a Luhn (mod-10) check digit over everything before it. That is all a checkout form can verify offline — brand by prefix and length, typos by Luhn.

The `source` parameter picks where the number comes from. `synthetic` (the default) builds one: a real IIN prefix of the brand, random digits, the Luhn check digit. These numbers are synthetic — they may coincidentally match a real card number, but no real account stands behind them, the expiry and security code are random, and nothing about them is chargeable. The other sources are fixed snapshots of the test cards Stripe, Adyen, Braintree, PayU and Checkout.com publish for their sandboxes, each tagged with the `scenario` its number triggers there and the processor’s own label in `processorScenario`. Only scenarios triggered by the number alone are included — a decline Braintree triggers by amount, or Adyen by holder name, is not in the list. The package README names each source page and the date of the snapshot.

How it’s calculated

The last digit is a Luhn (mod-10) check digit computed over all the digits before it.

payload = 37828224631000, last digit 5 to be checked
from the right: 0 doubled → 0, 0 kept → 0, 0 doubled → 0, 1 kept → 1
3 doubled → 6, 6 kept → 6, 4 doubled → 8, 2 kept → 2
2 doubled → 4, 8 kept → 8, 2 doubled → 4, 8 kept → 8
7 doubled → 14, and 14 − 9 = 5; 3 kept → 3
sum = 0+0+0+1+6+6+8+2+4+8+4+8+5+3 = 55
(10 − (55 mod 10)) mod 10 = (10 − 5) mod 10 = 5

Edge cases

• Mastercard has two IIN ranges: 51–55 and the newer 2221–2720. Validators written before 2017 accept only the first; `edge=true` builds on the boundary prefixes 2221, 2720, 51 and 55.
• Lengths differ by brand: Amex is 15 digits, Diners Club International 14, Visa 16 or 19, Maestro anything from 12 to 19. A form that insists on 16 digits rejects valid cards — `edge=true` draws each brand’s shortest and longest length.
• The security code is four digits on Amex and three on every other brand, and each brand names it differently: CVV2, CVC2, CID, CAV2, CVN2.

Gotchas

• A card expires at the end of its expiry month, not at its start: `10/26` is still valid on 31 October 2026. `expiryDate` reports that last day.
• Adyen and PayU accept their test cards only with the expiry and code they publish, so those records carry the processor’s values, and a request whose expiry params exclude them (`?source=adyen-test&expired=true`) is a 400 rather than a card the sandbox would refuse.
• A processor test card works only in that processor’s test mode — in live mode every one of them is declined.