D
David Starr
Overview
Managed Applications provide a powerful deployment model that enables publishers to install software solutions into the customer’s tenant using an ARM template. More about Managed Applications can be learned in my previous article on the topic or in this full-length on-demand course from Mastering the Marketplace.
A popular capability of Managed Applications is metered billing. Metered billing is charging for usage, or transactions above and beyond the standard price of the Managed Application. An example is an optical character recognition (OCR) company that charges a base price of $100 monthly for their product and an additional $0.01 per page scanned.
This article will take you through the metered billing for Managed Applications from creating the billing dimensions to calling the metered billing API.
How metered billing works
To use metered billing in your Managed Application solution, one must first define metered billing dimensions in Partner Center. This is essentially defining the types of transactions that may be charged for and the cost of each.
After the Managed Application is deployed by the customer, it may start submitting usage events to the marketplace metered billing API. The application must keep track of the transactions that occur and then emits the usage events to submit charges.
In addition to charging for transactions occurring in the Managed Application, metered billing can open up interesting scenarios for creative billing models. For example, using metered billing, a publisher might charge for enabling additional features after the Managed Application is deployed.
Example Managed Application offer with metered billing
The following image demonstrates the basic model of overage-based billing. For each plan, we have defined a base price, several transactions to include in the base price, and the cost for each transaction above and beyond those included in the base price.
The image below shows an offer with three plans for which we have defined different pricing models.
Plan details
Let’s take a deeper look at the different plans shown in the image above.
Silver plan
In this plan, the publisher is charging $100 per month for use of the basic service. And with that $100, 1000 transactions are included in the monthly fee. If the customer uses the included 1000 transactions, the 1001st transaction will cost 3 cents, as will additional transactions beyond that.
Gold plan
Gold is similar, but with different price points. For $200 per month the customer gets 2500 transactions and is charged a reduced rate of 2 cents per transaction after that.
Platinum plan
The platinum plan costs yet more money per month, but includes more transactions in the base price. Additionally, the prices of transactions over the number included is offered at a further reduced rate.
Defining metered billing dimensions
Metered billing dimensions are defined in Partner Center as part of each plan on a Managed Application offer. Dimensions are the line items for which a usage event may be submitted. From our OCR solution example, an offer may have a dimension defined for each page scanned.
Some quick constraints:
The following image shows how a dimension is defined in Partner Center. Note the base price of $100 per month. Then the “docs-scanned” dimension is defined with a price of $0.03 per transaction and 1000 transactions included per month.
Calling the metered billing API
After a Managed Application is deployed, it may then call back to the marketplace metered billing API to create the charges to the customer. Posts to the API must be at least an hour apart, and the usage event must be submitted no more than 24 hours after the event occurs.
For metered billing to work, the Managed Application must be active and deployed. That is, one cannot charge for a transaction after the Managed Application is removed from the customer’s subscription.
Usage events may be submitted one by one, or in a batch. When submitting a single usage event, a simple payload describing the transaction and how many units to charge for is sent to the API. When submitting in a batch, publishers can report transactions across many customers, many plans, and many dimensions, all in one call.
The endpoint to use when reporting single usage events is as follows.
This endpoint accepts posts with the JSON shown below. Note that the resourceUri is the identity of the Managed Application instance, not the managed resource group associated with the application.
Reporting architectures
There are two architectures for submitting usage events to the metered billing API: direct reporting, and centralized reporting.
Direct reporting
Direct reporting is the model we’ve been using for discussion throughout this article. One or more Managed Application instances are deployed into customer environments and each is responsible for emitting usage events directly to the API.
Events are submitted by resources inside a managed resource group. Resources that may emit events include virtual machines, containers, Azure functions, or anything else that may call an API. The following image shows a high-level view of how the Managed Application interacts with the metered billing API.
Centralized reporting
A very different deployment architecture is a centralized billing architecture. In this model, a publisher may create a system that lives in the publisher’s tenant, and it is responsible for reporting usage to the marketplace. The centralized metered billing solution is called from the Managed Application resources in the managed resource group.
This architecture is used by publishers to centralize the logic and functionality of reporting usage events, and not have the actual deployed solution do the billing directly. Below is a sample image of the centralized reporting model. Please be aware that the implementation of the centralized reporting service may be anything at all that brokers calls from the Managed Application to the billing API. The example case below is just one possible implementation.
In the solution below, the customer’s Managed Application submits transaction reports to an Azure data storage queue. The transaction reports are queued until they are read and dequeued by a reporting service (cron job, web job, Azure function with a timer, etc.) and then submitted, typically in batch mode, to the billing API.
Again, this is only one model for a centralized reporting solution. The technology used and how your metering service behaves is up to you.
Conclusion
Metered billing opens new ways to bill for your solution and focuses on billing per transaction. Dimensions are defined in Partner Center and then referenced in calls to the metered billing API. Additionally, there are two models of usage reporting (direct and centralized) that publishers may choose between.
For more on metered billing in Managed Applications, see the following video tutorials and sample code.
Continue reading...
Managed Applications provide a powerful deployment model that enables publishers to install software solutions into the customer’s tenant using an ARM template. More about Managed Applications can be learned in my previous article on the topic or in this full-length on-demand course from Mastering the Marketplace.
A popular capability of Managed Applications is metered billing. Metered billing is charging for usage, or transactions above and beyond the standard price of the Managed Application. An example is an optical character recognition (OCR) company that charges a base price of $100 monthly for their product and an additional $0.01 per page scanned.
This article will take you through the metered billing for Managed Applications from creating the billing dimensions to calling the metered billing API.
How metered billing works
To use metered billing in your Managed Application solution, one must first define metered billing dimensions in Partner Center. This is essentially defining the types of transactions that may be charged for and the cost of each.
After the Managed Application is deployed by the customer, it may start submitting usage events to the marketplace metered billing API. The application must keep track of the transactions that occur and then emits the usage events to submit charges.
In addition to charging for transactions occurring in the Managed Application, metered billing can open up interesting scenarios for creative billing models. For example, using metered billing, a publisher might charge for enabling additional features after the Managed Application is deployed.
Example Managed Application offer with metered billing
The following image demonstrates the basic model of overage-based billing. For each plan, we have defined a base price, several transactions to include in the base price, and the cost for each transaction above and beyond those included in the base price.
The image below shows an offer with three plans for which we have defined different pricing models.
Plan details
Let’s take a deeper look at the different plans shown in the image above.
Silver plan
In this plan, the publisher is charging $100 per month for use of the basic service. And with that $100, 1000 transactions are included in the monthly fee. If the customer uses the included 1000 transactions, the 1001st transaction will cost 3 cents, as will additional transactions beyond that.
Gold plan
Gold is similar, but with different price points. For $200 per month the customer gets 2500 transactions and is charged a reduced rate of 2 cents per transaction after that.
Platinum plan
The platinum plan costs yet more money per month, but includes more transactions in the base price. Additionally, the prices of transactions over the number included is offered at a further reduced rate.
Defining metered billing dimensions
Metered billing dimensions are defined in Partner Center as part of each plan on a Managed Application offer. Dimensions are the line items for which a usage event may be submitted. From our OCR solution example, an offer may have a dimension defined for each page scanned.
Some quick constraints:
- A plan may have up to 30 billing dimensions
- Transactions may not cost less than $0.01
- Different plans may share the same dimensions with different pricing
- Different plans may define different dimensions
The following image shows how a dimension is defined in Partner Center. Note the base price of $100 per month. Then the “docs-scanned” dimension is defined with a price of $0.03 per transaction and 1000 transactions included per month.
Calling the metered billing API
After a Managed Application is deployed, it may then call back to the marketplace metered billing API to create the charges to the customer. Posts to the API must be at least an hour apart, and the usage event must be submitted no more than 24 hours after the event occurs.
For metered billing to work, the Managed Application must be active and deployed. That is, one cannot charge for a transaction after the Managed Application is removed from the customer’s subscription.
Usage events may be submitted one by one, or in a batch. When submitting a single usage event, a simple payload describing the transaction and how many units to charge for is sent to the API. When submitting in a batch, publishers can report transactions across many customers, many plans, and many dimensions, all in one call.
The endpoint to use when reporting single usage events is as follows.
Loading…
marketplaceapi.microsoft.com
This endpoint accepts posts with the JSON shown below. Note that the resourceUri is the identity of the Managed Application instance, not the managed resource group associated with the application.
Reporting architectures
There are two architectures for submitting usage events to the metered billing API: direct reporting, and centralized reporting.
Direct reporting
Direct reporting is the model we’ve been using for discussion throughout this article. One or more Managed Application instances are deployed into customer environments and each is responsible for emitting usage events directly to the API.
Events are submitted by resources inside a managed resource group. Resources that may emit events include virtual machines, containers, Azure functions, or anything else that may call an API. The following image shows a high-level view of how the Managed Application interacts with the metered billing API.
Centralized reporting
A very different deployment architecture is a centralized billing architecture. In this model, a publisher may create a system that lives in the publisher’s tenant, and it is responsible for reporting usage to the marketplace. The centralized metered billing solution is called from the Managed Application resources in the managed resource group.
This architecture is used by publishers to centralize the logic and functionality of reporting usage events, and not have the actual deployed solution do the billing directly. Below is a sample image of the centralized reporting model. Please be aware that the implementation of the centralized reporting service may be anything at all that brokers calls from the Managed Application to the billing API. The example case below is just one possible implementation.
In the solution below, the customer’s Managed Application submits transaction reports to an Azure data storage queue. The transaction reports are queued until they are read and dequeued by a reporting service (cron job, web job, Azure function with a timer, etc.) and then submitted, typically in batch mode, to the billing API.
Again, this is only one model for a centralized reporting solution. The technology used and how your metering service behaves is up to you.
Conclusion
Metered billing opens new ways to bill for your solution and focuses on billing per transaction. Dimensions are defined in Partner Center and then referenced in calls to the metered billing API. Additionally, there are two models of usage reporting (direct and centralized) that publishers may choose between.
For more on metered billing in Managed Applications, see the following video tutorials and sample code.
- Metered billing overview (video)
- Metered billing technical details (video)
- Marketplace solutions (sample code repository)
Continue reading...