Sell your SaaS on Google Marketplace

If you have a Software as a Service to sell, Google Cloud Marketplace gives you a way to sell it. The customers’ decision to buy is much simplified, since they can pay through their Google invoice.

This article is a high-level guide for engineers to creating your Marketplace solution. You can offer VM images or Kubernetes containers on the Marketplace. However, most vendors sell Software as a Service, so we will focus on that. We won’t aim for completeness or detail, but rather we’ll raise the main points of difficulty that aren’t immediately clear from the documentation.

Bring your products to market

In ordinary Google Cloud Platform usage, you simply invoke openly available cloud APIs. Integrating with the Marketplace seller system is quite different: It resembles an enterprise integration, driven by business discussions between your organization and Google. Technically, your systems will participate in two-way multistep workflows with Google’s own business systems. Compared to core GCP, there is much less publicly available information in the documentation and public forums.

Before you start the integration, you will need Google’s approval. The engineering team will be blocked until this approval is received.

To get it, the business side of your organization will work with Google through the Partner Advantage program. The process typically takes many weeks. If you work with DoiT Cloud Solve, our account managers will help your team through that.

The reason for this approval process is Google’s desire to maintain quality. A few years ago, Google Marketplace was a vast sea of apparently abandoned offerings, as vendors did not work on integration with the Google systems. Today, Google tightly vets offerings and only accepts a select few high-quality, high-volume solutions,

You will know that the approval has arrived when you have access to the Producer Portal, where you configure your solution, at https://console.cloud.google.com/producer-portal?project=PROJECT_ID

After the approval arrives, you will be able to make API calls or use the Producer Portal’s built-in functionality for preview, testing, and private deployment. Until then, you can prepare yourself by learning the architecture. I suggest reading the documentation and learning from the GitHub project DoiT-Easily.

DoiT-Easily is an open-source project which illustrates how to do the integration. It has multiple contributors from DoiT, but is not a supported product nor a fully featured, production-ready system. Rather, it is a working integration that provides an example to learn from and to fork. The documentation of DoiT-Easily gives a good overview, and you can also see a second blog post for a high-level discussion.

Integrating with the Procurement API is mandatory; use of the Service Control (Usage) API is optional.

The Procurement API manages user sign-up and cancellation; as well as entitlements — i.e., when a user buys a service or service level. The API is invoked in a multistep flow in which both your application and Google’s systems need to approve the entitlements. More details below.

The Service Control API can be used to report to Google how much of a charged resource was used, so that the customer can be billed: For example, the number of mebibytes processed, hours online, or number of invocations of your API. Because you can offer pricing plans that don’t track usage, you can skip this API for a minimal initial implementation.

This architecture diagram from DoiT Marketplace lays out the components.

Marketplace Integration Architecture

You will be integrating both your front-end and back-end applications. These run in your dedicated Marketplace project; any cloud components other than those dedicated to integration can optionally run in this or in another project. If you have multiple Marketplace listings, use this same integration project for all.

Front-end

Your front-end allows users to log in and sign up and then to buy a subscription to your service (“entitlement”). The front-end is your own web app; the client has your look and feel

When users click to register, the Google Marketplace page sends users to your front-end (whose public URL you have registered with Marketplace). This request includes a JWT token signed by Google to authenticate that the referral was in fact from Google Marketplace. Your front-end client-server app lets the users register within your systems and then notifies Google through the Procurement API.

Back-end

When a user selects a pricing plan in the Google Marketplace UI, Google publishes an entitlement event on Pub/Sub, which your back-end receives.

You then decide whether to approve or reject this entitlement (purchase). Your approval might be immediate and automatic, or you might have a human intervention. If the approval will take some time, invoke the Procurement API to send a status message to users. When the decision is ready, the back-end invokes the Procurement API to approve or reject the entitlement.

You can offer your product on several pricing models, which affects the complexity of your integration. Offering your product for free, or charging by monthly subscription, means that you do not need to report usage. If you charge by a usage metric such as storage time, amount of data processed, or any custom metric, then you will have to create an integration to report that to the Service Control API.

You can skip the front-end development efforts if you only sell through private offers: In a private offer, you create the pricing for a specific customer, rather than having them choose an offer on the Google Marketplace site. This makes some front-end integration unnecessary, as accounts can be approved directly via the Pub/Sub message from Google to your back-end. One limitation on this approach is that if you have private offers, you must also have at least one public offer; however, you can request a waiver for that requirement from Google. Another challenge is that you will have to create some sort of mechanism, often an internal web-app, for creating and making your private offers.

If you enable auto-approval (a feature only for private offers), then backend development isn’t really needed either.

Since two projects across two corporations — Google and yours — are involved, you will need to grant permissions in both directions.

Your service account

Create a service account in your project. Register the service account in the Procurement Portal as part of your product definition, to give it permission to invoke the Procurement API and subscribe to Cloud Pub/Sub for the entitlement events sent by Google.

The user deploying your solution needs to be able to impersonate (act as) your service account, using serviceAccountTokenCreator.

Google’s service accounts

In your project’s IAM, grant roles to allow Google’s service accounts to access your project: three for production ( details here) and one for testing (see here)

After your integration is developed and tested, it will need a review from Google before release, so leave time for that.