Expired card test numbers, and testing the date logic itself.
There are two different things worth testing here: does your processor correctly decline an expired card, and does your own form catch an invalid expiry date before it ever reaches the processor?
Two Different Tests, Often Conflated
An expired-card decline can happen in two completely different places in your stack, and testing only one leaves a real gap:
- Client-side / form validation — your own checkout form should reject an obviously past expiry date before ever submitting it, giving the customer instant feedback
- Processor-side decline — if a stale date somehow reaches your payment processor, it should decline with a specific expired-card reason, not a generic error
Most teams test the second one (using a processor's fixed test card) and forget the first, since it requires generating a Luhn-valid number with a genuinely past date — which is exactly what standard processor test cards don't give you, because they're fixed values with fixed (usually far-future) expiry conventions.
Stripe's Expired Card Test Number
| Number | Decline code |
|---|---|
| 4000 0000 0000 0069 | expired_card |
This confirms your integration correctly surfaces an expired-card error from Stripe's side. It does not test your own client-side date validation, since the number itself is fixed regardless of what expiry date you submit alongside it.
Testing Your Own Date Validation
This is exactly the gap Luhnly's generator was built to close. Select Expired date from the Scenario dropdown in the generator above, and it produces a card number that's still genuinely Luhn-valid, paired with an expiry date calculated to be one to 36 months in the past relative to today. That lets you confirm your own form catches the problem locally — before a request ever reaches your processor — independent of any single processor's fixed test data.
Related Guides
Frequently Asked Questions
Does Stripe's expired card test number let me pick which date is on it?
No — 4000 0000 0000 0069 is a fixed value; Stripe's system returns the expired_card decline regardless of what expiry date you actually submit with it. It tests your error handling, not your form's own date validation.
How do I test that my own form rejects a past expiry date?
Use Luhnly's generator with the Expired date scenario selected — it produces a Luhn-valid number paired with a genuinely past date, calculated relative to today, so you can confirm your client-side validation catches it before submission.
Is an expired card decline a fraud signal?
No — it's simply a date-validity issue, not a security concern. It's safe to tell the customer directly that their card has expired and ask for a different one.