Checkout.com routes every commercial signal toward a sales conversation, yet the CRM that presumably captures those leads is invisible to all public scanning. The company’s front-end stack reveals a carefully segmented delivery architecture built on Webflow, Cloudflare, and Redocly, but not a single pixel, cookie, or JavaScript snippet from Salesforce, HubSpot, or any other customer relationship management platform was detected in the crawl. That absence does not mean they lack one—it means their demand infrastructure is designed to keep the sales engine completely air-gapped from the marketing surface, a choice with significant implications for how competitors think about tech stack visibility and enterprise buyer expectations.
This deep-dive analyzes the publicly observable portions of Checkout.com’s technology footprint as captured on May 29, 2026. The analysis draws on front-end scanning, sitemap crawling, DNS records, and security headers—it does not include backend transaction systems, core payment gateways, or private API endpoints. Every technology name that follows was confirmed via HTTP headers, JavaScript objects, DOM attributes, or TLS certificates present in the sampled surface. If something wasn’t seen, it might still be there, but its absence from the outer layer is itself a strategic signal worth examining.
The Stack at a Glance
The Checkout.com public web presence breaks into four distinct delivery surfaces, each with its own technology choices. The main marketing site lives on Webflow, a visual CMS that generates static pages and hosts them behind Cloudflare’s CDN. TLS certificates are issued by Google Trust Services, and the DNS records point to Cloudflare’s nameservers, confirming a full-stack Cloudflare edge in front of the Webflow origin. This combination gives Checkout.com a globally fast, highly cacheable front end that can handle traffic spikes without touching the Webflow backend.
On the main site, the JavaScript instrumentation tells a story of conversion optimization. Google Analytics is present, alongside Hotjar for session recordings and heatmaps. Advertising pixels from Google Ads and Facebook fire, confirming paid media spend that likely drives demand into the contact-sales funnel. Two experimentation tools—Optimizely and Intellimize—run simultaneously, which is a strong signal that Checkout.com is running A/B tests on page layouts, form fields, or messaging, and possibly using Intellimize’s AI-driven personalization to tailor the experience by visitor segment.
Separate from the marketing site is the API reference subdomain, `api-reference.checkout.com`. This surface uses Redocly, a popular tool for rendering OpenAPI specifications into interactive documentation. The choice of a dedicated subdomain—rather than a path on the main site—is deliberate: it keeps developer resources technically isolated from the marketing surface, likely to allow different deployment cadences, caching policies, and authentication models. The trust subdomain `trust.checkout.com` was verified as active, hosting security and compliance information on its own segmented infrastructure. Two other subdomains—`identity.checkout.com` and `support.checkout.com`—were linked from the site but could not be fully verified in the crawl, suggesting they may be behind authentication or exist as redirect targets that the scanner couldn’t resolve.
Beneath these front-end surfaces, DataDog Real User Monitoring (RUM) tracks performance and errors on the main site. A sandbox subdomain (`developer-experience-mfe.sandbox.checkout.com`) was also detected, which points to micro-frontend experimentation. The `mfe` in the subdomain is a near-certain reference to “micro frontends,” an architecture where different teams independently deploy UI components that are stitched together at runtime. This is a sophisticated pattern for a company whose public presence otherwise appears to be a monolithic Webflow site, and it hints at a more complex internal developer platform powering logged-in experiences or tooling that isn't publicly crawlable.
How They Acquire Customers
Checkout.com’s go-to-market motion is unequivocally sales-led, not product-led. The main site’s conversion paths funnel visitors to a contact form requiring name, email, company, and a message. There is no self-serve signup, no free trial, and no way to access product functionality without a human conversation. Pricing pages are gated behind the same contact-sales flow, reinforcing that even basic commercial information is reserved for qualified prospects.
The sitemap sample captured 200 pages, of which 127 were blog posts. That ratio suggests a content engine heavily invested in buyer education and SEO top-of-funnel acquisition. The blog content presumably targets terms around payments, fraud, authorization rates, and global acquiring—topics that bring in finance and engineering leaders researching solutions. But notably, no content was detected that would serve a self-serve evaluation path, such as interactive product tours, sandbox signup pages, or usage-based pricing calculators. The captured sample included a “/partners/join” section with just two pages, indicating a partner ecosystem that is either nascent or not publicly developed on the main site.
The technology signals reinforce this sales-led design. The absence of any visible CRM tag means the handoff from form submission to sales team is opaque. A form on a Webflow page can POST to a Webflow-native form handler, a third-party endpoint, or a serverless function that feeds into a CRM. Without the CRM pixel, it’s impossible to know whether the company uses Salesforce, HubSpot, Pipedrive, or a custom system. This is a deliberate air gap: by not exposing the CRM on the public web, Checkout.com reduces the attack surface and avoids leaking data about its sales processes to competitors scanning their stack. For a payments company handling sensitive financial transactions, this operational security mindset extends even to marketing infrastructure.
Paid acquisition channels are clearly active. The Google Ads pixel combined with the Facebook Pixel indicates cross-platform retargeting and conversion tracking. Coupled with Optimizely and Intellimize, the marketing stack shows a machine that can drive paid traffic to landing pages, test variants, personalize for returning visitors, and push qualified leads into a sales pipeline that remains invisible beyond the form. What’s missing are lifecycle automation tools. No marketing automation platform like Marketo, Pardot, or Customer.io was detected. No evidence of email nurture workflows, lead scoring, or automated onboarding sequences surfaced. Google Workspace is the only collaboration tool observed, but that doesn't indicate marketing automation.
This gap suggests that Checkout.com relies on its sales team to handle all post-form nurturing manually or through internal systems that aren’t browser-accessible. For an enterprise sales motion targeting large merchants and platforms, this may be sufficient—deals are high-touch by nature. But it also implies that the company may be leaving expansion revenue on the table by not automating cross-sell or upsell communications once a customer is landed. For founders evaluating their own stacks, this is a stark illustration: you can scale demand generation with content and ads, but if the nurture and expansion loops aren’t instrumented, your cost to acquire and expand will remain dependent on human bandwidth.
Infrastructure & Operations
The infrastructure decisions at Checkout.com reveal a clear separation of concerns between marketing, documentation, and trust. The marketing site on Webflow behind Cloudflare is a common pattern for growth-stage B2B companies: Webflow gives non-engineers control over the website, while Cloudflare accelerates content delivery, mitigates DDoS attacks, and provides edge computing capabilities. The TLS certificate from Google Trust Services (a free, automated CA integrated with Cloudflare) indicates that certificate issuance and renewal are fully automated, reducing operational overhead.
What’s more telling is the subdomain segmentation. `api-reference.checkout.com` runs Redocly, which serves machine-readable OpenAPI specs rendered as clean, human-friendly documentation. By placing this on a separate subdomain, Checkout.com can manage the API docs site independently—different deployment pipelines, different monitoring, different access controls. Developers who need to integrate with Checkout.com’s payment APIs get a dedicated, performant surface that isn’t cluttered by marketing content. This also means that SEO for developer terms can be tuned separately, though in the captured sample the docs subdomain did not appear integrated into the main sitemap, suggesting the two surfaces are treated as separate SEO properties.
The trust subdomain `trust.checkout.com` is verified and likely hosts security whitepapers, compliance certifications, incident reports, and penetration test summaries. This is a standard practice for enterprise SaaS, particularly in fintech, where procurement teams demand centralized security and compliance information. The fact that Checkout.com maintains a dedicated subdomain for trust content (rather than a `/trust` path on the main site) again speaks to segmentation: the trust site can be hosted on infrastructure with stricter access controls, different uptime guarantees, and separate content management workflows.
The `identity.checkout.com` and `support.checkout.com` subdomains could not be verified in the crawl. This often happens when those subdomains require authentication or are behind IP restrictions. Identity likely handles customer authentication for dashboard access, possibly via a service like Auth0 or Okta, but the exact provider wasn’t detectable. Support could be a Zendesk instance or a custom portal; without rendering the page, the stack remains hidden. This layered approach—public marketing on Webflow, API docs on Redocly, trust on a locked-down subdomain, and identity/support behind auth—is a mature, defense-in-depth architecture that separates public from authenticated, and content from transaction.
The detection of DataDog RUM on the main site shows that Checkout.com monitors real user sessions for performance regressions and JavaScript errors. The `developer-experience-mfe.sandbox` subdomain is particularly interesting. Micro frontends are a pattern where a web application is decomposed into smaller, independently deployable units, each owned by a different team. If Checkout.com is experimenting with this, it might be for their merchant dashboard or internal tooling rather than the marketing site. This would allow multiple development teams to ship updates to different parts of the UI without coordinating a monolithic release, accelerating feature delivery for paying customers. Competitors evaluating their own delivery maturity should note this: even companies whose public face is a simple CMS site may be operating a highly modular internal platform under the hood.
What This Means for Competitors
For product managers and founders building in the payments space or adjacent B2B fintech, Checkout.com’s stack offers several strategic signals.
First, the total absence of a CRM signal is a reminder that stack detection is inherently partial. When you scan a competitor’s website, you see only what they choose to expose. A sophisticated ops team can load CRM forms via iframes, proxy submissions through serverless functions, or use postMessage to communicate with a hidden frame—all invisible to HTML scraping. Checkout.com’s air gap suggests that the most sensitive parts of their revenue operations are deliberately obscured. If you’re doing competitive intelligence, you need to supplement web scans with other signals: job postings (do they hire Salesforce admins?), press releases (do they announce a partnership with a CRM vendor?), and sales team LinkedIn profiles (what tools do they list?). A blank scan result does not mean the tool is absent; it means it’s hidden.
Second, the Webflow-Cloudflare front-end is becoming the default for B2B marketing sites, but it creates a content management ceiling. Webflow is excellent for static pages and blogs, but it struggles with dynamic content, personalization beyond what Intellimize can layer on, and complex CMS needs. If Checkout.com’s blog grows to thousands of posts, or if they want to add interactive product tours, they may hit Webflow’s limits. Competitors who anticipate needing a more flexible CMS early—say, a headless setup with Contentful or Sanity—can build a content infrastructure that scales more cost-effectively over time.
Third, the heavy investment in experimentation tools (Optimizely and Intellimize simultaneously) is a pattern worth emulating, but it also reveals a reliance on tooling rather than culture. Two overlapping experimentation platforms can indicate that different teams purchased their own tools, or that one is being phased out. For a company whose product is a developer-facing API, the marketing site’s A/B testing sophistication must eventually connect to product experience. The detected micro-frontend sandbox may be where product-side experimentation happens, but from the public scan, there’s no evidence of experimentation inside the API docs or the developer dashboards. Competitors who tie their experimentation from the first touch all the way through product onboarding will have an advantage in conversion rate optimization that Checkout.com’s current separation of surfaces may hinder.
Fourth, the documentation story matters. Redocly is a strong choice for OpenAPI-driven docs, but the separation from the main site means the docs don’t benefit from the main site’s SEO authority unless cross-linking is deliberate. Competitors who integrate their docs into a single domain with their marketing site (using a subdirectory like `/docs` instead of a subdomain) can concentrate domain authority and provide a seamless experience for users moving from learning to trying. Checkout.com’s subdomain approach is clean for engineering but suboptimal for SEO and user journey continuity.
Fifth, the trust and security posture is enterprise-grade but not fully transparent. The `trust.checkout.com` subdomain, DMARC reject policy with BIMI, and vulnerability disclosure page all signal a mature security program. However, no compliance certifications like SOC 2, PCI DSS Level 1, or ISO 27001 were observed in the sampled crawl. That doesn’t mean they aren’t certified; it means they may not publish badges on the public site, or they may gate that information behind the trust subdomain’s authenticated sections. For enterprise buyers, the trust subdomain is the place to look, but if certifications are not immediately visible, it adds friction to the procurement process. Competitors that prominently display their certifications on both the main site and a trust center can reduce this friction.
Finally, the absence of self-serve onboarding is a strategic choice, not a flaw. Many API-first companies have moved toward product-led growth (PLG) with free tiers, sandbox accounts, and usage-based pricing. Checkout.com’s strict sales-led motion suggests they target high-value enterprise deals where the sales cycle involves complex negotiations, custom pricing, and compliance assessments. For them, a self-serve flow would likely attract unqualified leads that waste sales time. But this also leaves the door open for competitors who can offer a PLG motion to capture the long tail of developers and small businesses that Checkout.com ignores. The complete lack of a public sandbox signup on the main site—despite having a micro-frontend sandbox subdomain—shows that developer experience for unauthenticated users is not a priority.
Key Takeaways
The CRM air gap is a deliberate security and competitive intelligence strategy. Checkout.com’s public surfaces reveal demand generation tools (Google Ads, Facebook, Hotjar, Google Analytics, Optimizely, Intellimize) but no CRM pixel. This means prospects fill out a form, and everything beyond that is invisible to scanners. Competitors should assume similar opacity when analyzing payment infrastructure companies and look for indirect signals of the sales stack. Webflow plus Cloudflare is a pattern that works until it doesn’t. The combination delivers speed, global reach, and marketing team autonomy. But as content scales and personalization needs grow, the limitations of a visual CMS without server-side logic may force a replatforming. Teams evaluating their own marketing stack should plan for this growth inflection point. Experimentation tooling is advanced but potentially fragmented. Running Optimizely and Intellimize together may reflect organizational silos rather than a coherent experimentation strategy. High-performing growth teams consolidate on one platform and integrate it tightly with their data infrastructure to enable full-funnel optimization. Checkout.com’s approach works for now but may create integration debt. Subdomain segmentation is a double-edged sword. Separating docs, trust, identity, and support onto distinct subdomains improves security posture and allows independent deployment, but it fractures SEO authority and complicates the user journey. For developer-facing products, a unified domain with clear paths for each audience often outperforms a scattered subdomain architecture. No PLG motion is a vulnerability as much as a strategy.* By gating everything behind a contact-sales form, Checkout.com locks out the segment of developers and small businesses that prefer to evaluate products independently. Competitors can capitalize on this gap by offering transparent sandbox access, clear pricing, and a self-serve path from first API call to first transaction.
Checkout.com’s technology choices reflect a company that knows exactly who it sells to—large enterprises with complex payment needs—and has built a web presence that signals trustworthiness, performance, and security without revealing any more than necessary. The stack is not flashy, but it is deliberate. For founders and product leaders evaluating this space, the lesson is clear: your public technology footprint is a strategic signal. What you expose tells competitors how you acquire and retain customers. What you hide can be just as informative. Whether you adopt Checkout.com’s approach or go the opposite direction with full transparency and PLG, the critical thing is to make the choice intentionally, backed by a clear understanding of your target buyer and your own operational security requirements.