I am wondering if there are best practices or recommended methods for charging for a subscription to a Stripe App.
I see a couple of options:
- I don’t think I can use a pricing table inside my settings page. I could do this on a separately hosted site, but would need to collect stripe account IDs manually?
- I could collect payment details inside my settings page and create a subscription via the API?
What would you suggest?
1 Like
Thanks for the question Dan,
Unfortunately, as of today, we don’t support charging for your Stripe app from within Stripe directly.
- Correct, you wouldn’t be able to use pricing table from within your app settings page. Today, most apps do what you mentioned and host their own separate site (you could use something like Stripe hosted checkout) and you wouldn’t need to collect the account ID manually.
- Unfortunately that isn’t supported today.
That said, making it easy to charge for your app within Stripe is on our roadmap, a couple questions:
- Is this for a new or already existing app, and what is the pricing model?
- If it’s a new app, what is the app and what will it do?
Thanks for getting back to me!
This is for a new app.
I wanted a project to understand the Stripe App ecosystem. Simple enough to make progress in relatively short order, but with sufficient complexity to find the rough edges, and hopefully publishable to the Marketplace to see what the installation/conversion rates look like in the real world.
The app is a marketing platform/CDP integration:
- An end user adds the app to their Stripe account
- Goes through an OAuth flow with the marketing platform
- Selects Stripe Events they want passed through to the marketing platform
- A simple server receives events, parses out important fields and sends them to the marketing platform’s event API
If I see traction, I’ve got some other Stripe App projects I want to explore further! (But always looking for inspiration!)
Stripe Hosted Checkout looks interesting. To double check, would I need to collect the account ID manually, or is there a way to pass an account ID into the hosted checkout somehow (e.g. via a URL parameter if I link from the app settings page)
I added my vote for this feature. We have a published app in the Marketplace. We’ve introduced it as a free-trial app while we implement our billing dashboard for our customers. I can see how this could be a tricky feature to implement for the Stripe Apps team since payment strategies for Stripe Apps Authors would be as diverse as the author’s offerings. For example, in our App, Parcelcraft Shipping, we want to offer free trial where users can ship their first 25 shipments free. After the free trial ends, users have the option to pay per shipment or per month. I can see this working for Apps if the Stripe Apps team were to allow Stripe Payment Elements as part of the allowed components that can be used in Stripe Apps. That said, I think this can be just as easily accomplished using an off-dashboard custom solution, and an off-dashboard solution may be more appropriate so the payment strategy can be tightly customized to the use-case of the app.
3 Likes
To add a bit more depth to this conversation from the Apps team…
We fully encourage the use of Stripe Billing (subscriptions) or Stripe Checkout for taking payment for the useful functionality apps provide to users.
While the technical complexities of encompassing all the different potential developer business models in a native apps billing package are significant, that’s actually not the reason for the current limitations. The specific requirements around beginning the transaction from your own site exist because of regulatory compliance considerations across numerous markets around the world.
We are planning to support native monetization of apps in the Marketplace in the future, and getting these kinds of asks obviously helps us prioritize that in our roadmap.
On a technical level, the shortest path to setting up your own monetization strategy today is to add Stripe Billing to your website. You can create pricing plans, feature comparison tables, etc. and walk users through the checkout flow. When you the user completes the payment process, you’ll get an event that you can then associate with their account on your end.
Whether or not the merchant’s account ID is necessary for you depends on which auth type you choose for your app:
-
If you use the default “platform” auth type, then you get a webhook notification every time a merchant installs your app containing their account ID, and you use that account ID + your platform key to make authorized requests on behalf of that account.
-
If you use OAuth, the account ID is generally not necessary. You’ll send the access token with the request, and the token is scoped to the correct merchant account, so you don’t need to specify the account ID.
-
If you use restricted API keys (RAKs) you just send the RAK with the request, which is again scoped to the correct Stripe account.
Putting all that together, the flow would generally go like this:
- A merchant installs your app.
- You receive a webhook notification with the details of the install (including the account ID if you need it).
- The merchant is guided to sign up/sign in to your service, and you associate their account on your end with the appropriate auth material (account ID, OAuth token, or RAK).
- You begin the billing checkout flow, and when the flow is completed you associate that payment or subscription with the merchant’s account on your end.
One final note: if your app needs to make API calls from a UI Extension in the Stripe Dashboard to your own service, you’ll also need something like an OAuth flow to provide the UI Extension with credentials to make those API calls, which can be another place to link the two accounts in your system if it’s helpful to you.
Lots of info there, hopefully it’s helpful.
2 Likes
Continuing the discussion from Billing for Stripe Apps: