Stripe payment succeeds but access stays locked

1. Confirm account and mode.

   In Stripe Dashboard, locate the existing payment in the correct account and environment. Compare the deployed key types locally: pk_test_ and sk_test_ belong to test mode; pk_live_ and sk_live_ belong to live mode. Never copy the secret value into the browser to test it.

2. Open the matching delivery attempt.

   Go to Workbench, Webhooks, select the destination for your app and open the relevant event. Read the delivery status, attempt time, destination URL and HTTP response. A payment in one mode does not prove an endpoint configured for another mode received it.

3. Check the signature inputs.

   For a failed verification, compare the endpoint’s signing secret with the server environment setting. Dashboard endpoints and Stripe CLI forwarding use different secrets. Inspect the handler to confirm it verifies the raw request body with the Stripe-Signature header and that endpoint’s secret.

4. Trace fulfillment after verification.

   If delivery reached the app, inspect its server log at the recorded attempt time. Match the event to the intended order and customer, then read the resulting entitlement in your own database. A successful HTTP reply is not evidence that the purchase was granted.

WORKSA verified Stripe event gives the correct customer the intended access exactly once.

BROKENThe event fails verification, reaches the wrong destination or produces no correct entitlement.

Ranked in the order to investigate, not by claimed frequency.

1. Test and live configuration are mixed.

   Keep each environment’s keys, products and event destination aligned. Correct the mismatched configuration on the server, deploy it, and repeat a test transaction using only the matching test setup.

2. Webhook signature verification uses the wrong input.

   Use the signing secret for that exact destination and preserve the unmodified request body for verification. Do not parse and reserialize JSON before verifying it. Keep signature verification enabled.

3. The handler acknowledges without durable fulfillment.

   Record the processed event and apply the entitlement reliably to the correct customer. Handle repeated deliveries without granting twice. Reconcile the existing payment after the handler is repaired instead of creating another charge.

• Stripe can deliver events more than once and does not guarantee their ordering. Fulfillment must tolerate repeats and should use the provider’s current object state when ordering matters.
• Some payment methods finish asynchronously. Choose the documented events for your payment flow; do not treat every completed browser redirect as settled payment.

When to stop and hand it over

Escalate real charges with missing or duplicated access, any exposed sk_ credential, or a handler that cannot verify signatures. Give the repairer payment and event ids plus a redacted delivery response. Keep the signing secret and customer payment details private.