Stripe "No Such Payment Intent" in WooCommerce? Causes & Fix

Your Stripe logs are full of No such payment_intent: 'pi_…', or webhook signature verification failures, and orders are stalling. The PaymentIntent almost certainly exists. The credentials you're asking with just can't see it. Here's how to find the exact mismatch.

Last updated: 16 Jul 2026 · ~9 min read

What "no such payment_intent" actually means

Stripe objects are scoped to an account and a mode. A PaymentIntent created in test mode does not exist in live mode — they are two separate universes that happen to share an ID format. When you ask with the wrong key, Stripe doesn't say "wrong mode"; it says the object doesn't exist, because from that key's point of view it truly doesn't. The API returns resource_missing and a message naming the ID it couldn't find.

Webhook signature verification failures are the same disease with a different symptom. Each webhook endpoint has its own signing secret (whsec_…), and each is scoped to a mode. Point your store at a live endpoint's events while holding the test endpoint's secret and every delivery fails verification — Stripe's dashboard shows 400s, your store shows nothing, and orders sit unpaid. Same root cause: the credentials and the objects are from different places.

The most common causes (most likely first)

1. Test/live mode mismatch on the API keyThe PaymentIntent was created in one mode and you're querying with the other mode's key. Tell: take the pi_ from the log and search it in the Stripe dashboard — if it only appears with the test-data toggle on, but your store is using an sk_live_ key (or the reverse), that's it. This is the single most common version of this error.
2. The webhook signing secret is from the wrong endpoint or the wrong modeSignature verification fails with something like "no signatures found matching the expected signature for payload". Tell: Stripe Dashboard → Developers → Webhooks shows your endpoint returning 400 on every delivery. The whsec_ is per-endpoint and per-mode — copying the test endpoint's secret into live settings fails 100% of the time, not intermittently.
3. The keys now belong to a different Stripe accountThe store was migrated, sold, moved from an agency's account to the client's, or the keys were rotated against a different account. Tell: new orders work perfectly, but refunds and captures on older orders throw "no such payment_intent" — those intents live in an account your current key has never seen.
4. A restricted API key without the right permissionRestricted keys tend to report a missing resource rather than admit the object exists but is off-limits, so a permissions problem wears this error's face. Tell: the secret key in your Stripe settings starts rk_ rather than sk_, and the failures are total rather than order-specific.
5. The stored ID isn't a PaymentIntent at allOrders paid under the old Charges API, imported from another platform, or created by a customisation can carry an ID of the wrong type. Tell: read the ID in the error — a ch_, cs_, pm_ or seti_ being looked up as a PaymentIntent will never resolve, regardless of your keys.
6. The intent lives on a connected accountWith Stripe Connect, marketplace or multi-vendor setups, the PaymentIntent belongs to a connected account, and a platform-level request without that account's context finds nothing. Tell: you have a Connect-based marketplace plugin, and only vendor-related payments throw the error.

Where to look first

• Get the raw error first. Turn on Log debug messages in the Stripe gateway settings, then read WooCommerce → Status → Logs and pick the woocommerce-gateway-stripe log. Copy the exact ID it names.
• Search that ID in the Stripe dashboard and watch the test-data toggle. Visible only with test data on? Your store is using live keys against a test object (cause 1). Not visible in either mode? The intent belongs to another Stripe account entirely (cause 3).
• Read the ID's prefix. If it isn't pi_, no key change will help — you're looking up the wrong kind of object (cause 5).
• For signature failures, go to Stripe Dashboard → Developers → Webhooks and open the endpoint. Confirm it's in the same mode as your store, then reveal its signing secret and compare it character-for-character with the one in WooCommerce → Settings → Payments → Stripe. A 400 on every delivery is a secret mismatch, not a network problem (cause 2).
• Check the key format itself. sk_test_ and sk_live_ tell you the mode at a glance; an rk_ means a restricted key with a permission set worth checking (cause 4). Watch for a trailing space pasted in with the key.
• Cross-check the mode in one more place: the store's test-mode toggle, the API keys, and the webhook secret must all agree. Two out of three agreeing is exactly how this error survives a first round of fixing.

How to know you fixed it

Frequently asked