Card Testing and Carding
Your checkout can become a testing service for stolen cards. The attacker wants an authorisation result, even when they have no interest in the product your store sells.
Try freeTL;DR
Card testing checks whether stolen card details work. Failed attempts create processing load; successful ones create fraud exposure. Detect attempts across cards and stop suspicious submissions before they reach your payment provider. Track legitimate payment completion when you tighten controls.
What is Card Testing and Carding
The attacker submits stolen card details through a payment or card-saving form and reads the result. They repeat the process across cards, retaining those that work for later purchases or resale.
A completed order is not necessary for every test. Card-saving checks and unsuccessful authorisations also reveal whether submitted details are accepted. Your order history therefore shows only part of the incident.
The Core Abuse Pattern & Hidden Costs
Retail & e-commerce
Guest checkout, gift-card purchases and low-value products offer places to submit payment attempts without an established account. Your storefront remains usable, but your payment service handles repeated authorisations that never become genuine purchases.
The cost includes infrastructure load and investigation time. Authorisation fees depend on your provider agreement. Successful test payments create disputes, while sustained high declines can affect how issuers assess later legitimate payments. Stripe documents these consequences, including the difference between card setup and payment testing.
Small order values make the incident easy to underestimate. Your team still has to identify fraudulent payments, stop fulfilment and distinguish card testing from customers retrying a declined purchase.
Online marketplaces
The attacker submits stolen cards against inexpensive listings. Attempts are scattered across buyer accounts and sellers, making the pattern harder to see from any one seller's order list.
Sellers expect to fulfil successful orders. Cancelling confirmed fraudulent purchases requires stopping dispatch, explaining the decision and correcting balances. Your fraud team must investigate across the marketplace rather than waiting for an individual seller to report a problem.
A genuine low-value product does not make the payment legitimate. Equally, low price alone is a poor blocking rule when inexpensive purchases are a normal part of your marketplace.
Fraudsters’ Best Practices
Stay below the order-review threshold
The attacker chooses small payments that attract less attention in a review queue organised by order value. The value being obtained is the answer from the payment system. Your largest-order report does not show which pages are being used to validate cards.
Spread attempts across accounts and IPs
Different emails, guest sessions and connections keep each individual history short. A per-account limit sees only a few failures. Compare the number of different cards attempted from the same device or session to see what account-level totals miss.
Use payment checks outside the main checkout
A saved-card form also reaches the payment provider. Protecting the purchase button leaves a gap if other forms initiate validation. Map every place your application creates a payment or saves a card, including server-side calls behind those forms.
Learn from payment responses
The attacker reads whether the attempt succeeded and what happened when it failed. Detailed errors help them interpret a test. Your customer-facing response should explain the next useful action without exposing unnecessary payment-provider diagnostics.
OWASP OAT-001: Carding defines bulk card validation and distinguishes it from guessing missing card details. Its public source repository gives your engineering and payments teams a shared vocabulary for incident review.
How to Detect & Prevent Card Testing and Carding
Compare authorisation attempts with completed orders. Check distinct payment-method references per device, repeated declines and retries against the same basket. Use provider-supplied references rather than collecting raw card details for this analysis.
Apply rate limits and verification before another payment attempt is created. Keep your payment provider's own fraud controls enabled and cover card-saving forms as well as checkout.
Preserve a reasonable retry path for genuine customers. Measure accepted customer payments, disputes and support contacts after changing limits; fewer attempts alone does not establish that checkout improved.
How Kairal can help you stop Card Testing and Carding
Kairal records checkout requests with their device, IP and session, scores them and applies configured checks or blocks. Enforcement needs to run before the payment-provider call so a blocked request does not initiate another authorisation.
Kairal Business Defense, currently in early access, adds payment-abuse assessment using payment references supplied by your integration.
You inspect Kairal's logged decisions alongside provider declines and completed payments, then adjust protection on the affected forms. Your store and provider retain payment acceptance, refunds and dispute handling. Blocking a later attempt does not reverse a payment already processed.
Make your business a harder target.
Get a 3-month free hands-on trial to gain visibility into the threats facing your online business.
Send your website details. Our team will prepare your account and email you the next steps.