Grant
7c4dfbacd2
Threads the merchant-profile + payment-provider snapshot semantics through
every call site that used to call state.payment_provider() (the legacy
"active provider" singleton). New invoices now record which provider
settled them; subscriptions snapshot both merchant_profile_id and
payment_provider_id at creation so mid-cycle product re-routing doesn't
redirect existing buyers; the reconciler picks the right provider per
invoice; tipping draws from the same Bitcoin balance that received the
purchase; tier-change invoices stick with the buyer's existing merchant
identity.
migrations/0021_invoice_provider_link.sql (new)
Adds invoices.payment_provider_id (nullable FK), backfills existing
pending/settled rows to the earliest-connected provider on the default
profile. Additive — no drops, no removals. Companion to 0020 from the
foundation commit.
models.rs
Invoice gains payment_provider_id: Option<String>.
db/repo.rs
row_to_invoice reads the new column. All three invoice SELECTs include
it. create_invoice + create_invoice_with_currency take a new optional
payment_provider_id parameter and persist it on INSERT.
subscriptions.rs
Subscription struct gains merchant_profile_id + payment_provider_id
(snapshotted on create). SUB_COLS + row_to_subscription + the manual
SELECT in find_lapsing_subscriptions all updated. create_subscription
accepts both new fields and writes them on the INSERT row.
renew_one — reads the sub's payment_provider_id snapshot and resolves
the provider via state.payment_provider_by_id(). Falls back to the
legacy state.payment_provider() for any subs created pre-:52 that
the migration backfill missed.
capture_zaprite_payment_profile — uses the INVOICE's provider, not
"the active one." Saved-profile ids are scoped per Zaprite org; using
the wrong provider would fail the lookup.
try_auto_charge_zaprite — uses the sub's snapshotted provider (same
rationale).
reconcile.rs
Per-invoice provider lookup. Each pending invoice is reconciled
against state.payment_provider_by_id(inv.payment_provider_id), with
graceful fallback for NULL provider ids. No more single-global-
provider assumption.
tipping.rs
Tip pay-out uses the provider that settled the license's purchase
invoice (joined via licenses.invoice_id). Same rationale as the
capture hook — the tip needs to draw from the right LN node.
api/upgrade.rs (both buyer-driven and admin-driven tier-change sites)
Tier-change invoices ride on existing licenses. The right provider
is whichever the license's subscription is snapshotted to (so the
proration charge settles to the same merchant identity that collects
renewal fees). Falls back to the invoice's recorded provider, then
the legacy default, for licenses with no subscription or pre-
snapshot rows.
api/purchase.rs
StartPurchaseReq gains an optional `rail` field
("lightning"/"onchain"/"card") for the future buy-page multi-rail
picker. When omitted (today's behavior), the daemon picks the first
rail the product's merchant profile exposes — which is correct for
single-provider operators AND back-compat for any pre-:52 client
not yet sending the field.
Provider resolution: product → merchant_profile → rail →
resolve_provider_for_profile_rail. The redirect_url defaults to the
profile's post_purchase_redirect_url (with {invoice_id} substitution)
if set, else Keysat's own /thank-you. New invoices carry their
provider's id via the new create_invoice_with_currency parameter.
api/webhook.rs
issue_license_for_invoice now passes snapshot fields when calling
subscriptions::create_subscription — both merchant_profile_id (from
product lookup) and payment_provider_id (from the invoice row).
main.rs
Replaces the legacy "active provider preference" boot loader with a
default-profile-first-provider warm-up. The legacy state.payment
singleton stays populated for back-compat with call sites that
haven't yet migrated to the on-demand resolution path. Pre-migration
fallback to the old singleton-config loaders preserved so the
daemon still boots cleanly on a DB that hasn't run 0020 yet.
Remaining for part 3:
- BTCPay + Zaprite connect flows take merchant_profile_id and
INSERT into payment_providers (currently still write to the
dropped singleton tables, broken post-migration).
- api/payment_provider.rs activate endpoint becomes irrelevant in
the new model — repurpose as list-providers, or delete.
- Thank-you page (api/mod.rs) provider-kind lookup ports to the
invoice's recorded provider.
- Webhook routes refactor to /v1/{kind}/webhook/{provider_id}.
- Admin UI for Merchant Profiles + product picker + buy-page brand
block + rail picker.
- Tier-cap wire-up for unlimited_merchant_profiles entitlement.
- Version bump to :52 + release notes.
Build: cargo check passes. Deprecation warnings remaining flag exactly
the call sites listed above as the part 3 todo list.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
49 lines
2.3 KiB
SQL
49 lines
2.3 KiB
SQL
-- Link invoices to the payment provider that created them.
|
|
--
|
|
-- Companion to migration 0020 (merchant profiles + multi-provider). With a
|
|
-- single active provider, the reconciler could just iterate pending
|
|
-- invoices and call `provider.get_invoice_status()` on every one — every
|
|
-- invoice was implicitly from the only configured provider. With
|
|
-- N providers per profile and M profiles per Keysat instance, that
|
|
-- assumption breaks: each invoice needs to record WHICH provider it was
|
|
-- created against so the reconciler can dispatch to the right
|
|
-- `get_invoice_status()` and the webhook handler can validate against
|
|
-- the right secret.
|
|
--
|
|
-- Additive: nullable column + index. Backfill points every pre-migration
|
|
-- invoice at whatever provider was active when 0020 ran (same heuristic
|
|
-- the subscriptions backfill uses — earliest-connected on the default
|
|
-- profile). Post-migration, `repo::create_invoice_with_currency` always
|
|
-- writes the provider id.
|
|
--
|
|
-- Why not part of 0020: 0020 has shipped to the master operator's git
|
|
-- history (commit 04e0dcd) but not yet been *applied* to any DB (the
|
|
-- master box is still on :51, which has neither migration). The append-
|
|
-- only convention for migrations is the safer pattern even when we could
|
|
-- technically still rewrite 0020 — keeps the sqlx migration hashes
|
|
-- stable for anyone who ever runs an intermediate WIP build.
|
|
|
|
PRAGMA foreign_keys = ON;
|
|
|
|
ALTER TABLE invoices
|
|
ADD COLUMN payment_provider_id TEXT REFERENCES payment_providers(id);
|
|
|
|
CREATE INDEX IF NOT EXISTS idx_invoices_provider
|
|
ON invoices(payment_provider_id);
|
|
|
|
-- Backfill existing pending/settled invoices to point at the provider
|
|
-- that was active when 0020 ran. Heuristic: pick the provider on the
|
|
-- default merchant profile whose kind matches the (now-removed)
|
|
-- active_payment_provider setting if it existed pre-0020; else the
|
|
-- earliest-connected provider on the default profile. Mirrors the
|
|
-- backfill logic in 0020's UPDATE subscriptions block — same merchant
|
|
-- identity, same provider, deterministic across re-runs.
|
|
UPDATE invoices
|
|
SET payment_provider_id = (
|
|
SELECT id FROM payment_providers
|
|
WHERE merchant_profile_id = (SELECT id FROM merchant_profiles WHERE is_default = 1)
|
|
ORDER BY connected_at ASC
|
|
LIMIT 1
|
|
)
|
|
WHERE payment_provider_id IS NULL;
|