Metered Usage With a Prepaid Wallet: Debit First, Refund on Failure

Some features in our platform cost real money each time they run. Searching a mapping service for local businesses, generating an AI draft or streaming live video all involve outside providers that bill us per use. Building those features means deciding how customers pay for what they use without surprises on either side.

We chose a prepaid wallet with a simple set of rules: show the price first, debit the wallet before the paid work starts, refund automatically if the work fails and keep limits that prevent runaway spending.

Why prepaid instead of billing later

Billing for usage at the end of the month is common, and it has drawbacks for small organizations. A busy month can produce an unexpected bill. A mistake, such as an automation that runs too often, may not be noticed until the invoice arrives.

A prepaid wallet keeps spending visible. The organization adds funds, sees its balance and knows exactly what each action costs before it runs. If the balance runs low, actions stop rather than quietly accumulating debt. Wallet top-ups are paid through our shared payment hub and only credited when the verified payment confirmation arrives.

Debit first

When a metered action starts, our system first records a usage entry with its expected cost and debits the wallet. Only then does it call the paid provider. If the wallet cannot cover the cost, the action does not start.

Debiting first may sound strict, but it prevents a real problem. If the provider call ran first and the debit afterward, a crash between the two would mean work was done but never paid for, or a retry would do it twice. Debiting first makes the order of events clear: payment is reserved, then work happens.

Refund on failure

If the provider call fails, the usage entry is refunded to the wallet automatically. The debit and the refund are linked to the same usage record, so a retried job cannot refund twice. Customers pay only for work that actually happened.

Where the outcome is uncertain, such as a timeout after the provider may have completed the work, we do not automatically retry or refund. We hold the entry for review, so neither the customer nor the provider is charged twice for the same result.

Prices set in one place

Each metered feature has its prices set by our administrators in a pricing screen, often as a markup on the provider's cost with optional fixed prices for specific actions. Prices are never buried in code. When the provider changes its pricing, we update one setting rather than shipping a release.

Limits that protect everyone

Metering needs guardrails:

• A minimum balance before a costly feature can start
• Monthly spending limits on the provider side, so a bug cannot run up an unlimited bill
• Daily limits on automatic top-ups for organizations that choose to refill from a saved card
• Clear usage history so organizations can see what was used, when and at what cost

Prices are captured when work starts

Prices change from time to time, as provider costs move or as we adjust a feature. A long-running activity, such as a live stream that lasts an hour, should not suddenly cost more in its final minutes because a price changed midway. So metered sessions keep the billing terms and prices that were in effect when they started. Customers can trust that the cost they saw at the beginning is the cost that applies.

Internal use is recorded, not charged

When Jag Journey uses its own features, or when internal accounts run them, the usage is still recorded at cost so we know what it costs us, but it is not charged to a wallet. Measuring internal use honestly helps us price features sustainably.

AI credits follow a similar path

Our AI features use credits that are purchased with wallet funds and shown with an estimate before work starts. Every AI feature is listed in a registry with its billing rules before it can run. You can read more in every AI call is registered before it runs.

Frequently asked questions

What is a prepaid wallet?

A prepaid wallet holds funds an organization adds in advance. Metered features draw from it as they are used, so spending is visible and capped by the balance.

What happens if a paid action fails?

The amount debited for that action is refunded to the wallet automatically, so you only pay for work that completed.

Can usage charges run out of control?

Wallet balances, minimum balance requirements and spending limits are designed to stop actions before costs grow unexpectedly.