Business Model
Prepaid Electric meters require users to purchase electricity or credit in advance. When the balance in the meter decreases to zero, it can automatically cut off power or trigger an alert. Compared with postpaid meters, this reduces the risk of arrears and is commonly used in rental housing, temporary construction sites, and some overseas electricity markets. The system needs to integrate with billing, payment gateways, and customer service. The meter reports balance and events via NB-IoT/4G and receives remote recharge and tariff update commands.
Security
Keys and certificates need to be protected against cloning and replay attacks; over-the-air recharge messages must be authenticated. Local overdraft policies and reconciliation rules during network outages should be clearly defined in the specifications to avoid disputes.
And DL/T 645
Most domestic meters support DL/T 645 extended frames; platform integration requires unified data identifiers and reading cycles, with cellular modules serving only as transmission channels.
Billing Model and User Experience
In prepaid mode, users purchase electricity before use; power is cut off or alarms triggered in case of arrears, requiring high communication real-time performance. The platform must clearly display remaining balance, tariff version, and tier switching points; thresholds for SMS or app notifications should be configurable. Refunds, ownership transfers, and meter replacements involve balance carryover and must be consistent with the marketing system. When the cellular link is interrupted, overspending and credit strategies in the meter must be securely stored locally and reconciled afterwards to prevent malicious balance manipulation.
Operations and Risk Control
Air recharge must prevent replay, forgery, and man-in-the-middle attacks, and the lifecycle of keys and counters should be planned. Batch account opening and closing must have audit trails. When mixed networking with postpaid users, the billing engine must differentiate between two sets of rules to avoid incorrect deductions. When the module remotely upgrades rates in the table, there should be rollback and re-issuance mechanisms in case of power failure or communication failure.
Engineering Practice Supplement
Regarding the implementation of "prepaid metering" in IoT and cellular module projects, it is recommended to document network constraints (target market frequency bands and decommissioning plans, APN and private network strategies, roaming and tariffs, PSM/eDRX and other power saving modes) and terminal constraints (antenna and RF layout, power ripple and surge, thermal design and derating, EMC/safety regulations) as acceptability criteria during the project initiation stage. During the R&D phase, reproduce boundary faults using weak network simulation, high/low temperature and voltage deviations, and retain logs and waveforms; in mass production, establish batch and calibration traceability, with component replacements undergoing change reviews. After launch, include connection success rate, reconnection counts, latency, and power consumption on the operation dashboard, with anomalies traceable to version and batch.
Checking the Meter Balance and the Top-up Token
Prepaid metering means the balance, or the remaining energy, decrements inside the meter. At the threshold the policy defines, it alarms or opens the load switch. It does not wait for a billing cycle to collect later. A top-up is not a new number written into the meter. It is an authenticated token containing an amount or an energy quantity, a meter id, a key version, and an anti-replay counter. The meter increases the balance only after the signature checks. The cellular module only carries that token and the remaining credit and trip events sent upward. It cannot "change the balance" at the link layer. Many domestic meters still use extended frames of the meter protocol for data identifiers. The platform must read by those identifiers. A transparent cache in the module is not the meter's real register.
Conditions of use include keys rotated in step on the meter and on the vending system, a monotonic counter, and an offline credit limit written into the meter in advance that can later be matched to vending records. Stepped tariffs and tariff versions need an effective time. An old token must not be posted at the old price after the new tariff takes effect. A change of customer or of meter must carry the balance across. Otherwise the new meter starts at zero and the old balance is abandoned. The local switch position must be reportable, so the system does not believe power is off while the site is still using it.
Offline Credit and a Tariff Version Out of Step
The complaint that comes up most often is an overdraft policy that exists only in the cloud. While offline, the meter still follows the factory rule "open at zero." The customer has already bought energy, the token is still in the module queue, and the load is disconnected. Next, the vending system resends the same token because of a timeout, the meter's counter does not reject it, and the balance is added twice. Third, a tariff update that fails in transit is applied only in the cloud. The meter still decrements on the old step. Each account shows a small tail difference, and it is noticed only when the totals are settled.
Trip and close commands need acknowledgement and a retry. Module send-success is not enough. If power-quality events share a narrowband connection with top-ups, the token is blocked behind a waveform; see power-quality monitoring. The day top-up funds reach the merchant account is not the day they post inside the meter. The end-of-day match should list "collected, not delivered" and "delivered, not confirmed" on their own. The basis is in settlement and reconciliation.
The meter should also be able to tell "token received" from "balance increased." Module send-success only means the token left the queue on the terminal side. If signature check fails, the balance does not change. If the cloud treats send-success as posted, the customer sees a charge and no energy on the meter. The reason for a failed check has to come back: wrong key version, counter rollback, meter id mismatch, or a truncated message. The four are handled differently. When a meter is replaced, the voucher that carries the old meter's remaining credit must match the old meter's last reading. Do not write the theoretical balance from the vending system straight into the new meter. Breaker state and balance are two registers. Reading only the balance displays "credit present, switch still open" as a failed top-up. The tariff version should ride with every decrement record, so reconciliation can see whether a tail difference comes from the old tariff or from a missed read. A record with no tariff version should go to the exception list. It should not be merged straight into the daily energy total.