I am a product manager working on the Forge billing flows. As you all know Forge app developers will start getting charged from Jan 1st 2026 once they cross the free tier. I will be posting a detailed RFC on how we will go about the mechanism in the coming weeks and get your feedback. There will also be finalised pricing announcement soon. However, I am seeking inputs from the community on two questions to start with
Consider the example where company ABC has 2 apps and is having the below consumption for a month. Note: Below are not the final prices and are only used for explanation.
Which of the following invoice structure would you prefer to see considering all the necessary drill down analysis will be provided for app developers on the console and why ? The third option is basically aggregating the charge elements even further into groups. Also, please feel free to share the kind of drill down analysis you would expect to see on console.
Would your team or company be okay with associating all of its app costs with one credit card, or would your team want to create multiple invoice groups, such as having multiple cards associated with different sets of apps and receiving separate invoices for different app sets? Is there a use case where your company (similar to vendor profile on marketplace) wants to have multiple invoice groups?
I am sure the community would have a lot of questions on the entire process. We assure the community that we will get back with a detailed RFC soon, but if the community can share thoughts on these 2 questions in this post, it will be valuable for the RFC that will be published soon.
On the invoice, we’d prefer to see option 1.
Different apps, different budgets and teams. So cost should be split out by app.
However we would also need all of the data in the first graphic in order to use the data in e.g. cost optimization. These data should be available e.g. through the API.
It should be a combination of option 1 and option 2. Page 1 should be the summary, and there should be a copy of page 2 for every app. (Extra PDF pages are free, right?)
I’ll let other people respond to the question of how many credit cards, but I would say this: it is only fair that the billing date for Forge usage is aligned with the Atlassian Marketplace share payout dates for the same periods.
So, if Atlassian is going to pay vendors for January app usage on February 21, then the Forge usage for January should not be billed any earlier than Februrary 21 either. It is, however, also essential to be able to see month-to-date usage in the portal in near-real time fashion (such as up to the previous day’s usage as a minimum), to be able to be reactive to cost overruns.
Also, I think it is probably an error to only permit credit card payments, versus also allowing for a deduction from app revenues, or else generating invoices for vendors to pay. If apps generate (say) $10,000 or $30,000 or more in charges in a month, it is not realistic to assume that all such vendors will necessarily have (or even be able to get) a credit card with a sufficiently-high limit.
Hi everyone, thanks for the feedback. Please keep it coming.
To start with, we are planning to implement credit card and PayPal which would be a consistent approach for all. The marketplace revenue cut strategy wouldn’t work for all, as there are partners with all free apps, and we would still need to charge for additional usage beyond the free tier; costs can at times go beyond revenue generated. We have the user story to explore multiple payment options, there are different custom cases that we would have to account for, we will keep the community posted on our strategy.
Finally, what happens if the card is declined?
We are working on it and will share our approach in the RFC.
As a vendor, I would expect to be able to set a maximum spend per app.
It would be unreasonable to be forced to have no spending limit, and be hit with a charge of e.g. $10000 for a free or low revenue app.
W.r.t. to payment, credit card payments are quite fragile in our experience, at least internationally. While we pay most of our bills with credit card, sometimes the payments get rejected without us knowing why.
Having the option to pay by bank transfer would help a lot.
However I would not know how our business would pay with paypal at all, as our business has no paypal account and probably never will have one / be eligible for one.
I am admittedly shocked about the PayPal direction: this is a company that was renowned for requiring people to link their bank accounts via electronic debit to even be able to do business with them, automatically siphoning money from said accounts whenever they deem it appropriate (seemingly at their sole discretion), having an opaque dispute resolution process, closing accounts with little to no effective recourse, and making it difficult or impossible to ever speak with an actual human being.
I will never do business with PayPal and I cannot fathom ever wanting to link anything even slightly business-critical to their services. This is a question of not just principles, but also risk.
Atlassian already has a department for handling accounts receivable from global customers. Could Atlassian please consider just leveraging this as an option for Forge billing and using it to generate invoices, just like you do for customers? It would probably be reasonable if you only were to offer this option for average monthly bills of (say) over $1k, and force the rest to pay by card.
thanks for sharing and involving the community early on.
Invoice Structure
We prefer Option 1, as a per-app breakdown is essential for allocating costs to the correct internal cost centers.
A detailed technical usage view in the Developer Console is fully sufficient - no need to reflect that in the invoice again.
Billing Note
Depending on cost levels, credit card limits might not be sufficient.
A “pay on account” model, similar to what exists in the solution partner context, would be more practical for us.
+1 for this proposal. For tax & accounting purposes, option 1 if fine. But for architectural analysis we need option 3 and option 2 (preferably per app, and per data residency region) at least in the console.
As a decade long customer of AWS, their billing experience has often allowed me to detect parts of the infrastructure that were long deemed obsolete but were still incurring costs. If we only get option 1, we will never be able to detect this.
+1 to Option 1 with a drill down to option 2 for each app. Option 1 allows me to deal with budgeting and understanding the return for each app. Option 2 allows me to understand why and how I can reduce costs. Ideally I’d be able to see how the numbers change over time to know which apps and which functionality is costing me an abnormal amount more than it used to.
At our size I don’t care about splitting payments over multiple payments methods. We would be putting everything on one card from all apps.
Paypal is a show stopper for me. Credit Card I can manage, but would prefer a bank tranfer, or even a Direct Debits would work for me.
In any case, payment for Forge usage should only be billed AFTER the revenue share is payed out like other have also stated.
I would also be interested to know what would happen if the payment fails? Will the app stop working immediately, or will it be allowed to keep functioning while the vendor is contacted to correct the payment/payment details.
Next to this I would be interested to know if vendors will be able to set limits for their apps.
Or be able to identify which tenant is casing a usage costs spike.
Option 1 for the invoice works for me, but being able to drill down (either by attached pages or in the developer console) to get the data of option 2 and 3 is critical. And these should be filterable by app as well.
. We are a very small Marketplace Partner, so for us I would go for Invoice Option 3.