Honour per-wave fiat when the organiser set an explicit rail list #67

Merged

padreug merged 1 commit from fix/wave-aware-payment-methods into main

2026-10-03 05:50:43 +00:00

padreug commented

2026-09-30 17:39:50 +00:00

Owner

Reported from aio-demo: event fiat enabled, Card offered at checkout, purchase refused with "Fiat payments are not enabled for this ticket wave."

Cause

effective_payment_methods returned the organiser's explicit extra.payment_methods before consulting anything else:

explicit = list(...)
if explicit:
    return explicit          # <- the wave never got a look in

So the wave argument I added in #61 did nothing in the common case. The webapp always sets extra.payment_methods from its payment-method checkboxes, which makes the explicit path the normal one, not the exception. Three layers then disagreed:

the NIP-52 tag advertised tickets_payment_methods: lightning,fiat while omitting tickets_allow_fiat — contradicting itself
the checkout rendered a Card button
api_ticket_create, the only wave-aware check, refused the purchase

Confirmed against the live instance — the reported event's waves:

primary        allow_fiat: True
Earliest Bird  allow_fiat: False
Early Bird     allow_fiat: False
Just a bird    allow_fiat: False

Fix

Asking about a specific wave means asking what a buyer can actually use for it, so a rail that wave cannot honour is dropped. The event-level question (no wave) still reports every rail the organiser enabled — that is what the admin views want. Fiat-only rails on a non-fiat wave now yield an empty list, which is honest: nothing is purchasable from that wave.

Tests

5 new, including both publisher shapes with an explicit list — the case that actually bit, and which the #61 tests missed because their fixtures left payment_methods empty. That gap is why a bug survived a PR that claimed to fix this exact contradiction. 133 pass; ruff, black clean; mypy unchanged from baseline.

Does not fix existing data

Waves already created through the webapp were saved with allow_fiat unset, so they genuinely cannot take fiat until toggled — the LNbits admin's per-wave dialog has that switch. The webapp half is aiolabs/webapp fix/wave-fiat-inheritance.

Reported from aio-demo: event fiat enabled, Card offered at checkout, purchase refused with **"Fiat payments are not enabled for this ticket wave."** ## Cause `effective_payment_methods` returned the organiser's explicit `extra.payment_methods` before consulting anything else: ```python explicit = list(...) if explicit: return explicit # <- the wave never got a look in ``` So the `wave` argument I added in #61 did nothing in the common case. The webapp always sets `extra.payment_methods` from its payment-method checkboxes, which makes the explicit path the **normal** one, not the exception. Three layers then disagreed: - the NIP-52 tag advertised `tickets_payment_methods: lightning,fiat` while omitting `tickets_allow_fiat` — contradicting itself - the checkout rendered a Card button - `api_ticket_create`, the only wave-aware check, refused the purchase Confirmed against the live instance — the reported event's waves: ``` primary allow_fiat: True Earliest Bird allow_fiat: False Early Bird allow_fiat: False Just a bird allow_fiat: False ``` ## Fix Asking about a specific wave means asking what a buyer can actually use for it, so a rail that wave cannot honour is dropped. The event-level question (no wave) still reports every rail the organiser enabled — that is what the admin views want. Fiat-only rails on a non-fiat wave now yield an empty list, which is honest: nothing is purchasable from that wave. ## Tests 5 new, including **both publisher shapes with an explicit list** — the case that actually bit, and which the #61 tests missed because their fixtures left `payment_methods` empty. That gap is why a bug survived a PR that claimed to fix this exact contradiction. 133 pass; ruff, black clean; mypy unchanged from baseline. ## Does not fix existing data Waves already created through the webapp were saved with `allow_fiat` unset, so they genuinely cannot take fiat until toggled — the LNbits admin's per-wave dialog has that switch. The webapp half is `aiolabs/webapp` `fix/wave-fiat-inheritance`.

padreug added 1 commit

2026-09-30 17:39:50 +00:00

fix: honour per-wave fiat when the organiser set an explicit rail list

lint.yml / fix: honour per-wave fiat when the organiser set an explicit rail list (pull_request) Failing after 0s

Details

b55d6866d6

Reported from aio-demo: an event with fiat enabled, Card offered at
checkout, and the purchase refused with "Fiat payments are not enabled
for this ticket wave."

`effective_payment_methods` returned the organiser's explicit
`extra.payment_methods` list before ever consulting the wave:

    explicit = list(...)
    if explicit:
        return explicit          # <- the wave never got a look in

So the `wave` argument I added for #61 did nothing in the common case.
The webapp always sets `extra.payment_methods` from its payment-method
checkboxes, which means the explicit path is the normal one, not the
exception — three layers then disagreed:

- the NIP-52 tag advertised `tickets_payment_methods: lightning,fiat`
  while omitting `tickets_allow_fiat`, contradicting itself
- the checkout rendered a Card button
- `api_ticket_create`, the only wave-aware check, refused the purchase

Asking about a specific wave means asking what a buyer can actually use
for it, so a rail that wave cannot honour is now dropped. The
event-level question (no wave) still reports every rail the organiser
enabled — that is what `/republish-all` and the admin views want.

Fiat-only rails on a non-fiat wave now yield an empty list, which is
honest: nothing is purchasable from that wave.

5 tests, including both publisher shapes with an explicit list — the
case that actually bit, and which the #61 tests missed because their
fixtures left `payment_methods` empty. 133 pass.

Does not fix the data on events already created through the webapp:
their waves were saved with `allow_fiat` unset, so those waves genuinely
cannot take fiat until toggled. That is aiolabs/webapp's side.

padreug referenced this pull request from aiolabs/webapp

2026-09-30 17:40:03 +00:00

Ticket waves follow the event's fiat setting #179

padreug merged commit 33501dfc90 into main

2026-10-03 05:50:43 +00:00

padreug deleted branch fix/wave-aware-payment-methods

2026-10-03 05:50:44 +00:00

padreug referenced this pull request from a commit

2026-10-03 05:50:45 +00:00

Merge pull request 'Honour per-wave fiat when the organiser set an explicit rail list' (#67) from fix/wave-aware-payment-methods into main

padreug referenced this pull request from a commit

2026-10-03 05:51:50 +00:00