Stripe's documented test card suite is the top pick for most teams testing expiration dates, because it pairs fixed card numbers with known future expiry dates, matching CVC values, and predictable decline responses. The criteria that matter are narrow. The number has to pass a Luhn check so your formatter and validator behave the way they do in production. The expiry date has to sit far enough in the future that it will not quietly age out of your test suite. The provider has to document how it treats a past date, the current month, and a far-future date. And none of the values can come from a real account. Everything below compares the realistic options against those four points.

card expiry date test

What a test expiry card actually is

A test expiry card is a card number and expiration date issued by a payment processor for use in its sandbox. The number is not tied to a bank account, it will never authorize a real charge, and it exists so developers can exercise the code path that reads the expiration field. When you type an expired month and year into a sandbox checkout, the processor returns the same class of error a live gateway would return. That is what lets you verify your error handling, your retry logic, and the copy you show a customer.

related article

Two different things get confused here. The first is client-side date validation, where your own form checks whether the entered month and year are in the past. The second is server-side authorization, where the processor or issuer decides whether to decline. A test expiry card only helps with the second. You still need your own fixtures for the first.

related article

Criteria for choosing a test card source

• Luhn validity. Test numbers should pass the check digit algorithm so your code path matches production input.
• Documented expiry behavior. The source should state what happens with a past date, a current-month date, and a far-future date.
• Stable dates. Numbers with expiry dates a year or more out beat ones pinned to a date that has already passed.
• Decline coverage. You want values that return expired card, incorrect CVC, and generic decline so you can assert on each case.
• No real card data. Nothing in the set should be a live account, and nothing should be stored after authorization.

Option 1: Processor sandbox test cards

Stripe, Adyen, Braintree, and most large gateways publish test card numbers directly in their developer documentation. Each number arrives with a fixed expiry, a CVC, and a note about which error it triggers.

read more

• Pros: Dates are already set, decline behavior is documented, and the numbers work in the provider's own sandbox with no setup.
• Cons: Coverage varies by provider, some older example dates have expired, and you cannot invent new ones without leaving the documented set.

Use case: You are integrating one gateway and want to confirm that an expired card produces the error your UI expects. Start here before writing anything yourself.

Option 2: Generated Luhn-valid test numbers

You can compute a check digit for a made-up prefix and produce a number that passes validation, then pair it with any expiry date you like. A generator that follows the Luhn formula in ISO/IEC 7812-1 makes this repeatable.

• Pros: You control the expiry, so you can test a date that passed last month, a date in the current month, and a date ten years out.
• Cons: A gateway will not recognize the number and may reject it before it ever reaches expiry logic, so the test proves your code and not theirs.

Use case: Unit tests and form validation. If you need to assert that February of last year is rejected, a generated number with a controlled date is the cleanest fixture.

Option 3: Fixtures inside your own test suite

Store a small table of numbers, expiries, and expected outcomes in your repository and drive both unit and integration tests from it. Keep the table labeled as sandbox data so nobody mistakes it for a real account.

• Pros: Deterministic, versioned with your code, and easy to extend when you add a new gateway.
• Cons: You own the maintenance, and a hardcoded date eventually goes stale if nobody reviews it.

Use case: Teams running CI against more than one processor. One fixture table feeding several integration suites keeps behavior comparable across gateways.

Why the expired case deserves its own test

An expired card is not the same failure as a declined card. The expiration check can happen in your form, in the gateway's pre-authorization step, or at the issuer, and the message a customer sees changes depending on where it stops. Test all three: a date your form rejects before submission, a date the sandbox rejects, and a valid date that the sandbox declines for an unrelated reason. Log the raw response code each time so you can tell the paths apart later.

What you should never do

Never test with a real card number, even your own. The PCI Security Standards Council is explicit that sensitive authentication data, which includes the CVV, must not be stored after authorization. Buying, selling, or trading real card numbers is a federal crime in the United States, and a sandbox that accepts a real number is a sign that something is wired wrong. Processor-issued test data exists precisely so you never need to touch a live account.