How to Fix Stripe REST API Error: “No such price” / “Invalid Request”

by

If your store utilizes recurring billing, dynamic tier-pricing, or subscription-based services via the WooCommerce Stripe Gateway plugin, transactions require real-time synchronization between your local database product metadata and Stripe’s pricing engine dashboard.

When a user attempts a checkout transaction and the operation drops with an “Invalid Request: No such price” exception, the customer is barred from purchasing. Standard support teams often tell you to “re-sync your webhook endpoints” or “re-authenticate test mode keys,” which misses the mark. This error indicates a structural identity mismatch where your WooCommerce checkout request calls a cached, legacy, or deleted Stripe Pricing ID (price_...) that doesn’t exist on Stripe’s live billing server.

Below is the deep-tech cause of this synchronization disconnect and the exact procedural fixes to align your product IDs and restore transaction pipelines immediately.

The Error Snippet

When a payment processing run fails or an upgrade/downgrade order breaks on checkout, your WooCommerce logs under WooCommerce -> Status -> Logs (or your Stripe API Request Logs) will output this exact structure:

Plaintext

Stripe\Exception\InvalidRequestException: No such price: 'price_1OabcDE2fG3hI4jkL5mN6oPq'
in /wp-content/plugins/woocommerce-gateway-stripe/includes/abstracts/abstract-wc-stripe-payment-gateway.php:214
Stack trace:
#0 /wp-content/plugins/woocommerce-gateway-stripe/vendor/stripe/stripe-php/lib/ApiRequestor.php(523): Stripe\ApiRequestor::_specificAPIError()
#1 /wp-content/plugins/woocommerce-gateway-stripe/vendor/stripe/stripe-php/lib/ApiRequestor.php(164): Stripe\ApiRequestor->_requestRaw()

Why This Happens (The Real Technical Cause)

When processing automated recurring credit card transactions or tiered subscriptions, WooCommerce passes an explicit, unique alphanumeric metadata string—the Stripe Price token ID—via the REST API back to the payment engine processors.

This specific REST API exception triggers due to two common enterprise synchronization structural flaws:

  1. The Live-to-Test Sandbox Pipeline Leak: The site database was recently migrated, duplicated, or staged from a Test Mode environment to a Live Environment (or vice-versa). The localized database table records for the products contain old product string attributes generated in the development sandbox (price_... strings originating from the test keys). When the Live Stripe endpoint receives this token request, it naturally throws a 400 / 404 Invalid Request because that specific token hash string only exists inside the alternate sandbox partition.
  2. Manual Dashboard Asset Deletion: An store administrator went directly inside the Stripe.com Dashboard -> Products menu and manually deleted or re-created a subscription tier pricing matrix to adjust corporate pricing. WooCommerce, however, caches data blocks using localized transient database nodes. The storefront keeps passing the dead historical price ID string, leading to an immediate processing crash.

How to Fix It Safely (Step-by-Step Solutions)

Follow these technical procedures to clear out ghost token strings and re-align your product pricing architectures cleanly.

1.Purge Stale Product and Gateway Meta Transients:Step 1.

To force WooCommerce to stop utilizing stale cached Stripe API parameters, go to your WordPress Dashboard sidebar and navigate to WooCommerce -> Status -> Tools. Scroll down to find Clear WooCommerce transients and click the button. Next, scroll to Clear expired transients and execute it as well.

2.Force metadata synchronization inside the product panel:Step 2.

If the product is an individual subscription plan, navigate to Products -> All Products and open the affected item editor page. Scroll down to the Product Data schema box, toggle the pricing structure from subscription back to “Simple Product,” update the page, and then flip it back to “Subscription.” This operation forces the underlying post-meta arrays to completely clear out stale hidden fields like _stripe_price_id and regenerate new hashes on the next save loop.

3.Cleanse Database Post Meta Strings Directly via phpMyAdmin:Step 3.

If you have hundreds of products throwing this error across a massive catalog, manually changing tabs is inefficient. Log into your hosting panel’s database explorer (phpMyAdmin), open your target database, execute this targeted SQL query statement to locate and instantly wipe out any mismatched legacy Stripe Price attributes across your entire product mapping index:

SQL

DELETE FROM wp_postmeta WHERE meta_key IN ('_stripe_price_id', '_stripe_product_id', '_stripe_plan_id');

(Note: This safe metadata query does not delete your physical store items. It simply deletes the external API connector ties, forcing the Stripe plugin to seamlessly recreate matching, pristine pricing data blocks in the Stripe Dashboard upon the next purchase run).

4.Verify Token Alignment in Stripe Logs:Step 4.

To test the new data bridge configuration, place a test order. Go back to your Stripe Dashboard -> Developers -> Logs. Locate the newest POST /v1/payment_intents or POST /v1/subscriptions endpoint call line. Verify that the response status code returns an explicit 200 OK, and verify that the nested JSON payload lists the correct live environment price key matching your live dashboard profile context.

Pro-Tip for Live Recovery Control: If you are using advanced configuration extensions like WooCommerce Subscriptions alongside the base gateway, always ensure you have the “Stripe Product and Price Synchronization” setting checked inside your global API integration tabs. If a payment still trips, you can hook a custom shortcode handler in your system utility files to safely fallback to a regular transaction checkout routine if a remote model error fires:

PHP

add_filter( 'wc_stripe_use_order_pay_page_fallback', '__return_true' );

Leave a Comment