Ayzal Guard scores email, IP, and velocity before your checkout calls the payment gateway. Botnets flood checkout forms with stolen cards to validate them. Every failed attempt still charges you an authorization fee and counts against your fraud ratio. One API call in between form submit and payment gateway: → Disposable email detection → IP reputation (proxy, VPN, Tor, datacenter, recent abuse) → Canonical velocity Integration guides for Stripe, PayPal, Express, Flask, PHP, and Rails in the KB.

Maker here. The trigger was getting hit with a card-testing attack on my own SaaS last year, 300 failed charges in an hour, Stripe flagged the account, and their support told me "consider adding radar rules" which only fire after the charge.

The insight that became the product: the signals that identify a card-testing bot exist before the charge attempt, in the email and the browser session. That's what Guard scores.

Two things I deliberately didn't do:

1. No monthly minimum : 500 free checks forever, $49/mo when you outgrow it.

2. No hard block on API failure : Guard fails open. A checkout that errors out because the risk vendor is down is worse than a missed bot.

Happy to answer anything about the detection logic or the freemium math.

The insight that became the product: the signals that identify a card-testing bot exist before the charge attempt, in the email and the browser session. That's what Guard scores.

Two things I deliberately didn't do:

1. No monthly minimum : 500 free checks forever, $49/mo when you outgrow it.

2. No hard block on API failure : Guard fails open. A checkout that errors out because the risk vendor is down is worse than a missed bot.

Happy to answer anything about the detection logic or the freemium math.

Ayzal Guard

Stop card-testing bots before they hit your payment gateway

Stop card-testing bots before they hit your payment gateway