Checkout Detector
Pricing
from $30.00 / 1,000 results
Checkout Detector
Detects if a website has an active checkout/payment capability. Returns checkout type, payment providers, detection method, and confidence. HTTP-first, browser only as fallback.
Pricing
from $30.00 / 1,000 results
Rating
5.0
(1)
Developer
Etan gentil
Maintained by CommunityActor stats
2
Bookmarked
2
Total users
1
Monthly active users
8 days ago
Last modified
Categories
Share
Detects whether a website has an active checkout / payment capability, identifies the payment providers and e‑commerce platform, and tells you whether the checkout is reachable without a signup wall.
Built for bulk enrichment (Clay / CRM): give it a bare domain, get back a clean true/false plus the supporting detail.
⚡ How it works — HTTP‑first, browser only as fallback
Most detectors launch a full browser on every site. A browser costs 10–40× more compute and runs 10–50× slower than a plain HTTP request, and the most reliable checkout signals (response headers, Content‑Security‑Policy, loaded SDKs, JSON‑LD, platform APIs) don't need one. So this Actor inverts the usual order:
TIER 1 — HTTP only (no browser) resolves the large majority of sites• one homepage GET → HTML + headers + CSP + Set‑Cookie• parallel platform API probes:/products.json · /wp-json/wc/store/v1/cart · /rest/V1/store/storeConfigs · robots.txt• match curated payment/platform fingerprints (Wappalyzer methodology)GATE• decisive signal → return immediately (no browser)• commercial but unconfirmed → render once (Tier 2)• no commercial signal → return false (no browser)TIER 2 — ONE passive Playwright render (only when needed)• reads JS globals (window.Shopify / Stripe / Paddle …), dataLayer,localStorage cart keys, and the fully‑hydrated DOM• strictly passive: no clicking, no add‑to‑cart, no cart mutation
The browser launches only on the minority of sites Tier 1 can't resolve — that's where the cost saving comes from, with recall held steady by the passive render.
Detection model
Signals are graded, not summed into a fragile weighted score:
- Decisive (any one ⇒
has_checkout: true): Shopify/products.json, WooCommerce Store API, MagentostoreConfigs,shopify-checkout-api-token, JSON‑LDProduct+price, cart<form action>, third‑party hosted checkout (Gumroad, Lemon Squeezy, Paddle, FastSpring, Chargebee, Recurly, Snipcart, Kit), a payment SDK inscript-src, a platform/PSP JS global, a store response‑header or cookie. - Corroborating (combine for the SaaS / ambiguous middle): pricing page + signup CTA, dataLayer e‑commerce events, e‑commerce cookies, product URLs, shipping/billing fields, visible prices, PSP allowed in CSP, card‑brand mentions.
- Negative: parked domain, sales‑gated with no self‑serve, contact‑sales‑only without prices.
📥 Input
| Field | Type | Default | Description |
|---|---|---|---|
url | String | required | URL or bare domain (e.g. example.com or https://example.com) |
timeoutSeconds | Integer | 30 | Max time for the browser fallback. Tier 1 (HTTP) is much faster and ignores this. |
{ "url": "https://zuvees.ae", "timeoutSeconds": 30 }
📤 Output
One JSON object per run, pushed to the dataset.
| Field | Type | Description |
|---|---|---|
domain | String | Root domain analyzed |
has_checkout | Boolean | true if an active checkout/payment capability was detected |
checkout_type | String | ecommerce · saas · third_party · donation · unknown |
checkout_accessible | Boolean | true if reachable without a signup/login wall (inferred SaaS = false) |
detection_method | String | The single strongest signal used (e.g. shopify_products_json, psp_sdk, cart_form) |
payment_providers | Array | Detected gateways / methods (e.g. ["Stripe", "Apple Pay", "Visa"]) |
ecommerce_platform | String | Detected platform (e.g. Shopify, WooCommerce), or null |
confidence | Number | 0.0–1.0 |
scraping_status | Object | { tier, browser_used, blocked, error, time_elapsed_ms } |
Example (Shopify store):
{"domain": "zuvees.ae","has_checkout": true,"checkout_type": "ecommerce","checkout_accessible": true,"detection_method": "shopify_products_json","payment_providers": ["Apple Pay", "Google Pay", "Visa", "Mastercard"],"ecommerce_platform": "Shopify","confidence": 0.95,"scraping_status": { "tier": "http", "browser_used": false, "blocked": false, "error": null, "time_elapsed_ms": 2310 }}
scraping_status.browser_used: false means the result came from the cheap HTTP tier — most rows will look like this.
💡 Clay / CRM usage
- Filter prospects: keep rows where
has_checkout = true(addcheckout_accessible = trueto target self‑serve commerce, orcheckout_type = "saas"for subscription products). - Personalize: reference
ecommerce_platformorpayment_providersin outreach. - Cost:
browser_used = falserows are the cheapest; the Actor only spends a browser render when a site looks commercial but HTTP couldn't confirm it. - Pair with the Pricing Detector Actor for a full monetization view.
Detection fingerprints are curated from the open Wappalyzer methodology (categories: Payment processor, Ecommerce) plus active platform API probes the standard tech‑detectors don't perform.

