Trace callback failures after a signing-secret change

Identify the direction of the failed request

Checkout and notifications can fail independently. The store makes API requests to the payment service, while Stripe sends webhook requests back to a registered endpoint. Stripe’s webhook documentation describes checking those incoming requests with the endpoint signing secret. The API-key documentation describes separate publishable, secret and restricted API keys. Replacing a checkout API key is not evidence that the endpoint now has the correct signing secret.

Use a genuine provider delivery record and the receiver’s redacted verification error to locate the failure. If incoming signature verification failed, investigate that path. If the recorded error belongs to an outgoing API request, give the implementer that separate request reference and category. A customer-facing checkout error alone cannot identify either credential problem. If both paths changed at the same time, preserve both observations rather than combining them into one guessed cause.

Tie the rotation to one endpoint and one deployment

Stripe’s recorded webhook instructions describe a unique signing secret for each endpoint, with different secrets for test and live use even when the endpoint URL is shared. Identify the actual destination and account context affected by the incident. Record only the endpoint’s non-secret identity and environment label; no secret value is needed in the incident record.

The same instructions allow an endpoint secret to be rolled with immediate expiration or delayed expiration of the old secret. During a chosen overlap, more than one secret is active. Ask the authorized implementer to compare the recorded rotation time, any chosen expiration time and the time the running receiver adopted its configuration. Record the time zone for each. An overlap that has ended can make a stale receiver fail, but the timeline must establish that this is what happened in your installation.

A change recorded in a settings file is not enough to establish what the active receiver loaded. Have the implementer identify the deployed configuration reference and confirm the match within its authorized credential system. Your worksheet needs the result of that comparison and its owner, not a pasted key, a partial secret or a screenshot of a revealed credential.

A signature error still has more than one possible explanation

Stripe requires the raw request body for signature verification. Its documentation warns that changing that body causes verification failure. An endpoint may therefore reject a notification even when its secret is correct. Ask whether the deployment around the rotation also changed the framework, request parsing or a proxy that handles the body. This is a targeted check for the implementer, not proof that such a change occurred.

Keep transport errors distinct from verification errors. Stripe treats redirects as delivery failures, and access restrictions can produce 4xx responses. A 4xx status by itself does not establish a signing-secret mismatch: the request may have been rejected before the verification code ran. Pair the provider’s delivery attempt with the receiver’s matching error category and time. If the receiver has no matching record, record that absence and investigate the path to it.

When an incoming event verifies successfully but the order remains unchanged, the remaining question is downstream processing. Stripe documents quick acknowledgment and asynchronous work, so a successful 2xx delivery does not prove the order update completed. Preserve that distinction when deciding whether the credential repair closed the observed incident.

Hand off facts while keeping credential access controlled

The useful handoff names the endpoint, credential type changed, change times, first observed failing delivery, redacted verification category and authorized implementer. Stripe says secret and restricted API keys must not be shared through email or chat. Keep webhook signing secrets out of the same handoff. The implementer should inspect the actual values through the business’s authorized access process and report whether they match.

Once the owner has repaired and verified the affected path, separately reconcile notifications missed during the incident. Do not assume a new successful delivery updates the backlog. If you need a Prism checkout consultation, summarize the platform, timing and unresolved symptom using the website, research-only products and question. Confirm the requested investigation or implementation scope, responsibilities, fees and terms before work. Public inquiries receive email follow-up; they do not authorize a repair, book an appointment, buy a service or submit a processing application.

Credential-change symptom map

Complete this from actual change records and matching delivery logs. Keep raw payloads, signature headers, customer records and all secret values in their authorized systems. The outcome is an owner and a specific check, not a diagnosis based only on timing.

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.