#MaximG - test mode
1 messages · Page 1 of 1 (latest)
There should be a "copy to live mode" button on the product's page in your dashboard, but otherwise you are correct that we don't have much built-in functionality for copying/syncing products and prices between the two
Yeah, we're not trying to go from test to live. we want to go the other way.
Yeah unfortunately no built in button or API call to do that. The suggested way to do that would be making API calls to copy/update the products an prices between envs. You can even listen to live webhooks on those objects being update to do it
For #2 it really depends on what you want your staging environment to be. I'm not sure I fully follow your use case at the moment but am happy to walk through it and discuss what your end goal is here
Hrm...they don't currently create products and prices using the API. They manually create a product and pricing plan in Stripe (dashboard) and then manually enter corresponding info to plans created in the app to designate what content is associated with that plan.
That would be great
Gotcha. So the best way to sink that automatically would probably be to listen for the product.created, product.updated, price.created, etc events and then when you get them use the API as that account to create or update the product or price
That brings up the question of what to do if they manually edit things in the test mode dashboard themselves, but that would be a way to make sure that there is at least some syncing going on
Would that require using both sets of keys (production and test) in our staging environment? We'd be listening for the product.created in production (with prod keys) and then use the api (with test keys) to create the corresponding product (and customers, etc) in Test Mode?
(Thanks for you help on this, by the way. Really appreciate it.)
Yes, the environment that your calls happen in is decided by which keys you use.
What language are you using here? Some if not all of our client libraries support specifying the key you are using per-request, which you would likely need to use if you decide you want to write syncing code like that
ruby
thanks.
You might be able to get away with just listening with your prod endpoint secret and only making updates with your test mode key, but having the live key to look things up if need be would probably be helpful
okay. we'll dig into this and see if it's worth doing.
in the meantime, do you all have any general caution against sending webhooks from the live stripe account to a staging environment? Because stripe initiates all payments rather than the client-side, it doesn't seem like anything could go wrong just by virtue of sending the webhooks there.
This would let us not worry about getting the stripe test mode data synced.
Not as far as I know but that is because Stripe doesn't really have a concept of staging in this sense. Can you tell me more about what you want your staging environment to look like here?
Sure. It's basically identical to production most of the time unless there's a pending release of production-ready code that's waiting to be deployed for whatever reason.
They have a dev environment for the (non-technical) clients to poke around with well-tested code before it's declared ready to ship. And that dev environment is connected to an entirely separate stripe account (in test mode).
Ah gotcha, thanks for clarifying. No red flags immediately pop up to me.
The one thing I can think of is that certain actions in prod do depend on a response from the webhook endpoint. For example Invoices can wait for up to 72 for all of your webhook endpoints to respond to the corresponding invoice.created event. So if the staging endpoint is down that could delay invoice finalization. But assuming your endpoint is always up and responding that shouldn't be more of an issue than it is with any other endpoint that you have