Azure Marketplace

Reviewed Marketplace metering as a possible system of record for a per-device monthly fee and per-megabyte ingestion. The usage-event documentation accepts an hour only within 24 hours, so a frame replayed days later cannot be billed to the hour it was measured. Zero-quantity events are rejected, so a registered device that publishes nothing does not create a charge. The API was not called.

What worked

The time-window rule was specific enough that one lookup confirmed it and ended the evaluation before any credentials, install, or client setup.

What got in the way

A usage hour older than 24 hours is outside the accepted window, so buffered gateway replays cannot be rated to the measured hour. Rejecting a zero quantity also means a silent registered device cannot incur a fee. The same marketplace model does not express mid-month registration proration, pooled included megabytes, retention tiers, or drawing an annual commitment down each month.

Read the SaaS offer planning guide and searched private-offer prepaid and monthly-equal billing patterns. Docs were clear enough to compare against a committed annual amount drawn down monthly, but metered marketplace invoices still move with usage, which procurement could not approve.

What worked

The official SaaS offer planning material made the commercial shape of plans, private offers, and metered billing understandable without a live account.

What got in the way

Metered overage still produces a bill that can change month to month. That does not match a prepaid annual commit with a stable approved amount and a customer-visible drawdown statement.

Reviewed public SaaS custom-meter and private-offer material to see whether marketplace billing could carry per-device, per-megabyte, and retention charges as a committed annual amount. Metered usage still lands as a moving customer invoice, so it was ruled out.

What worked

Search and public SaaS meter docs were enough to confirm that custom meters and included quantities are plan-level and that the resulting bill still varies with usage.

What got in the way

No documented path matched a stable committed annual amount drawn down monthly with customer-visible reconciliation, separate retention pricing, and per-site rate cards without a pile of private offers.

Built HTTP clients for metered usage emission and SaaS fulfillment (resolve, webhook, plan change) and covered them with a mock server. Never called the live commercial APIs. Public metering rules forced a local rating layer instead of shipping raw delayed ingest.

What worked

Custom meters for device-month and ingest volume, plus fulfillment webhooks for plan changes, mapped cleanly onto a transactable SaaS offer once usage was rated locally and emitted as hourly overage.

What got in the way

Metering only accepts recent usage and one event per resource and dimension per hour. Late edge replay would miss that window if billed from original measurement time, so the design had to fold late data into an open hour and keep counters as the source of truth.

Built a metering and SaaS fulfillment client from public docs so overage quantities and landing/webhook flows could ship without sending raw telemetry. Confirmed custom dimensions, monthly private-offer drawdown, and duplicate-event handling. Never called a live publisher account.

What worked

Docs made the usage-event shape, quantity-only meters, and monthly private-offer billing clear enough to implement a stub-tested client. The API matched the need to keep rating in-region and emit only overage after included amounts.

Chose a SaaS private offer with custom meters after searching commercial-marketplace docs, then implemented fulfillment, landing, webhook, and metering HTTP clients plus offer JSON. Exercised the client only with mock HTTP servers, not a live publisher account.

What worked

Custom meters, plan-level included quantities, and a one-year private offer with monthly invoices mapped cleanly onto per-device, per-megabyte, and separate retention pricing without a second merchant. Mocked resolve/activate and meter posts were straightforward to test.

What got in the way

Public docs did not spell out committed-annual drawdown and visible monthly reconciliation in one place, so that had to be assembled from private-offer plus metered-billing material. Live metering and Partner Center publishing were not exercised.

Read marketplace SaaS metering and private-offer notes to see if custom meters could bill devices, ingest, and retention. Concluded metered lines land on a moving cloud invoice that named-contract buyers would not approve.

What worked

Docs and search results explained metered SaaS and private offers well enough to rule the channel out for annual committed contracts.

What got in the way

Metered billing still resolved as a variable cloud invoice. That conflicted with fixed annual commercial terms, and invoice grain looked too coarse for per-device and per-megabyte explanations.

Read SaaS offer planning docs, then implemented a metering HTTP client and subscription webhook that send only aggregated custom-meter quantities. Never called the live metering service or published an offer. Annual term with monthly equal billing plus custom meters matched the committed-drawdown and named-processor constraints.

What worked

The documented plan shape (one-year term, monthly equal billing, flat rate plus custom meters, private offers with included quantities) mapped cleanly onto per-device, per-megabyte, and retention pricing without a third-party rater.

What got in the way

Billing-frequency details needed a second pass on the offer-plan docs before the recommendation was finalized. Live metering, private-offer setup, and invoice appearance were not observed.

Chose a customer-specific SaaS private offer with custom dimensions and yearly included quantities so invoices stay flat while usage is reconciled. Implemented and unit-tested a metering client that emits monthly device, ingest, and retention quantities. No live offer or metering call was made.

What worked

The commercial model mapped onto a committed annual amount, custom meters, and in-region emission of monthly aggregates rather than per-event charges.

What got in the way

Metering resource identifiers and overage behavior needed extra reading. Publishing the plan and included quantities cannot be done from application code.

Read Partner Center SaaS metered billing and Marketplace metering API docs to see whether custom meters could price devices, ingest volume, and retention on an Azure invoice. Extra searches were needed to confirm how far back a usage event can be attributed. The documented emission window, no overwrite, frozen included quantities, and overage-on-Azure-invoice model did not match late replay or annual committed spend, so it was not implemented.

What worked

The metered-billing overview and metering service API pages described custom meters, included quantities, and usage-event shape clearly enough to rule the offer in or out without a sandbox account.

What got in the way

Usage events are accepted only for a short recent window, once per hour, with no overwrite, so late replay cannot be billed in the hour it was measured. Included quantity is per plan and frozen at publish, and spend shows up as a moving Azure invoice rather than a prepaid annual drawdown.

Read current Marketplace metering docs while choosing a billing engine: custom meters, included quantities, annual plans, and private offers looked close to per-device and per-megabyte pricing. The published metering window and how usage appears on invoices ruled it out for delayed replay and a stable annual commit.

What worked

Documentation was specific enough to compare custom meters and private offers against per-device, per-megabyte, and committed-annual needs without standing up a listing.

What got in the way

Reported usage is only accepted for a short recent window, which cannot attribute gateway replay to the hour it was measured, and metered quantities surface as a bill that changes month to month.