What is a test expiry card?

A test expiry card is a fake card number paired with a made-up expiration date inside a sandbox payment environment. No real account sits behind the number, so the date only has to pass the same format checks a live card would pass. Developers use these pairs to test checkout forms, saved-card logic, and renewal jobs without moving money.

card expiry checker

Why test cards carry an expiry date

Payment forms validate the expiry field before they contact an issuer. A sandbox that skipped the field would hide bugs in your validation code, your database schema, and your error messages. Test dates give you a controlled value to push through those checks.

card expiry validation

• Front end checks: month range, two-digit or four-digit year, no past dates.
• Back end checks: storage format, card-on-file updates, token refresh.
• Renewal logic: what happens when a stored card reaches its expiry month.

How test expiry dates are formatted

Most gateways expect MM/YY, where MM runs from 01 to 12 and YY is the last two digits of the year. Some APIs want MM/YYYY, and others take the two parts as separate fields. Check the sandbox docs for the exact shape before you hardcode a value.

test card expiry

• MM/YY: the common choice on web checkout forms.
• MM/YYYY: common in server-to-server API payloads.
• Split fields: expiry_month and expiry_year sent as integers.
• ISO style: YYYY-MM when the date is stored in a database.

Future dates vs expired dates

A future date keeps the card valid, which is what you need for a successful test charge. A date in the past flips the same number into a decline case, which is useful for testing your error copy. Pick the direction that matches the scenario in front of you.

expiry date test card

Which expiry date should you use?

1. Start with the test number your processor publishes for an approved charge.
2. Pair it with any future date, such as 12/34 or 01/35.
3. Run the charge and confirm your app stores the date in the format your database expects.
4. Repeat with a past date, such as 01/20, and check that the decline path fires.
5. Keep both values in a fixture file so every environment uses the same data.

Stripe states in its test card table that any future expiration date works with its published numbers. Other processors publish the same kind of table with slightly different rules. Match the date to the outcome you are testing, not to a real card.

How a gateway validates an expiry date

Validation runs in stages, and each stage can reject the input on its own. Knowing the order helps you find where a test case fails.

1. Parse the string and strip spaces or slashes.
2. Reject months below 01 or above 12.
3. Compare the date to the current month and reject past values.
4. Check the card number against the Luhn algorithm.
5. Send the request to the sandbox and read the response code.

Step three is the one that surprises people. A date that passed last year fails today, so old fixtures rot. Store test dates far in the future, or compute them at run time.

Does the expiry date change the decline reason?

Sometimes. Several sandboxes tie decline behavior to the test card number, not the date. Others use a past date to produce an expired_card response. Test both paths if your app branches on the decline code.

• expired_card: the date has passed.
• incorrect_cvc: the CVC check failed, unrelated to the date.
• card_declined: a generic refusal from the issuer.

Testing saved cards and renewals

Expiry dates matter most after the first charge. A card on file has a date that will pass, and your app has to handle the failure that follows.

• Expiring soon: many apps warn the customer a month before the date.
• Expired on file: the renewal attempt should fail and ask for a new card.
• Updated date: card updater services can return a new expiry for a live card, so leave room in your schema for that change.

Sandbox clocks do not move, so you cannot wait for a date to pass. Seed the stored record with a past date and run the renewal job by hand.

Test card data vs real card data

A test card is a string you can share in a repo. A real card number, expiry, and CVC belong to a person's account, and using that trio without permission is card fraud. PCI DSS treats the CVC as sensitive authentication data that must not be stored after a transaction is authorized. That is why every test suite should use published sandbox numbers and nothing else.

FAQ

What expiry date should I put on a test card?

Any future MM/YY value works for most sandboxes, such as 12/34. If the processor documents a specific date for a test case, use that instead.

Can I use an expired date on purpose?

Yes. A past date is the standard way to trigger an expired-card decline without touching a live account.

Do test card numbers work in live mode?

No. Sandbox numbers are rejected by production systems, and production numbers do not exist in sandbox tables.

Why does my test date get rejected?

Common causes are a past year, a four-digit year sent to a two-digit field, or a month written as 13 or 00. Check the field format first.