generation credit refund receipt: Save evidence for the refund decision

A generation credit refund receipt is an application evidence record, not a separate public receipt endpoint exposed by the current gateway. Its purpose is to show why a refund was expected, what ledger evidence was observed, and whether job settlement completed. A reassuring status message alone cannot answer those questions.

Start with the expected outcome

Record the job identifier, model, reserved credits, observed state, error code where present, and the reason a refund is expected. Keep the original submission response or error response that supplied the identifier. A failed client connection without a known job needs an unresolved-attempt record rather than a fabricated refunded job.

The current service refunds failed and canceled terminal updates. It also has a settlement retry path for an explicitly recorded submission failure. A missing output download, an abandoned browser tab, or a human rejection of an otherwise successful image is not automatically the same event.

If the upstream accepted work but the application could not persist its reference, preserve that distinction. Do not generate a receipt claiming rejection merely because the HTTP request ended unsuccessfully.

Link to ledger evidence

The refund helper uses a deterministic transaction identifier shaped as job-refund followed by the job identifier, and it records a REFUND entry with a reason-bearing description. It also checks matching historical positive refund entries to avoid crediting more than the requested target amount.

For an internal reconciliation report, store the observed refund transaction identifiers, amounts, timestamps, and their source. Public job responses do not become a general ledger export simply because an operator can inspect those records internally. If your application lacks ledger access, mark the ledger evidence as unavailable rather than filling it from inference.

The job’s creditsActual value and the ledger credit are related but distinct evidence. A refund might be recorded while a later settlement update still needs attention. Keep both observations with timestamps.

Use a concrete local record

A fictional receipt can state: job fixture-17 reserved twenty credits, terminal failure was observed, twenty refunded credits were found in an internal ledger snapshot, and actual consumption was recorded as zero. Label such a record a fixture and leave production identifiers out of examples.

Include an evidence status such as awaiting ledger verification, awaiting job settlement, reconciled, or conflict. These are your application’s states. They are not additional gateway job states or new provider response fields.

Review delivery and privacy

Restrict detailed receipts to the owning user or authorized operators. Redact credentials and private input URLs from exported support records. Keep enough identifiers to locate the job without publishing the entire creative brief unnecessarily.

Acceptance requires that another operator can follow the reason, job, expected amount, observed ledger entry, and settlement outcome. Continue with partial refund reconciliation, accepted job refunds, and credit reservation before marking a disputed refund resolved.

Continue with costs and billing

• AI image generation API pricing compared: Nano Banana, Flux Pro, Ideogram v3
• How to cap spending on a generation API key
• Flux API cost at volume: what 10, 100 and 10,000 images work out to
• Browse all costs and billing guides