Prepaid Credit, Refunds, and Unused Balance
1. Separate payment from consumption
Prepaid billing has two distinct events: funding an account and consuming services. A successful payment adds purchasing capacity; API requests consume that capacity according to the applicable rates. Depositing money does not mean you have already spent it on inference.
For engineers using CodeRelay Hub, a pay-as-you-go API hub, this distinction matters when reconciling payments against requests routed through https://api.coderelayhub.com. Keep payment records separate from usage records. One explains how the account was funded; the other explains what workloads consumed.
2. Identify what the balance contains
A displayed balance is not necessarily a single pool with identical conditions. Before calculating what remains available or potentially refundable, determine whether different credit categories exist and how each is treated.
- Purchased credit: Value added through a payment.
- Promotional credit: Value granted through an offer, potentially subject to separate restrictions.
- Adjustments: Credits or debits correcting earlier accounting entries.
- Reserved usage: Amounts temporarily allocated to work that has not finished settling, if the billing system uses reservations.
These are categories to check, not a claim that every platform implements them. If the dashboard shows only one number, ask for a breakdown before assuming every unit has the same refund or expiration rules.
3. Reconcile settled usage before calling money unused
Start with an accounting identity: opening credit plus additions and adjustments, minus settled usage and completed refunds, equals closing credit. If your application maintains its own ledger, compare records over the same time window and account for reporting delays.
Capture request identifiers, timestamps, selected models, reported usage, and charge information when available. Distinguish an unsuccessful application operation from an unbillable API request: a client timeout alone does not establish whether upstream processing occurred or whether a charge applies.
Retries deserve particular attention. A repeated request can represent additional work rather than a replacement for the first attempt. Investigate individual records instead of subtracting every failed client operation from the invoice.
4. Check eligibility before requesting a refund
Unused credit and refundable credit are different concepts. Refund eligibility depends on the applicable terms, credit source, payment circumstances, and any relevant requirements. This walkthrough does not establish CodeRelay Hub's refund policy, expiration rules, or processing timeline.
Before submitting a request, verify whether purchased credit is eligible, whether a request window applies, whether promotional amounts are excluded, and whether fees or minimum amounts affect the result. Also confirm the destination of an approved refund. An account adjustment and money returned through a payment method are not interchangeable outcomes.
5. Make the request easy to investigate
Provide the workspace identifier, payment reference, payment date, amount paid, requested refund amount, and a concise explanation. Include a balance snapshot with its timestamp, but treat the underlying transaction history as the stronger reconciliation record.
Never send API keys, full card details, or authentication tokens in a support message. If usage appears incorrect, provide the relevant request identifiers and explain the discrepancy precisely. Ask for confirmation of the approved amount and any resulting balance adjustment rather than assuming your requested amount will be returned.
6. Treat unused balance as an operating decision
If you plan to keep using the service, estimate funding needs from your own recent settled usage and expected workload. Smaller, deliberate top-ups can reduce the amount left idle, although the right funding cadence depends on payment options and operational needs.
Keep referral accounting separate, too. The referral reward is 11% of what referred users pay, which is a payment-based figure, not a measure of their API consumption. Do not assume referral earnings and purchased API credit have identical withdrawal, refund, or expiration conditions.
7. Verify the final state
Before retiring a workspace, stop scheduled jobs, disable automatic funding if configured, and let outstanding requests finish or reach a known state. Then reconcile the final usage ledger, any approved refund, and the remaining balance. Save transaction references and confirmations for your records.
A zero balance is not sufficient evidence that a refund reached its destination. Verify both sides: the workspace adjustment and the corresponding payment record.
Open a free workspace to get started.