Cards and prepaid credits

r2db uses a separate account and ledger for this product. It does not use Headwaters billing records.

Add a card

In Billing, choose Add a card. Stripe's hosted Checkout collects and stores the payment method. Card numbers never pass through the r2db application.

The console displays the card brand, last four digits, and expiry. Manage payment methods in Stripe's customer portal.

Add credits

Choose a top-up amount from $10, $25, $50, or $100. The API accepts $10–$1,000 in whole cents.

A completed checkout page is not proof of payment. Your balance changes only after the service verifies Stripe's signed webhook and confirms the paid amount, currency, customer, and account.

The payment intent is the ledger reference, so replaying an event or delivering multiple events for the same purchase cannot add credits twice.

Trial credits

An invited preview account may start with a one-time trial credit, which the operator configures. It appears in your credit activity as **Preview trial credits** and is granted once per account, so signing up again does not repeat it.

Trial credit admits requests exactly like purchased credit, and in this preview neither is spent by using the service — see **Spending credits** below.

Spending credits

**This preview does not meter usage.** A positive balance is what admits your requests, and running them does not reduce it. Only purchases and trial grants move your balance, and your credit activity shows those.

The operator still configures a request price in microdollars, and a zero or missing price disables data requests entirely until they set one. The console shows that configured rate as what a request will cost when metering arrives, not as what is being deducted today.

Per-request metering was removed because it could not pay for itself. Recording one request's charge wrote two rows to the control database, which cost twice what the request was priced at. Metering returns aggregated — counted inside your database and written to your ledger periodically — rather than one ledger row per request. Storage and upload traffic are not metered either. Production pricing has to account for all of it before a public launch.

Balance and payment state

Database creation requires a positive balance, and in this preview it also requires that your email address be on the operator's invite list — an account that is not on it is refused with HTTP 403 rather than 402, and adding credits will not change that. Application calls return HTTP 402 when your balance is not positive. A canceled checkout leaves the balance unchanged. If the browser returns before the webhook arrives, refresh the balance after a moment.

This release supports purchases. Usage metering, refunds, disputes, automatic top-ups, tax handling, and email receipts configured outside Stripe need an operator policy before public launch.

Live results and retries

Live queries are implemented, and this preview meters none of what they cost: not the subscription, not the write-driven delivery that follows it, and not storage. Opening a subscription checks your balance and does not reduce it. Complete production workload pricing remains release work. Hibernatable sockets do not imply an object stays resident for the entire connection lifetime.

A write retried with the same idempotency key applies its operations once within the 24-hour receipt window.