Skip to main content
Use monetization callbacks when the device needs to react to paid orders, PIN verification, or active service sessions. [image:paid IoT session flow from checkout to device active service]
Firmware should react to the typed events it receives. It should not expose internal broker topics, raw device secrets, or backend-only identifiers to end users.

Payment events

The Payments object handles both pending and successful payment events. Use it to update a display, unlock a device after payment, or log order information locally.
Common values include item title, price, order ID, quantity, and metadata.

Verification events

The Verifications object handles PIN display and verification result events. Use it when a customer must enter a PIN or pass a precondition before using the device.

Device state

The DeviceStates object helps firmware react to state changes such as idle, pending payment, expired payment, successful payment, maintenance, or active service.

Init flow

The Inits object provides the initial device configuration after connection. It can include entity configuration, merchant status, active order ID, verification flags, and business mode (service or vending).

Vending dispense

When the device business mode is vending, a successful prepaid payment delivers catalog SKUs to dispense. Use the typed Dispenses object (or ON_DISPENSES) to drive motors or servos.
Common helpers: isValid(), itemCount(), skuAt(i), metadata(). Vending checkout requires prepaid catalog items. Postpaid items are not available in vending mode.

Active session end

The ActiveSession callback lets firmware end an active paid session from the device when local rules are met. This is useful for usage limits, sensor thresholds, or device-side safety rules.
Use this for device-side business rules only. Customer payment status and session ownership should still come from Firmngin.