When Should Billing Start for a Microsoft Marketplace SaaS Subscription?
When you create a SaaS offer in Partner Center, you add plans. Those plans are the versions customers can buy, such as Basic, Professional, and Enterprise. Each plan includes an important setting that many publishers overlook: auto-activation.
That setting decides when billing begins.
For each plan, you choose one of two paths:
- Auto-activation on. Billing begins immediately when the customer purchases.
- Auto-activation off. Billing begins only after you activate the subscription.
At first glance, starting billing at purchase looks like the obvious choice. For many SaaS sellers, it is not. The right answer depends on when the product is actually ready for the customer to use.
When should billing begin?
This decision applies to both public offers and private offers sold through Microsoft Marketplace.
In most SaaS businesses, payment starts when the customer can log in and use the product. That moment is controlled by your platform, not by the marketplace checkout. Buying a subscription in Microsoft Marketplace does not automatically mean the product is ready to use.
That gap matters. A customer can complete a purchase while your team is still creating the account, importing data, configuring users, or standing up infrastructure. If auto-activation is on, billing can start before the customer has anything to use. If auto-activation is off, you can activate the subscription after the product is ready, and billing starts then.
This is especially important for larger enterprise solutions. Those implementations often need more than a new login. They may require data import, user setup, purchase option configuration, and a deployment model that takes time.
The architecture changes the answer
How quickly you can make the product available depends on how the SaaS platform is built.
Creating a customer account
In a multi-tenant architecture, a new customer is often just another account in a shared platform. Provisioning can usually be automated through your own APIs. If that process is fast and reliable, auto-activation can make sense. The customer buys, your system creates the account, and the product is ready around the same time billing starts.
Deploying a dedicated environment
Some customers need stronger isolation. That can mean a separate database. In more extreme cases, it can mean a dedicated runtime, including deploying the full application into its own Azure tenant.
Automating that kind of setup is a bigger job. You are not only creating an account. You may also need new tenants, data ingestion, and infrastructure as code to deploy the services the product depends on. If that work takes hours or days, turning on auto-activation can create an awkward moment: the customer is being billed, but the environment is still being built.
The marketplace triggers the work
Whatever automation you have, the product is only ready at purchase time if something starts that automation when the sale happens.
That trigger comes from the Microsoft Marketplace SaaS fulfillment APIs. The webhook you configure in Partner Center is the event source. It fires for several subscription events, including activation.
If auto-activation is enabled for the plan, Microsoft activates the subscription at purchase and calls your webhook. A common pattern is to receive that event, write a message to a queue, and let a worker create the customer account or start the infrastructure deployment.
If auto-activation is off, you still use the same APIs. The difference is timing. The customer purchases, your team or your automation prepares the environment, and then you activate the subscription so billing can begin.
How to choose
Use auto-activation when the product can be ready immediately, or close enough that the customer can start using it as soon as they buy.
Leave auto-activation off when setup takes real work: data import, dedicated infrastructure, customer-specific configuration, or any process that is not instant.
The goal is simple. Billing should start when the customer can use what they bought. The marketplace setting should follow your product reality, not the other way around.