# Stop Magento Spam Sign-ups and Card-Testing Without CAPTCHA ![Magento spam and card-testing defence editorial hero](images/magento-stop-spam-card-testing.webp) ## Overview You can stop bot sign-ups and card-testing on a Magento 2 store without putting a CAPTCHA in front of real customers. The two attacks are different problems: bots create fake accounts and flood forms to poison your customer database, while card-testers push stolen card numbers through the payment step in rapid, low-value attempts to find which ones still work. CAPTCHA hurts on both counts because it taxes every genuine buyer, and solver farms and headless browsers beat it anyway. The techniques that actually work are silent: honeypots, timing checks, human-interaction gates, and velocity limits that watch behaviour instead of asking a question. **Key point: the reliable defences are invisible to humans and expensive for bots; CAPTCHA is the reverse, which is why it costs you conversions and still lets the traffic through.** --- ![Store owner reviewing a clean customer sign-up list free of bot accounts](images/magento-stop-spam-card-testing-lifestyle.webp) ## What are the two attacks? They share a name (bots) but hit different parts of the store and cause different damage. **Account and registration spam** targets your open forms: registration, contact, newsletter, and product reviews. Bots fill them to seed spam links, inflate your subscriber count, plant fake reviews, or build a stock of accounts to abuse later. The result is a dirty customer database and a support inbox full of noise. **Card-testing (carding)** targets the payment step. An attacker holding a list of stolen card numbers runs many small authorisations to learn which cards are still live, then sells or uses the working ones elsewhere. Magento's guest checkout posts to `POST /V1/guest-carts/:cartId/payment-information`, and a bot can hit that endpoint far faster than any human checks out. ## What damage does card-testing do? The amounts are tiny; the cost is not. - **Gateway and processing fees.** Every authorisation attempt, approved or declined, can carry a fee. Thousands of tests turn into a real bill. - **Fraud flags and account risk.** A spike in declines and micro-transactions is exactly the pattern payment processors watch for. Sustained card-testing can get your merchant account reviewed or frozen. - **Chargebacks.** The cards that do go through are stolen, so the genuine cardholders dispute them, and you pay the chargeback plus a fee on each. - **A poisoned database.** Bot accounts and fake reviews degrade the data you make decisions on, from segmentation to social proof. --- ## Why does CAPTCHA hurt more than it helps? CAPTCHA moves the cost onto the wrong party. Every real customer pays the friction; the bots that matter often do not. Magento does ship two CAPTCHA options. The built-in image CAPTCHA lives under **Stores > Configuration > Customers > Customer Configuration > CAPTCHA** for the storefront and **Stores > Configuration > Advanced > Admin > CAPTCHA** for the admin. Google reCAPTCHA is configured under **Stores > Configuration > Security > Google reCAPTCHA Storefront** and **Google reCAPTCHA Admin Panel**, and it can guard the login, registration, forgot-password, contact, newsletter, review, and checkout forms. reCAPTCHA even hooks the web API layer, so in principle it can validate the place-order call. The problem is what that costs you. Adding a challenge to checkout is one of the most reliable ways to lower conversion, because you interrupt buyers at the moment they are ready to pay. Meanwhile commercial solver services clear image and reCAPTCHA challenges cheaply, and modern bots run real browser engines that pass the invisible scoring. You pay in lost sales for a wall the determined attacker walks around. --- ## How do you detect bots without a CAPTCHA? Behaviour gives bots away. You do not need to ask a human to prove they are human when the automated client already looks nothing like one. ### Step 1 - Add honeypot fields Insert form fields that are hidden from real users with CSS. A human never sees them and leaves them blank; a bot that fills every field in the form gives itself away. It is invisible, adds no friction, and catches a large share of naive bots. ### Step 2 - Check submission timing A human takes seconds to read and complete a form. A bot submits almost instantly. Record when the form was rendered and reject submissions that arrive faster than a person could plausibly type, for example under a second on a contact form. ### Step 3 - Require real interaction Keep the submit action gated until the page sees genuine input: mouse movement, a touch, or a keypress. Headless bots that post directly to the form handler without ever driving the page fail this check silently. ### Step 4 - Validate a per-load token Issue a signed token when the form loads and require it back on submit. Submissions that reuse an old token or arrive without one, typical of scripted replay, get dropped before they reach your handlers. ### Step 5 - Rate-limit by velocity at the payment step Card-testing is defined by frequency: many attempts from one source, or many cards against one cart, in a short window. Limit authorisations per IP, per session, and per cart, and block a source that trips the threshold. Velocity limits catch the payment attack that form checks cannot see. --- ## Common mistakes ### Mistake 1 - Treating CAPTCHA as the whole answer CAPTCHA is a single, beatable layer that also taxes real users. Leaning on it alone gives you the conversion cost without the protection. ### Mistake 2 - Ignoring the payment endpoint Most stores harden the login and registration forms and forget that the guest checkout endpoint is a target in its own right. Card-testing does not touch your account forms at all. ### Mistake 3 - Leaving password reset unthrottled Magento already limits reset requests under **Stores > Configuration > Customers > Customer Configuration > Password Options** (five requests, ten minutes apart by default). Switching this off to reduce support friction hands bots a free enumeration and abuse channel. ### Mistake 4 - No velocity limit on authorisations Without a per-source cap on payment attempts, a card-tester can run thousands of authorisations before anyone notices, and the first sign is often the processor's warning rather than your own. --- ## Advanced: layering silent defences The strongest setup combines cheap-for-you, expensive-for-bots checks, so beating one still leaves the others standing. - **Stack the signals.** Honeypot, timing, interaction gate, and token validation each catch a different class of bot, and together they filter the overwhelming majority of automated traffic with zero human friction. - **Watch velocity across carts, not just sessions.** A card-tester spreads attempts thinly to stay under a per-session limit, so also cap attempts per IP range and per card fingerprint where your gateway exposes it. - **Alert on the pattern.** A burst of declines, a run of micro-authorisations, or a spike in new accounts from one network is the signal. Feed those into an alert so you react in minutes, not at the next statement. - **Keep a block log.** Recording blocked submissions with IP, user agent, and form type turns a vague "we get bots" into a diagnosable pattern. --- ## Where Moogento Fits Magento's native answer to form spam is CAPTCHA, which is the friction this guide is trying to avoid. [NoMoreSpam](https://moogento.com/nomorespam-m2) applies the silent techniques instead: it injects hidden honeypot fields, records timestamps to catch submissions that arrive too fast for a human, validates a per-load cryptographic hash, and keeps the submit button disabled until it sees real mouse, touch, or keyboard input. It guards the registration, login, forgot-password, contact, newsletter, and review forms, flags reviews stuffed with links or missing a rating, and can log every blocked submission. That closes the account-and-registration side of the problem without asking a real customer to solve a puzzle. For the payment step, pair form-level protection with velocity limits at your gateway or firewall, since card-testing is stopped by rate control on authorisations rather than by anything on a form. --- ## Real-World Impact Stores that move from CAPTCHA to silent detection typically see: - Bot sign-ups and fake reviews fall while genuine registrations and checkouts carry no extra friction. - A cleaner customer database and a quieter support inbox, because the noise never gets written. - Fewer card-testing authorisations reaching the processor once velocity limits are in place. The aim is not a perfect wall. It is making your store cheap to leave alone and expensive to attack. ## FAQs ### How do I stop bot sign-ups in Magento without CAPTCHA? You can stop bot sign-ups in Magento without CAPTCHA by using silent behavioural checks: honeypot fields hidden from real users, timing checks that reject instant submissions, a gate that requires real mouse or keyboard input, and a per-load token. These catch bots without adding any friction for genuine customers. ### What is card-testing in Magento? Card-testing, or carding, is when an attacker runs many small payment authorisations with stolen card numbers to find which ones still work. In Magento it targets the checkout payment endpoint, and it is defined by high frequency rather than large amounts. ### Does Magento have built-in CAPTCHA? Yes. Magento Open Source includes an image CAPTCHA under **Stores > Configuration > Customers > Customer Configuration > CAPTCHA** and **Advanced > Admin > CAPTCHA**, and Google reCAPTCHA under **Stores > Configuration > Security > Google reCAPTCHA Storefront**. Both add friction for real users and can be beaten by solver services. ### Does CAPTCHA stop card-testing? CAPTCHA does not reliably stop card-testing. reCAPTCHA can be enabled on checkout, but it lowers conversion for every genuine buyer and is routinely cleared by commercial solver farms and real-browser bots. Velocity limits on payment attempts are a better fit for the payment endpoint. ### How do I protect the Magento checkout payment endpoint? Rate-limit authorisation attempts per IP, per session, and per cart at your gateway, firewall, or CDN, and block sources that exceed the threshold. Card-testing is a velocity attack, so a per-source cap on attempts is the control that stops it. ### Why does spam hurt my Magento store beyond the noise? Bot accounts poison your customer database and segmentation, fake reviews damage social proof, and inflated newsletter lists distort your metrics. Card-testing adds gateway fees, chargebacks, and the risk of your merchant account being flagged. ### Does Magento limit password reset requests already? Yes. Under **Stores > Configuration > Customers > Customer Configuration > Password Options**, Magento limits reset requests by default to five within a ten-minute window. Leave this protection on, since disabling it opens an easy abuse channel for bots. ## Next Steps - Add silent form protection (honeypot, timing, interaction gate, token) to registration, login, contact, newsletter, and reviews. - Keep password-reset throttling on and confirm its values under **Customer Configuration > Password Options**. - Add velocity limits on payment authorisations at your gateway, firewall, or CDN. - Log blocked submissions so you can see and tighten against the patterns hitting you. The highest-value move is pairing silent form checks with a velocity limit on the payment step, because together they cover both attacks without charging your real customers a CAPTCHA on the way through. Related reading: [Securing Magento 2](securing-magento-2.md) and [Magento Admin Audit Logs](magento-admin-audit-logs.md).