Payment providers should be constructed from database configs (complete PaymentMethodFactory integration)

[v0l]

PaymentMethodFactory (lnvps_api/src/payment_factory.rs) can build payment handlers from database payment_method_config rows (create_lightning_node, create_fiat_service, create_onchain_provider, get_*_for_company), and the startup data migration seeds those rows from YAML — but nothing at runtime actually uses the factory:

• The Lightning node is built from YAML settings (Settings::get_node()) and injected into SubscriptionHandler
• The on-chain provider likewise comes from Settings::get_onchain() (reusing the YAML LND section with hardcoded defaults), so DB fields like min_confirmations, address_type and account on the new OnChainProviderConfig have no runtime effect yet
• Revolut/Stripe payment handlers load DB configs directly in payments/mod.rs, bypassing the factory

The DB config was presumably intended to be the source of truth (per-company payment providers). Completing the integration means:

• Build the Lightning node and on-chain provider from payment_method_config via the factory at startup (fall back to YAML settings when no DB config exists)
• Respect the on-chain config fields (min_confirmations, address_type, account) — currently hardcoded to 1 / p2wkh / default account in Settings::get_onchain()
• Route the Revolut/Stripe listeners through the factory for consistency
• Decide multi-company semantics: SubscriptionHandler currently holds a single global node/provider, while the factory is per-company

Related: #109 / PR #180 introduced create_onchain_provider + get_onchain_provider_for_company and the seeded OnChain DB config.

[v0l]

Assessment

I traced the runtime wiring to scope this out. Findings and a recommended plan below.

Where the handlers actually come from today

• bin/api.rs builds node and onchain from YAML via Settings::get_node() / Settings::get_onchain() (lines ~165-166), then threads that single global pair into:
  • SubscriptionHandler::new(...) — used for invoice creation + on-chain address derivation
  • Worker::new(...) → ReferralPayoutHandler (LN node, for payouts)
  • listen_all_payments(...) — the settlement listeners
• SubscriptionHandler holds one node, one onchain, one revolut (built from settings.get_revolut()), i.e. a single global set, not per-company.
• Settings::get_onchain() hardcodes address_type: WitnessPubkeyHash, account: None, min_confirmations: 1, reusing the YAML LND section — so the new OnChainProviderConfig DB fields have zero runtime effect.
• payments/mod.rs::listen_all_payments already loads Revolut/Stripe configs straight from the DB (db.list_payment_method_configs() + inline filter/construct), bypassing PaymentMethodFactory.
• PaymentMethodFactory is fully built and unit-tested (create_lightning_node, create_onchain_provider, create_fiat_service, get_*_for_company) but has no non-test callers — confirmed via grep.
• The startup data migration seeds payment_method_config rows against the first company (companies.first()), so there is a natural "default company" already in play.

The real fork in the road: multi-company semantics

The blocker is that the factory is per-company while SubscriptionHandler is global. Two viable directions:

Option A — Global-from-DB with YAML fallback (recommended). Build the global node/onchain via the factory from the default (first) company's enabled config at startup; fall back to Settings::get_node()/get_onchain() when no DB config exists. Route the Revolut/Stripe listeners through get_fiat_service_for_company. This makes the DB the source of truth, respects min_confirmations/address_type/account, and ticks checkboxes 1-3 without a cross-cutting refactor. Multi-company routing (checkbox 4) gets documented as follow-up. Estimated ~M.

Option B — Full per-company routing. Make SubscriptionHandler (and every invoice/address-creation path, the worker's referral payout handler, and the settlement listeners) resolve the provider per company via the factory at payment time. This is the "correct" end state but touches invoice.rs, onchain.rs, worker.rs, the referral payouts, and a large number of call sites/tests. Estimated ~XL — needs a work file and incremental PRs.

Recommendation

Do Option A now (single PR), and leave a scoped follow-up issue for Option B (true per-company provider routing). Concretely:

1. In bin/api.rs, construct a PaymentMethodFactory, resolve default-company LN + on-chain via get_lightning_node_for_company / get_onchain_provider_for_company, unwrap_or the existing YAML builders.
2. Delete the hardcoded on-chain defaults path once the factory is the primary source (keep YAML fallback for envs with no seeded config).
3. Switch listen_all_payments Revolut/Stripe construction to factory.get_fiat_service_for_company(...).
4. Note the remaining single-global-provider limitation inline + open a follow-up for per-company routing.

Open question for the maintainer: are we ever expecting more than one company with distinct LN/on-chain backends in the near term? If yes, it may be worth biting the bullet on Option B rather than shipping A first. Holding here for that call.