Checkout Detector avatar

Checkout Detector

Pricing

from $30.00 / 1,000 results

Go to Apify Store
Checkout Detector

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

Etan gentil

Maintained by Community

Actor stats

2

Bookmarked

2

Total users

1

Monthly active users

8 days ago

Last modified

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, Magento storeConfigs, shopify-checkout-api-token, JSON‑LD Product+price, cart <form action>, third‑party hosted checkout (Gumroad, Lemon Squeezy, Paddle, FastSpring, Chargebee, Recurly, Snipcart, Kit), a payment SDK in script-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

FieldTypeDefaultDescription
urlStringrequiredURL or bare domain (e.g. example.com or https://example.com)
timeoutSecondsInteger30Max 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.

FieldTypeDescription
domainStringRoot domain analyzed
has_checkoutBooleantrue if an active checkout/payment capability was detected
checkout_typeStringecommerce · saas · third_party · donation · unknown
checkout_accessibleBooleantrue if reachable without a signup/login wall (inferred SaaS = false)
detection_methodStringThe single strongest signal used (e.g. shopify_products_json, psp_sdk, cart_form)
payment_providersArrayDetected gateways / methods (e.g. ["Stripe", "Apple Pay", "Visa"])
ecommerce_platformStringDetected platform (e.g. Shopify, WooCommerce), or null
confidenceNumber0.01.0
scraping_statusObject{ 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 (add checkout_accessible = true to target self‑serve commerce, or checkout_type = "saas" for subscription products).
  • Personalize: reference ecommerce_platform or payment_providers in outreach.
  • Cost: browser_used = false rows 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.