No billing history: a paying user cannot see what they bought, when, or why their limits dropped

[KruGoL]

The wallet can buy a subscription but never shows what was bought. Three
questions a paying user will ask have no answer anywhere in the UI:

• "I paid — where is my order?" If the tab was closed and the order id is
  gone, the only remaining trace is Paymento's email. order-status is keyed by
  orderId alone and there is no list endpoint.
• "What did I buy, and when?" Nothing records it. Settings → Subscription
  shows the CURRENT plan, its expiry and two usage bars — no history.
• "Why did my limits drop?" The gateway lazily demotes a lapsed paid
  subscription to free with no error — silently lower limits.
  PlanDowngradeWatcher catches it and opens the upgrade modal with the
  'expired' banner, but nothing says which plan expired or when.

The data already exists

paymento_orders carries order_id, token, plan_id, email,
price_cents, status, status_name, api_key / upgrade_api_key,
key_revealed, settlement_json, fulfilled, awaiting_confirmation,
created_at, updated_at.

GET /api/paymento/order-status?orderId=… already returns orderId, status
(created | pending | paid | failed), statusName (raw Paymento, incl.
UserCanceled), fulfilled, confirming, settlement (on-chain details from
/verify), upgrade, maskedKey and planName. GET /api/paymento/key-info
(by x-api-key) returns maskedKey, planName, subscriptionState
(active | expired | inactive) and activeUntil.

So date, plan, amount, status, settlement and expiry are all available today.
What is missing is a way to ask for them per wallet, and a surface to show them.

The purchase IS linkable to the wallet on the normal path

PlanScreen.startCheckout always asks for an in-place upgrade of the key the
wallet already holds ("same key, new plan, fresh 30 days"); a fresh key is
minted only against a pre-upgrade gateway or when the user explicitly picks
forceNewKey. That existing key is the identity-bound one provisioned at
onboarding through /auth/verify, which carries
api_keys.owner_id = "<network>:<pubkey>".

So for a normal purchase the chain already closes server-side:

paymento_orders.upgrade_api_key → api_keys.owner_id → network:pubkey

No schema change is needed to answer "the orders belonging to this wallet" for
the common case. Only a fresh-key purchase stays unlinked (api_keys rows
created outside getOrCreateOwnerKey leave owner_id NULL).

Options

A. Local ledger (wallet only). Stop deleting the PendingOrderRecord
(src/sdk/subscription/pendingOrder.ts, added by #504) at terminal status;
fold it into a compact completed entry — order id, plan name, price, created,
settled, status, key mask, never the key — and render Billing from it. No
gateway change, works for fresh-key purchases too. Cost: the history lives in
one browser and cannot be recovered after a wipe or on another device.

B. Server-side history endpoint (gateway). A read endpoint listing orders
whose upgrade_api_key belongs to the caller's owner key. Covers the normal
path with no schema change; survives reinstalls and works across devices.

Authentication must be the pubkey challenge (/auth/challenge +
/auth/verify), NOT x-api-key. Keys are deliberately portable — the wallet
offers "Use a different key" and the timeout path offers "I have a key" — so a
key-authenticated endpoint would hand anyone holding a pasted key the buyer's
order history and their email. Signature auth exposes nothing new: only the
holder of the private key can read, and they already know both halves.

C. Bind fresh-key purchases too. The wallet already calls
order-key-ack?orderId=… after storing a purchased key durably. Signing that
call would let the gateway set owner_id on the purchased key. Note two costs:
it ends the key's portability, and api_keys has a UNIQUE partial index on
owner_id, so a wallet cannot own two keys as the schema stands.

Recommended: A + B — the ledger for the surface and for offline/fresh-key
coverage, the endpoint so the history survives a reinstall. C only if key
portability is being dropped anyway.

Two related facts the page should state honestly

• There is no cancellation and no refund. The Paymento store has no cancel
  endpoint; payment_sessions / refund_amount belong to the legacy
  /api/payment/* flow, not to this one. "Cancel this payment and start over"
  sets a local abandonedAt only — the order lives on and can still settle
  (which is Cut the abandon/background-settlement machinery: a recovered key from a cancelled order has nowhere to land #508). Nothing to cancel in the subscription sense either: it is
  not recurring, it simply expires after 30 days.
• A downgrade costs the remaining days. isPlanSelectable blocks only
  re-buying the CURRENT active plan, so a cheaper plan is purchasable; on
  fulfilment changePlan(key, planId, expiry) sets the new plan with a fresh
  30 days and no proration. Buying down silently discards whatever was left.
  Either warn in the UI or refuse the move while a paid plan is active.

Bonus: this gives #508's orphaned key a home

#508 describes a key delivered by a cancelled-but-settled order that has
nowhere to land: the toast points at Settings → Subscription, which cannot
reach it, so a paid key is announced and then lost. A Billing list is exactly
that missing home — the order appears as a row with "key delivered" and an
"install this key" action.

Out of scope, worth filing separately

The browser learns about payment only by polling: the gateway has an IPN
callback from Paymento and its own 5-minute re-verification for 24h, but no
SSE or WebSocket anywhere, so the page updates on the next poll tick rather
than when the payment confirms.

Related: #501, #504, #508.

---

Where the gateway-side half is tracked

Everything this page needs from the SGW — the per-wallet order listing, a push
so the screen reacts when a payment confirms, cancellation, proration and an
expiry signal — is collected in
unicitynetwork/aggregator-subscription#83. Options B and C above are items 1
and 6 there; option A (the local ledger) needs nothing from the gateway and can
ship on its own.

The downgrade warning this page would have to explain is filed separately as
#510.

[KruGoL]

Decision: the local-only option (A) is rejected. A history that lives in one
browser cannot answer "where is the order I paid for" at the moment people ask
it — after clearing site data, on another browser, or on a second device. A
tried implementation is closed in #514.

So this issue now depends on option B and nothing else:
unicitynetwork/aggregator-subscription#83 item 1 — a gateway endpoint listing the
caller's orders, authenticated by the /auth/challenge + /auth/verify pubkey
signature, never by x-api-key.

Two things worth carrying forward when it is built:

• The link already exists for the normal path. Sphere's checkout always asks for
  an in-place upgrade of the identity-bound key, so
  paymento_orders.upgrade_api_key → api_keys.owner_id → network:pubkey closes
  without a schema change. Only fresh-key purchases stay unlinked
  (owner_id is NULL on them).
• Nothing is being archived in the meantime. The wallet deletes a settled
  order's record at each terminal outcome, so orders that settle before the
  endpoint exists will not appear in any history later — accepted, not
  overlooked.