Credit Balance
A Credit Balance tracks the consumable credits (USTs -- Technical Service Units) available to an organization for service-based work. Credits are the currency of the UST billing model: each type of service request has a fixed credit cost, and credits are deducted from the balance as work is completed.
How credits work
Instead of billing by the hour, MIDDAG uses a standardized credit system:
- "Plugin Update" costs 4 credits.
- "API Integration" costs 10 credits.
- "Plugin Development" costs 30 credits.
The customer buys a credit package (or receives credits as part of a service plan), and credits are consumed as service requests are fulfilled. This gives customers cost predictability and protects them from billing surprises.
One balance per organization per currency
Each organization has one credit balance per currency (BRL or USD), determined by the organization's billing entity. The balance is created automatically when the Service domain is enabled for the organization -- even if the initial balance is zero.
A zero balance does not block work. Service requests continue, and any excess is billed separately. This ensures the system always captures the true operational cost.
Credit operations
| Operation | When it happens | Effect on balance |
|---|---|---|
| Credit | Credits purchased or recharged | Balance increases |
| Reserve | Service request created | Credits soft-locked (reserved) |
| Release | Service request cancelled | Reserved credits returned |
| Consume | Service request completed | Credits permanently deducted |
| Expire | Expiration date reached | Credits removed |
Reserve and consume (FIFO)
Credits follow a FIFO (first-in, first-out) consumption model. The oldest credits are consumed first.
When a service request is created, the estimated credits are reserved (soft-locked). When the request is completed, the actual credits are consumed. If actual exceeds estimated, the difference is taken from available balance or billed as a one-off charge.
Expiration
Credits have a configurable expiration period, governed by the Credit Policy:
| Setting | Default | Description |
|---|---|---|
expiration_months | 12 | Months until plan credits expire |
grace_after_days | 30 | Grace period after expiration date |
avulso_expiration_months | 6 | Expiration for one-off credit purchases |
A daily cron job scans for expired credits and removes them from the balance. One-off credits purchased outside a plan have a shorter expiration period by default.
Low balance alerts
When the available balance drops below a configurable threshold (default: 20% of the last credit allocation), the system fires a notification. The admin and the organization's primary contact are alerted, prompting a recharge or plan adjustment.
Transaction history
Every credit operation is recorded in a transaction log:
| Field | Description |
|---|---|
| Type | credit, reserve, consume, release, expire |
| Amount | Positive for credits added, negative for deductions |
| Service request | Linked SR (if applicable) |
| Balance after | Running balance after the transaction |
| Timestamp | When the operation occurred |
| Notes | Description (e.g., "Reserve for SR-20260015") |
This log serves as the complete financial audit trail for credit consumption. Customers can view their transaction history in the portal.
What admins see
In the WordPress admin, the credit balance view shows:
- Organization name
- Current balance and reserved amount
- Currency
- Recent transactions
- Expiration schedule for active credit allocations
Admins can manually credit an organization (for recharges, corrections, or goodwill gestures) and view the full transaction history.
Related pages
- Services -- the work that consumes credits
- Service Requests -- individual tasks billed against the balance
- Policies -- Credit Policy settings for expiration and limits
- Entitlements -- the SVC entitlement that the balance belongs to