# Purchases, receipts, and refunds

Source: https://convergingthought.com/docs/billing/payments

> Follow credit from a verified payment event into the project ledger.



Internalize uses prepaid project credits. Purchases start at $10 through Polar, with no free trial or automatic top-up.

## Live purchase flow [#live-purchase-flow]

Open [Billing](/internalize/app/billing), select **Add to balance**, and choose an amount. The purchase form accepts whole-dollar amounts from $10 to $1,000, with $25 suggested.

You can also select **Add credits** from the playground or memory dialog. Checkout returns to the original project and restores the draft, whether you complete or cancel the purchase. No model call starts automatically.

Polar handles checkout and payment details. Applicable tax is shown at checkout. Internalize credits the purchased value before discounts; tax is not converted into inference credit. A $10 credit purchase grants $10 of normal spendable credits even when an approved discount reduces the payment, including a 100% discount. The receipt records the discount and the actual amount paid.

Keep the selected project in mind. Credits belong to the project associated with the checkout, not to every project in the account. The current console does not expose self-service balance transfers between projects.

## Payment confirmation [#payment-confirmation]

Returning from checkout does not itself create a balance. A verified payment event updates the durable payment record and credit ledger. This prevents an unverified redirect or repeated page refresh from granting credit.

Duplicate events for the same paid order do not issue credit twice. If checkout succeeded but the balance has not updated, inspect the receipt and project, then allow the payment event to reconcile. Do not immediately buy again merely because the first browser redirect was interrupted.

## Receipts and credit activity [#receipts-and-credit-activity]

The Billing workspace shows the most recent 100 ledger entries, including purchases, settled usage, and refunds. References link an entry to its payment order or job identity. The display can round dollars for readability, while the ledger retains micro-USD precision.

**Receipts & payment details** opens the payment portal after the project has payment history. Payment-card details are managed by Polar rather than stored in the console's project record.

## Refunds [#refunds]

A refund removes the credited principal associated with the refunded amount. It does not erase historical inference or learning usage. If the resulting balance no longer covers open reservations, the project can be frozen against new spending until the mismatch is resolved.

Refunds reverse the same proportion of the purchased credits as the refunded payment. For example, a $10 credit purchase discounted to $8 loses $5 of credits when $4 is refunded. A full cash refund reverses the full credit package. Zero-dollar orders have no cash to refund.

Refund handling is monotonic: a later duplicate paid event cannot undo a recorded refund and mint the credit again. Do not try to repair a mismatch by manually changing a displayed balance or repeatedly revisiting a checkout URL.

The console does not provide a self-service refund initiation control. Contact [team@convergingthought.com](mailto:team@convergingthought.com) with the authorized project and order reference for a billing question. Do not include card numbers, full payment credentials, API keys, or source content.

For a usage discrepancy, start from the job's settled charge and the corresponding ledger entry. See [Credits and pricing](/docs/billing) and [Usage](/docs/product/usage) to distinguish a reservation, a charge, and a rounded summary.