Merchant Card Testing Procedure: Detect and Stop Attacks

A merchant card testing procedure is the fixed sequence a payment team runs when small authorization attempts arrive in bulk at the checkout. The purpose is to identify the pattern, cut off the source, prevent settlement of fraudulent authorizations, and report the event to the acquirer. Card testing is the practice of running stolen card numbers through a live payment page in low-value attempts to learn which numbers still authorize. The cardholder is not the target of the attack. Your store, your processing fees, and your chargeback ratio are.

I can’t help with CVV sales or unauthorized card testing

Prerequisites

• Dashboard access to your payment gateway with permission to edit fraud rules
• A named contact at your acquiring bank or payment processor
• An incident log template with fields for time, source, volume, and action taken
• Authority to pause a payment endpoint without a code release

The Procedure

1. Confirm the pattern. Export authorization logs for the last 24 hours and filter for orders under one dollar, twenty or more distinct card numbers from a single IP address, or a decline rate above 30 percent on one checkout endpoint.
2. Freeze settlement. Place a hold on unsettled authorizations tied to the flagged orders so the funds do not capture while you investigate.
3. Isolate the source. Record the IP addresses, device fingerprints, user agents, and email domains shared across the flagged attempts.
4. Block at the edge. Add the identified IP ranges and device signatures to your web application firewall or gateway blocklist.
5. Raise the authorization floor. Set a minimum order amount on the affected endpoint and require a CVV and AVS match for every transaction under that amount.
6. Add velocity limits. Cap the number of authorization attempts allowed per IP, per card BIN, and per email address within a rolling hour.
7. Turn on 3-D Secure. Enable step-up authentication for the affected channel so issuers can challenge risky attempts directly.
8. Void the fraudulent authorizations. Release the holds on orders you have confirmed as test attempts so they never capture.
9. Notify your acquirer. Send the incident log to your processor contact with the time window and the volume of attempts.
10. Review after 72 hours. Compare decline rates and authorization volume against the pre-attack baseline to confirm the block is holding.

What to Capture in the Incident Record

• First and last timestamp of the attack window
• Total authorization attempts and total dollars attempted
• Count of distinct card numbers, BINs, IP addresses, and devices involved
• Rules changed, with the exact values set and the time of the change
• Name of the person who notified the acquirer and the time of that contact

Common Mistakes

Teams often block a single IP address and stop there. Testers rotate through proxies, so a blocklist without velocity limits rarely holds for more than a few hours. A second mistake is capturing the small authorizations to avoid a decline rate penalty. Capturing known test transactions converts a fraud attempt into a chargeback, which costs more than the decline. A third is skipping the acquirer notification. Issuers track testing patterns across merchants, and processors can flag your account if the volume looks like complicity rather than victimization.

merchant card test patterns

Ongoing Controls

After the immediate response, keep a standing rule set: a minimum order value, mandatory CVV for card-not-present orders, per-IP attempt caps, and a weekly review of decline rates by endpoint. Review your rules whenever you change processors or add a new payment channel, since rules rarely migrate with the integration. Log every rule change with a timestamp so a later chargeback dispute can be traced to a known configuration.

Merchant Card Testing Method: What It Is and How Merchants Spot It