Closed cmutel closed 6 months ago
Stripe link for academic membership is here: https://buy.stripe.com/aEU5nr3Al3oVe9a4gg Stripe link for membership is here: https://buy.stripe.com/6oEeY17QBbVraWY5kl
Docs on how to get notification from Stripe upon successful payment: https://docs.stripe.com/payments/checkout/fulfill-orders
Membership model is in https://github.com/Depart-de-Sentier/dds_registration/pull/57
@lilliputten I think you can take over here, ping me if something isn't clear.
How is this supposed to work? Am I right supposing the next:
We have to show the form ('New view to become a member') first, right?
What should this form contain?
Only 2 links for academic/regular membership payment on Stripe? (Probably a switch to choose academic/regular mode and a button to start paying?)
As I get it, I should set up an API endpoint for Stripe webhook to receive updates on payment status ('Stripe callback...'). (They offer Stripe CLI for use as the local playground. It'd help.)
What about different currencies? Wouldn't it be enough to provide a currency selector and pass a parameter to Stripe API? (Haven't tried to study it yet.)
Not sure I have everything worked out yet, but:
The membership
page should have some text explaining what membership means and what DdS is (I will write this), and then four buttons:
If you aren't logged in you need to do that first.
For both Stripe methods we need a callback which creates an entry in Membership
automatically.
For invoices we will need to enter the membership info manually for now.
So no real form, unless you need that for Stripe callbacks.
What about different currencies?
It's always Euros.
What have we to do for 'invoice' options? To generate an invoice pdf for it? Or to go to the Stripe page with a special (which one?) parameter?
(I missed this answer yesterday.)
Invoice means generate an invoice PDF, yes.
@cmutel
I'm going to extend the membership model with type
and paid
fields -- to store the data before it has been paid. So we will be creating the membership record, inactive (unpaid) at first. And later (when we receive the payment confirmation) we just change the paid
status (but, probably, will have to verify that the type
hasn't been changed -- that the user paid for the same type that he booked initially).
Is that ok?
Otherwise, I could try to store this type
(I need it between a few screens) in the session data.
And paid
definitely will be required later.
Sure, that sounds fine.
Do we need (in the future, probably?) the membership revoking feature? At least, it could make sense during the period when user hasn't made his payment yet, but already changed his mind?
Not sure, let's not worry about this now.
Displaying of the membership status has implemented as part of #101, commit #ae5dce4.
models.py
) created