How it works
What happens between the URL and the report
The scanner behaves like a customer who never finishes buying. It walks forward through a signup flow, photographs and measures every screen it reaches, stops the moment it sees a field for a card number, and writes down what it saw.
1. Discovery — finding the page where a subscription is offered
You give the scanner a URL. If that page already shows recurring-interval wording — a price followed
by /mo, per month, billed annually — it is treated as the plans page and used
directly. Otherwise the scanner looks through the visible links on that page for one whose text or path
matches pricing, plans, subscribe, membership or join, and
follows the first match.
If you already have the direct checkout URL, tick Manual URL mode on the scan form. Discovery is skipped entirely and the URL you gave is treated as the signup page.
2. The walk — forward only, and it stops at the card field
From the plans page, the scanner clicks the primary call-to-action inside a plan card and captures whatever screen that produces. It repeats this for up to four steps forward.
Two rules govern what it will click. It never clicks a control whose text reads as completing a
purchase — pay, place order, buy now, confirm and pay. And it stops
dead the moment a screen contains a card-number field: an input marked
autocomplete="cc-number", a field named or identified as a card, or an embedded payment
iframe from a processor such as Stripe, Braintree or Adyen.
3. Capture — a screenshot and a measurement of every screen
At each step the scanner records two things side by side.
- A full-page screenshot at 1440×900, device scale 1, saved to disk.
- A structured snapshot of the page: its title and URL, all visible text, every checkbox, radio and submit control with its label and its checked-on-load state, the computed font size and colour of each label, and the distance in pixels from each control to the nearest submit button.
It also collects links whose text or path matches terms, conditions, refund, cancel or subscription agreement, and fetches up to three of them so that renewal and cancellation language in linked documents can be told apart from language on the page itself. That distinction is the difference between several of the checks passing and failing.
4. The deterministic pass — signals computed in code, with no model involved
The first analysis pass is ordinary code: pattern matching over the captured text, arithmetic over the captured geometry. It produces named signals such as whether renewal wording appeared in the visible text of the consent step, whether it appeared only in linked terms, whether a checkbox referencing the renewal terms exists separately from a terms-of-service checkbox, whether any checkbox was already ticked when the page loaded, the computed type size of the smallest element matching the renewal pattern, and whether a price with a billing interval sits within 400 pixels of the submit control.
Each signal records where it came from. Every report carries the full list, values and provenance included, so a reader can check the scanner's work rather than take it on faith. Every signal, how it is computed, and how it is known to go wrong.
5. The visual pass — describing what is on the screen
Each screenshot, together with that step's structured capture, is sent to a vision model with a single question: describe what is visually present. It answers in four fixed fields — whether renewal terms are visible, how prominent they are, how close they are to the consent action, and what kind of consent control is visible — plus free-text observations. It is told explicitly not to judge legality.
The response is parsed strictly. If it cannot be parsed the request is retried once, and if that fails the step is marked analysis unavailable. If no API key is configured, the visual pass does not run at all. In either case the checks that depend on it are reported as could not be determined — never as passing.
6. Mapping — signals to state rules
The rule matrix holds 9 rules across 14 state frameworks currently in effect, stored as data rather than as code branches. Each rule names the statute it relates to, a link to that state's official code page, the condition under which it applies, and the condition under which the scanner records a finding.
Rules are evaluated with three-valued logic: true, false, or unknown. If a rule refers to a signal the scan never managed to observe, the rule lands in could not be determined with the missing signal names listed. It is never reported as a finding, and it is never quietly reported as fine. See every rule, its statute and its severity.
Paste mode — for sites that block automated browsers
Most real checkouts refuse an automated browser. Paste mode is the fallback: open the checkout yourself, copy the rendered HTML, and paste it in. The markup is rendered locally with every network request blocked, so nothing at all is requested from the site being examined. You can add the text of the linked terms and up to four screenshots you took yourself.
What the scanner will not do
- It does not create an account, log in, or hold credentials of any kind.
- It does not enter payment details or submit a purchase.
- It respects
robots.txt, identifies itself in its user agent, and runs one scan at a time so it never opens a second browser against a site. - It does not attempt to work around bot protection, rate limits or login walls. Where it is refused, it says so in the report and points you at paste mode.
Read the limitations before you read a report — they matter more than anything on this page.