SailingSteve
commented
5 years ago https://api.wevoteusa.org/apis/v1/donationHistory/
is_organization_plan: "True"
11: {created: "2019-08-15 23:31:59+00:00", amount: "100.00", currency: "USD",…}
amount: "100.00"
brand: "MasterCard"
charge_id: ""
created: "2019-08-15 23:31:59+00:00"
currency: "USD"
exp_month: 12
exp_year: 2022
funding: "Credit"
is_organization_plan: "False"
last4: "4444"
last_charged: "None"
organization_we_vote_id: "None"
record_enum: "SUBSCRIPTION_SETUP_AND_INITIAL"
refund_days_limit: 10
stripe_status: ""
subscription_canceled_at: "2019-08-17 20:54:45+00:00"
subscription_ended_at: "2019-08-17 20:54:45+00:00"
subscription_id: "sub_Fd8hVSnHsyd90U"
12: {created: "2019-08-15 23:31:59+00:00", amount: "100.00", currency: "USD",…}
amount: "100.00"
brand: "MasterCard"
charge_id: "ch_1F7sQFD153UBwRssbC6o8bQe"
created: "2019-08-15 23:31:59+00:00"
currency: "USD"
exp_month: 12
exp_year: 2022
funding: "Credit"
is_organization_plan: "False"
last4: "4444"
last_charged: "None"
organization_we_vote_id: "None"
record_enum: "PAYMENT_AUTO_SUBSCRIPTION"
refund_days_limit: 10
stripe_status: "succeeded"
subscription_canceled_at: "None"
subscription_ended_at: "None"
subscription_id: "no"
There is a test page in the webapp at https://localhost:3000/more/stripe_elements_test that can be used to run the proof of concept of Stripe Elements component (login elements that sit on our page, instead of requiring a pop up payment dialog).
See the throwaway test code at src/js/routes/More/StripeElementsTest.jsx
The page also uses the server side coupon validation api.
Only the "25OFF" coupon is defined on the server for use by a voter. In addition 'DEFAULT-PROFESSIONAL_MONTHLY' and 'DEFAULT-ENTERPRISE_MONTHLY' exist on the server for use when no coupon was entered by the voter, and are used to define the list prices for the plans. In the default case, the list and discount prices are the same, and can be used to populate the WebApp prices. The default coupons, should not show up in the coupon entry field, they are for the case where no coupon is defined.
Validating a coupon, does not really redeem the coupon, so it can be called as often as you want. The redeem will be done when the subscription (paid plan) is handed over to stripe for payment. Redeem is really just applying the discounted price, and incrementing the redeemed field in the coupon table (the donate_organizationsubscriptionplan table in Postgres).
See https://github.com/wevote/WeVoteServer/blob/develop/donate/models.py create_initial_coupons(). Once we get the Python Admin UI going for editing coupons, then we can create as many as we want, and maintain them going forward.
The validation of coupons, and the display of StripeElements is in good shape (although minimally styled in the throw away code), some of the backend work is ongoing ... to distinguish between donation subscriptions and organization paid subscriptions -- both use Stripe and mostly the same Python code and SQL tables on the server.
I have a support issue in to stripe on how to recover our plan name code which does not seem to be in their charge webhook return, but is mentioned in a html receipt for the charge which they generate -- should have the answer in a few days.
Also the API calls used for the donation table in the DonationList component (https://localhost:3000/more/donate), will bring in the list of Organization Paid Plans (Subscriptions tab), and payments (Donations tab) -- they will be distinguished from donations, in the historyList, when the parameter 'is_organization_plan' is true as a result of calling https://api.wevoteusa.org/apis/v1/donationHistory/ You can use that as a working model of APIs that can be used for the new PaidAccountUpgradeModal etc.