Card Testing Fraud: How Small Businesses and Nonprofits Can Protect Online Payment Forms

A card-testing attack does not need to steal money from your business to become expensive.

Over one weekend, an online donation form used by a nonprofit supported by VCCP received more than 200 automated payment attempts. The organization did not benefit from those transactions, but the processing costs were real. The attack generated several hundred dollars in fees, interrupted donation processing and forced the organization to stop and secure its payment path.

The nonprofit is not identified here because this article is not meant to expose a victim. It is to help business owners, nonprofits, and website operators understand how card testing works, recognize the warning signs, and build better protection before an attack becomes expensive.

What is card testing?

Card testing, sometimes called carding or card spinning, is a form of payment fraud. Criminals obtain stolen card information and use automated scripts or bots to submit many small transactions. They are trying to discover which card numbers are still valid before using or selling them elsewhere.

According to NMI’s card-testing guidance, these attacks can generate hundreds or thousands of card-not-present transaction attempts within minutes. Even when most attempts are declined, the merchant may still face authorization costs, operational disruption, account restrictions, and possible disputes.

Card testing is not limited to traditional online stores. Any publicly accessible form that can submit a card transaction may be targeted, including:

• Donation pages
• Event-registration forms
• Invoice-payment pages
• Membership and subscription forms
• Online checkout pages
• Hosted payment links
• Customer account and saved-card features

Why small businesses and nonprofits are attractive targets

Fraudsters often look for payment forms that are easy to reach and inexpensive to test. A donation page with an open amount field may accept very small payments. A small organization may also have fewer technical resources, less frequent transaction monitoring, and limited staff available outside normal business hours.

That does not mean the organization did anything wrong. It means you should treat every public payment form as a potential target for automated traffic.

A payment page can be designed for generosity and convenience while still needing strong protection against automated abuse.

Warning signs of a card-testing attack

Card testing often creates a pattern that looks very different from normal customer activity. Watch for:

• A sudden increase in authorization attempts
• Many small transactions or repeated identical amounts
• A high number of declines within a short period
• Repeated attempts using similar names, email addresses, or billing information
• Transaction volume that is far above the organization’s normal activity
• Multiple cards attempted from the same device, session or network address
• Unexpected gateway, processor, or fraud-alert notifications

Do not wait for the monthly statement if daily activity suddenly looks unusual. Fast detection can reduce fees and prevent a larger disruption.

What to do if card testing is happening now

If you believe a payment page is under attack, act quickly and document every step.

1. Pause the affected payment path

Temporarily disable the form, payment button, or integration that is receiving the suspicious traffic. If the entire website does not need to come down, leave the informational pages available and pause only the affected payment function.

2. Contact the processor and gateway

Ask whether the account has been restricted and whether additional attempts are still reaching authorization. Request help identifying the source, transaction pattern, and available fraud controls. The payment processor, gateway, and website provider may each control a different part of the solution.

3. Preserve the evidence

Download transaction reports, alert emails, and relevant website logs. Record when the activity began, the amounts attempted, the number of approvals and declines, and every action taken. This information can help your providers investigate and may be important if disputes follow.

4. Secure account access

Change passwords if there is any possibility that credentials were exposed. Do not reuse passwords across services. Enable multifactor authentication, review user access, and rotate gateway or API security keys with help from the appropriate developer or provider.

5. Involve the website developer

A processor can respond to transactions that reach its system, but the website may need controls that stop automated attempts earlier. Ask the developer to review CAPTCHA, rate limits, session validation, bot filtering, form security, and application logs before the payment path is reopened.

Use layered protection, not one security switch

No single setting can guarantee that card testing will never occur. Effective protection combines controls at the website, gateway, and processor levels.

CAPTCHA and bot detection

CAPTCHA can help distinguish legitimate people from automated scripts before a payment request is submitted. Google’s guidance for carding protection recommends protecting pages where customers enter card information and evaluating transaction risk before authorization.

Configure and validate CAPTCHA correctly. Simply displaying a checkbox does not help if the website fails to verify the result before allowing the transaction to continue.

Velocity limits and rate controls

Velocity controls limit how many attempts can come from the same customer, device, card, session or network address during a defined period. They can also flag an abnormal number of declines or card changes. The thresholds should reflect the organization’s normal activity so legitimate customers are not blocked unnecessarily.

AVS and card-security-code rules

Address Verification Service and CVV or CVC response rules provide additional signals. They are useful layers, but they should not be treated as complete protection because stolen records may contain matching information and fraudsters can vary their attempts.

Gateway detection and real-time alerts

Some gateways monitor transaction patterns and can restrict an account when they detect suspected testing. For example, NMI’s Automatic Card Testing Detection can send email and text alerts and restrict processing when its algorithm identifies suspicious activity.

Merchants should confirm who receives security alerts, add more than one responsible contact when possible, and test that the contact information remains current.

Fraud rules and risk scoring

Gateway tools may allow rules based on transaction amount, country, email address, network address, frequency, or approval rate. More advanced services can apply device intelligence, behavioral analysis, and risk scoring. Configure these tools for the business rather than enabling them without review.

Daily monitoring and reconciliation

Review online payment activity frequently. Compare the number of attempts, approvals, declines and refunds with normal business volume. Make sure alerts go to someone who can respond, including during weekends or events when donation activity may be higher.

Why a hosted payment page may still need website protection

A hosted form can reduce the amount of sensitive card data a merchant’s website handles, which can be valuable. However, the link, button, or page that sends users to the hosted form may still be exposed to automated abuse.

Ask where each control operates:

• Does the website stop bots before redirecting?
• Does the hosted form require CAPTCHA or another verification step?
• Does the gateway limit repeated failed attempts?
• Does the processor monitor unusual authorization volume?
• Who is alerted, and how quickly?
• Who has authority to pause and restore processing?

Security gaps often appear between systems because each provider assumes another layer is responsible.

Questions to ask before launching an online payment form

1. What prevents an automated script from submitting repeated transactions?
2. Are CAPTCHA results verified before authorization?
3. What velocity or decline thresholds are active?
4. Are AVS and CVV responses reviewed or enforced?
5. Which fraud tools are included, and which require an added fee?
6. Who receives security alerts by email and text?
7. Can you disable the payment form without taking down the entire website?
8. Will declined authorization attempts generate processing costs?
9. What is the emergency response process outside normal business hours?
10. How often should you review fraud rules and account permissions?

Two VCCP payment pathways worth comparing

VCCP is not limited to one online-payment pathway. The right fit depends on the merchant account, website platform, transaction workflow, desired security controls, pricing and support requirements. Two VCCP options are worth comparing.

CardConnect with Clover Hosted Checkout

For eligible CardConnect merchants using Clover Ecommerce, customers can be directed from the merchant’s website to a Clover-hosted payment page. Clover securely handles the card information on its hosted page, which can reduce the merchant’s PCI-compliance burden.

According to Clover’s Hosted Checkout documentation, the hosted page includes reCAPTCHA to help prevent card-not-present fraud. Clover states that reCAPTCHA is enabled by default for new merchants, but each merchant should confirm it remains enabled. Clover also provides configurable fraud controls, including AVS and CVV verification, transaction and velocity limits, allow and block lists, and risk scoring. Availability and default settings can vary by Clover plan and account configuration.

Clover’s card-testing guidance emphasizes using multiple controls together rather than relying on one setting. VCCP can help eligible businesses explore Clover solutions through the appropriate CardConnect relationship.

NMI Gateway and hosted payment tools

For compatible merchant accounts, NMI provides gateway technology with automatic card-testing detection, real-time alerts, account restrictions, and configurable fraud rules. NMI’s hosted-payment tools can also include CAPTCHA, suspicious-activity blocking, key verification and optional one-time-password protection, depending on the payment flow and configuration.

NMI can be useful when a business needs a gateway that connects compatible processors, websites, software, recurring billing, invoicing, or other card-not-present workflows. As with Clover, review and configure the available protections for the specific merchant rather than assuming they’re active.

Neither pathway is automatically the right answer for every organization. VCCP can help compare the merchant account, gateway, hosted-payment experience, fraud controls, pricing, and website responsibilities before you select a solution.

VCCP can help you ask the right questions

Payment security is not only a technical issue. It is also an operational and financial issue. A small organization may have a web developer, a gateway provider, and a merchant processor, but no single person reviewing how the pieces work together.

VCCP helps businesses and nonprofits compare payment pathways, identify the providers responsible for each layer, and understand which questions to answer before a payment form goes live.

If you already accept payments online, we can help you review the current workflow. If you are building a new donation, invoice, or checkout experience, we can help you compare compatible merchant-account and gateway options, including CardConnect with Clover Hosted Checkout and NMI payment technology.

This article is provided for general educational purposes and is not legal, cybersecurity or PCI-compliance advice. Fraud tools, gateway features, fees, and processor responses vary by provider and account configuration. No security control can guarantee that it will prevent all fraudulent activity. Work with your payment providers and qualified technical professionals to evaluate your specific environment.