Usage-based billing needs a unit the customer understands and a calculation you can explain. A payment processor carries out a transaction; do not assume it also measures consumption of your service.
Choose a clear unit
It might be a session, request or consumed unit. Define when it counts, any minimum and what is excluded. “Service usage” is too vague if the same action can be recorded more than once.
Keep an event reference and calculation period. This helps identify duplicates and explain an adjustment without deleting the original record.
A fictional worked example
Assume €0.20 per unit for a closed period. This calculation does not establish tax treatment or represent AndorPay pricing.
| Item | Units | Amount |
|---|---|---|
| Recorded usage | 100 | €20 |
| Identified duplicates | −10 | −€2 |
| Billable usage | 90 | €18 |
Before preparing the €18 payment, the system should explain which ten units were excluded. If usage changes after the period closes, decide whether to correct that period or create a later adjustment.
Upfront, afterwards or with a fixed element?
Prepaid credit requires rules for what happens when it runs out. Charging afterwards requires limits and a closing schedule. A fixed fee plus usage model should explain what is included and when additional charges begin.
These rules do not appear simply by renaming a plan. Your subscription worksheet should describe them, and the software must support the calculation.
What should the integration check?
Separate usage recording, calculation, document and payment. Test duplicate events, missing data, adjustments and unknown payment outcomes. Fix each operation’s amount so later usage changes cannot silently alter a sale already submitted.
Considering this model? Tell us the unit, frequency and system measuring usage. We can review the payment part and identify the connections that need confirming.