FixesStripe errors and fixes
Webhooks that fail or don’t update your database, subscriptions and access, Checkout, the customer portal, Apple Pay and Google Pay, and test versus live mode. Each page is checked against Stripe’s own docs and says what to try first.
12 Stripe fixes. Also see Payments and integrations.
- Stripe webhook errorNo signatures found matching the expected signature for payloadUsually it’s the wrong signing secret. Each endpoint has its own, the Stripe CLI prints a different one, and the same endpoint has a different secret for test and live keys. Next most likely: your framework parsed or changed the request body before the signature check ran.
- Stripe fulfillment bugThe payment went through in Stripe, but the account was never upgradedMost often, the upgrade only runs on the success page after checkout. Stripe says you can’t rely on that page, because customers don’t always reach it. Grant access from a webhook instead, and check the webhook’s delivery log in the Dashboard for failed deliveries.
- Stripe Billing errorWhy is my Stripe subscription stuck as incomplete?A new subscription stays incomplete until its first invoice is paid, and the customer has 23 hours. If the PaymentIntent says requires_action, the card needs authentication: listen for invoice.payment_action_required, send the customer through it with stripe.handleNextAction, and give access only after invoice.paid or an active subscription. After 23 hours it becomes incomplete_expired and you need a new subscription.
- Stripe payment errorWhy does Stripe say the card was declined with generic_decline?Stripe’s docs say card issuers categorize most declines as generic, so the exact decline reason is often unclear. Check the payment in the Dashboard: if Radar blocked it, the outcome type is blocked and you can allow-list a legitimate payment; if the issuer declined it, read the decline code and the advice code, ask the customer to re-enter the card or use another one, and don’t keep retrying a charge the advice code says not to.
- Stripe BillingStripe subscription canceled, but access in the app is wrongWhen a customer cancels at period end, the subscription runs on until the period ends, cancel_at_period_end becomes true, and Stripe sends customer.subscription.updated. Access should continue until the period ends. When it ends, Stripe sends customer.subscription.deleted: that’s the event that should remove access. Removing access on the update cuts people off early; ignoring the deleted event never removes it.
- Stripe BillingThe Stripe customer portal isn’t workingSave the portal settings in the Dashboard for live mode as well as sandboxes, since each has its own. Create a new portal session on your server each time a signed-in customer clicks the button, because session links are short-lived, and pass a return_url unless a default is set. Then listen to subscription webhooks so the app follows what customers change.
- Stripe API errorNo such customer: ‘cus_…’; a similar object exists in test mode, but a live mode key was used to make this requestStripe keeps test and live data apart: an ID created with test keys doesn’t exist in live mode. Your database still holds customer IDs saved during testing, and the app now calls Stripe with live keys. Create a new live customer for each user whose saved ID came from testing, and make sure every server and environment uses keys from the same mode.
- Stripe Billing errorStripe: “This customer has no attached payment source or default payment method”For a subscription invoice, Stripe uses the subscription’s default_payment_method; if that isn’t set, it uses the customer’s invoice_settings.default_payment_method or default_source. The error means none of them gave it a payment method to charge. Set the card as the customer’s invoice_settings.default_payment_method, and for new subscriptions set payment_settings.save_default_payment_method to on_subscription.
- Stripe go-live problemStripe checkout works in test mode but fails in live modeTest mode (Stripe now calls it a sandbox) and live mode have separate API keys, products, prices, customers and webhook endpoints, and nothing created in one exists in the other. Put the live keys in your production app’s settings, recreate your products and prices in live mode and switch their IDs in your code, add a live webhook endpoint with its own signing secret, then redeploy.
- Stripe webhook problemStripe shows the webhook delivered, but my database never updatedA 200 only means your endpoint received the event. Stripe asks you to answer quickly, before the slow work, so if the database write fails after that, Stripe still records a successful delivery and has nothing to retry. Your own server logs hold the error. Check them first, then the event types your endpoint receives, repeated or out-of-order events, and the database key your handler writes with.
- Stripe Connect errorStripe Connect: the seller finished onboarding, but charges or payouts are still disabledComing back to your return URL doesn’t mean onboarding is complete. Retrieve the account and read its requirements: as long as requirements.currently_due isn’t empty, it can be restricted. Send the seller back through a new Account Link when anything is due, create a fresh link from your refresh URL when one expires, and listen to account.updated so new requirements don’t surprise you.
- Stripe payments problemStripe: Apple Pay or Google Pay doesn’t show in the payment formRegister every domain and subdomain that shows the payment form on the Payment method domains page, in live mode as well as each sandbox. If the form sits in an iframe, register both domains. Then confirm the wallets are on in your Payment Method Configurations, and test on a device with a real card in the wallet, outside a private window.
Looking for another platform? See every fix.
A different Stripe error?
Describe it and get a written quote
Send the error and what you were doing. You get a written scope, a fixed price and a timeline; we reply by email, usually within one business day.