What Forter sees and what it decides
Forter is called by the store's checkout backend, not by the CDN (the network of edge servers that usually sits in front of a site). When a shopper clicks "Place Order", the store sends Forter the cart, payment details, a device fingerprint, and a fortertoken. Within a few hundred milliseconds Forter answers: approve, decline, or review. The piece that matters for automation is the device fingerprint — a snapshot of the browser collected by a Forter JavaScript SDK (a script the checkout page loads) that includes canvas/WebGL fingerprints (tiny rendering quirks unique to your graphics hardware), your accept-language header, timezone, and a hardware-tied identity blob.
The key point: Forter scores identity, not just the session. A clean fingerprint is not enough — the identity also has to look real, meaning the IP location matches the billing address, the account has history, and the payment card has a good reputation. That is why scrapers that solve every CAPTCHA still get declined at checkout: the fingerprint says "human" but the identity says "made up".
When scrapers actually encounter Forter
Scrapers doing pure data extraction — price monitoring, listings, reviews — never see Forter; those pages don't call it. You only run into it when you automate an action that touches money or identity:
- Automated checkout flowsSneaker bots, ticketing bots, retail arbitrage
- Account creation at scaleBulk sign-ups from the same fingerprint or IP range
- Coupon & promo-code redemptionOne-per-customer offers claimed in volume
- Returns & refunds automationProgrammatic refund or chargeback flows
The failure is silent
Checkout just says "Payment declined, please try a different card" — identical to an ordinary card rejection. The real reason is that Forter declined the transaction on identity grounds, not because anything was wrong with the card.
What works against Forter
Hardening your browser fingerprint alone won't help, because Forter scores identity, not fingerprints. The countermeasures are operational, not technical: match the billing address to the IP location, use payment cards with a clean track record, let accounts age and build up real activity before checking out, and avoid the velocity patterns (for example, 10 accounts in 10 minutes from the same IP block) that Forter watches for. Importantly, Forter shares decline signals across every store that uses it — an identity declined at one Forter customer is flagged at all the others.