How to Find Out What Payment Processor a Website Uses
Stripe, PayPal, Adyen, Square — payment processors leave scripts and network calls behind. Here is how to detect a site's payment gateway from the checkout.
To find out what payment processor a website uses, go to its cart or checkout page, open the DevTools Network tab, and watch which payment domains load — js.stripe.com means Stripe, paypal.com/sdk means PayPal, js.braintreegateway.com means Braintree, and so on. The checkout is the key place to look, because that is where the payment SDK actually loads and the card form renders; a homepage scan will usually miss it. The card fields themselves are typically an iframe served from the processor's domain, which names the gateway directly. This guide covers every signal, the right place to look, and the cases where hosted checkouts make detection harder.
It pairs with how to find out what ecommerce platform a website uses and the broader how to find out what technology a website uses, since payments are one layer of the commerce stack.
Why the payment processor is worth knowing
The payment processor is one of the most valuable single facts about an online store. For payments and fintech sales, it identifies both who a merchant currently banks with and whether there is a switching opportunity — a Stripe merchant is a different prospect from an Adyen merchant. For competitive research, the processor is part of the commerce stack alongside the platform, and it hints at scale: a small shop on a single basic gateway is a different operation from one running an enterprise processor with multiple payment methods. And for understanding the market, mapping which processors power which sites reveals real adoption patterns. Because payment SDKs run in the browser, much of this is readable from the outside.
Where to look: the checkout, not the homepage
The most important tactic is where you look. Many sites deliberately avoid loading their payment scripts on the homepage and product pages, because payment SDKs add weight and these pages need to be fast. The scripts load only when you reach the cart or checkout, where the card form is rendered and the pay button appears. So the workflow is: add an item to the cart, proceed toward checkout, and then open DevTools. Detecting on the homepage will frequently come up empty even when the site clearly takes payments — the evidence simply is not loaded yet. (You do not need to complete a purchase; the scripts load as the checkout page renders.)
Method 1: watch the Network tab on checkout
With the checkout open, open DevTools (F12), go to the Network tab, and reload. Payment processors phone home to their own servers, so their requests stand out. Look for the SDK and API domains: a request to js.stripe.com/v3 is Stripe's JavaScript SDK; calls to paypal.com/sdk/js are PayPal; js.braintreegateway.com is Braintree; checkout.adyen.com or Adyen's script domain is Adyen. Interacting with the payment form (clicking into a card field, choosing a method) often triggers further calls that confirm the provider. The Network tab is the most reliable method because it shows what actually loads and fires, including processors added through a platform's checkout.
Method 2: View Source and the iframe origins
A source check also works. View the checkout's source (Ctrl/Cmd + U) and search for the processor domains above. Better still, inspect the card form: card-number fields are almost always rendered inside an iframe served from the processor's domain — this is how Stripe Elements, Braintree Hosted Fields and similar keep the sensitive card data off the merchant's own page for security and PCI scope reasons. Right-click the card field, choose Inspect, and read the iframe's src origin: if it points to js.stripe.com or assets.braintreegateway.com, that names the gateway directly. The iframe origin is one of the cleanest signals because it is structural to how modern card forms work.
Method 3: the pay buttons and DOM
Express payment buttons are visible giveaways. A PayPal button is rendered by PayPal's SDK and is unmistakable; Apple Pay and Google Pay buttons indicate those wallet integrations (often via the underlying processor); Shop Pay points to Shopify Payments (which is powered by Stripe under the hood); and buy-now-pay-later buttons for Klarna, Afterpay/Clearpay or Affirm each load their own scripts and branding. Scanning the checkout's buttons and the DOM around them reveals the full set of payment methods on offer, which is often several at once.
The signal table
| Processor / method | Tell-tale domain / marker |
|---|---|
| Stripe | js.stripe.com, Stripe Elements iframe, Stripe( |
| PayPal / Braintree | paypal.com/sdk, js.braintreegateway.com, PayPal button |
| Adyen | checkout.adyen.com, Adyen script/iframe |
| Square | squarecdn.com, Square Web Payments SDK |
| Shopify Payments | Shop Pay button (Stripe-powered under the hood) |
| Klarna | klarna.com / x.klarnacdn.net, Klarna widget |
| Afterpay / Clearpay | afterpay/clearpay script and badge |
| Affirm | affirm.com / cdn1.affirm.com, Affirm messaging |
A single matching domain usually settles the question; several together tell you the full payment line-up.
Reading the platform's built-in checkout
Many stores do not bolt a payment processor onto a custom checkout — they inherit one from their ecommerce platform, which shapes what you will find. A Shopify store typically routes through Shopify Payments (Stripe under the hood) with a Shop Pay accelerated-checkout button, and may add PayPal and a BNPL option in the platform's payment settings; the giveaway is the Shopify checkout domain and the Shop Pay branding. A WooCommerce site (WordPress) commonly uses the WooCommerce Stripe or PayPal extensions, so you will see those processors' scripts loaded by the plugin. A BigCommerce or Adobe Commerce (Magento) store exposes the gateway its merchant configured, often Stripe, Braintree, Adyen or a regional acquirer. So before you even inspect the form, identifying the platform — using how to find out what ecommerce platform a website uses — narrows the likely processors and tells you whether you are looking at a platform-native checkout or a custom one. The two questions are tightly linked: the platform frequently is the reason a particular processor is present.
The big caveat: hosted and redirect checkouts
Detection is hardest when a site uses a hosted or redirect checkout — where, instead of embedding the card form, the site sends you to the processor's own page to pay (Stripe Checkout's hosted page, a redirect to PayPal, or a gateway-hosted payment page). In these flows the merchant's own pages may load little payment script, because the actual payment happens on the processor's domain after a redirect. You can still identify the processor from where the checkout sends you — the redirect destination is branded — but you lose the in-page detail (the embedded SDK, the iframe origin). Redirect flows are common for smaller merchants and for certain platforms, and they are deliberately more opaque, so be honest that detection is less complete there than with an embedded form.
A worked example
You want to know how a competitor's store takes payment. You add a product to the cart and proceed to checkout, then open the Network tab and reload. You immediately see a request to js.stripe.com/v3 — Stripe's SDK is loading. Inspecting the card-number field shows it is an iframe with a js.stripe.com origin, confirming Stripe Elements. Scrolling the checkout, you also see a PayPal button (a second method) and a Klarna "pay in 4" widget (a buy-now-pay-later option), each loading its own script. So the picture is: Stripe for cards, with PayPal and Klarna as additional methods — a fairly mature, multi-option checkout. That tells you both the core processor relationship and the breadth of payment choice the merchant offers, all from a couple of minutes on the checkout page.
What the payment stack reveals about a business
The payment setup is a surprisingly rich signal. A store on a single basic gateway with one payment method is usually a smaller or simpler operation. A checkout running an enterprise processor like Adyen, or offering many methods (cards, wallets, several BNPL options, local payment methods), signals a larger, more sophisticated merchant investing in conversion and international reach. The specific processor also carries meaning: Stripe is the default for developer-led and modern commerce; Shopify Payments indicates a Shopify store (see how to tell if a website is built with Shopify); Adyen and similar point to enterprise scale. For a payments company, this is direct sales intelligence; for anyone researching commerce, it is a clear read on a merchant's maturity.
Privacy, ethics and scope
A note on doing this responsibly: detecting a payment processor uses only the publicly observable behaviour of a checkout page — the scripts it loads and the iframes it renders — exactly as the visitor's browser sees them. You should never enter real card details, attempt a transaction you do not intend to complete, or try to interfere with the payment flow. The goal is to read what loads, not to test or probe the payment system. Used this way, payment detection is ordinary technographic research, the same kind of public-signal reading covered in what is technographics. Keep it to observation and you stay firmly on the right side of the line.
How accurate is payment detection?
Accurate for embedded checkouts, less so for redirect flows. When the payment form is embedded, the SDK domain, the iframe origin and the pay buttons make the processor clear, and detection is reliable — especially for the major providers, which have stable, recognisable fingerprints. The accuracy gap is the hosted/redirect checkout, where the in-page evidence is thin and you depend on the redirect destination, and cases where a processor is reached entirely server-side. So "what processor does this embedded checkout use?" is usually answerable with confidence, while "what gateway sits behind this fully redirected checkout?" can be only partially answered from the outside. Report what the page actually shows, and be clear when a redirect hides the rest.
The workflow
- Go to the cart/checkout — not the homepage — and only then open DevTools.
- Watch the Network tab for payment SDK domains like
js.stripe.com. - Inspect the card field's iframe origin to name the gateway directly.
- Read the pay buttons (PayPal, wallets, Klarna/Afterpay) for the full method set.
- For redirect checkouts, note the destination and accept that detail is limited.
Go deeper
- The platform behind the store: how to find out what ecommerce platform a website uses.
- Spotting Shopify specifically: how to tell if a website is built with Shopify.
- The whole stack: how to find out what technology a website uses.
- Support tooling on the same site: how to detect live chat and chatbot tools on a website.
Want the payment stack, platform and full technology picture in one report? Analyse any site with StackOptic — free, no sign-up.
Frequently asked questions
How do I find out what payment processor a website uses?
Go to the site's cart or checkout page, open DevTools and watch the Network tab — payment processors load scripts from their own domains, such as js.stripe.com (Stripe), paypal.com/sdk (PayPal) or js.braintreegateway.com (Braintree). You can also View Source on the checkout and search for those domains. The card form is often an iframe from the processor's domain, which names the gateway directly. Detection tools list payment providers automatically.
Why is the checkout page the best place to look?
Because that is where the payment SDK actually loads and the card form renders. Many sites do not load their payment scripts on the homepage or product pages to keep them fast; the scripts appear when you reach the cart or checkout. So a homepage scan can miss the processor entirely, while opening DevTools on the checkout reveals the SDK request, the iframe origin and the pay buttons — the real evidence of which gateway is in use.
What if the site uses a hosted or redirect checkout?
Some sites send you to the processor's own hosted page to pay (a redirect checkout) rather than embedding the form. In that case the in-page scripts may be minimal and the detail lives on the redirect destination. You can still identify the processor from where the checkout sends you — for example a redirect to a Stripe Checkout, PayPal or a gateway-branded page. Redirect flows are deliberately more opaque, so detection is less complete than with embedded forms.
Can one site use more than one payment processor?
Yes, and it is common. A site might use Stripe or Braintree for card payments while also offering PayPal, plus buy-now-pay-later options like Klarna or Afterpay, each loading its own script and button. Marketplaces and larger merchants sometimes route through multiple gateways. So expect to find several payment-related domains on a mature checkout, and report the full set rather than assuming a single processor handles everything.
Why would I want to know a site's payment processor?
It is a high-value piece of competitive and sales intelligence. For payments and fintech companies, knowing which gateway a merchant uses identifies both a competitor relationship and a potential switching opportunity. For commerce research, the processor is part of the stack alongside the platform and other tools. It can also indicate a merchant's scale and sophistication, since enterprise processors like Adyen signal a larger operation than a basic single-gateway setup.
Analyse any website with StackOptic
Get the full technology stack, performance, security and SEO report in seconds — free.
Analyse a websiteRelated articles
How to Tell If a Website Uses Crisp
Crisp is a developer-friendly, affordable live-chat and messaging tool. Detect it via the client.crisp.chat/l.js script, the window.$crisp object and the CRISP_WEBSITE_ID value.
How to Tell If a Website Uses Tidio
Tidio is an affordable live-chat and chatbot tool for SMBs and ecommerce. Detect it via the code.tidio.co/<publicKey>.js script, the window.tidioChatApi object and tidioChatCode.
How to Tell If a Website Uses Bugsnag
Bugsnag (SmartBear) is an error-monitoring and stability platform. Detect it via the @bugsnag/js SDK, the window.Bugsnag object, the API key in Bugsnag.start() and notify.bugsnag.com beacons.