Skip to content

v2.0.0: fiat payment support with core-based providers - #87

Draft
dadofsambonzuki wants to merge 31 commits into
lnbits:mainfrom
dadofsambonzuki:main
Draft

dadofsambonzuki wants to merge 31 commits into
lnbits:mainfrom
dadofsambonzuki:main

Conversation

@dadofsambonzuki

@dadofsambonzuki dadofsambonzuki commented Jul 8, 2026 •

Copy link
Copy Markdown

Summary

Major refactor to include fiat providers from LNbits core settings. Supports Stripe, PayPal, Square, and Revolut.

Changes

  • Fiat checkout tab - Fiat tab is present if a fiat payment provider is selected when charge is created.
  • BIP21 on-chain URIs — bitcoin: links now include amount parameter per BIP21 spec
  • QR layout fixes — centered QR with properly grouped Pay/Copy/Download buttons
  • Updated docs — description.md, README.md, config.json

See individual commits for detailed changes.

- Replaced standalone Fiat Configuration card and admin settings dialog
  with a single gear icon button that opens a combined modal
- Extension Settings section (admin only) with network, mempool URL,
  webhook method via lnbits-dynamic-fields
- Fiat Configuration section (all users) with per-provider toggles
  and password fields
- Dialog auto-closes after saving fiat config
- Add api_endpoint, api_version, location_id to FiatConfig model
- Add m017 migration for new fiat_configs columns
- Show provider-specific fields in settings UI (Secret Key for Stripe,
  Client ID/Secret for PayPal, API Secret Key for Revolut,
  Access Token/Location ID for Square) instead of generic labels
- Per-provider validation in canSaveFiatConfig (PayPal needs
  api_secret, Square needs location_id, others just api_key)
- Use structured fields in helpers.py instead of parsing extra JSON
…_providers

- Remove FiatConfig model, CRUD, API endpoints, UI, and migrations
- Charge creation validates fiat_provider against settings.get_fiat_providers_for_user()
- _create_*_checkout functions read credentials directly from core settings
- Webhook verification uses core settings for secrets
- Charge dialog fiat dropdown uses g.user.fiat_providers
- Settings modal no longer has fiat configuration section
…ix webhook double-encoding

- Gracefully handle missing register_fiat_webhook_handler in core
  (required until PR #4051 is merged).
- Send proper dict (charge.model_dump()) in webhook POST body instead
  of a pre-encoded JSON string (charge.json()) to avoid double-encoding.
Add settlement_method and settlement_proof columns to Charge (m017):
- lightning: stores preimage as proof
- onchain: stores txids as JSON proof
- fiat: stores provider name and checkout/order id

Record settlement in all payment detection paths (invoice listener,
onchain websocket, balance polling, both fiat webhook handlers, and
restart recovery). Expose both fields in the public charge payload and
websocket updates, and show 'Paid via <method>' with the proof on the
public paid screen.

Also add m018 to backfill settlement info for historical paid charges
from existing extra/fiat column data.
…ted hook)

Commit c424acf accidentally removed the closing braces and the created()
hook along with the fiat provider methods, leaving the file with a
syntax error so the SatsPay page never rendered in the browser.
…outs

Create fiat invoices via core create_payment_request(fiat_provider=...)
tagged with the charge id, instead of calling Stripe/PayPal/Revolut/
Square APIs directly. Core owns the provider checkout session, verifies
provider webhooks at its own callback endpoint, marks the internal
payment paid and notifies invoice listeners.

- on_invoice_paid settles charges with settlement_method/proof from
  payment.fiat_provider and extra.fiat_checking_id
- check_charge_balance also polls the fiat payment status
- drop /satspay/api/v1/fiat/webhook endpoint, handle_fiat_webhook_event
  and the PR #4051 dispatcher registration (not needed, per review)
- store the core payment_hash in fiat_payment_requests for polling
…unavailable

When no Bitcoin price provider responds (e.g. transient DNS/outbound
network issues), get_fiat_rate_satoshis() silently returns 0.0, so the
computed sats amount becomes 0 and create_charge() fails with the
generic 'Amount must be greater than 0' exception. That surfaces to
checkout flows (e.g. the events extension) as 'Could not create payment
for any enabled method'.

Raise a clear HTTP 503 with the failing currency instead, so callers and
users can distinguish a transient rate outage from a bad request.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant