How to prevent Stripe card testing before checkout

Card testing is not only a payment problem. The attack often starts earlier, when an automated session creates accounts, tests coupons, rotates IPs, and prepares checkout attempts that look like normal traffic until the payment step.

If your backend creates a Stripe Checkout Session for every request, card-testing bots get a clean path to payment infrastructure. A better pattern is to score the request before Checkout Session creation and only continue when the user, device, IP, and email context look acceptable.

Why card testing reaches checkout

Card testers usually optimize for volume and low friction. They look for forms that accept disposable identities, tolerate datacenter or proxy traffic, and create payment sessions before the application understands the session risk.

Common warning signs include repeated checkout attempts, disposable email domains, unusual ASN patterns, country mismatch, low-value carts, and many sessions with similar metadata.

Pre-checkout scoring pattern

Call RequestGuard before creating the payment session:

const assessment = await requestGuard.assess({
  ip,
  email,
  domain: email.split("@")[1],
  userAgent,
  event: "checkout",
  sessionId,
  metadata: {
    cart_total: cartTotal,
    retry_count: retryCount,
    coupon,
  },
});

if (assessment.decision !== "allow") {
  return Response.json({ error: "Verification required" }, { status: 409 });
}

// Create the Stripe Checkout Session only after the request is allowed.

This keeps obvious automation away from the payment step and gives suspicious-but-possibly-real users a challenge or review path.

Signals that matter

• IP and connection risk for VPN, proxy, Tor, datacenter, and suspicious geography.
• Email and domain risk for disposable or synthetic identities.
• Device and session context for repeated attempts.
• Behavior metadata such as cart value, retry count, coupon, account age, and fulfillment type.

The goal is not to block every unusual signal. The goal is to make a consistent decision: allow, challenge, review, or block.

Operational checklist

• Score checkout attempts before creating payment sessions.
• Use stricter thresholds for digital goods, credits, trials, and gift cards.
• Store the RequestGuard request ID with the order or customer.
• Challenge uncertain sessions instead of hard-blocking every medium-risk user.
• Monitor false positives and allow trusted customers or partner traffic.

Stripe handles the payment. RequestGuard helps decide whether the session should reach payment at all.