Square's Official Sandbox Test Numbers
Square's own documentation is explicit about this: the sandbox "doesn't accept valid credit cards" in general — it only recognizes specific reserved numbers, similar to how Stripe's sandbox works.
| Value | Scenario |
| 4111 1111 1111 1111 | Visa — success |
| 5105 1051 0510 5100 | Mastercard — success |
| 4000 0000 0000 0002 | Card declined |
| 4000 0000 0000 0010 | Card-on-file authorization declined |
| CVV: 911 | Triggers "CVV incorrect" error |
| Postal code: 99999 | Triggers "postal code incorrect" error |
| Expiration: 01/40 | Triggers "expiration date incorrect" error |
| 7783 3200 0000 0000 | Gift card, $1.00 sandbox balance |
Set the expiration date to any future month and year for the standard test cards above. These numbers only function against Square's sandbox credentials — they'll do nothing in production or against any other processor.
Where Luhnly Fits In
Because Square's sandbox only recognizes its own reserved numbers, a Luhnly-generated card won't process a payment there — same situation as Stripe. But that fixed list is still just eight or so numbers, which becomes limiting the moment you need:
- Bulk test data for seeding a database or staging environment with many unique-looking (but harmless) records
- Form-validation and UI testing — checking your input mask, card-brand detection, and client-side Luhn check before a request ever reaches Square's API
- Load testing a checkout flow with many distinct card numbers rather than the same handful repeated
Luhnly complements Square's fixed test cards rather than replacing them — use Square's official numbers for anything that actually calls their API, and Luhnly for everything upstream of that.
Frequently Asked Questions
Can I use a Luhnly-generated number with Square's sandbox?
No. Square's sandbox explicitly does not accept arbitrary valid credit card numbers — it only recognizes a small, fixed set of reserved test numbers. Use Square's official test cards above for anything that calls the Square API, and use Luhnly for UI or form-validation testing upstream of that call.
What triggers a decline in Square's sandbox?
Specific reserved card numbers, plus specific CVV, postal code, and expiration date values documented by Square, each trigger a corresponding declined or error response.
Does the classic 4111 1111 1111 1111 test card still work on Square?
It's Square's documented default Visa test number, but developers have occasionally reported inconsistent behavior with it over time. Always check Square's current sandbox documentation rather than relying on memory.