Debit Card Test Software: Sandbox Testing Guide

Debit card test software runs transactions against a payment processor's sandbox using published test card numbers, so you can verify approvals, declines, refunds, and error handling without touching a real account. The legitimate version runs on test PANs issued by processors such as Stripe or Adyen. Tools built to check live card numbers against issuer responses, often marketed as "CVV checkers," are fraud tools: they violate card network rules, they are illegal in most jurisdictions, and they are not covered here. This guide is about sandbox testing only.

card testing application

What the software actually tests

• Approval flows, including authorization and capture.
• Soft and hard declines, and the result codes your UI shows.
• CVV and AVS response mapping, tested with reserved mismatch numbers.
• 3-D Secure challenge and frictionless paths.
• Refunds, partial captures, and void timing.
• Idempotency and retry behavior on timeouts.

Prerequisites

• A sandbox merchant account in test mode with its own API keys.
• The processor's current test card list, pulled from its docs rather than copied from an old blog post.
• A staging checkout build that points at the sandbox base URL.
• Request logging enabled, with a retention window you control.

Run a debit test pass

1. Create or open the sandbox merchant account and confirm it is in test mode.
2. Load the processor's test card list and copy the numbers into your test fixture file.
3. Submit an approval case with a generic test PAN and the test expiry shown in the docs.
4. Confirm the authorization response and the captured amount appear in the sandbox dashboard.
5. Submit a decline case using the processor's decline-triggering amount or PAN.
6. Submit a CVV mismatch case and check that your checkout maps the code to the right message.
7. Submit a 3-D Secure case and complete the challenge page.
8. Issue a full refund, then a partial capture and refund, and verify the ledger entries.
9. Replay one request with the same idempotency key and confirm no duplicate charge appears.
10. Log each case as pass or fail against the expected response code.

Test data rules

• Use only numbers from processor documentation. They sit in reserved test ranges that never resolve to real accounts.
• Never enter a real cardholder number into a test tool. Storing a CVV after authorization violates PCI DSS.
• Do not buy or build tooling that pushes live PANs to issuers to check validity. That is card testing, it is detectable through enumeration patterns, and it is a criminal offense.
• Keep test fixtures out of production configuration and out of shared repos with live keys.

Common failures

• Production keys in staging, so a test PAN gets a real decline.
• An expired test expiry date copied from stale documentation.
• Result codes hardcoded in the client instead of read from the response.
• Test request bodies written to shared logs without redaction.

Verification checklist

• Every decline path shows a distinct, actionable message.
• Refund and partial capture totals reconcile in the dashboard.
• Retries reuse idempotency keys.
• Test card data appears nowhere in production logs.