Payment signatures failed after a proxy changed request bodies
Preserve the actual verification error, affected endpoint and event references, the last known successful verification, and the timing and scope of the middleware change. Ask the implementer to establish what request body reached verification and whether the original raw body was preserved. Stripe requires the raw body and the endpoint signing secret; manipulating the body causes verification to fail. A failure after a deployment makes that change worth investigating, but does not prove it caused the failure. Keep signature checks enabled throughout the investigation.
For: A research-only merchant or operations lead whose payment notifications began failing signature verification after a proxy or middleware change.
Begin with a real delivery and the receiver’s matching error record. The provider’s delivery attempt shows which destination it tried, when it tried and the response it received. The receiver’s log must establish whether signature verification failed. A store order that did not update, by itself, does not locate the fault at verification.
Stripe distinguishes other delivery failures: redirects returning 3xx are failures, and access restrictions can produce 4xx responses. Record the actual response and the observed verification error separately. A rejected request at a proxy may never have reached the application’s verifier. If there is no matching application record, label verification as unconfirmed rather than assigning the error to request-body handling.
Identify the destination, provider account scope and relevant event types from the actual configuration. Use an internal endpoint name or sanitized route in the worksheet, without credentials or private query tokens. This keeps a failure on one destination from becoming a claim that every payment notification is broken.
Trace the body supplied to the verifier
Stripe’s signature verification depends on the raw request body and the endpoint signing secret. Its event documentation warns that manipulation of the body causes verification failure. This means apparently unchanged business values are not enough evidence that the verifier received the required raw body.
Ask the responsible implementer to trace the receiving path through the proxy, middleware and application’s verification step. The question is where the body is obtained, whether a layer changes it, and which component is responsible for preserving it until verification. Record any actual parsing or reconstruction identified in that trace; do not infer a transformation just because a proxy is present.
Keep the body and signing-secret values out of this worksheet and ordinary support messages. The record needed here is the finding, the component or configuration involved and the responsible owner. The implementer should confirm the endpoint’s signing-secret association separately without copying the secret. Correct body handling does not prove the secret matches, and a correct secret does not compensate for a changed body.
Compare deployment evidence with the failure window
Place the last known successful verification, the first known failure and the middleware deployment time on one timeline, retaining the time zones shown in the source records. Record which routes the deployment affected and whether the failing destination was among them. A missing earlier log is missing evidence, not proof that failures began exactly at deployment.
The change record should name what changed in the request path, not merely say that security or performance was improved. Compare the old and new handling descriptions where the actual release records permit it. An affected route, aligned timing and an identified body transformation together support a focused repair request. Timing alone supports investigation, not a confirmed cause.
If the trace shows the original body reaches verification unchanged, keep the failure open and examine the endpoint and signing-secret association with the implementer. If the request did not reach the verifier at all, route the issue to the owner of the observed delivery failure. Do not keep pursuing body mutation after the evidence points to a different stage.
Separate a repaired verifier from recovered orders
The repair request should preserve Stripe’s raw-body requirement and retain signature verification. Turning off verification removes the control being investigated; a successful response after that bypass is not evidence that verification was repaired. Confirm who is authorized to change the request path and what real receiver evidence will demonstrate the correction.
Keep affected event references as a separate reconciliation list. Stripe can deliver events more than once and out of generation order, and manually resending an event does not cancel automatic retries. This worksheet does not authorize a replay or a second payment. Recovery needs an authorized plan that checks the existing store and payment records before repeating downstream actions.
A 2xx response acknowledges endpoint delivery, not completion of order processing. After an authorized repair, record verification evidence and the associated order outcome separately; clearing the delivery error does not close every affected order. For a Prism checkout-review consultation, summarize the platform, middleware change and observed failure without sending raw payloads, signing secrets or customer logs. Scope, responsibilities, fees and terms for any investigation or implementation must be agreed before work. The public inquiry leads to email follow-up, not an incident-response commitment.
Request transformation trace
Use real delivery, receiver and release records for one affected endpoint. Record findings and internal references rather than request bodies or secrets. A suspected transformation remains unconfirmed until the request-path evidence identifies it.
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.
Request transformation trace. The last column is for temporary notes.
Trace item
Evidence to inspect
What it establishes
Your finding
Endpoint identity
Evidence to inspectConfigured destination, account scope and event selection, identified without private tokens.
What it establishesPins the failure to the receiving path actually involved.
Middleware change
Evidence to inspectRelease reference, affected routes, deployment time and documented request-handling change.
What it establishesIdentifies a candidate change; chronology alone does not prove cause.
Verification error
Evidence to inspectExact non-sensitive error wording, receiver time and matching delivery response.
What it establishesDistinguishes a verifier rejection from a request that never reached verification.
Raw-body handling owner
Evidence to inspectImplementer’s trace of where the body is obtained and whether it changes before verification.
What it establishesNames the component responsible for preserving the original body.
Signing-secret association
Evidence to inspectAuthorized implementer’s confirmation that the endpoint uses its corresponding secret; never the value.
What it establishesKeeps secret mismatch separate from body transformation.
Affected event references
Evidence to inspectInternal event references tied to delivery attempts and actual order records.
What it establishesDefines the reconciliation set without authorizing resend, charging or fulfillment.
Repair and remaining recovery
Evidence to inspectEvidence of verification after the authorized correction, plus each unresolved downstream outcome.
What it establishesA delivered notification and a completed order are separate closure conditions.
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.
Limits
These raw-body and delivery statements describe Stripe webhooks. Another provider or integration needs its own verification contract.
Do not disable signature checks, open broad firewall access, replay events or repeat payments on the strength of this worksheet.
Do not paste raw payloads, signature headers, signing secrets, API credentials, private endpoint tokens or customer records into the worksheet or public form.
Stripe event delivery and verification — checked 2026-09-29. Stripe requires the raw request body and endpoint signing secret for verification; manipulation causes verification failure. Delivery responses, duplicate and out-of-order events, and retry behavior are distinct from downstream order completion. A 2xx acknowledgment does not prove order processing finished.
Prism solutions — checked 2026-09-21. Prism publishes storefront review, processing preparation and help with provider website questions. Any requested technical investigation or implementation requires an agreed scope, fees and terms; provider eligibility stays with the provider.
Prism contact — checked 2026-09-21. The public form asks for the website, products and question, excludes card details, passwords and customer records, and leads to email follow-up rather than a booked service or processing application.