Need Advice: Preventing Donation-Only Orders and Fraudulent Transactions on Shopify Stores

Shopify App Store
1

Hi Shopify Developers,

We are the developers of a Shopify donation app that allows merchants to add donation products to their storefronts.

Recently, one of our merchants experienced a large number of fraudulent donation orders. According to the merchant, attackers appeared to be testing stolen credit card numbers by placing small donation orders, which resulted in multiple chargebacks and additional fees for the merchant.

As app developers, we are trying to understand whether there is a better way to prevent this behavior on Shopify stores.

Our Current Setup

The donation is implemented as a normal Shopify product.

We already have multiple safeguards in place:

  1. Customers cannot visit the donation product page directly.

  2. The donation widget is only shown when the cart contains at least one non-donation (real) product.

  3. If the cart contains only the donation product, we automatically clear the cart.

  4. We removed donation purchase options from collection pages and other storefront locations.

  5. We use both Liquid and JavaScript-based protections.

The Challenge

A determined user can still:

  • Disable JavaScript.

  • Directly call Shopify cart endpoints.

  • Manipulate cart requests.

  • Add the donation product through methods outside the normal storefront flow.

Since the donation is ultimately a regular Shopify product, it appears that storefront-level protections can only go so far.

Questions

  1. Is there any Shopify setting that merchants can enable to reduce this type of fraud?

  2. Is there a recommended way to prevent donation-only orders on non-Plus stores?

  3. Can Shopify Flow be used effectively for this use case, or would it only help after the order is created?

  4. Are there any Shopify Functions, Checkout settings, Fraud settings, Shopify Protect features, or payment gateway settings that could help merchants stop these transactions?

  5. Has anyone dealt with card-testing attacks on donation products or low-value products before? If so, what solution worked for you?

From our understanding, app developers do not have a way to fully block direct cart manipulation on non-Plus stores before checkout. We would appreciate any guidance from developers who have faced similar situations.

Thank you in advance for any suggestions or best practices.

2

Card-testing on a donation product is a hard one because the attacker pattern matches the legitimate pattern almost exactly: a single-line, low-value, no-shipping order. Most of the layered defenses that work for normal stores (shipping address checks, AVS) lose half their signal on a donation product.

A few things that have worked for merchants in similar situations:

  1. Block disposable / typo emails at the checkout email step. Card-testing bots cycle through huge pools of throwaway addresses (10minutemail, mailinator, plus-aliased gmail variants with random strings). This kills a meaningful chunk of the low-effort traffic before it ever hits the payment gateway. I built MailShield ‑ Email Validator - Stop bad emails at checkout before they become bad orders. | Shopify App Store for this; the free tier covers normal volume.

  2. Require a real shopper session before the donation can be added to cart. Sounds like you already do this with the “must have a real product in cart” rule, but worth checking whether the bot is faking the cart-add through the Cart Ajax API directly. If it is, you can add a session-age check (cart must be at least N seconds old before donation add) or a server-side referrer check on the donation add-to-cart call.

  3. Cloudflare Turnstile or hCaptcha on the cart/checkout pages for stores on Basic plans (Plus has Bot Protection native). Most card-testing traffic comes through residential proxies that fail invisible challenges.

  4. Encourage the merchant to talk to their payment processor’s fraud team directly. Shopify Payments / Stripe have a real “card-testing alert” channel and can throttle authorization requests from a store while an attack is active. This is the fastest mitigation during a live attack.

  5. On the merchant-facing side: a per-IP / per-fingerprint rate limit on donation submissions, plus a minimum donation amount (most card-testers go straight to the $1 floor) shifts the economics enough that they move on.

One more thing: the chargebacks are the part that hurts the merchant most. Once you are above the chargeback ratio threshold, Shopify Payments / Stripe will start applying reserves. Worth flagging that risk explicitly to the merchant so they treat the fraud window as urgent rather than as something to grind through.

3

@Stackedboost Thank you for your response and the detailed explanation.

It seems that MailShield – Email Validator would only work on Shopify Plus stores. Or does it also work on Basic plans?

If it works on Basic plans as well, could you explain what it actually does to prevent card-testing attacks?

Yes, we can check for sessions, but fraudsters can still create legitimate sessions and behave like normal customers. They can simply add a product to the cart through the regular storefront flow instead of calling the AJAX Cart API directly. Ultimately, their goal is only to test stolen credit cards, and Shopify will still allow them to proceed once they reach checkout, whether they arrive there through the normal storefront flow or through API-based cart manipulation.

Regarding CAPTCHA, I do not think most merchants would be willing to place a CAPTCHA on the cart page, as it would introduce friction for genuine customers and add an extra step to the purchasing process.

That IP-blocking solution is really good. We could create a functionality in the app that allows merchants to report previous spam orders, and then we could block those IP addresses from placing future donation orders.

However, this approach would only work after the merchant reports the fraudulent order. To identify and block a fraudulent IP address, at least one spam order would already have been placed. In that sense, the merchant would still have to deal with the initial fraudulent transaction.

While this could help prevent future orders from the same IP address, the challenge still remains at the first point of attack.

As you mentioned, most card testers target the $1 price point. However, one merchant implemented a minimum donation amount of $5, and the fraudsters simply started placing $5 donation orders instead. Because of that, I do not think it is practical to identify fraudulent transactions solely based on a $1 donation threshold or similar donation amount patterns.

What are your thoughts about this ?

Thank you again for sharing your insights.

4

@Ajay_Rabari, all fair pushes. Let me address each honestly.

1. Plan compatibility: MailShield works on all plans including Basic. It runs as a Checkout Function plus post-checkout webhook, not a Plus-only Script Editor mechanism. No Plus gate.

2. Session check vs storefront flow: You’re right. If a card tester behaves like a normal customer (storefront → cart → checkout), session-based detection won’t catch them. MailShield doesn’t claim to. The angle is different: it looks at the email signal, not the session pattern.

Card testers using stolen cards almost never use their real personal email, because (a) they don’t want chargeback notifications hitting their real inbox, (b) they cycle through emails per test, (c) they typically don’t have the patience to register fresh Gmail accounts. Practical reality from what I’ve seen: a meaningful chunk of card-testing attempts use disposable services (mailinator, tempmail, 10minutemail, guerrillamail) or obvious typo’d Gmail patterns. Those get caught.

It won’t stop a determined fraudster using a residential proxy plus a real-looking Gmail. That’s a different tool stack (3DS, behavioral biometrics, Stripe Radar).

3. CAPTCHA on cart: Agreed, that’s a UX killer. Better to do all friction-reducing work silently in the background: email validation, IP scoring, velocity limits, and only escalate to challenge if multiple signals fire.

4. IP blocking reactive nature: You nailed the limitation. The fix that makes it less reactive is combining IP with email-pattern signals. When you catch one fraudulent transaction, you also catch the email pattern (often a specific disposable provider or a typo’d Gmail variant). The next 99 attempts from that pattern get blocked before they reach checkout, even from a different IP.

5. $1 vs $5 threshold: 100% agree. Fixed-amount thresholds fail because fraudsters adapt within minutes. No single signal works alone. The realistic posture is multi-signal: email + IP + velocity + amount + behavioral, with thresholds that adjust based on how many other signals fire.

Honest framing on MailShield: it addresses the disposable-email vector specifically. One layer in a fraud stack, not a silver bullet. For a merchant getting hammered with $1 donation card-testing right now, pairing it with Shopify’s built-in IP velocity limits plus a checkout amount minimum (just to slow them down, not stop them) usually gets the most lift per hour of work.

What types of attacks are you seeing where this wouldn’t help? Curious if there’s a specific gap worth building for.

5

Thank you so much again for this detailed explanation.

As donation app developers, our merchants typically see these kinds of attacks when fraudsters add only the donation product to the cart and then use stolen credit cards to test whether the card is working or not.

I will definitely recommend your app to merchants who have concerns around this issue. I will also explore what we can build on our end and which built-in Shopify features might help mitigate these attacks.

For your reference, I have attached a screenshot of one such order. The email address appears to be fake, and I am not sure whether the contact number entered is valid either.

image
image1219Ă—696 106 KB