Most guides to Google Cloud Marketplace start with onboarding steps. That is the wrong place to start, because there is a prior question that disqualifies a meaningful number of ISVs and it is commercial rather than technical.
Where does your product run?
Google’s documentation is direct about it. SaaS products on Cloud Marketplace are described as software products that run on Google Cloud and are billed by Google, requiring partner-managed infrastructure. Google’s quick start guide for sellers puts it as a requirement that solutions “run primarily on Google Cloud”.
Compare AWS and Microsoft, where a SaaS listing is fundamentally a commerce integration. Your product can run anywhere; the marketplace handles billing and entitlement. On Google Cloud the expectation reaches into your architecture.
If your product runs entirely on AWS or Azure, do not infer your way around this from documentation. Take it to your Google partner contact and get a direct answer about your specific product before you budget engineering time. The answer may be more flexible than the docs read, or it may not, but it is not a question to discover the answer to after you have built an integration.
This is worth saying plainly because it is the single most common reason a Google Cloud Marketplace project stalls, and the stall usually happens after the work has started.
Two other product requirements are easy to miss: your listing must comply with Cloud Marketplace listing requirements, and a SaaS product must not include professional services, hardware or other non-software components billed through Cloud Marketplace. If you habitually bundle implementation with your software, that packaging does not transfer here.
Onboarding
Assuming eligibility is settled, the process differs from the other clouds in shape:
- Register as a vendor if you have not sold on Cloud Marketplace before.
- Complete the onboarding validation form. Required for your first listing and for every subsequent one, which is different from AWS where listing creation becomes self-service after the first.
- Get Producer Portal access, which requires submitting a project information form provided by the Cloud Marketplace team.
That middle step matters for planning. There is more human-in-the-loop here than on AWS, so a listing timeline depends partly on Google’s team rather than entirely on you.
Fulfillment: two approvals, not a token
The handshake is distinct from the other two clouds. Where AWS gives you a token to resolve and Microsoft gives you a token plus a separate activation call, Google has you approve the customer account, then approve the order.
Two acknowledgements rather than a token exchange. Your integration is reacting to entitlement events and confirming them, rather than receiving a credential and resolving it. Code written for AWS does not port, and neither does code written for Microsoft. Full comparison in selling SaaS on three clouds.
Transaction models determine who pays whom
Google has operated multiple transaction models, and the agency model has applied to certain transactions since October 2023.
Which model applies to your product and offer type determines the flow of funds — who bills the customer, who pays you, and what appears in your reconciliation. Confirm it for your specific case rather than assuming, particularly if channel partners are involved. We covered how differently the three clouds handle this in CPPO explained.
Metering and reporting
The usual obligations apply with Google’s own API and its own semantics. Everything in metering and entitlements transfers conceptually: report on time, make retries idempotent, watch period boundaries, reconcile per customer rather than in aggregate.
The practical note is that this is a third independent metering implementation and a third report format to reconcile against one ledger. Nothing about Google’s version is harder than the others; it is simply separate.
AI agents
Google has been building out the agent side of Cloud Marketplace steadily since announcing AI Agent Space in late 2024. By October last year this had become a dedicated area where customers discover partner-built agents, with Gemini-powered natural language search and validation for A2A and Gemini Enterprise integration.
The validation requirement is the part to note if you are considering an agent listing: Google is gating on integration compatibility, not just publishing anything submitted. That is a higher bar than a standard listing and a longer timeline.
Committed spend works the same way
The core commercial argument is identical to the other clouds. Google Cloud customers hold spend commitments, marketplace purchases draw down against them, and that converts a budget conversation into a procurement conversation. The committed spend and quota credit mechanics are not AWS-specific.
If your customers are standardised on Google Cloud, this is the reason to go through the eligibility conversation rather than skipping the cloud entirely.
A realistic sequence
- Resolve eligibility with your Google partner contact. Nothing else matters until this is answered for your product.
- Register as a vendor and start the onboarding validation form early, since it involves Google’s team.
- Confirm which transaction model applies to you.
- Build the account-approval and order-approval flow as a new integration, not a port.
- Implement metering against Google’s API.
- Plan reconciliation for a third disbursement shape.
Launch covers this end to end, and the Google Cloud page sets out what CloudX handles.
The summary
Google Cloud Marketplace asks a question the other two do not: does your software run on Google Cloud. Get a direct answer about your product before committing engineering time. After that the mechanics are comparable in effort to the other clouds — a separate integration, a separate metering implementation, and a transaction model you need to confirm rather than assume.