API Refund Policy Template and Decision Guide
Create an API refund policy for prepaid credits, subscriptions, metering errors, outages, leaked keys, and billing disputes.
Refund rules should match how usage is delivered
Digital API usage is often consumed immediately and cannot be returned. That does not justify a vague no-refund sentence. A useful policy separates unused prepaid balance, already consumed usage, recurring subscription fees, duplicate charges, metering errors, and service failures.
This material is a drafting guide rather than legal advice. Consumer law, payment-network rules, tax treatment, and contractual obligations vary by jurisdiction and customer type. Obtain legal review before publishing final terms.
Classify the reason for the request
Support teams need categories that lead to consistent decisions. A duplicate payment or confirmed meter defect is different from dissatisfaction after substantial usage. A provider outage is different from a customer integration error. Define these categories before cases arrive.
| Scenario | Evidence | Possible resolution |
|---|---|---|
| Duplicate charge | Payment identifiers and invoice | Refund duplicate payment |
| Metering error | Usage logs and calculation replay | Correct invoice or issue credit |
| Service outage | Status and request records | Service credit under published policy |
| Customer bug | Valid authenticated usage | Usually no refund; discretionary review |
| Leaked key | Usage anomaly and incident report | Case-by-case review after revocation |
Treat prepaid credits explicitly
State whether unused credits are refundable, whether promotional credits are excluded, when balances expire, and what happens after account closure. If credits are nontransferable and have no cash value, say so clearly before purchase.
Consider a short refund window for substantially unused first purchases while protecting against abuse. Define the usage threshold and processing method. Avoid promising instant refunds when payment settlement, taxes, or fraud review can create delays.
Explain credential incidents and customer controls
API keys are bearer credentials, so the account owner is generally responsible for authenticated usage. The policy should require secure storage and prompt revocation after suspected disclosure. At the same time, provide practical controls: usage alerts, spending caps, per-key limits, recent activity, and one-click revocation.
A fair policy allows review of confirmed incidents without guaranteeing reimbursement. Consider the customer's response time, prior alerts, unusual locations, the effectiveness of your abuse controls, and whether your own security failure contributed to the usage.
- Require the customer to revoke the affected key before review.
- Request timestamps, key prefix, workspace, and expected usage pattern.
- Preserve relevant logs without collecting the full secret.
- State whether temporary account restrictions may apply during investigation.
Publish a simple request process
List the support address, request deadline, required account and invoice details, expected review time, and refund destination. Refunds should normally return to the original payment method; account credits should be offered only when permitted and clearly accepted.
Track refund rate and reasons in the API Pricing Calculator. Frequent refunds may indicate confusing pricing, weak alerts, billing defects, or poor onboarding. Updating the product is often more valuable than tightening the policy language.