Section 1: Why bots target try-on widgets
Virtual try-on widgets are an attractive bot target because they provide free AI image generation. A try-on endpoint accepts a photo and a product image and returns an AI-composited result — from a bot's perspective, this is a free, publicly accessible AI image generation API. Automated scripts can hit the endpoint thousands of times per hour to generate product images, headshots, or synthetic training data at zero cost to the attacker and full monthly-cap cost to you as the merchant.
The economic incentive is significant: a quality AI image generation API typically costs $0.05–0.20 per image. A try-on widget endpoint without bot protection is effectively offering this service for free to anyone who reverse-engineers the request format. At scale, a single bot campaign can exhaust a merchant's entire monthly try-on quota in hours, leaving real shoppers with degraded service for the rest of the billing period.
Section 2: Photta's five-layer defense stack
Photta deploys five independent defenses, each catching a different attack vector. Layer 1 — hCaptcha: every try-on request must include a valid hCaptcha token generated in the browser. Headless bots and automated HTTP clients cannot solve hCaptcha without human interaction, blocking simple scripted attacks. Layer 2 — BotD fingerprinting: the SDK runs BotScore by FingerprintJS to detect headless browsers, automation frameworks (Puppeteer, Playwright), and suspicious browser environments before the shopper even submits a photo.
Layer 3 — Domain allowlisting: your pk_live_ key only accepts requests from domains you register in Settings → Allowed Domains. Requests from any other origin return HTTP 403 immediately, before any AI processing occurs. Layer 4 — IP rate limiting: more than 10 try-on requests per minute from a single IP address triggers automatic throttling; more than 30 per minute triggers a temporary block. Layer 5 — Monthly cap: your plan's monthly try-on limit (500/2,000/10,000 depending on tier) is hard-capped server-side. Exhausting the cap stops all try-ons for the rest of the billing cycle, preventing runaway cost scenarios.
Section 3: Monitor bot attempts in your dashboard
Log in to business.photta.app and navigate to Security. The Security panel shows three charts updated in real time: Blocked Attempts (total per hour), Block Reason Breakdown (hCaptcha failures vs. BotD detections vs. domain mismatches vs. rate limit triggers), and Top Blocked IPs (the IP addresses generating the most blocked requests in the past 24 hours). A healthy store typically shows near-zero blocked attempts during normal operating hours.
The Security panel also includes an Anomaly Alerts section. Photta's analytics layer watches for sudden spikes in try-on volume or blocked attempts that deviate more than three standard deviations from your 7-day baseline. When an anomaly is detected, you receive an email notification within 15 minutes and the alert appears in the dashboard. You can configure notification thresholds under Settings → Notifications → Security Alerts.
Section 4: Respond to suspicious activity
When you see unusual patterns in the Security panel — a spike in blocked requests, a cluster of attempts from one IP range, or a sudden drop in your monthly quota — take these actions in order. First, check the Top Blocked IPs list. If one or a small number of IPs account for most blocked attempts, click 'Block IP' next to each one to permanently ban them at the Photta layer. Blocks apply immediately and persist until you manually remove them.
Second, if the attack is using multiple IPs (a distributed botnet), contact Photta support via the dashboard chat with your merchant ID and the attack timestamp range. Photta's security team can apply a CIDR-level block on the attacking subnet within a few hours. Third, if your monthly quota has been significantly depleted by bot activity, open a support ticket — Photta offers one-time quota restoration for documented bot attacks. Attach a screenshot of your Security panel's anomaly alert as evidence.
Section 5: When to add custom CAPTCHA on top
Photta's built-in hCaptcha runs invisibly — most legitimate shoppers never see a CAPTCHA challenge. In very rare cases (high-value stores, publicly indexed widget endpoints), the built-in defenses may not be sufficient if a sophisticated attacker is using human CAPTCHA-solving farms. In this scenario, add a second CAPTCHA layer at your own product page level before calling photta.open(). Verify your custom CAPTCHA on your server, then pass a signed verification token to the Photta SDK as photta.open({ verificationToken: 'your_token' }) to ensure only verified sessions can initiate a try-on.
Custom CAPTCHA is a last resort for stores that have experienced repeated sophisticated attacks. For the vast majority of merchants, Photta's five-layer stack provides sufficient protection with no shopper-visible friction. If you are evaluating whether to add a custom layer, check your Security panel's Block Reason Breakdown first — if hCaptcha failures account for fewer than 1% of your total blocked attempts, the stack is working and an additional layer adds friction without meaningful security gain.