Introduction
The Microsoft commercial marketplace has several deployment models and architectures, as explained my previous article, “An introduction to marketplace deployment architectures.” Software-as-a-Service (SaaS) offers are a very popular option when integrating your software solution with the marketplace because this offer type supports (you guessed it) SaaS product architectures so well.
After finishing this article you'll have a better understanding of the following elements of a SaaS offer in the Microsoft commercial marketplace.
- Reasons to choose SaaS
- The landing page
- The webhook
- Creating a SaaS offer in Partner Center
- Additional recommended practices
- Some follow up resources
Choosing SaaS
There are many reasons SaaS may be a good fit for your offer’s deployment architecture. In a SaaS model, the actual software solution runs on the publisher’s Azure subscription, giving full control over resources and services to the publisher. This is especially well-suited for multi-tenant SaaS solutions that serve up the product as a service to the customer. Choosing to use a SaaS offer doesn’t mean you must be hosting your customers in a multi-tenant solution architecture, but this is one of the cleanest all-up solution architectures.
It's important to realize you don’t necessarily need to change code in your existing solution to use a SaaS offer type in the marketplace. In fact, you can implement a complete, but minimalist, SaaS offer by providing only two required elements: a landing page, and a subscription webhook.
The landing page
A landing page is a required web page, hosted anywhere on the internet and implemented in any tech stack, that integrates with Azure Active Directory (AAD) Single Sign On (SSO) and with the SaaS Fulfillment API to communicate with the marketplace. The landing page provides a place for customers to configure their accounts, review subscription details, or learn about things like support resources, next step instructions, or product FAQs.
The landing page comes into play at the end of the customer subscription process. When a customer subscribes to a SaaS offer, a deployment takes place, creating a new subscription. At the end of the new subscription deployment, the customer is presented with a link or button prompting them to “Configure my account.” Clicking this prompt opens the landing page, which has the user login with AAD SSO.
When the landing page is launched it receives a token on the query string that may be resolved via the SaaS fulfillment API to retrieve information about the subscription that was just created. Using this subscription information, it is common practice to show subscription details to the customer and ask them for additional information the publisher may need to create or configure a new customer account. For example, a landing page may ask the customer to input the contact information for whomever they should contact for next steps.
Once done reviewing the subscription details on the landing page and providing any additional information, the customer typically submits the landing page, and some automated backend flow is started. It could be something simple, like sending an email to whomever activates the new customer account. Or it could be more sophisticated, like putting information into a database.
In a system where the landing page might create the customer’s new account, it might make a call back to the SaaS Fulfillment API’s activate endpoint, which activates billing on the new subscription.
The webhook
The second required integration point for SaaS offers is for the publisher to provide the URL of an HTTP endpoint (webhook) that accepts posts from the marketplace. When there is a change to a customer’s subscription, like selecting a new plan or cancellation of the subscription, a message is posted to the webhook with subscription information.
The implementation of a webhook could be as simple as sending the subscription change information in an email, or it could be more sophisticated, like updating a customer’s record or taking appropriate action to update their account’s functionality.
Setting up Partner Center
Partner Center is a centralized portal for partners to manage offers, subscriptions, billing, and more. A SaaS offer is created in Partner Center and plans and pricing are added to the offer. The SaaS offer also includes a technical configuration, which has four requirements.
- The URL of the landing page
- The URL of the webhook
- Your tenant ID
- An Azure application registration ID
The tenant ID
The tenant ID is a unique identifier for your AAD tenant. It is required to authenticate your application and securely interact with the Azure services and APIs. You can find your tenant ID in the Azure portal by navigating to "Azure Active Directory" and selecting "Properties." Include the tenant ID in your SaaS offer technical configuration to establish a secure connection between your application and the Azure Marketplace.
The Azure application registration ID
The Azure application registration ID, also known as the client ID, is a unique identifier generated when you register your application in Azure AD. This registration should be created in the same tenant mentioned in the previous section. This registration enables secure sign-in and subscription management for your landing page. After registering your application, you need to provide the client ID (application registration ID) in your SaaS offer configuration to ensure proper authentication and secure communication with the Azure services.
Additional recommended practices
We’ve covered the essentials of the SaaS offer integration points with the marketplace, but there are some other things you may want to consider, such as the following.
- Creating customer accounts
- Building a subscription management application
- Integrating your SaaS solution for metered billing
The next sections look at these considerations in detail.
Creating customer accounts
When you get a new customer, is the customer’s new account automatically created and all required resources deployed, or is there a manual process involved? Both scenarios are supported by SaaS offers, but the flow looks a little different for each.
Automated account creation
It’s advisable to provision new customer accounts and resources via an automated process. This speeds the process for the customer and makes it less error prone for the publisher. If you are selling high volumes of subscriptions, automated provisioning is highly recommended.
In an automated account creation example, the landing page may store data about the new subscription and return to the customer with a message like, “Creating your account.” Then a different process can do the work of creating the customer’s new account using required information gathered from the landing page. After the account is created, the provisioning process then makes a call to the /activate endpoint of the SaaS Fulfillment API and billing begins.
Manual account creation
There are some business models where it may not be worth automating the customer provisioning process. It may be that some human intervention is needed to run some scripts, insert data into a DB, or take some other action. This is supported and makes sense when you sell subscriptions infrequently, as it may not be worth the cost of automation when only setting up a few new subscriptions per year.
Manual provisioning of a new customer’s account and resources is a process that begins with the landing page, which may do nothing more than send an email to your operations team and then return to the customers with a “we’ll contact you,” message. From there, the operations team fills the order and must then use a tool to make a call to the /activate API endpoint and start billing for the subscription.
A subscription management application
Most publishers want to know what is happening with their customers’ subscriptions. While we’ve talked about simple landing pages and webhooks that might just send an email, a step up would be to save these subscription status messages into a data store and create a subscription management tool that uses that data.
Metered billing integration
Azure Marketplace metered billing is a pricing model that allows customers to pay only for the services or resources they use, based on consumption or usage. In this model, customers are charged based on the amount of usage, rather than a fixed or upfront fee. The pricing is based on a billing system that tracks and bills customers based on their usage of a particular solution or service. This allows customers to pay only for what they use and avoid unnecessary costs associated with underutilization.
Metered billing implementations typically require that the actual SaaS application keeps track of some sort of transaction, sending an SMS message for example. The SaaS application would report to the marketplace that an SMS message was sent, and the customer then gets charged the price of sending the text.
Next-step resources
There are several places you can go to help you gain more knowledge and skill in implementing SaaS offers for the marketplace. To accelerate your journey, check out the following resources.
The Mastering the Marketplace learning library is a collection of video, hands-on labs, and sample code to help you learn about all about the marketplace. Here is a special on-demand SaaS course that takes you from start to finish in developing your own SaaS integration.
The SaaS Accelerator is a codebase I will cover in more depth in a future article. For now, know that it is an OSS reference implementation of a complete SaaS integration that you can have up and running in less than 20 minutes, instead of building your own solution from scratch. Have a look at the SaaS Accelerator’s GitHub repo and head over to the learning library for a complete course on the SaaS Accelerator.
Key Microsoft Learn documentation you’ll want to review includes the following.
Summary
This article covered several aspects of building SaaS offer for the Microsoft commercial marketplace. We learned that the two required technical components of a SaaS solution are a webhook and a landing page, and we covered the role of each. We also discussed working in Partner Center and some additional best practices you may want to consider for your implementation. Finally, I provided a set of resources for you, so you take the next steps to getting your SaaS offer up and running as quickly as possible.