Design payment registration system

[BrendaH]

Consult with JW about the payment registration system. Payments, exceptions, terms, refunds and possible consequences for the actual registration. How is stuff stored, updated, exported/imported, etc.

[matthijskooijman]

An MVP should perhaps use a simple payed: yes/no field like the existing system.

[matthijskooijman]

See #54 for the MVP version.

[matthijskooijman]

See also #3, #21 and #20

[matthijskooijman]

Payment objects and online payments have now been implemented, solving a large part of this issue. What is left is:

• Exporting the mollie payments to be included in the bookeeping system.
• Payment exceptions (i.e. delayed payment or payment in terms)
• Automatic refunds through Mollie (i.e. when changing registration options #71 or when a registration is cancelled #67). Manual refunds can already be tracked.
• Tracking price change due to cancellation (this is distinct from the actual refund, which transferring money, this is about tracking that the refunded money is actually no longer owed). https://github.com/evolution-events/Artaxerxes/issues/67#issuecomment-949065022 has a proposal.

For payment exceptions, I was thinking to maybe add a "payment_exception" boolean to registration, that:

• Treats the registration as paid for things like payment deadlines
• Allows the user to specify a custom payment amount (to allow paying in terms)

It might make sense for us to specify the payment amounts, but that is way more complicated, probably easier to just trust the participant beforehand (and check afterwards).

[matthijskooijman]

Some more things to do:

• 119

• Decide whether waitinglist registrations should be paid immediately. This was our original policy (still stated in the house rules), on which we made an exception for On the Styx, and probably also implicitly for 1672. The current online payment implementation also does not allow paying for waitinglist registrations, so we should either change the house rules, or make this configurable per event.

[matthijskooijman]

Allows the user to specify a custom payment amount (to allow paying in terms)

This is now unconditionally possible, for things like optional crew prices, but it also works for payment in terms.