Ecommerce Website Development in Pune: Stopping Fake Orders, Bot Checkouts and Card-Testing Attacks on Your Shopify or WooCommerce Store
If your store suddenly shows dozens of failed or tiny orders, new customer accounts with random names, or a spike of payment attempts that no real shopper made, you are probably being hit by bots. The fix is layered: slow automated traffic at the edge, make the checkout and account forms hard to script, verify the visitors you cannot be sure about, and watch for the pattern so you notice early. No single plugin does all of this. This guide, from the viewpoint of ecommerce website development in Pune, explains what these attacks look like, why they hit small Indian stores too, and what to build or configure on Shopify and WooCommerce, with a checklist you can hand to your developer.
It is written for store owners, operations leads and anyone who has been told "it is just spam" and wants to know when it is not. We do not quote loss figures or attack statistics, because we have no reliable Indian data to cite and will not invent any. Everything below is about how the attacks work and how to reduce them, not about how common they are.
Three different problems that look alike
Store owners often lump these together, but they need different responses.
- Fake or junk orders. Orders placed with false names, addresses or numbers, or cash-on-delivery orders that no one intends to accept. Motives range from mischief and competitor harassment to testing a store's behaviour. The cost is wasted packing, shipping and attention, and inflated return rates.
- Card testing (carding). Criminals have lists of stolen card numbers and need to learn which ones work. They try small purchases on stores with weak checkout protection, over and over. Most attempts fail; the successful ones tell them which cards are live. For you the cost is a flood of failed payment attempts, possible disputes and potential trouble with your payment provider.
- Account and form spam. Bots creating customer accounts, subscribing to newsletters with fake addresses, or filling contact forms with links. This damages your email reputation and database quality and can break reporting.
The technical defences overlap, but the first needs business rules, the second needs checkout hardening, and the third needs form protection.
Why a small Pune store is a target
Attackers do not choose stores personally. They run scripts that look for known software, such as common checkout endpoints, and try them. A store on a popular platform with default settings is found because it is easy to find, not because it is important. Small stores are attractive precisely because they tend to have default configurations and nobody watching the logs overnight.
For card testing specifically, the WooCommerce developer team documented how the platform's Store API checkout could be hit directly without loading the visible checkout page, which meant that some CAPTCHA plugins protecting the classic form did not protect the newer route (WooCommerce Developer Blog: Card Testing Attacks and the Store API). The lesson applies beyond one platform: protection has to be on the endpoint that actually processes the order, not just on the page people see.
Recognise the pattern early
You can catch most attacks within hours if you know the signs.
| Signal | What it may mean | Where to look |
|---|---|---|
| Many failed payment attempts in a short window | Card testing | Payment provider dashboard, order notes |
| Orders for the cheapest product, or a fee-only product, repeated | Card testing | Order list sorted by amount |
| Same IP address or small group making many attempts | Scripted traffic | Server logs, security plugin, CDN analytics |
| Customer names that look random, or emails at disposable domains | Bot sign-ups | Customer list |
| Many COD orders with the same address, or sequential phone numbers | Fake order campaign | Order list, address field |
| Sudden spike in checkout starts with no matching ad or campaign | Bot traffic | Analytics, ad platform |
| Contact form messages full of links in a language you do not use | Form spam | Form entries |
Set up an alert so you hear about it without checking. For example, a notification when failed payments in an hour cross a threshold you choose, or when orders arrive at unusual hours. Your payment provider may offer alerts of its own; ask what is available on your account.
The layered defence
Think of the defences as layers, each stopping a different kind of attacker. None is perfect; together they make you a more expensive target than the next store.
Layer 1: Slow automated traffic before it reaches the store
A CDN or web application firewall (WAF) in front of the store can block known bad sources, limit request rates and challenge suspicious visitors before they touch your checkout. Cloudflare, for example, is commonly used in front of both WooCommerce and custom stores; Shopify-hosted stores have platform-level protections but fewer settings you can change yourself.
Rate limiting means allowing only so many attempts from one source in a given time. On WooCommerce, the Store API includes a rate limiter that is disabled by default and can be enabled through a documented filter, and from WooCommerce 9.6 stricter limits can be applied specifically to the place-order route; stores behind a proxy or CDN need to enable proxy handling so that real customers are not blocked together (WooCommerce Developer Blog). The same post notes that rate limiting slows attacks but does not fully stop them, which is exactly why it is one layer, not the plan.
Ask your developer: is rate limiting on, at the server or CDN and at the application? What are the limits, and are they set so that a family sharing one office network is not blocked?
Layer 2: Make the checkout hard to script
- Verification challenge on the order step. A challenge such as Cloudflare Turnstile, Google reCAPTCHA or a similar tool can be shown on checkout, registration and contact forms. Turnstile describes itself as a CAPTCHA alternative that can be embedded in any website without sending traffic through Cloudflare, and that works without showing visitors a puzzle (Cloudflare Turnstile documentation).
- Validate on the server, not just in the browser. A challenge only helps if your server checks the token it produces. In Turnstile's case, the token must be verified from your back end against the siteverify endpoint, using a secret key that must never appear in front-end code; tokens expire after 300 seconds and can be validated only once (Cloudflare Turnstile: server-side validation). If a plugin shows the widget but the order route does not check the result, bots can skip it.
- Cover every route that creates an order. The WooCommerce team found that some CAPTCHA plugins did not protect the block checkout or the Store API, so invalid checks were bypassed, and then patched the most common ones (WooCommerce Developer Blog). After installing any protection, test it: try to submit an order through each checkout type your store offers and confirm that a missing or invalid token is rejected.
- Honeypot and timing checks on forms. A hidden field that humans never fill and bots usually do, plus a minimum time between page load and submit, stop many simple scripts. These are the "hidden" fields that are legitimate anti-spam techniques for form protection; they are never used to hide content from visitors. Our guide on contact form spam and bot protection covers them.
Layer 3: Verify the customers you cannot be sure about
Fake orders are mostly a cash-on-delivery problem, because an order that costs the customer nothing is cheap to place. Practical measures that sit on the website side:
- Phone OTP at checkout for COD orders, or for first-time customers. Our article on checkout forms and guest checkout covers the usability trade-off; OTP adds friction, so apply it where the risk is, not to every order.
- Pin code and address validation. Reject impossible pin code and city combinations at entry.
- Order confirmation by WhatsApp or call for high-value or flagged COD orders before dispatch. Our WhatsApp commerce page and business API page describe how confirmations can be automated.
- Limits for new customers: a lower maximum COD value or quantity for first orders, shown clearly so it does not feel arbitrary.
- Prepaid incentive, where it suits your margins, so honest customers have a reason to pay upfront.
- A block list for phone numbers, emails and addresses of confirmed abusers, kept lawfully and used only to refuse orders from them.
Layer 4: Harden the payment step itself
Card testing succeeds when an attacker can attempt many payments cheaply. Reduce that:
- Limit attempts per session and per IP. After a few failed payments, require a pause or a challenge.
- Do not offer a minimum-value or free path that still triggers a card check. Attackers favour the cheapest item or a donation-like small amount. If you sell low-value products, think about a minimum order value or bundle rules.
- Use the payment provider's fraud tools. Many providers offer risk scoring, velocity checks and the ability to block certain patterns. Ask your provider what is switched on by default, and what you can enable. We do not compare provider fees in this article; our payment gateway service page describes how we integrate gateways.
- Never log or store card numbers yourself. Card data should be entered into the provider's hosted fields, so your server never touches it. Our article on PCI DSS for ecommerce stores explains what that means for a merchant.
- Be aware of authentication rules for card and recurring payments in India, which affect checkout design; see our guide on RBI two-factor authentication and checkout.
Layer 5: Protect accounts, forms and the email list
- Use the same challenge on registration, login, password reset and newsletter forms.
- Prefer double opt-in for email subscriptions: a fake address cannot confirm. This protects your sender reputation.
- Block disposable email domains on registration only if you have a real reason, because it can also block privacy-minded customers.
- Limit login attempts and consider two-step verification for admin users. Our guide to HTTP security headers and email deliverability cover related hardening.
Platform notes: Shopify and WooCommerce
Shopify
Shopify runs the checkout on its own infrastructure, which means some protection is built in and some settings are out of your hands. What you generally can do: review the apps you have installed, because each can add risk; use the fraud analysis shown on orders; enable verification on COD or order-confirmation apps where you use them; and add a challenge to forms on your theme, such as the contact and newsletter forms. For anything about checkout internals, check Shopify's current documentation and your plan's features, since these change.
WooCommerce
WooCommerce gives more control and more responsibility. A sensible baseline:
- Keep WooCommerce, WordPress and your protection plugins updated. Our note on HPOS and order storage explains one reason updates matter for stores.
- Enable Store API rate limiting and the stricter place-order limits, with proxy handling if you use a CDN.
- Make sure your CAPTCHA or Turnstile plugin protects the checkout type you use, including block checkout, and test it.
- Use a WAF or CDN in front of the site.
- Review orders and failed payments regularly, and look at the "Pending payment" and "Failed" statuses, which are where card-testing leftovers pile up.
- Remove unused payment methods and test gateways from production.
What to do when an attack is under way
- Do not panic-refund or ship. Hold suspicious orders until verified.
- Capture evidence: IP addresses, timestamps, order IDs, the payment provider's references. You will need them for your provider and, if necessary, for a report.
- Turn up the dials: stricter rate limits, challenge on every checkout, temporarily disabling guest checkout or COD for new customers.
- Tell your payment provider promptly if you suspect card testing. They can often block patterns on their side and advise on disputes.
- Block at the edge, such as a country, network or pattern, only if you are sure it does not match real customers. Over-blocking costs real sales.
- Review after: how did it get through, which layer was missing, and what alert would have caught it sooner?
- Consider your obligations if customer data may have been exposed. See our article on CERT-In breach reporting and take legal advice for your situation.
Balancing protection and conversions
Every defence adds friction, and friction costs sales. A store that challenges every visitor at every step will stop bots and some customers too. Principles for keeping the balance:
- Apply stricter checks to riskier situations rather than to everyone: COD, first order, high value, unusual pin codes, many attempts.
- Prefer invisible checks to puzzles where they work.
- Test the real customer path on a mid-range phone, including error messages. A failing challenge with no explanation looks like a broken store. Our guide to dark patterns and checkout design is a reminder to keep the process honest and clear.
- Measure before and after: checkout completion rate, failed payments, fake order share, support messages. If completion falls sharply after a change, investigate.
A checklist for your developer
Copy this into a message to your web developer or agency and ask for a yes, no or plan against each.
- Is a CDN or WAF in front of the store, with rate limiting on checkout and login?
- Is application-level rate limiting enabled on the place-order route?
- Is a verification challenge on checkout, registration, login, password reset, contact and newsletter forms?
- Does the server verify the challenge token on every order-creating route, including block checkout and APIs?
- Is COD protected by OTP or confirmation for first-time or high-risk orders?
- Are address and pin code validated at entry?
- Do we get an alert when failed payments or orders spike?
- Are payment provider fraud tools enabled and reviewed?
- Is card data handled only through the provider's hosted fields?
- Are newsletter sign-ups double opt-in?
- Are admin accounts protected with strong passwords, limits and two-step login?
- Who is responsible for reviewing this monthly, and what is the escalation plan during an attack?
Working with Govindani Infotech on store protection
Govindani Infotech is a Pune-based website design and development company at 2nd Floor, Landmark Plaza, 206 Satara Road, Parvati Paytha, Pune 411009. We build and maintain Shopify, WooCommerce and custom online stores, including checkout, payment integration and order confirmation flows.
If your store is seeing odd orders or failed payments, a useful first step is a short review: tell us your platform and what you are seeing, and we will say which layers look missing and what we would check first, before any scope or price is discussed. You can message us on WhatsApp at wa.me/919201958278 or write through our contact page. Our ecommerce development service and checkout system service pages describe how we build stores.
Frequently Asked Questions
What is a card testing attack on an online store?
Criminals use scripts to try many small purchases with stolen card numbers to find which ones work. Most attempts fail, so the store sees a burst of failed payments. Rate limiting, a verified challenge on checkout and the payment provider's fraud tools reduce the risk.
How do I stop fake COD orders on my Shopify or WooCommerce store?
Combine phone OTP or WhatsApp confirmation for risky orders, pin code and address validation, lower COD limits for first-time customers and a prepaid incentive. Apply the checks to higher-risk orders so genuine customers are not put off.
Does CAPTCHA fully protect WooCommerce checkout?
No. A challenge only helps if the server checks it on every route that creates an order. WooCommerce's own developers found some CAPTCHA plugins did not protect block checkout or the Store API. Test your protection on the checkout type you actually use.
Is Cloudflare Turnstile enough to stop bot orders?
It is a useful layer, but not the whole plan. Pair it with rate limiting, server-side token validation, payment provider fraud tools and monitoring. Remember that tokens must be verified from your back end, not trusted in the browser.
How can I tell if bots are hitting my store?
Look for bursts of failed payments, repeated tiny orders, many attempts from one IP address, random-looking customer names and checkout spikes with no matching campaign. Set up alerts so you see these within hours, not weeks.
Sources: WooCommerce Developer Blog: Card Testing Attacks and the Store API, Cloudflare Turnstile documentation, Cloudflare Turnstile: server-side validation