You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This could support a variety of ad-hoc payment cases, such as
accommodation signup,
partly subsidized products for event organizers (eg. organizer hoodies),
partly subsidized tickets to an event for organizers (eg. TSH coniteanäytäntö),
catch-all ”the financeperson said I need to pay XX € to the event, so please take my money” form
etc.
Would require that the organization has a payment method configured.
When payments are configured for a Survey, it could automatically add a dimension for payment status (unpaid, paid, refunded).
Need to design how the price is calculated for a survey response:
Easiest way would be to specify a fixed price per response. However, this would already fail to serve most obvious cases such as multiple products (better served by ticket shop?), several instances on one form submission etc.
We could also assign prices to dimension values. This would, however, fail to serve multiple instances of a product.
We could embed a custom LISP dialect or even WASM runtime for which we could compile pricing logic functions with Rust…
…but let's not :)
We could have a field type for product selection. Products and their prices would be configured via the configuration of that field type.
This could support a variety of ad-hoc payment cases, such as
Would require that the organization has a payment method configured.
When payments are configured for a Survey, it could automatically add a dimension for payment status (unpaid, paid, refunded).
Need to design how the price is calculated for a survey response:
Slack discussion (
lippukauppa2025
private channel, ask Japsu)The text was updated successfully, but these errors were encountered: