grant/keysat
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
76 Commits 1 Branch 0 Tags
033a1f4a6a00c4315a5cbd4583e92ed797d95eee
Commit Graph

2 Commits

Author SHA1 Message Date
Grant 54f7ea08b5 P1 — change-tier UX, Zaprite webhook copy, self-tier guard, Lightning copy 
Bundle of bugfixes from the P1 testing batch. None individually
huge; together they close several "tested it, hit a sharp edge"
items.

1. Change-tier modal — kill the paid path from UI
   The Apply-as-comp toggle is gone. Admin tier changes always
   apply as comp now. The reasoning (per Grant's testing): admin
   tier changes are operator-driven, payment has either already
   happened off-rails or it's a comp; the "admin generates
   invoice and forwards URL" flow is a tiny niche that just
   produces orphan invoices when the modal gets dismissed.
   Buyers who want to pay use the SDK's /v1/upgrade.
   The API path is unchanged for back-compat with scripted
   operators (skip_payment defaults to true here).

2. Change-tier modal — downgrade detection + warning banner
   Detects target.tier_rank < current.tier_rank (or price-diff
   when ranks aren't set), renders a yellow warning card listing
   the entitlements the buyer is about to lose, and confirms via
   browser dialog before submit. Operator sees what they're
   doing.

3. Self-tier guard on admin change-tier
   POST /v1/admin/licenses/<id>/change-tier rejects when <id>
   is the daemon's own self_license. Avoids the recursion Grant
   hit when trying to downgrade himself: the on-disk signed key
   is the source-of-truth at boot, so the DB tier_change just
   produces a half-applied state. Error message points at the
   right paths (re-mint via master Keysat OR rename
   /data/keysat-license.txt for testing). With the P0 self-tier
   live-refresh in place the recursion is now fully resolved
   anyway, but the guard is good belt-and-suspenders for
   operator clarity.

4. Zaprite webhook — full URL in copy + persistent action
   - The Connect Zaprite action now shows the EXACT
     https://your-keysat-url/v1/zaprite/webhook URL to paste
     into Zaprite's dashboard. Previous copy showed a
     placeholder "<your Keysat public URL>/...", which Zaprite's
     form rejects (it requires full https://). Daemon's
     /v1/admin/zaprite/connect now returns webhook_url; the
     action displays it.
   - New "Show Zaprite webhook setup" StartOS Action — operators
     who skipped the step on first connect, or who lost the
     output, can run this any time and get the URL again.
   - Full explainer of what webhooks unlock vs polling-only:
     "without webhooks, Keysat polls /v1/orders every 60s, so
     license issuance lags settle by up to a minute; with
     webhooks, ~1s." Lives on /v1/admin/zaprite/status response
     as `webhook_explainer` + in the action's display text.

5. Connect-while-connected short-circuit
   POST /v1/admin/zaprite/connect now returns 409 Conflict with a
   clear "already connected — disconnect first" message instead
   of silently overwriting an existing config. (BTCPay's
   start_connect already had this guard since the durable
   provider switch work.)

6. Lightning vs on-chain copy on the wait page
   /thank-you was hard-coded to "next block confirms" — wrong
   for Lightning payments (instant) and confusing in the common
   case where buyers paid via Lightning and saw a "waiting for
   block confirmation" message. Updated to: "Lightning settles
   in seconds; on-chain typically settles in 10-20 minutes (one
   block confirmation)." Method-aware copy (parsed from the
   provider's invoice payload) is a deeper fix but out of scope
   here — this gets the operator-facing accuracy right today.

Test count unchanged; all 77 still passing.
 2026-05-09 13:58:03 -05:00
Grant 9eba309a8f v0.2.0:2 — Zaprite payment provider + recurring subscriptions schema foundation 
This release adds Zaprite as an alternative to BTCPay. Operators
can now choose between two payment rails:
- BTCPay: Bitcoin-only, you run the BTCPay Server yourself
- Zaprite: Bitcoin + fiat cards (USD/EUR via Stripe/Square), brokered
  by Zaprite, settles to your connected wallets

Only one is active at a time per Keysat instance. Switching requires
Disconnect → Connect; existing license keys are unaffected. Future
v0.3 work routes per-policy choice (e.g., "free tier via Zaprite,
paid tier via BTCPay") if operators want both, but for v0.2.0:2 it's
either-or.

What's in this release:

**Migration 0011 — recurring subscriptions schema (dormant).**
Adds `subscriptions` and `subscription_invoices` tables, plus
`is_recurring`/`renewal_period_days`/`grace_period_days` (default 7)/
`trial_days` (default 0) on policies. No daemon code uses these
yet — phases 2-6 of RECURRING_SUBSCRIPTIONS_DESIGN.md land in
follow-up commits. Migration regression test covers the additive
contract against populated data.

**Migration 0012 — zaprite_config.** Singleton-row table for the
operator's Zaprite API key + base URL + recorded webhook id.
Mirrors btcpay_config from migration 0002.

**ZapriteProvider implementation.** New module at
src/payment/zaprite/ with client.rs (HTTP, Bearer auth), config.rs
(DB persistence), provider.rs (PaymentProvider trait impl). Maps
Zaprite's currency enum (BTC/USD/EUR) to/from the Money type;
maps Zaprite's order status enum (PENDING/PROCESSING/PAID/COMPLETE/
OVERPAID/UNDERPAID) to ProviderInvoiceStatus.

**Webhook security via externalUniqId round-trip.** Zaprite does
NOT publish a webhook signature scheme (verified May 2026 against
public OpenAPI + dashboard). Their docs explicitly designate
receiver-side idempotency as the security model. Keysat's defense:
attach our local invoice UUID as externalUniqId at order creation,
then trust the webhook only insofar as the order id resolves to
a local invoice in an expected state. Documented in detail in the
payment::zaprite module-level comment + the validate_webhook
docstring.

**Admin endpoints.**
- POST /v1/admin/zaprite/connect: validates the API key by pinging
  GET /v1/orders before persisting; swaps active provider atomically
- POST /v1/admin/zaprite/disconnect: clears stored creds + provider
- GET  /v1/admin/zaprite/status: read-only connection snapshot
- POST /v1/zaprite/webhook: webhook landing route (alias of the
  existing /v1/btcpay/webhook handler since validate_webhook is
  trait-level)

**StartOS Actions** under a new "Zaprite" group: Connect Zaprite,
Check Zaprite connection, Disconnect Zaprite. Operator pastes the
API key into a masked input; daemon validates + saves.

**Tests.** Two new in tests/api.rs (zaprite_webhook_event_parsing
covers the full event-type mapping + missing-id rejection +
malformed-JSON rejection; zaprite_provider_kind pins the
identification). Migration regression test for 0011. Test count
grows 39 → 41.

Operators on BTCPay see no change. Operators wanting Zaprite go
through the StartOS Actions tab → Connect Zaprite, paste their
API key, register a webhook in Zaprite's dashboard pointing at
their public Keysat URL + /v1/zaprite/webhook.

Recurring subscriptions are NOT yet operator-visible — schema only
in this release. Daemon-code that uses the subscriptions tables
(renewal worker, validate-hot-path subscription branch, admin UI)
lands in subsequent commits per the design doc's phased plan.
 2026-05-08 16:34:58 -05:00