A place to discuss charging merchants for your apps and services using the billing API.
I've gone through the "Ways To Build" reference and still can't determine which approach to use for a solution I'm considering. Let's say I own a web app or SaaS that displays email data. I'd like to use an email address to fetch customer data and any related orders for that user (via REST or GraphQL) in a specific Shopify merchant's store (e.g. my app's logged in user is also a Shopify merchant that has authorized my solution to access their store data when they first acquire an account with my app). I may also need to issue refunds or cancel orders for a particular merchant's customer.
Channels seem specific to making purchases via the API, so I assume I can rule that out. My solution doesn't need to integrate with the Shopify admin UI, so does that rule out a Public App (and App Bridges?)? Private apps are restricted to a single store or a known group of stores/clients - but what if my web app's users are dynamic?
Solved! Go to the solution
This is an accepted solution.
Installation with Shopify is easy. After all, there really is nothing more than you requesting scopes, and if they merchant replies YES to them, you get a token. Once that is completed, you have a shop name, and a token. The rest is up to you. You decide what these mystery features are. They don't get installed in the App so much as you enable them, and if you can and want, you bill for them. oAuth itself has nothing to do with that, because you asked for the scopes you need in advance.
So for all your "special needs" where you are keeping track of add-ins, add-ons, whatever you choose to call it, that is up to you to manage as you see fit, and has nothing (or little) to do with actual Shopify App Installation. Your abstract needs are met with your clever coding, and ability to juggle making those features accessible. Merchants will of course not be thrilled if your implementation is amateur hour, complex, buggy or hard to fathom, so best you keep it simple.
The billing API has come a long way, allowing you to charge for just about any scenario you can dream up and deliver. So again, make a public App, square away your installs with a token, and move into your world of custom addons as you see fit.
You are going to want to build out a public App. Shopify merchants will install it and authorize that App to access customer data and order data. You are correct in thinking you are not wanting to be a Sales Channel. You are not. So go with public App, and then you can choose how to render the value in your App, and make merchants happy.
Thanks HunkyBill! The installation part remains a bit confusing. Let's say my web app supports third-party "add-ins", and I want to develop this as an add-in. My add-in acquisition process would use Shopify's OAuth process to allow the user to authorize the add-in to access their Shopify store via my Shopify app/integration. Would this authorization process - associated with my Shopify app's registration for OAuth - then "install" my Shopify integration into their store? Or would that be a separate process they would have to go through before they can use the add-in to grant access to my app?
This is an accepted solution.
Installation with Shopify is easy. After all, there really is nothing more than you requesting scopes, and if they merchant replies YES to them, you get a token. Once that is completed, you have a shop name, and a token. The rest is up to you. You decide what these mystery features are. They don't get installed in the App so much as you enable them, and if you can and want, you bill for them. oAuth itself has nothing to do with that, because you asked for the scopes you need in advance.
So for all your "special needs" where you are keeping track of add-ins, add-ons, whatever you choose to call it, that is up to you to manage as you see fit, and has nothing (or little) to do with actual Shopify App Installation. Your abstract needs are met with your clever coding, and ability to juggle making those features accessible. Merchants will of course not be thrilled if your implementation is amateur hour, complex, buggy or hard to fathom, so best you keep it simple.
The billing API has come a long way, allowing you to charge for just about any scenario you can dream up and deliver. So again, make a public App, square away your installs with a token, and move into your world of custom addons as you see fit.
Ah - perfect, I was hoping it was like that! I'm on my way, thanks again HunkyBill!