I’m looking for advice on how to set up my backend for a Stripe App.
I’ll want to test my app in both test and live mode. I also want a dev and production version of my app backend.
Is the best practice to support both test and live modes in dev and production?
And then my development process would include uploading test versions of my app which point to my dev API endpoints, and once I’m satisfied with my testing upload a new version of my app which points to my prod backend?
Hi @dan.massey,
That’s a really good question, and the Stripe Apps docs are pretty light on best practices in this regard. We’ve started an internal thread to put together some new guides on this topic, and we’ll share out something more in depth with you here in the next day or two.
In the meantime, I can speak to some very basic answers to your questions:
Supporting both live and test mode is not only a best practice, but basically an expected behavior for Stripe Apps going forward. Doing this in both dev and prod is certainly a best practice, though we are working towards minimizing the differences between modes for developers as part of our overall testing improvements. Testing both modes in your dev backend ensures that both modes will be supported when you do publish your app and use your prod backend.
The aim is generally not to need you to upload different version of your app for dev vs. prod. In many cases, you can use the constants field in the app manifest file to help manage things like different sets of endpoints. Check out the app manifest docs for more about that. You can also add multiple endpoints to your content_security_policy, for example. I don’t think we’ve fully nailed this story yet, and we’ll keep improving it based on your feedback.
Thanks @gabrielhurley_stripe that’s definitely helpful info!
To give you one quick bit of feedback as I’m working through this: Being able to run a local version of an app with a development manifest using stripe apps start --manifest stripe-app.dev.json is great.
On my wishlist is similar support for extending manifest files for stripe apps upload.
How I envisage using this:
stripe-app.json manifest, where I would set the next version I plan to releasestripe-app.qa.json file that had different endpoints specified in the CSP/constants objects, as well as a different version number. Ideally, I would be able to inherit the prod version number from stripe-app.json and append, say, -qaI would then be able to release a QA version of my App which I could use for external testing, against the dev version of my backend in both test and live modes. Assuming my testing was successful, I would then be able to “promote” the QA app and matching backend to prod.
I feel your pain. This issue cost me 6 months of personal development hell. I’m the developer of the Parcelcraft Shipping App, now publically available in the Stripe Apps Marketplace. To save simple user settings, we had to go through a LOT of development. We are saving user settings to a Supabase database, cached by a Redis server for high-availability on a Digital Ocean server backed by a fail-back. These are not natural choices directed by the Stripe Apps team, but I’m happy to share my back-end code to share how we accommodate test and live environments. Please contact me at benson@parcelcraft.com. We’re have been considering open-sourcing our code for some time now and we’d love to share our discoveries.