DEV Community: Rahul S

Card-Testing Bots Will Find Your Checkout the Day You Launch. Here's the Pre-Charge Filter That Stops Them.

Rahul S — Mon, 06 Jul 2026 23:55:53 +0000

The first time you ship a public create-payment-intent route, you assume the risk is someone paying with a stolen card. That happens, but it's not what wakes you up at 3am in week one. What wakes you up is a graph: a flat decline rate that suddenly spikes to 80%, thousands of $1.00 authorizations from cards you've never seen, all in a few minutes.

That's card testing. Fraudsters buy a dump of stolen card numbers and need to know which ones are still live before they try to actually cash them out somewhere else. Your brand-new checkout is a free oracle: fire a tiny authorization, read the response, sort the "approved" cards from the dead ones. Your store is just the validation step.

Why it slips past everything you already have

Here's the uncomfortable part. Every defense you reach for first doesn't fire, because each individual request is completely valid.

Amount tampering? No — they send a legitimate amount. Idempotency bug? No — every request is genuinely distinct. Webhook signature check? Never gets there; they don't care about fulfillment, they only care about the auth response. Stripe Radar? Radar is very good, but it's scoring the charge, and by the time a request reaches Radar you're already being billed per authorization attempt. Enough of those and your decline rate alone can dent your account standing with the card networks, independent of any single fraudulent charge succeeding.

The shape of the attack is the inverse of the bugs everyone writes about. The classic checklist — verify the webhook, don't trust client-side amounts, scope your keys — is all about a malformed request the server trusts too much. Card testing is a perfectly well-formed request that's still hostile. Correctness fixes don't touch it, because there's nothing incorrect to fix.

The cheap filter goes before the charge

The insight that makes this tractable: you don't have to detect a stolen card. You have to detect the pattern of a bot spraying your endpoint, and that pattern is visible before you ever call paymentIntents.create.

Card-testing waves look almost nothing like your real buyers at the network level:

They arrive from datacenter / hosting ranges (or a rotating residential-proxy pool), not consumer ISPs.
The associated emails are fresh throwaways with no prior session, no order history, no sending reputation.
They hit the create-intent route directly, often skipping the pages a real shopper loads first.

None of those are things a stolen card number tells you. They're things the connection and identity tell you. So the move is to score the source IP and email before you spend a Stripe call on them, and only let human-looking traffic reach the payment processor at all.

A pre-charge gate in Express

Here's a middleware that runs in front of the payment route. I'm using IPASIS here because it returns IP reputation and email risk in one call with sub-20ms latency, which matters when it sits on the hot path of checkout — but the shape is the same whatever you score with.

// middleware/preChargeGate.js
const RISK_API = "https://ipasis.com/api/v1/scan";

async function preChargeGate(req, res, next) {
  const { email } = req.body;
  const ip = (req.headers["x-forwarded-for"] || req.ip || "").split(",")[0].trim();

  try {
    const resp = await fetch(
      `${RISK_API}?ip=${encodeURIComponent(ip)}&email=${encodeURIComponent(email)}`,
      {
        headers: { Authorization: `Bearer ${process.env.RISK_KEY}` },
        // keep the timeout tight — this is on the checkout hot path
        signal: AbortSignal.timeout(1500),
      }
    );
    const data = await resp.json();

    // Trust score is 0-100; low means "looks automated / high risk"
    const looksAutomated =
      data.trust_score < 30 ||
      (data.ip?.datacenter && data.email?.disposable);

    if (looksAutomated) {
      // DON'T hard-error with a clear "declined" — that's the exact
      // signal the tester wants. Slow them down instead.
      return res.status(202).json({ status: "processing" });
    }

    req.risk = data;
    next();
  } catch (err) {
    // Fail OPEN. A risk API being slow must never block real revenue.
    console.warn("pre-charge risk check skipped:", err.message);
    next();
  }
}

module.exports = preChargeGate;

Then the payment route only ever sees traffic that already cleared the gate:

const express = require("express");
const preChargeGate = require("./middleware/preChargeGate");
const stripe = require("stripe")(process.env.STRIPE_SECRET_KEY);

const app = express();
app.use(express.json());

app.post("/api/create-intent", preChargeGate, async (req, res) => {
  const intent = await stripe.paymentIntents.create({
    amount: req.body.amount,   // still validate this server-side!
    currency: "usd",
    metadata: { risk_score: req.risk?.trust_score ?? "skipped" },
  });
  res.json({ clientSecret: intent.client_secret });
});

Three things that are easy to get wrong

Don't return a clean decline. The whole point of card testing is reading your response. If a flagged request gets an instant, unambiguous "card declined," you've just given the bot a faster oracle. Return a soft 202/processing, add latency, or route to a challenge — anything that makes the endpoint expensive and low-signal to probe.

Fail open, always. This gate sits in front of money. If the risk API is slow or down, the correct behavior is to let the request through to Stripe, where Radar still has your back. Blocking real checkouts because a side service hiccuped is a worse outcome than a bit of card testing.

Score, don't hard-block. A single "datacenter IP" is not proof of fraud — plenty of legitimate users are on corporate VPNs. It's the combination (datacenter range + disposable email + no prior session + burst timing) that makes a confident call. Weight the signals; don't bet everything on one.

Test it before you wire anything

Before writing a line of integration code, it's worth eyeballing what these signals actually look like. You can paste any IP or email into ipasis.com/scan and see how it classifies — residential vs datacenter vs known proxy, disposable-email flag, reputation. The API docs show the full response shape, and the free tier (3,000 requests/month, no card required) is plenty to prototype a checkout gate.

The takeaway isn't "buy a fraud API." It's that the card-testing wave is the one attack on your checkout that your correctness fixes structurally cannot see, and the cheapest place to catch it is one layer up from the charge — on the connection and the identity, before you've spent a single processor call on a request that was never going to be a customer.

Catch Disposable Emails Before They Wreck Your SaaS Metrics

Rahul S — Fri, 10 Apr 2026 13:40:27 +0000

Every SaaS founder knows the pain: your free trial signups look great on paper, but half of them are throwaway accounts using disposable emails. They inflate your metrics, abuse free tiers, and never convert.

Let's fix that — with code.

The Disposable Email Problem

Services like Guerrilla Mail, Temp Mail, and Mailinator let anyone generate a throwaway email in seconds. For SaaS products with free tiers, this means:

Metric pollution — your signup numbers lie
Free tier abuse — the same person creates 10 accounts
Wasted onboarding emails — bouncing into the void
Skewed cohort analysis — your retention data is garbage

Traditional regex-based blocklists can't keep up. New disposable domains pop up daily. You need a real-time intelligence layer.

Beyond Blocklists: Real-Time Email Intelligence

The smarter approach combines multiple signals:

Domain age — disposable domains are often days or weeks old
MX record analysis — throwaway services have recognizable mail server patterns
Known disposable provider databases — continuously updated
IP reputation correlation — is the signup IP also suspicious?

Checking all four gives you a confidence score, not just a binary yes/no.

Implementation: Node.js Example

Here's a practical signup validation middleware using IPASIS, which bundles IP + email intelligence in a single API call:

// middleware/validateSignup.js
const IPASIS_API = 'https://ipasis.com/api/v1';

async function validateSignup(req, res, next) {
  const { email } = req.body;
  const ip = req.headers['x-forwarded-for'] || req.ip;

  try {
    // Single API call checks both IP reputation + email validity
    const response = await fetch(
      `${IPASIS_API}/scan?ip=${ip}&email=${encodeURIComponent(email)}`,
      { headers: { 'Authorization': `Bearer ${process.env.IPASIS_KEY}` } }
    );
    const data = await response.json();

    // Check email signals
    if (data.email?.disposable) {
      return res.status(400).json({
        error: 'Please use a permanent email address'
      });
    }

    // Check IP signals — VPN + Tor + known bot
    if (data.ip?.threat_score > 75) {
      // Log for review but don't hard-block
      req.flagged = true;
      console.warn(`High-risk signup: ${email} from ${ip}`, {
        vpn: data.ip.vpn,
        tor: data.ip.tor,
        bot: data.ip.bot,
        threat_score: data.ip.threat_score
      });
    }

    req.ipasis = data;
    next();
  } catch (err) {
    // Fail open — don't block signups if the API is unreachable
    console.error('IPASIS check failed:', err.message);
    next();
  }
}

module.exports = validateSignup;

Using it in Express:

const express = require('express');
const validateSignup = require('./middleware/validateSignup');

const app = express();
app.use(express.json());

app.post('/api/signup', validateSignup, async (req, res) => {
  if (req.flagged) {
    // Route to manual review queue instead of auto-activating
    await addToReviewQueue(req.body, req.ipasis);
    return res.json({ message: 'Account pending review' });
  }

  // Clean signup — proceed normally
  await createUser(req.body);
  res.json({ message: 'Welcome aboard!' });
});

Python Flask Version

import requests
from functools import wraps
from flask import request, jsonify

IPASIS_API = "https://ipasis.com/api/v1"

def validate_signup(f):
    @wraps(f)
    def decorated(*args, **kwargs):
        email = request.json.get("email", "")
        ip = request.headers.get("X-Forwarded-For", request.remote_addr)

        try:
            resp = requests.get(
                f"{IPASIS_API}/scan",
                params={"ip": ip, "email": email},
                headers={"Authorization": f"Bearer {IPASIS_KEY}"},
                timeout=3
            )
            data = resp.json()

            if data.get("email", {}).get("disposable"):
                return jsonify({"error": "Please use a permanent email"}), 400

        except requests.RequestException:
            pass  # Fail open

        return f(*args, **kwargs)
    return decorated

What Signals Matter Most?

After analyzing thousands of signups, here's what actually predicts abuse:

Signal	Weight	Why
Disposable email	🔴 High	Direct indicator of throwaway intent
Email domain age < 7 days	🟡 Medium	Freshly registered domains are risky
VPN + disposable combo	🔴 Critical	Privacy layering = almost always abuse
Tor exit node	🟡 Medium	Legitimate privacy users exist, but flag for review
IP threat score > 75	🟡 Medium	Correlates with bot farms and proxy networks

The magic is in combining signals. A VPN user with a Gmail address? Probably fine. A VPN user with a disposable email and a threat score of 90? That's abuse.

Try It Yourself

You can test any email or IP right now at ipasis.com/scan — no account needed for the web scanner. For API access, the free tier gives you 1,000 requests/day, which is plenty for most early-stage SaaS products.

Key Takeaways

Don't just block — score. Binary blocklists create false positives. Score-based systems let you route suspicious signups to review queues instead of hard-blocking.
Combine IP + email signals. Either alone gives you half the picture. Together, they catch coordinated abuse.
Fail open. If your validation API is down, let signups through. A few bad actors are better than zero new users.
Log everything. Even if you don't block, log the signals. You'll want this data when you analyze churn.

Stop letting disposable emails pollute your metrics. A single API call at signup can save you hours of cleanup later.

Building something and fighting signup abuse? I'd love to hear what's working for you — drop a comment below.

Detecting Bots in 2026: IP Intelligence + Email Validation in One API Call

Rahul S — Thu, 02 Apr 2026 05:40:24 +0000

The Bot Problem Nobody Talks About

If you're running a web app in 2026, roughly 40% of your traffic isn't human. Scrapers, credential stuffers, fake signups — they eat your bandwidth, pollute your analytics, and sometimes steal your data.

Most developers slap on a CAPTCHA and call it a day. But CAPTCHAs are a UX nightmare, and sophisticated bots solve them anyway. There's a better approach: checking the reputation of incoming requests before they even reach your app.

The Two Signals That Matter Most

After building fraud detection systems for years, I've found that two data points catch 90%+ of malicious traffic:

1. IP Intelligence

Every request comes from an IP address, and that IP tells a story:

Is it a known proxy/VPN/Tor exit node? Legitimate users sometimes use VPNs, but bots almost always do.
Is it from a datacenter or residential ISP? Most real users browse from home or mobile — datacenter IPs are a red flag.
Has this IP been reported for abuse? Threat intelligence feeds track IPs involved in spam, attacks, and fraud.
What's the geolocation? A "US user" connecting from a hosting provider in Eastern Europe is suspicious.

import requests

# Quick IP reputation check
response = requests.get(
    "https://ipasis.com/api/scan/ip/185.220.101.1",
    headers={"Authorization": "Bearer YOUR_API_KEY"}
)
data = response.json()

print(f"Risk Score: {data['risk_score']}/100")
print(f"Is VPN: {data['is_vpn']}")
print(f"Is Datacenter: {data['is_datacenter']}")
print(f"Abuse Reports: {data['abuse_count']}")

2. Email Validation

For signups and form submissions, the email address is your second line of defense:

Does the domain actually exist? Disposable email services (guerrillamail, tempmail) are bot favorites.
Is the mailbox real? SMTP verification catches typos and fake addresses.
Is it a known disposable/temporary email? There are 10,000+ disposable domains.
Is the domain newly registered? Fresh domains often exist solely for fraud.

# Email validation
response = requests.get(
    "https://ipasis.com/api/scan/email/suspicious@tempmail.xyz",
    headers={"Authorization": "Bearer YOUR_API_KEY"}
)
email_data = response.json()

print(f"Valid: {email_data['is_valid']}")
print(f"Disposable: {email_data['is_disposable']}")
print(f"Domain Age: {email_data['domain_age_days']} days")

Combining Both: A Practical Middleware

Here's a real-world pattern I use — a middleware that scores every signup request:

from flask import Flask, request, jsonify
import requests

app = Flask(__name__)
IPASIS_KEY = "your-api-key"

def check_reputation(ip, email):
    """Score a signup attempt using IP + email intelligence."""
    risk = 0
    flags = []

    # Check IP
    ip_resp = requests.get(
        f"https://ipasis.com/api/scan/ip/{ip}",
        headers={"Authorization": f"Bearer {IPASIS_KEY}"}
    ).json()

    if ip_resp.get("is_vpn"):
        risk += 20
        flags.append("vpn_detected")
    if ip_resp.get("is_datacenter"):
        risk += 30
        flags.append("datacenter_ip")
    if ip_resp.get("abuse_count", 0) > 5:
        risk += 25
        flags.append("known_abuser")

    # Check email
    email_resp = requests.get(
        f"https://ipasis.com/api/scan/email/{email}",
        headers={"Authorization": f"Bearer {IPASIS_KEY}"}
    ).json()

    if email_resp.get("is_disposable"):
        risk += 40
        flags.append("disposable_email")
    if not email_resp.get("is_valid"):
        risk += 50
        flags.append("invalid_email")

    return {"risk_score": min(risk, 100), "flags": flags}

@app.route("/signup", methods=["POST"])
def signup():
    ip = request.remote_addr
    email = request.json.get("email", "")

    result = check_reputation(ip, email)

    if result["risk_score"] > 60:
        return jsonify({"error": "Signup blocked", "reason": "suspicious_activity"}), 403
    elif result["risk_score"] > 30:
        # Flag for manual review but allow
        return jsonify({"status": "pending_review"}), 200
    else:
        # Clean signup, proceed normally
        return jsonify({"status": "approved"}), 200

Why This Beats CAPTCHAs

Approach	User Friction	Bot Detection Rate	Latency
reCAPTCHA v2	High (click images)	~85%	2-5s
reCAPTCHA v3	Low (invisible)	~70%	1-3s
IP + Email Intelligence	Zero	~92%	<200ms

The key advantage: zero user friction. Your legitimate users never see a challenge. The API call happens server-side in milliseconds, and bad actors get blocked silently.

Getting Started

If you want to try this approach, IPASIS offers a free tier with 1,000 requests/day — enough to protect a small-to-medium app. You can also test any IP or email interactively on the free scanner.

The API docs cover authentication, rate limits, and response formats. The API is REST-based with JSON responses — no SDK required.

Key Takeaways

Don't rely solely on CAPTCHAs — they hurt UX and sophisticated bots bypass them.
IP intelligence catches infrastructure-level fraud (VPNs, datacenter IPs, known abusers).
Email validation catches identity-level fraud (disposable emails, fake domains).
Combine both for a risk score that lets you block, flag, or approve in real-time.
Server-side checks = zero user friction — your real users never know it's happening.

Bot detection doesn't have to mean annoying your users. Sometimes the smartest security is invisible.

What bot detection approach are you using? Drop a comment — I'm curious what's working for others in 2026.