Billing for company organizations #11986
Conversation
divbzero
commented
Jul 29, 2022
•
divbzero
commented
- Closes Recurring monthly Payment #11088.
- Closes Restrict releases #11089.
- Closes Remove restrictions from PyPI Organization Account #11090.
- Closes Download payment receipts/invoices #11091.
- Closes Update payment details #11092.
- Closes Remove organization if it is not approved by the admin #12061.
- Configure environment variables
- Two new services to get/delete - Bug fix to delete_organization
- Add tests for get/delete services - Add support to test_delete_organization
- Fix stripe-mock api base url - Add remaining billing tests - Add remaining subscription tests - Assortment of bugs squashed along the way
Search is only supported on API version 2020-08-27 or later.
- Specify Stripe `api_version` in tests - Fix mismatched parameters for `create_checkout_session` - Fix mismatched parameters for `create_portal_session` - Fix mismatched parameters for `update_price` - Fix mismatched parameters for `webhook_received` - Update test for `add_routes` - Update test for `webhook_received`
We currently have one metered per-seat price. This is a placeholder for supporting an additional base price as @ewdurbin described in pypi#11986. We will leave implementation of an additional base price for another PR.
divbzero
force-pushed
the
feature/billing
branch
from
89d48ad
to
bccf804
Compare
|
@ewdurbin I think this is ready for review except for base + usage billing which we will try for but think I’d prefer leaving for a separate pull request. I have left a placeholder in commit bccf804 to support base + usage billing on the backend. On the frontend I am still investigating whether it is most straightforward to implement pricing selection as a Stripe pricing page, a Stripe checkout option, or a pricing page in Warehouse. |
There was a problem hiding this comment.
I think this is in a good spot. One request to update the "name" for the Customer object that will end up in stripe.
One thing I'm struggling to decide on how to handle is what email address to associate with the Stripe Customer object, as this is where invoices will be sent.
I think we should consider adding a "Billing Email" to the Organization object and collecting it during signup. We need to consider the experience for Community projects when signing up though. As is, It's kind of abrupt and surprising that after a Corp project signs up, they're immediately sent into stripe checkout. Perhaps an interstitial for the Corp projects to collect any new information (there may be more) and tell them what's about to happen would be good.
This interstitial could initially just be a simple page/form saying "Hey we need to collect your billing info (email), you won't be charged, and we're about to send you to stripe checkout".
| Create the Customer resource via Billing API with the given name and description | ||
| """ | ||
| return self.api.Customer.create( | ||
| name=name, |
There was a problem hiding this comment.
I'd like for us to give the customers objects in Stripe names like "PyPI Organization - " since the account is shared between other PSF usage (namely pycon).
There was a problem hiding this comment.
Added customer name prefix in commit f292504.
Differentiate between PyPI and other customers as @ewdurbin described in pull request pypi#11986.
|
@ewdurbin The way it’s set up right now, the billing email is collected on the Stripe Checkout page, associated with the customer in Stripe, and can be updated on the Stripe customer portal page. Is that sufficient for what we need? Or would we want to store this in the |
|
@ewdurbin Could the interstitial be a confirmation modal or do we prefer a separate page? |
I think it should be stored on the Organization object itself, set via the Stripe API, and blocked from change in the customer portal. I'm concerned that this particular field will be very confusing if someone is trying to change it and doesn't know to go to the Stripe billing portal. |
Since I think we may want other functionality (like a form to collect any pertinent information, and namely billing email for now) it needs too be its own view. |
- Modify `add_subscription` to include billing email - New service for updating billing email - Changes to `checkout.session.completed` event - Handle `customer.updated` event
- Test model update - Tweaks to current tests - New tests for `customer.updated` event
- Abstract out into its own model
- Changes to interfaces and services in support of refactor
Stripe API searches product name by exact or substring match. An additional check is needed to ensure we have an exact match.
Pluralize relation between StripeCustomer and StripeSubscription.
Conflicts resolved manually:
requirements/lint.txt
warehouse/locale/messages.pot
