I am currently setting up a new product line for my company. Basically it is a micro SaaS offering within our main product features. I’ve created a subscription funnel, very simple and at the end I have the stripe integration to handle the subscription.
I am having a hard time testing this on staging.
Here is what I tried
Using test price_ids from stripe:
I create the payment intent (using the test mode product_ids from stripe)
I add the test card details (42424 etc.)
I confirm the payment
Upon confirmation I get an error from stripe saying "No such price: 'price_XXXXXXXX'; a similar object exists in test mode, but a live mode key was used to make this request."
Using live price_ids
I create the payment intent (using the test mode product_ids from stripe)
I add the test card details (42424 etc.)
I confirm the payment
Upon confirmation I get an error from stripe saying Your card was declined. Your request was in live mode, but used a known test card.
So it appears to me that I have an issue with the staging environment not taking the test API keys.
How would you handle it?
I thought of using a deployment variable, but I am having a hard time finding the stripe test API keys.
Just to confirm: are you having trouble testing Stripe in preview mode when you’re working in the WeWeb editor or on a project that you published in WeWeb on the staging environment?
The test keys are used when you’re working in the WeWeb Editor.
When you publish your app, whether you publish it to the staging environment or promote it to production, the production keys are used.
If you wish to continue using the test keys on a published app, you can add the test keys in the 2 fields normally reserved for the production keys in the Stripe plugin.
Hi @Joyce thank you for the answer, initially I wanted to test on staging using the test keys from stripe. But indeed I’ll update the production key in weweb with the test keys from Stripe.
@Joyce This is a real limitation for us. It seems there is no way to use the Stripe plugin in both Staging and Production at the same time. We use test data in Staging, so therefore we need to use the test Stripe keys in Staging. But if I do that, Production breaks. In fact, you dont even need to publish a new version of the app for the plugin key changes to take effect:
How can I get Staging to use test keys and Production to use live keys at the same time please?
Agreed, i was about to create a support ticket on this, but definetely agree, production stripe keys should only work on production, and stripe test keys should work on both editor and staging.
Or for those that have the staging feature, have a toggle button that let’s users choose whether they they would like staging to use production Stripe Keys or test Stripe keys.
Thanks for adding this to your development roadmap. This has also become a critical limitation now that our client’s WeWeb application is going live in production and we need a way to continue sharing staging test links with them which use Stripe’s test mode.
Given your team have published the GitHub - weweb-assets/plugin-stripe repository we are considering forking this to improve the live mode / test mode handling as a stop-gap whilst we wait for this feature to be officially released.
Unfortunately the published client-side code is calling serverside endpoints such as POST .../designs/${websiteId}/stripe/create-payment-intent which do not appear to be part of this repo.
Is the source code for these Stripe plugin endpoints published anywhere and is it possible for us to fork this code for the purpose of using this as a custom plugin?
Same problem for me : my staging points to the test branch on my xano backend, which creates mistmatches because the test branch uses a test key. It would be really great if I could use test keys to test my app with the staging and not break production to do so !
Hello everyone, I think many of you could benefit from doing this by using a Chrome Extension. The setup is very simple and I explain it in this topic (for Supabase) [Supabase] Switch between Production and Staging in one click, at the end of the day, it’s the same principle, just with a different API call.