The best starting point for most US merchants is the PCI DSS Self-Assessment Questionnaire paired with a tokenized checkout, because those two items close the gaps attackers use most often. The criteria below are coverage of real attack paths, effort to run, evidence you can hand to an acquirer or auditor, and fit for a team of a given size.
What a credit card security test actually covers
A credit card security test is a controlled check that confirms card data stays protected from the moment it is typed at checkout to the moment the transaction settles. Four surfaces matter:
Credit Card Security Check: How CVV, AVS, and 3D Secure Work
- Input handling: how the checkout page parses and validates the card number, expiry date, and CVV before anything leaves the browser.
- Authorization messaging: whether the CVV2 and address verification values travel in the authorization request instead of landing in a database.
- Storage and tokenization: whether a token replaces the account number so no cardholder data sits in your systems.
- Access control: who on your team can reach logs, dashboards, refund tools, and processor credentials.
The test is not a one-time event. Payment flows change when you add a method, switch processors, or ship a new checkout, and each change reopens parts of the surface.
PCI DSS self-assessment
The Self-Assessment Questionnaire is the document most small and mid-size merchants use to show how card data is protected. Version 4.0 of the standard brought several requirements into effect in March 2025, so an SAQ finished against older wording may not survive scrutiny. The questionnaire asks you to map every place an account number, expiry date, or CVV touches your environment, then prove the mapping with configuration records and screenshots.
Pros
- Accepted by processors and acquirers as evidence of due diligence.
- Forces a written inventory of systems that handle card data.
- Scales from a few dozen questions to a few hundred, based on how you take payments.
Cons
- Question wording is dense and easy to answer incorrectly.
- Self-attestation carries little weight if a breach later shows the answers were wrong.
- Requires annual renewal and updates after significant changes.
Use it if: you take cards directly, store any cardholder data, or your processor asks for a signed attestation each year.
CVV verification in a gateway sandbox
Because the CVV2 cannot be stored after authorization, a CVV test is not a database test. It checks that the value is collected, passed once in the authorization message, and discarded. Sandbox card numbers that trigger specific response codes make this practical without touching live accounts. You want to see a clean pass, a no-match response, and a not-processed response, then confirm that none of those values appear in logs, error messages, or order notes.
Pros
- Runs in a test environment with no real cardholder data.
- Reveals logging mistakes, which are a frequent source of leaks.
- Fast to repeat after each checkout release.
Cons
- Sandbox behavior does not always match production processor rules.
- Does not test storage, access control, or network paths.
Use it if: you build or maintain your own checkout and want a repeatable check before each release.
3-D Secure authentication testing
Authentication adds a bank-side step to the payment flow, and the test work sits in the branching: frictionless approvals, challenge flows, failed challenges, abandoned sessions, and exemption handling for low-risk orders. Each branch needs a defined outcome for the order and for the authorization that follows.
Pros
- Shifts liability for certain fraud chargebacks when the flow is implemented correctly.
- Exposes gaps in order state handling that also affect refunds and voids.
Cons
- Requires coordination with your processor and issuer test environments.
- Adds checkout steps that can reduce completed orders if tuned poorly.
Use it if: you sell high-ticket items, digital goods, or anything with elevated fraud exposure.
External scans and penetration testing
Network-level testing looks at the outside of your environment rather than the checkout page. Quarterly external scans by an Approved Scanning Vendor and an annual penetration test are the standard pair, and the penetration test repeats after significant infrastructure changes. A useful report names the weakness, the path taken to reach it, and the fix, not just a severity label.
Pros
- Finds exposed services and misconfigured hosts that code review misses.
- Produces dated evidence for auditors and cyber insurers.
Cons
- Costs more than self-assessment, especially for a wide scope.
- A scan result alone does not prove card data is safe.
Use it if: you host any part of the payment path, run servers that touch transaction data, or need insurer documentation.
Consumer-side card security checks
Cardholders run a different set of tests. Turn on transaction alerts, read the statement line by line at least once a month, and dispute anything unfamiliar with the issuer. Federal law limits what you owe on unauthorized credit card charges, and issuers generally go further than the legal floor. A security freeze or a temporary lock on your credit file blocks new accounts from being opened in your name, which matters more than the charge itself when card details leak.
- Set alerts for every transaction, not just those above a threshold.
- Dispute in writing and keep the confirmation.
- Replace the card number after any confirmed compromise, even if the charge is small.
Use it if: you are a cardholder reacting to a suspicious charge or a breach notice.
Putting the checks in order
- Map where card data enters, travels, and rests in your environment.
- Move storage to tokens so the map has fewer boxes.
- Run sandbox CVV and authentication branch tests on every release.
- Complete the SAQ once, then review it after each payment change.
- Schedule external scans quarterly and a penetration test annually.
Teams that skip the mapping step usually over-test the checkout page and under-test everything behind it, which is where the expensive failures happen.