Monetization

Launchpad surfaces Apigee monetization as a developer-facing Plans & Billing hub. Developers browse published rate plans, add prepaid credit, subscribe to API products, and then attach those products to apps so they can call the APIs.

Apigee still owns the commercial data. The portal never stores balances, rate plans, or subscriptions of its own — it reads and writes them live against the connected Apigee organization.

How it works

Four objects have to line up. Mixing them up is the usual reason a purchase “succeeds” but API calls still fail.

On Apigee X you subscribe to an API product, not to a named rate plan. The catalog shows products labelled by their currently published plan. Draft or superseded plans cannot be purchased.

Prepaid and postpaid

Every Apigee developer needs a billing type. An unset type blocks purchases, so Launchpad applies a portal default the first time a developer is provisioned.

The portal default is Prepaid. Self-registering developers can only spend credit they have already topped up. Switching someone to postpaid is a credit decision, so it requires the Manage Billing Type permission (granted to Administrator by default).

Set up rate plans in Apigee

Rate plans are created in Google Cloud Apigee, not in the portal. The portal only lists plans that already exist and are published.

1. Sign in to Google Cloud Console and open Apigee for the right project.
2. In the left menu under Distribution, click Monetization.
3. Click Create rate plan.
4. Give the plan a clear name (this is what developers see) and attach at least one API product. If the product list is empty, create the product in Apigee first.
5. Complete billing and pricing (prepaid vs postpaid charging model, currency, per-call or fixed fee, optional revenue share).
6. Use Save and publish (or save as draft, then publish).

Configure the portal

Connect Apigee

1. Confirm the portal is connected to the same Apigee organization that holds the rate plans. See Apigee Integration.
2. Use Test connection if it is available, and keep credentials valid.
3. In Configuration → Users, run Sync Developers so portal users exist as Apigee developers. Monetization is keyed by developer email.

Monetization defaults

In Configuration → API (Apigee Configuration), open Monetization Defaults:

• Default billing type — applied when a developer is first registered in Apigee (signup and admin sync). Prepaid is the safe baseline.
• Apply to existing developers — backfills developers created before a default existed. It never overwrites a billing type that is already set, and it runs per developer per workspace.

Who can change billing type

• To prepaid — the developer can switch themselves under Profile → Billing Details.
• To postpaid — requires Manage Billing Type. Assign it in Configuration → Users → Permissions. Holders also get a Billing Type dropdown when editing a user.

Plans & billing label

Developers see this area as Plans & Billing by default, not “Monetization.” Change the nav and page heading from Manage Workspaces → Display Settings under Plans & billing area (for example “Billing” or “Plans”). The /monetization URL does not change.

The developer hub

Logged-in developers open a single page at /monetization (the nav item uses your configured label). Older bookmarks still work:

• /billing redirects to the hub
• /plans and /plans/purchase redirect to the Buy APIs tab

The hub has four tabs:

Overview

• Prepaid — remaining wallet balance, a low-balance warning when credit is under 20, and Add credit. With more than one workspace, each wallet is listed separately (credit is not transferable).
• Postpaid — current billing cycle and a note that usage is invoiced. There is no wallet and no Add credit button.
• A snapshot of active plans, with a link to manage them.
• Prepaid only: recent top-ups.

Buy APIs

A searchable catalog of published rate plans. Each card shows the pricing model (Subscription, Pay per use, Freemium, or Custom), headline price, the API product, and a Subscribed badge when the developer already holds that product in that workspace. View details opens a fee breakdown; Purchase starts checkout.

Deep links from apps and catalogs land here:

• /monetization?tab=catalog — browse all plans
• /monetization?tab=catalog&plan=<ratePlanId> — open a specific plan
• Add &orgId=<id> when the plan is sold in a non-default workspace, and &returnTo=/apps/add to resume app creation after purchase

My plans

Active subscriptions with start dates, and a separate inactive list for plans that ended or were cancelled. Cancel plan expires the subscription immediately — Apigee X has no “cancel at end of period” operation. Apps using that product lose paid access the same day.

Activity

Prepaid only: top-up history (id, date, payment provider, amount, status). Hidden for postpaid developers. Usage deductions themselves are reported by Apigee per billing cycle; the portal does not yet show invoices or metered usage.

Add prepaid credit

From Overview or the header Add credit button, developers pick a preset ($10, $25, $50, $100) or a custom amount. With several workspaces they must choose which wallet to fund first — credit stays in that workspace.

• Production — Stripe Checkout collects payment. The signed Stripe webhook is the only path that credits the Apigee wallet, using an idempotent transaction id so a redelivered webhook cannot double-credit.
• After payment, the developer returns to the hub. If they were buying a plan, they can finish the purchase with the new balance.

Purchase a plan

1. On Buy APIs, open a plan and click Purchase (or purchase from the details drawer).
2. Confirm the plan, API product, estimated first charge (setup + first recurring fee), and — for prepaid — the wallet that will pay for it.
3. Click Confirm purchase. The subscription starts today.
4. On success, choose Create an app (or Continue creating app if they arrived from Apps) so the product is attached and a key is issued.

If a prepaid wallet is short, checkout shows the required amount, the available balance, and an Add credit action prefilled with the shortfall. After the top-up settles, they return and complete the purchase.

Apps and paid products

When a developer creates or edits an app, the product picker knows about monetization:

• Subscribed products sort first and are marked Subscribed.
• A monetized product with no active subscription is gated: it cannot be selected. The card shows the price and a Subscribe link to that plan. Draft data on the app form is kept so they can return and finish.
• Products with no rate plan stay freely selectable.
• On edit, a product the app already carries is never blocked, even if the plan has lapsed. It is badged Needs a plan so the developer can see why calls will fail.

Purchase success deep-links to /apps/add?product=<apiproduct> so the product is preselected. See Developer Apps.

Multiple workspaces

If the developer belongs to more than one Apigee organization (shown in the portal as workspaces by default):

• Buy APIs lists plans from every reachable workspace, each card labelled with its workspace.
• The same product name can exist in two workspaces with different prices or plans.
• Each workspace has its own wallet and billing type. Credit cannot move between them.
• A purchase that is blocked for insufficient balance names the workspace whose wallet is short, and Add credit funds that wallet — not the default one.

Verify the flow

Use a normal developer account that is logged in and linked to an Apigee developer.

1. Open /monetization. Overview should show a prepaid wallet (even if zero) or a postpaid invoicing card, with no error.
2. Open Buy APIs and confirm the published plan from Apigee is listed.
3. Purchase it. Prepaid developers with a low wallet should be sent to Add credit; after funding, purchase should succeed.
4. Confirm the plan appears under My plans as Active.
5. Create an app and attach the same API product. The product should be marked Subscribed and selectable.
6. Optional: call the API with the app’s key, then re-open Overview. Prepaid balance changes can lag until Apigee processes the billing cycle. Per-call metering also requires the MonetizationLimitsCheck policy on the API proxy in Apigee — without it, calls succeed but are not billed.

Troubleshooting

Quick checklist

• Monetization is enabled for the Apigee organization.
• An API product exists, and a rate plan is created and published for it.
• The portal is connected to that organization, and the connection test passes.
• The test user is logged in and exists as an Apigee developer (email mapping).
• The developer has a billing type (apply the portal default if Overview looks empty).
• Buy APIs shows at least one published plan.
• Purchase succeeds and appears under My plans.
• The same product is attached to an app before expecting API access.

Common issues

• Catalog is empty — the plan is still a draft, or the portal points at a different Apigee organization. With several workspaces, a warning names any that could not be loaded.
• Developer legal name not specified — complete required developer profile fields in Apigee.
• Balance too low / insufficient prepaid balance — add credit to the workspace that sells the plan, then retry.
• No billing type on Overview — run Apply to existing developers. Do not diagnose from wallet balance alone: postpaid developers have no wallet, so a missing balance is normal for them.
• I bought the plan and the API still fails — create or edit an app and attach the product. If the app already has the product, check the proxy in Apigee for MonetizationLimitsCheck and VerifyAPIKey (or OAuth).
• Team app says it needs a plan — the purchase was personal. The team needs its own subscription (today that is created out-of-band in Apigee).
• I called the API but nothing was charged — the proxy is not enforcing monetization. Setup and recurring fees can still charge at purchase time; per-call consumption only meters when the proxy asks Apigee to.

If an issue remains, capture the exact screen, error message, and click path, then share it with your technical team or support.