Why StackPatrol does not show Stripe, Resend or your other backend services

When you submit a URL, StackPatrol opens that page in a real Chromium browser. It waits for the page to fully load, then records every single HTTP request the browser makes: scripts, fonts, stylesheets, fetch calls, images, iframes, web fonts, beacon calls, everything. Each request hits a domain. Those domains are matched against our vendor database of around 570 services, classified by ownership region.

This is the same technique browsers, ad blockers and most privacy scanners use. It is accurate and it is verifiable: if a third party sees the visitor's IP address during a normal page visit, StackPatrol detects it.

Tools like Resend, Postmark, SendGrid, Mailgun, OpenAI or an internal database are called from your server, not from the browser. The flow looks like this:

1. Visitor submits a contact form on your site.
2. Their browser sends the form data to your own backend (for example, POST /api/contact).
3. Your server, running in your datacenter, makes an HTTP call to Resend's API to dispatch the email.
4. Resend sends the email and returns a response to your server.
5. Your server returns a success message to the visitor.

From the visitor's browser, only one request was made: to your own domain. There is no network connection between the visitor and Resend. No script from Resend ever runs in the browser. It is technically impossible for any client-side scanner — StackPatrol, Wappalyzer, BuiltWith, the EU's own Webbkoll — to detect Resend in this scenario.

The same applies to most modern backends: your database, your background queue, your transactional email provider, your AI provider, your search index. None of them appear in a network audit because they were never on the network the visitor used.

Stripe is the case that surprises people most, because it is a payment processor and payment processors feel like they should be visible. The reason it stays hidden depends on how you integrated it.

Stripe Checkout (hosted, redirect-based). The user clicks “Buy” on your site, your backend calls Stripe to create a session, and the user is redirected to checkout.stripe.com. All payment UI lives on Stripe's domain. Nothing Stripe-related loads on your site. This is the most common setup for small SaaS products and the one StackPatrol itself uses.

Stripe Elements or Payment Element. If you embed the card form directly on your site, you must include js.stripe.com/v3 in your page. In that case StackPatrol does pick up Stripe, because the script runs in the browser. The script is also loaded preemptively on pages where checkout is even possible, for fraud detection.

Stripe Pricing Tables or Buy Buttons. The <stripe-pricing-table> web component loads Stripe scripts and Stripe iframes directly into the page. StackPatrol sees those.

If you use redirect-based Checkout and Stripe is missing from your report, that is correct. It is not a bug.

StackPatrol is built to answer one specific question: what do my visitors' browsers talk to when they load my pages? That question matters because the answer determines whether GDPR data transfers happen automatically, without consent, on every visit. A visitor cannot meaningfully consent to a transfer they cannot see.

Server-side services are a different conversation. When your backend calls Resend, you as the data controller chose what fields to send. You signed a DPA with Resend. You documented the processor in your ROPA. The visitor is not making that decision in real time, which means the legal and technical analysis is different.

Mixing the two in one report would confuse the picture. A vendor inventory that shows “Stripe (backend, covered by DPA)” next to “Google Fonts (browser-loaded, unconsented)” gives the wrong impression that both are the same kind of risk. They are not.

Server-side processors still need to be documented. They just need a different document. The standard checklist looks like this.

1. Maintain a Record of Processing Activities (ROPA). GDPR Article 30 requires this for most organisations. List every backend service that handles personal data, what categories of data it sees, what the legal basis is, and where the processor is located.

2. Have a Data Processing Agreement with each one. Stripe, Resend, SendGrid, Vercel, Supabase: all offer standard DPAs. Sign them and keep copies.

3. List your processors publicly. Most privacy policies include a sub-processor list. This is good practice and it is becoming an expectation in B2B sales: enterprise buyers ask for the list before signing. If you do not already have one, our own DPA page is a working example of the format.

4. Audit the browser side separately. That is what StackPatrol is for. The two inventories together (backend processors plus browser-loaded vendors) give you a complete picture.

Shows up in StackPatrol: Google Fonts, Google Analytics, Google Tag Manager, Meta Pixel, LinkedIn Insight Tag, HubSpot widgets, Intercom, Zendesk chat, Typeform embeds, YouTube embeds, reCAPTCHA, Stripe.js (when embedded), Cloudflare CDN assets, Hotjar, Mixpanel, Segment, marketing pixels of any kind.

Does not show up: Resend, SendGrid, Postmark, Mailgun, AWS SES, Stripe (when using redirect Checkout), Twilio, OpenAI, Anthropic, your database, your background job queue, your CRM API integrations, your own server-side analytics.

If you need a tool that captures the backend side too, you are looking for something different: APM tools like Datadog, Sentry or New Relic show server-to-server calls. They are far more invasive to install (an agent in your application) and they are built for engineers, not for privacy audits.