# Payment buttons and consent: what checkout scripts set before the first click Source: https://cookierampart.com/blog/2026-10-03-payment-buttons-checkout-scripts-consent.html [Home](../index.md) / [Blog](index.md) / Payment buttons and consent: what checkout scripts set before the first click Published 2026-10-03 Checkout pages load some of the most aggressive scripts on the web. Payment buttons from PayPal, Stripe, Apple Pay, and Google Pay each bring their own JavaScript, and that JavaScript starts working the moment it loads, long before the customer clicks anything. The question is not whether these scripts set cookies. It is what they set, and whether your banner accounts for it. ## What loads before the first click Payment button scripts do several things on load. They check the browser environment, they render the button, and they often set cookies or local storage for fraud detection and session continuity. Fraud detection is the tricky part: the scripts fingerprint the device and the session to tell legitimate checkouts from stolen-card testing, and that fingerprinting looks a lot like tracking. Some of this is genuinely necessary for the payment to work. A fraud signal that prevents card testing protects the merchant. But not all of it is necessary, and the scripts do not draw the line for you. The same library that performs the fraud check may also set marketing or analytics cookies, because the vendor's script is one bundle with one behavior. ## The consent problem with fraud detection Fraud detection sits in the grayest area of consent law. It is arguably necessary for the service the customer requested, completing a secure payment, which would make it exempt. But the exemption covers what is strictly necessary, not everything the script does. A device fingerprint used for fraud scoring might qualify; the same fingerprint shared with the vendor's advertising graph does not. The practical issue is that merchants cannot see inside the bundle. The payment provider's documentation describes the fraud features, not the full cookie inventory. Most merchants install the button, see it work, and never ask what else loaded. That is how checkout pages end up setting third-party cookies that no banner mentions. ## How to find out what your checkout sets The audit is simple and most merchants have never run it. Open the checkout in a fresh browser profile, open DevTools, and watch the storage and network panels as the page loads, before clicking anything. Note every cookie and every third-party request. Then click through the payment button flow and watch what changes. Do this for each payment method separately. PayPal's script behaves differently from Stripe's, which behaves differently from Apple Pay's. A single checkout page can load three or four payment scripts, and each brings its own inventory. Test them in isolation to attribute each cookie to its source. ## What to do with the findings Separate the necessary from the optional. Fraud and security functions tied to the transaction can typically be treated as necessary, but document the reasoning: which script, which function, why the payment would not work securely without it. Everything else goes behind consent like any other tracker. Load payment scripts conditionally where you can. If the customer has not chosen a payment method, the PayPal script does not need to be on the page yet. Deferring third-party payment scripts until the method is selected cuts the pre-click tracking surface without breaking the checkout. Update the cookie disclosure. Checkout scripts are the cookies visitors are least likely to expect and most likely to be surprised by. Listing them accurately in the cookie policy closes the gap between what the banner promises and what the checkout does. ## The bottom line Payment buttons are trusted because money is involved, but trust is not a consent category. Audit what the scripts set before the first click, keep what the transaction genuinely needs, gate the rest, and disclose all of it. The checkout is the last place a surprise tracker should be. ## Frequently asked questions ### Do small websites really need a cookie banner? If a site sets optional cookies for analytics or marketing and its visitors are covered by consent rules, yes. The banner can be simple; the obligation follows the tracking, not the site size. ### What cookies does a typical analytics tool set? Analytics tools set first party identifiers to distinguish visitors and sessions, plus preference cookies. The exact names change by version, so a live scan beats any static list. ### Where should a banner appear on mobile? It should be readable without covering the whole screen, with accept and reject equally reachable. A banner that blocks content until accepted weakens the consent it collects. ### Can a banner remember my choice across devices? Only if you are signed in and the site syncs preferences to your account. Otherwise choices are stored per browser, which is why you may see banners again on a new device. ## Get a free consent audit of your website [Free consent audit](mailto:hello@cookierampart.com?subject=Free%20consent%20audit%20-%20cookierampart.com)