A payment card test is a transaction you run to see how a payment system responds to a given card number: approved, declined, or pushed into a 3-D Secure challenge. Developers run these in a processor's sandbox with published test numbers. Merchants run them against their own live gateway before a launch. What you should not do is run them against card numbers you do not own, because that is carding, and it is a federal crime in the US under 18 U.S.C. § 1029. The mechanics look identical from the outside, which is exactly why the line needs stating up front.
What test cards actually are
Every major processor publishes a set of fake card numbers that behave in predictable ways. Stripe, Adyen, Braintree and Authorize.net all have them. Some numbers always approve. Others trigger a specific decline code like insufficient funds or expired card. Others force a 3DS challenge so you can walk through the authentication step. None of them touch a real bank account. They exist so you can build error handling without waiting for a live customer to fail.
The format still follows the real standard, so Luhn validation, BIN ranges and expiry parsing all get exercised. That is the point. A test card is a fixture, not a credential.
What a single test transaction cannot tell you
An approval in sandbox says your request shape is correct. It says nothing about whether the card is live, funded, or stolen. I have watched people confuse these two things and waste a week chasing a phantom integration bug. Real authorization outcomes depend on issuer rules, balance, risk scoring, and velocity, none of which the sandbox models.
For live traffic, the only honest signal is the authorization response your acquirer returns, plus later settlement. A card can authorize and still charge back. Test it all you want, you will not predict that from the front end.
What card testing attacks look like from the merchant side
Card testing is the abusive version: an automated script fires thousands of low-value authorization attempts to find numbers that still work. The signature is easy to spot once you know it. A burst of $0.50 to $1.00 authorizations from one IP block or a rotating set of them. A high ratio of declines to approvals. Disposable email addresses on every order. Card BINs from issuers you never normally see. Your acquirer will notice before you do, and the fees plus the chargeback exposure land on your merchant account.
Checks worth putting in a real integration test
- Luhn check and expiry format validation on the client, plus a server-side repeat of both.
- Correct card brand detection from the first digits, including co-badged cards.
- Every decline code your processor can return, each mapped to a message a customer can act on.
- The full 3DS challenge, including the failure and timeout paths.
- Idempotency keys, so a retried request does not double charge.
- Webhook handling for refunds, disputes, and asynchronous settlement.
Controls that stop card testing on a live checkout
- Rate limits per IP, per card fingerprint, and per session, with a challenge before the limit trips.
- Velocity rules on BIN and issuer, not just on customer account.
- A minimum order amount, or a CAPTCHA when the basket is unusually small.
- Device fingerprinting and bot signals fed into your risk engine before authorization.
- Alerting on authorization-to-sale ratios and on clusters of micro-amount attempts.
- 3-D Secure on high-risk segments, which shifts liability and kills most scripted attempts.
Handling the CVV correctly
PCI DSS is unambiguous here. The CVV may be used to verify a transaction and must not be stored after authorization, in any form, encrypted or hashed. It should never hit your logs, your error tracker, or an analytics event. If your test harness captures full request bodies, redact the security code before it leaves the process. I have seen that mistake in staging environments more than once, and it turns a harmless test setup into a compliance finding.
The short version
Use the processor's sandbox numbers to test your code. Use your own live card, with your consent, to test your production flow. Treat any other card number as off limits, and build the rate limits and monitoring that make your checkout a poor target for the people who do not follow that rule.