A secret payment key appeared in public checkout code

Classify the credential without trying it

A string in checkout code is not automatically a leaked secret. Stripe documents a publishable key for front-end use and states that it cannot create charges or read account data. Secret keys have unrestricted permissions; restricted keys are also not safe to expose. A restricted key’s limited permissions do not make it a publishable key.

Ask the account owner to identify the key from the provider’s own credential record and the integration configuration. Record the class, the relevant account or integration by a safe internal label, and whether the owner has confirmed the match. Do not test the suspected key by making payment requests. If classification is still unknown, keep the possible exposure open rather than declaring it harmless from the variable name in the code.

Preserve the location, not another copy of the secret

Record the public page or asset path, the deployed version if known, the first observed time with its time zone, and how the value became visible. A location and a time let an authorized maintainer find the affected release without circulating the credential. Omit query parameters or fragments that themselves contain private tokens. Do not attach an unredacted code excerpt, screenshot, or network export to an ordinary support message.

First observed is the time your team discovered the exposure. It does not establish when the credential first became public or whether anyone used it. Keep the suspected exposure period separate from the period that deployment records actually establish. If the security owner needs fuller evidence, let that owner arrange its controlled preservation; the worksheet below is only an index.

Give containment and code repair named owners

The payment-account owner should arrange prompt invalidation or replacement of a confirmed exposed secret through the provider’s documented process, with the authorized maintainer accounting for integrations that depend on it. The maintainer should remove the secret from publicly delivered code and identify why it was included. Do not put the replacement into the same public configuration. This is a recommended division of responsibilities, not a sequence of account buttons or permission for a reader to change an account they do not control.

Keep two completion records: what happened to the exposed credential in the provider account, and which corrected release stopped distributing it. Deleting a file does not undo a copy already retrieved. Replacing a credential does not by itself correct the build or configuration that published it. The account owner and maintainer need to reconcile both records, including any affected checkout dependency, before they describe the exposure as contained.

Separate exposure, observed activity, and the next consultation

The authorized security or account owner can compare available provider activity with the exposure period and the business’s legitimate activity. Record confirmed findings, records unavailable for review, and unresolved questions separately. Discovery of a key alone does not prove an unauthorized charge, loss, or access to customer records; absence of a finding in an incomplete review does not prove none occurred.

For a Prism checkout consultation, describe the affected public surface, the confirmed credential class, and the integration question after the responsible owners have been notified. The related checkout-review service explains how to scope help. Keep the credential and incident evidence out of the public form. Any requested technical or incident assistance needs an agreed scope, responsibilities, fees, and terms; a consultation is not an incident-response commitment or provider approval.

Credential exposure record

Complete this as a private incident index using real observations. Never enter a key value, even a replacement value, or attach secret-bearing code. Unknown classification or containment remains open; a confirmed publishable key alone does not establish a secret-key exposure.

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.