A test expiry card is a sandbox card number paired with an expiration date you choose, used to confirm a checkout form accepts valid dates and rejects expired or malformed ones. Payment gateways publish these numbers for developers, and they never touch a real account. The goal is to prove your date logic works before a live card reaches the form.

test card expiry

What is a test expiry card?

A test expiry card is any combination of a gateway test card number and an MM/YY value you control. The number identifies the sandbox; the date is the variable you change to trigger a pass or a fail.

Expiry Date Test Card Guide: Where to Buy CVV

• Card number: a published sandbox number, not a real account.
• Expiry: the field under test. Use past dates, the current month, and far-future dates.
• CVC and ZIP: placeholders, unless your form checks them against the issuer.

Most processors also ship decline-trigger numbers, so you can test an expired date and an issuer decline in the same session.

related article

Why expiry checks matter for real payments

An expired card fails authorization, and every failed attempt counts against your approval rate. A form that skips the check sends requests that cannot succeed.

card expiry validation

Recurring billing has the same problem. Stored expiry dates age out, and a subscription charge on a dead date produces a hard decline instead of a retry path.

• Card networks expect a valid expiration date with each authorization request.
• Expired credentials are a common cause of involuntary churn.
• Client-side checks cut useless requests to the processor.

How to test expiry input, step by step

1. Open a sandbox account with your payment processor and copy a test card number from its docs.
2. Load your checkout in test mode and enter a valid future date. Confirm the form accepts it and the sandbox returns an approval.
3. Enter a past date. Confirm the form blocks it before any network call.
4. Enter malformed values: month 13, month 00, year 00, a single-digit month, a pasted "12 / 27" with spaces.
5. Test the boundary: a card that expires in the current month.
6. Inspect the sandbox request log and confirm the date goes out as MM/YY or MM/YYYY, matching what the gateway documents.

Test cases that catch real bugs

• 13/2027 as a month. A form that accepts it has no range check.
• 00/00. Passes a naive "not empty" rule.
• 01/2020. A past date a regex-only validator lets through.
• 1/27 without a leading zero. Should normalize to 01/27.
• 12/2099. A far-future date some validators reject as implausible. Decide what you want here.
• Extra characters such as 12/27/2027. Should fail with a clear message.

What happens at the current month?

A card is valid through the last day of its expiration month. A card marked 08/2025 works on August 31, 2025 and fails on September 1. Test that edge with a fixed clock instead of waiting for the calendar.

Two-digit or four-digit year?

Pick the format your processor documents and stick to it. Two-digit years are the common case, but a field that accepts "27" and "2027" without telling the user which one it wants will send inconsistent payloads.

What a correct expiry field does

• Accepts digits and normalizes them to MM/YY as the user types.
• Allows paste of "12/27", "12-27", and "1227".
• Rejects month 00 and month 13 through 99 on the keystroke, not on submit.
• Repeats the check on the server, because the browser is not a trust boundary.
• Stores only the month and year, never the full card number or the CVC.

Server-side checks still matter

A client check is a courtesy to the customer; the server check is the control. Anyone can post a form payload straight to your endpoint with the browser validation bypassed.

Your server should re-parse the date, confirm the month is 1 to 12, and confirm the card is not past its expiration month at the moment of the charge. Run the same test cases against the API in your test suite with the clock mocked.

Sandbox and live data do not mix

Test keys, test card numbers, and test dates belong in development. Live keys belong in production. A shared config that flips between the two is how test data reaches a real processor.

Never test with a real cardholder number, your own live card included. Using someone else's card data to probe a form is card fraud in the US under 18 U.S.C. § 1029, and handling that data pulls your app into PCI scope.

• Keep production keys in a secret manager, not in the repo.
• Mask card numbers in logs and drop the CVC before it hits storage.
• Point staging at the sandbox endpoint, never at a live one.

FAQ

Does an expired card always get declined?

At authorization, yes. The issuer rejects a card past its expiration month. Your form should catch it first so the customer sees a specific message instead of a generic decline.

Why does my form accept month 13?

Because the check tests length, not range. Validate month 1 through 12, compare the year and month against today, then repeat the check on the server.

Can I test expiry without a gateway account?

Part of it. Unit tests with a mocked clock cover the date logic. The full path, from form to sandbox response, needs a test account.

Should I block a card that expires this month?

No. It is still valid. Trigger a card update request, but keep charging until the month ends.