Sushinet

Tag Suspicious Signups, Then Stop Them at Checkout

Flag throwaway and machine-generated email signups with a tagging rule, then let a checkout rule refuse the ones you have flagged — detection and blocking as two jobs, joined by a tag.

By Sushinet · Updated 14 September 2026 · 3 min read

recipe

Card testing does not arrive once. It arrives as a run — the same buyer, or the same shape of buyer, trying again within minutes, because the whole point is to find a card that works. By the time anyone reviews the first attempt, the fourth has already been made.

That rhythm is what makes this worth automating, and it is also what decides the shape of the answer. You are not trying to judge a single order perfectly. You are trying to make the second attempt cheaper to refuse than it is to make.

Two jobs, joined by a tag

Detection and refusal want opposite things.

Detection wants time and context. Recognising a throwaway domain means holding a list; recognising a generated address means reading its shape. Neither is hard, but both are work you want done carefully rather than quickly.

Refusal wants the opposite. It happens inside Shopify's checkout, on Shopify's servers, under a budget measured in milliseconds, and it cannot look anything up. It can only answer questions about what is already in front of it.

So the two live in different rules, and a customer tag joins them. Rules2Tag decides who is suspicious and writes the tag. Ruleproof reads the tag and refuses the checkout. Neither app needs to know how the other works — only that they agree on the word.

What each rule actually does

The detection rules watch customers as they arrive and tag the ones that match:

  • Customers using disposable email tags anyone signing up from a throwaway domain as fraud-suspected. This is the cheapest signal there is. Someone using a ten-minute mailbox for something they want posted to them is telling you something.
  • Customers with automated email patterns tags generated-looking addresses as bot-suspected — plus-aliases like name+1@, or a real-looking name with digits stapled on. Deliberately a different tag, because this signal is weaker and you may want to review rather than refuse.

The checkout rule does one thing: if the customer carries one of those tags, checkout stops with a message you wrote. One condition, which means it runs on the free plan, and which also means it is easy to reason about when something unexpected happens.

Watch it before you switch it on

Put the checkout rule in monitor mode first. It evaluates every checkout and records what it would have done, without affecting anyone. After a week you are not guessing about false positives — you are reading a list of the specific shoppers it would have turned away, and deciding whether that looks right.

This matters more here than for most rules, because the tags come from somewhere else. You are switching on a block whose trigger is another rule's judgement, and monitor mode is how you check that judgement against your own traffic before a real customer meets it.

The one thing to get exactly right

Both apps ship the same tag names — fraud-suspected and bot-suspected — so they line up without anyone having to think about it. (There is a third, possible-fraud, reserved for things you want a human to look at; the checkout rule deliberately does not block on it by default, because "review this" and "refuse this" are different instructions.)

If you change them, change them everywhere. A tagging rule writing suspected-fraud and a checkout rule watching for fraud-suspected produces no error, no warning and no sign of trouble. It produces a fraud rule that quietly never fires, which is worse than not having one, because you will believe you are covered.

Questions

Why split this into two apps instead of one rule?

Because detecting and refusing are genuinely different jobs, and Shopify keeps them in different places. Detection needs history and time — it looks at an address, compares it to a pattern, and can take as long as it likes. Refusing happens inside checkout, in milliseconds, with a strict budget and no ability to look anything up. A single rule that tried to do both would be limited by the harder half. Splitting them means the detection can be as thorough as you like, and the block stays a simple, fast question: is this customer tagged? The tag is the join between the two, which is also why the exact tag text matters more than it looks.

Isn't this just fraud prevention?

No, and the difference is worth being honest about. This is a blocklist you control, built from signals visible in the data your shop already holds — the shape of an email address, a disposable domain. It does not score a buyer, check a card, or see an IP, and it cannot tell you whether someone intended fraud. What it does is stop a repeat attempt from a buyer something has already flagged, which is the specific case where automation beats a human: the second, third and fourth attempt arrive faster than anyone can review the first.

Will this block real customers?

Some, eventually, and planning for that is the difference between a rule you keep and a rule you switch off in a week. A disposable-domain match is fairly safe — few genuine buyers use a throwaway address for something they want delivered. A plus-alias or digit-suffix pattern is less safe, because plenty of people legitimately use name+shop@gmail.com to organise their inbox. That is why the second rule tags a bot signal rather than a fraud one: the two deserve different responses. Watch what each is catching on your own traffic before either turns anyone away.

What happens to the tag when someone stops matching?

It comes off on its own. The tagging rule removes a tag it applied once the record stops matching, so a customer flagged by a pattern you later narrow does not stay flagged forever. Both rules in this recipe have that switched on deliberately, and it is worth knowing it is not the default — removal is normally opt-in, because a rule and a merchant can collide on the same hand-applied tag. A tag wired to a checkout block is the case where that trade goes the other way: a stale flag on a real customer is a refused sale every time they come back, and nobody ever goes looking for it, because from the outside the shop looks like it is working.

Can I use my own tag names instead?

You can, and the only thing that matters is that both rules use the same text. The two apps ship the same default names so they line up without anyone thinking about it. If you change them, change them in both places — a near-miss like suspected-fraud where the other rule expects fraud-suspected is the one failure that looks like nothing at all: no error, no warning, just a checkout rule that never fires.

More recipes

This recipe uses two apps

Each does one half of the job, and neither can do the other's — which is why this is a recipe and not a feature. Both have a free plan, so the whole thing can be built and watched before it costs anything.

Pricing · ← All recipes