Model six layers, not one rate
1. Provider and network charges
Rates can vary by channel, destination, message category, sender configuration, content, provider, and effective date. Store money as integer minor units with currency and retain the price version used for each billable event.
2. Retries and fallback
A retry may create another provider attempt. A fallback may create a send on a second channel. Decide when each is permitted, how duplicate customer experiences are prevented, and which attempts are billable.
3. Compliance operations
Registrations, sender verification, template review, consent records, and policy monitoring take time. The cost is often hidden across marketing, legal, and operations rather than assigned to messaging.
4. Engineering and reliability
Integrations need idempotency, queuing, webhook verification, state reconciliation, secret rotation, monitoring, and incident handling. A low unit rate does not compensate for an integration that frequently needs manual repair.
5. Customer support
Delivery questions are expensive when a support agent cannot connect a customer, project, app, message, provider event, and charge. Good attribution is a cost-control feature.
6. Reconciliation and finance
Provider records can arrive late or change. Your invoice and ledger model must preserve provisional states, adjustments, credits, taxes, and finalization rather than rewriting history.
Do not show one number as if it knows everything
| State | Meaning |
|---|---|
| Estimated | A planning value before dispatch or complete routing facts |
| Reserved | Funds held against an accepted attempt |
| Provisional | Observed cost that may await provider reconciliation |
| Final | Settled under the applicable billing policy |
| Reversed or adjusted | An immutable correction, not a deleted historical event |
Label freshness beside totals. “Updated 20 seconds ago with 14 events pending” is more useful than a live-looking counter with unclear completeness.
Reduce cost without degrading trust
- Stop duplicates at acceptance. Require an idempotency key and make the durable request record authoritative.
- Send only while the event is relevant. Cancel reminders when the customer has already completed the action.
- Use channel preference. Do not default every event to the most expensive or intrusive path.
- Bound retries. Classify errors and avoid retrying permanent failures.
- Attribute by app. A project total cannot identify which product flow created waste.
- Review low-value templates. Delivery volume is not evidence of customer value.
A useful monthly scorecard
Review accepted requests, provider attempts, unique delivered messages, cost per completed business outcome, retries, fallback sends, opt-outs, complaints, unreconciled events, manual support minutes, and spend by registered app. Compare these measures over time and annotate product or provider changes.
A cheaper platform rate does not automatically produce a cheaper messaging operation. Optimize the full path: relevance, permission, reliability, supportability, and financial explainability.
How MessageHop applies this model
MessageHop records immutable, idempotent billing events with explicit provisional and final cost states. Public rates are not listed without a dated provider basis, approved versioned markup, and applicable tax treatment. That boundary is intentional: an illustrative rate should never become a customer promise.