More info on PvA & PvV payment models


I currently have a Jira cloud app hosted on Atlassian Marketplace and it’s currently a Free app.

I wish to start payment via Atlassian Marketplace. I believe I will have to convert my free app into a PvA app as per the documentation here:

I also have an independent SaaS offering which tightly integrates with my free Jira App currently. I do allow paid subscription to my both SaaS product & Jira app - through my SaaS billing platform currently.

My query:

1) If I wish to launch payment on Atlassian Marketplace for my Jira App (which will enable access for my SaaS product as well), can I use one single PvA app to serve both the below set of customers? -

i) the ones completing billing via Atlassian Marketplace
ii) and the ones purchasing subscription from my SaaS platform (for both SaaS & Jira App)

If answer to 1 is YES -

2) Is there any API support from Atlassian or some other mechanism through which I can enable access to my PvA app even though customer is not completing payment on Atlassian platform?

3) If a single app cannot serve both the above use cases, is it recommended to keep 2 separate apps - one for my PvA customers and another for PvV customers?

If answer to 3 is YES -

4 a) My both apps will exactly be the same to start with - is that not a problem for Atlassian marketplace - what impact will it have in app discovery when I try to search my app in marketplace or on Google?

4 b) Are there any successful app examples that I can refer to where companies are operating dual apps for catering to both PvA & PvV use cases?


Just checking if someone could please help here. Thanks.

Welcome to the Atlassian developer community @BrowserStack,

There’s more here than I can credibly answer. However, I think I can answer your first question which will help collapse some of your uncertainty in the others.

The short answer is “no”.

Atlassian Marketplace is a very poor fit for “the ones purchasing subscription from my SaaS platform”. In my experience, the key Marketplace constraint that causes this is the concept of “licensing based on host product”. That makes sense for Forge/Connect apps where the user management is the underlying Jira; there are no users except the users of the host product. That doesn’t make sense for a SaaS product with an existing sign-up flow and no effective way to “bind” that flow to only Jira users.

To be clear, that’s more business constraint than technical. For example, you could decide that it’s fine if your PvA customers get free users & resources on your SaaS platform, and let them all pay based on Jira users. But the ability to exploit that model seems so apparent that I don’t know who would. And even if more business than technical, there is still a technical matter of making sure the SaaS platform’s licensing logic can reach an Atlassian product through an app. The license mechanisms only work within Connect or Forge auth contexts.

The workaround I’d suggest:

  1. Rename current free app to “BrowserStack Lite”, create new app “BrowserStack Pro”.
  2. Start a monorepo that serves both apps from the same deployment.
  3. What you do is ping /rest/atlassian-connect/1/addons/${addonKey} for both apps to determine if they’re installed and license status. Using that boolean you enable/disable features.

Tell users when they install Pro, not to uninstall Lite. Because they’ll both work interchangeably without any modules disappearing. ie if Pro is installed and licensed, Lite will have the full features of Pro.

1 Like