Postpaid

Postpaid items calculate the final amount from what happens during a service session. Choose postpaid when the amount is not known until the customer finishes using the device or service. Common postpaid use cases include:

• EV charging billed by energy consumed.
• Water dispensing billed by liters used.
• Equipment rental billed by time.
• A service billed from the latest sensor value.
• A machine billed by completed cycles or events.

​

How postpaid works

​

Create a postpaid catalog item

1. Open your merchant in the dashboard.
2. Open Price Rules and create a rule for the service.
3. Go to Catalog.
4. Create a new item or edit an existing item.
5. Set Payment Type to Postpaid.
6. Select the required Price Rule.
7. Complete the item details and device assignment.
8. Save the item and test a complete session on the public page.

Postpaid items use one quantity per order. Multiple quantity is disabled because each order represents one measured service session. Postpaid items can only be sold from devices in Service Mode. They stay unavailable on devices set to vending, because a vending order must have a final amount before dispense.

​

Send catalog metadata to a device

Open Advanced Settings in the catalog item editor when the device needs custom JSON alongside the service lifecycle. Both fields accept a JSON object or an array of JSON objects. Metadata is optional; Firmngin does not publish the metadata topic when its field is empty. /pr carries the selected postpaid item as {it, pc, oid, q}. The quantity is always 1. Firmngin creates the order and billing session, publishes /pr, publishes /mpp when configured, and then changes the device state to on_active_service. The Arduino Payments object exposes isPostPaid() and isPrePaid() as mutually exclusive booleans. For /pr, isPostPaid() is true and isPrePaid() is false. The Python Payment object exposes the equivalent is_post_paid=True and is_pre_paid=False. For prepaid /pp and /pm messages, these values are reversed. Payment type is independent from the pending and success flags. /moa is separate from /mpp and /mos. It can be configured for prepaid or postpaid items because both payment modes can enter active service. Firmngin publishes the parent /ds status first, then publishes /moa only when On Active Service metadata exists.

​

Configure a price rule

A price rule defines the base charge, billable quantity, unit price, and optional spending limit. A rule can contain any number of pricing components; Firmngin calculates every active component and adds their charges together. Physical meter entities follow the components. Different measured units such as kwh and count generate separate device entities. Components that reference the same unit share one generated entity and one Usage calculation policy. Per Time and Tiered Per Duration use the internal session timer and generate no physical meter entity. The Price Rule form shows Will be generated before creation. When editing an existing rule, it loads the persisted generated-entity status and displays the actual key and linked-device coverage. Partial generation and missing linked devices are shown explicitly; the browser does not predict the key.

​

Start amount

Start Amount is a base charge added to the usage charge. For example:

• Start amount: IDR 10,000
• Usage charge: IDR 15,500
• Final total: IDR 25,500

Set the start amount to 0 when the customer should pay only for measured usage.

​

Maximum amount

Max Amount limits the combined total. When the running amount reaches the limit, the session ends automatically. Leave it empty when the service does not need an automatic spending limit.

​

Pricing component

Choose the component that matches how you sell the service: Choose a unit that customers understand and that matches the values produced by the device, such as kWh, liter, minute, hour, kilometer, or cycle. Tiered components provide a Per Unit or Per Duration basis and use contiguous [From, Until) brackets: From is included and Until is excluded. Both fields display the component unit. The first bracket starts at 0, and the final bracket has no upper limit.

• Per Unit selects one fixed total from the measured-usage bracket. The charge is not multiplied by usage.
• Per Duration is progressive. Each duration slice is multiplied by that bracket’s rate, and partial duration is prorated. It supports second, minute, and hour.

​

Usage calculation

For per-unit and tiered pricing, Usage calculation controls how incoming readings become the billable quantity.

​

Cumulative delta

Use Cumulative delta for a total meter that normally only increases, such as an energy meter, water meter, odometer, or total production counter.

• The first reading sets the session baseline and adds no usage.
• Each later reading adds the difference between the current and previous reading.
• Lower readings are rejected.

Example: This prevents usage recorded before the customer started the session from being included in their bill.

​

Latest value

Use Latest value when the newest reading itself is the billable quantity. Values may increase or decrease. This works well for adjustable levels, a potentiometer, a final measured quantity, or another value where the customer should be charged from the current reading. Example: a latest value of 68 at IDR 500 per unit produces a usage charge of IDR 34,000.

​

Time integral

Use Time integral when a changing value must be accumulated over elapsed time. Examples include:

• Speed over time to estimate distance.
• Power over time to calculate energy.
• Flow rate over time to calculate volume.

Select the rate period represented by the incoming value: per second, per minute, or per hour. Set Maximum gap to prevent a long period without readings from being included as continuous usage.

​

Event count

Use Event count when each unique accepted reading represents one billable event, cycle, pulse, or completed action. Each accepted event adds one to the session quantity.

​

Price examples

​

Cumulative energy meter

• Start amount: IDR 10,000
• Price: IDR 500 per kWh
• First reading: 68 kWh
• Latest reading: 99 kWh
• Session usage: 31 kWh
• Usage charge: IDR 15,500
• Final total: IDR 25,500

​

Latest measured value

• Start amount: IDR 10,000
• Price: IDR 500 per unit
• Latest reading: 68
• Usage charge: IDR 34,000
• Final total: IDR 44,000

​

Time-based rental

• Price: IDR 300 per minute
• Session duration: 25 minutes
• Final total: IDR 7,500

​

Changes to an active rule

An active session continues using the price rule configuration that applied when the session started. Editing the rule affects new sessions, not a session already in progress. This keeps the price shown during a customer session consistent until the final bill is created.

​

Ending a session

A postpaid session can end through the stop methods enabled for the linked device:

• The customer selects End Session on the public order page.
• Device-side logic ends the session when Device Local End is enabled.
• A dashboard user force-ends the service.
• The configured maximum amount is reached.

Review Merchant Setup for verification and stop-mode configuration.

​

Troubleshooting

​

Usage remains zero

Check the selected usage calculation and the readings sent after the session started.

• With cumulative delta, the first reading is only a baseline.
• A later reading must be higher before usage increases.
• With latest value, the newest reading should appear as the quantity.
• With time integral, at least two readings and elapsed time are needed.

​

A lower cumulative reading is ignored

This is expected for cumulative delta. Use latest value or time integral for sensors that naturally move up and down.

​

The public page still shows the previous calculation method

End the existing test session and start a new one. Price-rule changes apply to new sessions.

​

The item is unavailable

Confirm that:

• The selected price rule is active.
• The item is linked to the correct device.
• The device is online and ready.
• The start amount meets the minimum requirement of the enabled payment channels.
• The merchant is available and approved for the intended payment mode.

​

Pre-launch checklist

• The item uses Postpaid payment type.
• An active price rule is selected.
• The pricing component and unit match the service.
• The usage calculation matches the device readings.
• Start and maximum amounts have been reviewed.
• The device sends readings during an active session.
• Customer and device stop methods have been tested.
• The public page shows running usage and the expected estimate.
• A complete test session produces the expected final bill.