Checkout has a certificate but still loads insecure resources

Check what the warning actually names

Start with the checkout URL and the exact browser message, including the browser version and time observed. Keep the main page’s origin—the scheme and host—separate from the resource address named in the message. Record which checkout step was visible when it appeared. A report that the page is insecure needs this context before anyone chooses a repair.

Stripe’s integration security guide says payment-page resources such as JavaScript, CSS and images should also be served over TLS to avoid mixed-content warnings. The certificate on the main page addresses that connection. It is not a record of how every separately requested resource was served.

Do not label every browser security warning as mixed content. If the message does not identify insecure resource loading, retain its wording and classify the cause as unresolved. Certificate errors, a blocked integration and a missing payment field need evidence specific to the reported condition; changing a resource address without that evidence may not address it.

Build an inventory from the rendered checkout

Have the authorized maintainer inspect the browser’s existing request and diagnostic information while loading the affected real checkout page. No card entry or payment submission is needed to record a warning already present on page load. If it occurs later in an actual buyer journey, preserve the existing report and stage rather than asking the buyer to pay again to reproduce it.

For each observed insecure request, record the resource category, a sanitized address, the page on which it appeared and the browser’s reported result. Distinguish a request the browser reports as blocked from one it reports as loaded; do not infer either outcome from the address alone. Keep the original diagnostic evidence within authorized systems when it contains private information.

Trace the reference back to the component that introduced it. A resource can be included by page content, a theme, an extension or another integration. These are places to investigate, not established causes. Record the source file, setting or vendor confirmation that supports the ownership assignment. The host serving the resource and the component requesting it can have different owners.

Sanitize before copying evidence. Keep the scheme and only the host and path detail necessary to identify the resource. Remove credentials, query values, private payment-link tokens and customer-specific path segments. Do not attach raw network exports, cookies, request bodies or authorization headers to a public inquiry.

Correct the reference at its documented source

The owner’s next decision depends on what the inventory establishes. If a merchant-maintained reference points to an insecure resource and a supported secure endpoint is confirmed, the maintainer can propose correcting that reference. If an extension or external service generates it, send the sanitized evidence to that integration’s maintainer and ask for its supported correction. If ownership is unknown, trace the reference before assigning a configuration change.

Do not assume replacing the scheme in an address establishes a working secure endpoint. The proposed replacement needs to serve the intended resource securely and remain compatible with the actual integration. An unnecessary resource may be considered for removal only after the owner checks its dependencies and authorizes that change.

Do not weaken browser protections or disable a security policy to make a warning disappear. Stripe’s Content Security Policy instructions depend on the Stripe product in use; they are not one universal configuration for every checkout. A policy-blocked resource and an insecure transport request should remain separate findings when both appear.

Close the specific loading defect with observed evidence

After an authorized repair, revisit the affected page and step in the browser context that exposed the warning. Confirm that the intended resource is now requested and served securely, or that an approved removal eliminated its request. Also confirm that the visible checkout component still loads as intended. Record the observation date, the changed reference and any warning that remains.

A disappearing warning without a resource comparison is weak closure evidence: a broken component that stopped loading may also stop making the old request. Likewise, a corrected image does not establish that every other checkout resource was examined. State exactly which requests were checked and leave unexamined behavior open.

For a PRISM checkout-review consultation, provide the public page, platform, sanitized warning and the integration owner identified so far. Agree on review and implementation responsibilities before work begins. This investigation does not certify the merchant’s security or PCI compliance, prove the outcome of a payment, or establish provider approval for a research-only catalog.

Resource transport inventory

Use one copy per observed insecure resource and repeat it for additional requests. Fill the last column from actual browser evidence and maintainer records. A resource is resolved only when the approved correction and its observed loading result are connected; an unknown owner stays open.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.