E-commerce Tech & Payment Stack Detector

SEO title: E-commerce Tech Stack Detector — platform, payments, pixels SEO description: Domain list in, tech stack out: e-commerce platform, payment providers (Stripe, Barion, SimplePay), and analytics pixels — with CEE/Hungarian coverage generic detectors miss, plus evidence per match.

Give it a list of domains, get back what each one runs: e-commerce/CMS platform, payment providers, and analytics/marketing pixels — with evidence for every detection (which signature matched and where). Built like Wappalyzer, but deliberately narrowed to e-commerce + payments + CEE (Central/Eastern European, especially Hungarian) providers most generic tech-stack detectors don't cover at all.

Why this exists

Generic tech-stack detectors are broad but shallow on payment providers and blind to the CEE region: they know Shopify and Stripe, but not Shoprenter, UNAS, Barion, or SimplePay — the platforms and payment rails that actually run a large share of Hungarian and CEE webshops. This actor is the opposite trade: a smaller, curated signature set (~35 techs, ~75 individual signatures) built specifically for e-commerce + payments + analytics, with the CEE angle as first-class coverage rather than an afterthought.

Typical use case: "which of these 500 leads are running Shopify with Stripe" or "which HU webshops on our list use Barion vs. SimplePay" — sales intelligence for payment-provider sales teams, agencies, and SaaS lead-gen, or just curiosity about a competitor's stack.

No login, no API key, no anti-bot risk — only the public landing page (+ a couple of same-origin linked JS assets) of each domain you supply is fetched, over plain HTTPS/HTTP, no browser.

Input

Field	Type	Default	Description
domains	array of strings	—	Required, non-empty, max 200. Domains or full URLs to fingerprint, e.g. "example-shop.hu" or "https://example-shop.hu/". Scheme/path/query/port/userinfo are stripped automatically; duplicates (after normalization) are removed.
checks	array of strings	["platform", "payments", "analytics"]	Which signature categories to run: "platform", "payments", "analytics". Narrowing this makes detection slightly faster (fewer signatures tested) but does not change the price.

You must provide domains — an input with an empty or missing list fails immediately with a message telling you exactly that, before any fetching happens.

Worked example — input

{
  "domains": ["allbirds.com", "shoprenter.hu"],
  "checks": ["platform", "payments", "analytics"]
}

Worked example — output (real data from a live run)

[
  {
    "domain": "allbirds.com",
    "platform": "Shopify",
    "payment_providers": [],
    "analytics": ["Google Tag Manager"],
    "evidence": [
      {
        "tech": "Shopify",
        "category": "platform",
        "match_type": "script-src-domain",
        "pattern": "cdn.shopify.com",
        "confidence": 0.95,
        "detail": "script src matched 'cdn.shopify.com': https://cdn.shopify.com/s/files/1/1104/4168/files/jsEncrypt.js?v=..."
      },
      {
        "tech": "Shopify",
        "category": "platform",
        "match_type": "html-substring",
        "pattern": "Shopify.shop",
        "confidence": 0.85,
        "detail": "substring 'Shopify.shop' found in page text: ...Shopify = Shopify || {}; Shopify.shop = \"weareallbirds.myshopify.com\"; Shopif..."
      },
      {
        "tech": "Google Tag Manager",
        "category": "analytics",
        "match_type": "regex",
        "pattern": "GTM-[A-Z0-9]{4,}",
        "confidence": 0.8,
        "detail": "regex 'GTM-[A-Z0-9]{4,}' matched: ...dataLayer','GTM-TH8KRSBJ'); </script> <!-- End Google Tag Ma..."
      }
    ],
    "final_url": "https://www.allbirds.com/",
    "fetched_at": "2026-07-07T18:50:21.352173+00:00"
  },
  {
    "domain": "shoprenter.hu",
    "platform": "Shoprenter",
    "payment_providers": [],
    "analytics": ["Google Tag Manager"],
    "evidence": [
      {
        "tech": "Shoprenter",
        "category": "platform",
        "match_type": "script-src-domain",
        "pattern": "shoprenter.hu",
        "confidence": 0.9,
        "detail": "script src matched 'shoprenter.hu': https://www.shoprenter.hu/wp-includes/js/jquery/jquery.min.js?ver=3.7.1"
      }
    ],
    "final_url": "https://www.shoprenter.hu/",
    "fetched_at": "2026-07-07T18:51:28.502982+00:00"
  }
]

A domain that failed to fetch entirely (DNS failure, timeout, TLS error, or a non-retryable HTTP error on both https:// and http://) looks like this instead — delivered for transparency, but not billed (see Pricing):

{
  "domain": "this-domain-does-not-resolve.example",
  "platform": null,
  "payment_providers": [],
  "analytics": [],
  "evidence": [],
  "final_url": null,
  "fetched_at": "2026-07-07T18:50:31.191275+00:00",
  "error": "Could not fetch 'this-domain-does-not-resolve.example' via https:// or http://: GET http://... failed after 4 attempts: [Errno -2] Name or service not known"
}

Output schema

Field	Type	Notes
domain	string	The (normalized) input domain this row is for
platform	string or null	The single e-commerce/CMS platform with the highest combined signature confidence, e.g. "Shopify", "Shoprenter", "UNAS", "WooCommerce". null if nothing matched — a valid, billable "we couldn't fingerprint it" answer, not an error
payment_providers	array of strings	Every payment provider detected, e.g. ["Stripe", "Barion"]. Can hold more than one — many shops run several
analytics	array of strings	Every analytics/marketing pixel detected, e.g. ["Google Analytics 4", "Meta Pixel"]
evidence[].tech / .category / .match_type / .pattern / .confidence / .detail	—	One entry per matching signature: which tech, which category (platform/payment/analytics), how it matched, and a short human-readable snippet of where
final_url	string or null	The landing page URL actually fetched, after redirects. null on a fetch-failure row
fetched_at	string (ISO 8601)	When this actor fetched the domain
error	string, only on fetch-failure rows	Present ONLY when the landing page could not be fetched at all — see "Billing model" below

Signature coverage

Platforms (10): Shopify, WooCommerce, Shoprenter (HU), UNAS (HU), Magento, PrestaShop, BigCommerce, Wix, Squarespace, OpenCart, Shopware.

Payment providers (10): Stripe, Barion (HU), SimplePay / OTP (HU), PayPal, Braintree, Adyen, Klarna, Revolut, Mollie, Paysera.

Analytics / marketing pixels (8): Google Analytics 4, Google Tag Manager, Meta Pixel, TikTok Pixel, Hotjar, Klaviyo, Microsoft Clarity, Pinterest Tag.

Each tech is backed by 1-4 independent signatures (script-src domain/path, HTML substring, regex, cookie name, <meta name="generator">, or response header) — a page can match several signatures for the same tech, and every match becomes its own evidence entry. See src/signatures.py for the full, documented list and match-type semantics.

How detection works

1. Fetch the domain's landing page (https:// first, falling back to http:// if that fails).
2. Extract up to 3 same-origin <script src="..."> assets and fetch them too (best-effort — a failed asset fetch is silently skipped, it just means less signal, not a run failure). No deep-crawl, no headless browser.
3. Run every requested signature category against the combined HTML + JS text, response headers, extracted cookie names, and the <meta name="generator"> tag.
4. Pick the single highest-confidence platform; collect the full set of matched payment_providers and analytics (a page can legitimately run several of each).

Pricing (pay-per-event)

Event	Price	When it's charged
domain-result	$0.004	Once per domain whose landing page was successfully fetched — including a domain that matched no signature at all (a valid, billable "couldn't fingerprint it" answer)

Plus Apify's own apify-actor-start synthetic event (first 5 seconds of compute free, platform-managed — never charged from this actor's code).

Example: 50 domains, all fetchable: 50 × $0.004 = $0.20. 50 domains where 5 fail to fetch: 45 × $0.004 = $0.18 — the 5 failed domains still appear in the dataset as (uncharged) error rows for transparency, but are not billed.

If a run's cost would exceed the Max total charge USD you set for it, the actor stops producing further results at exactly that point — it never crashes and never produces unbilled/"free" domain-result rows past the limit.

Billing model: fetch failures are delivered, but never charged

A domain that fetches fine but matches nothing is a valid, billable result (an honest "no tech detected" answer) — normal domain-result row, charged.

A domain that cannot be fetched at all (DNS failure, connection/timeout error, TLS failure, or a non-retryable HTTP error on both scheme attempts) is different: nothing was actually fingerprinted, so charging for it would bill you for a result this actor didn't produce. This actor's choice: such a domain still gets one dataset row (so you can see exactly which domains failed and why, with a human-readable error field), but that row is delivered uncharged — it does not trigger the domain-result event at all. The billing invariant this preserves: every charged domain-result row was successfully fetched, and every successfully-fetched domain is charged exactly once.

Error messages

• Missing/empty domains: "Missing 'domains': provide a non-empty list of domains or URLs to fingerprint..." — add the field.
• domains as a bare string instead of an array: "'domains' must be a list of strings, got a single string ..." — wrap it in a list.
• A domains entry with no usable host (e.g. an empty string): a speaking error naming the bad entry.
• domains over 200 entries: "'domains' has N entries, which is more than the maximum of 200." — split into multiple runs.
• Unsupported checks value: "'checks' contains unsupported value(s) [...]. Supported values are: ['analytics', 'payments', 'platform']." — fix the typo/remove the entry.
• 0 results with otherwise valid input: not an error — the run succeeds, but the log has an explicit WARNING: 0 results produced despite valid input (...) line, so this is never a silent/invisible "nothing happened."

All input validation happens before any network request — a structurally bad input never costs you a fetch.

Known limitations (documented, not hidden)

• html-substring/regex signatures can, in principle, match a page that merely mentions a technology in prose (a blog post comparing "Shopify vs. WooCommerce") rather than actually running it — the same trade-off every Wappalyzer-style detector makes. Mitigated by preferring script-src/cookie/meta-generator signatures where a reliable one exists, and by keeping substring patterns as specific as practical (e.g. "revolut.com" rather than the bare word "revolut", which this actor's own live testing caught colliding with unrelated English text like "civil commotion, revolution").
• Cookie-name signatures only see the LAST Set-Cookie response header. A server that sends several Set-Cookie headers on the initial response collapses to one under this actor's header handling — cookies set by an earlier header are invisible to cookie-name signatures. Script-src/HTML/meta-generator signatures are unaffected.
• No deep-crawl, no headless browser. Only the landing page plus up to 3 same-origin linked JS assets are fetched — a signature that only appears on a different page (e.g. a checkout page's payment-provider script) won't be seen from the landing page alone. This is a deliberate scope choice (politeness + cost), not an oversight.
• platform is a single best guess, not a set. If a page happens to match signatures for two platforms (rare, but possible for a migrated site with leftover assets), only the higher-combined-confidence one is reported as platform — though every matching signature for both still appears in evidence.

Data sources

The domain(s) you supply — this actor makes plain HTTP(S) GET requests to each one's landing page and a handful of its own same-origin JS assets, exactly like a browser's initial page load would (minus JS execution). No third-party data broker, no scraping of any site other than the ones you ask about.