The top pick for most teams is the Stripe test card 4242 4242 4242 4242 paired with any future expiry date. Stripe lists it in public testing documentation and its sandbox accepts it with any three digit CVC, which makes it the shortest path to exercising an expiration field end to end. Four criteria drive the pick: the number comes from a published sandbox list, it cannot reach a real cardholder account, it can trigger both the approved and the expired path, and it fits the same form fields your live integration uses.

Test Expiry Card: How to Check Card Expiration Dates in Checkout Code

How expiry validation works

An expiry month marks the last month a card stays valid. A card printed 04/27 works through April 30, 2027 and fails on May 1. Gateways return a decline specific to that case, and Stripe documents expired_card as one such code. Your form must parse MM/YY and MM/YYYY, reject months outside 1 to 12, reject dates in the past, and decide what happens at the month boundary. The issuer sets the cutoff, not the browser clock, so a card that passes at 11:58 p.m. on April 30 in your time zone can still fail in the gateway's. Freeze the clock in tests rather than trusting the build machine's date.

expiry date test card

Option 1: Stripe sandbox test cards

Pros

• Public list with stable numbers, readable without an account
• Any future expiry is accepted in test mode, so you can isolate the expiry field from other failures
• Separate numbers cover decline paths, including an expired card
• Same field names and validation surface as the live integration

Cons

• Sandbox responses differ from a live issuer, so not every real decline reproduces
• Tied to one processor; other gateways need their own set
• Test keys and test numbers have to be kept out of production config

Use this set when you build on Stripe, or as a reference while you design a harness for another gateway.

Expiry Date Test Card Guide: Where to Buy CVV

Option 2: Your processor's own sandbox cards

Pros

• Decline codes and field rules match what the processor returns in production
• Support can trace a test transaction by its identifier
• Some sets cover 3D Secure and wallet flows that the generic lists skip

Cons

• Documentation quality varies, and a few processors gate it behind an approved test account
• Numbers rotate on occasion, which breaks a hard coded fixture
• Fewer published examples means more of your own test design work

Pick this once the processor is fixed, in particular with regional acquirers whose decline messages differ from the large US gateways.

card expiry date test

Option 3: Synthetic numbers for unit tests

Pros

• No vendor dependency, so the suite runs offline in CI
• You can generate hundreds of cases for Luhn, formatting, and past versus future logic
• Fast feedback while the form component is still in flux

Cons

• No gateway will accept them, so they test your parser and not the integration
• They must be labeled as test data so nobody copies one into a config file

Use them for form level tests and keep at least one full sandbox run per release. Build them from a range your team controls, never from an issuer range you do not own.

Criterion: edge cases your expiry tests must cover

1. Card expiring in the current month is accepted
2. Card expiring last month is rejected with the expired decline, not a generic error
3. Month values 00 and 13 are rejected at the field level
4. Two digit years map to a window you define, and 00 does not land in the past by accident
5. Input forms 4/27, 04/27, 04/2027, and 04 / 27 all parse to the same value
6. Autofill works; the HTML standard defines cc-exp, cc-exp-month, and cc-exp-year tokens for these fields
7. Paste, backspace, and a cleared field do not submit an empty or partial date
8. Clock skew near the month boundary produces the same result in your test and at the gateway

Criterion: keep live card data out of the test path

PCI DSS requires that production cardholder data stay out of development and test environments. An expiry test card is useful only when the number beside it is also fake. Do not paste a customer's card into a staging build to see whether the date field accepts it, and scrub PAN and expiry from logs, error trackers, and screenshots attached to bug tickets.

What an expiry test card is not

A test card does not tell you whether a real card is live. Sending real numbers through a payment form to find the ones that authorize is card testing, a pattern processors and card networks flag, and it breaks merchant agreements. Test numbers exist to prove that your code handles a valid date, an expired date, and a malformed one. Nothing more.

Release checklist

1. Sandbox key confirmed in the test environment, live key absent
2. Valid, expired, and malformed dates each covered by a test case
3. Decline for an expired card mapped to a readable message for the user
4. Expiry field rejects month 00 and month 13 before the request leaves the browser
5. Logs checked for PAN or expiry leakage
6. One full end to end sandbox purchase run after the last change