closes https://github.com/TryGhost/Team/issues/682
This ensures that the Stripe Product name is updated during the
migrations of an existing site and any future updates to the Product
name.
no-issue
Since we do not necessarily have a single stripe product anymore, we
should be checking if an invoice webhook is for a stripe product which
we know about. We use the Products repository to search our database for
one.
refs https://github.com/TryGhost/Team/issues/637
All the APIs that currently work with price names needs to be updated to work with price ids instead to work with custom prices/products. This change updates APIs to work with Price IDs in `checkout` , `updateSubscription` and other APIs/methods.
refs https://github.com/TryGhost/Team/issues/616
This is a generic method for adding a subscription to a member for a
particular price/product pair. This will be used in the Admin for e.g.
giving complimentary subscriptions.
closes https://github.com/TryGhost/Team/issues/628
refs 9010a62d54
Following up on last commit, this moves up the expansion of Stripe customer fetch to always include `subscriptions` by default in api service so we don't accidentally miss it.
refs https://github.com/TryGhost/Team/issues/619
On linking a stripe subscription to a member, this change -
- Adds missing stripe price or stripe product from subscription to DB
- Missing Stripe price is attached to the first Ghost Product if no matching Product exists
- Updates usage from plan to price in the `linkSubscription` method
- Updates products associated with a member based on active subscriptions
refs https://github.com/TryGhost/Team/issues/616
Working with ProductRepository as a separate package was more trouble
than it was worth, so it's been moved into members-api. We expose the
product repository so that Ghost Admin API can access it.
refs https://github.com/TryGhost/Team/issues/586
On Ghost Boot, as part of configuring Stripe, this populates stripe products and prices for existing stripe customers in the newly created `stripe_prices` and `stripe_products` table, which allows us to map existing customers to default Ghost product and on current prices. The population script on boot is only run if we find -
- A Ghost Product
- No rows in `stripe_products`
- No rows in `stripe_prices`
- One or more rows in `members_stripe_customers_subscriptions`
refs https://github.com/TryGhost/Team/issues/593
- Bumps `stripe` node library major version to v8 - 8.142
- Bumps default Stripe version to latest - '2020-08-27'
- Updated webhook Stripe version to latest - '2020-08-27'
- Removes `@types/stripe` in favor of first-class types support in `stripe` lib directly
- Updates types across files
no-issue
1. We do not want to store payment events for payments of 0 value
2. Stripe webhooks can arrive and be processed "out of order", which can
result in us attempting to add a payment event for a member which
does not yet exist. The change here will 404 in such (edge) cases, so
that Stripe will retry the webhook at a later point, when the Member
has been created, allowing us to store the payment event.
refs https://github.com/TryGhost/Ghost/issues/12602
* Added Event Repository
** Added method for MRR over time
** Added method for newsletter subscriptions over time
** Added method for gross volume over time
** Added method for status segment size over time
* Captured login events
* Captured newsletter subscription/unsubscription
* Captured email address change events
* Captured paid subscription events
* Captured payment events
* Captured status events
refs https://github.com/TryGhost/Team/issues/479
* Fixed updating payment method for canceled subscriptions
Stripe considers canceled subscriptions as non-existent, so any attempts
to update them will fail with a 404 not found. Prior to this change we
were attempting to update *all* subscriptions for a customer, including
those which were canceled. This would cause an error and the loop to
break.
* 🐛 Fixed errors for members with multiple active customers
Members with multiple active customers would have their first active
customer found updated with the new payment method. We would then
iterate through *all* active subscription, and attempt to update their
payment method. If a subscription was not owned by the customer that was
just updated, it would error and cause the loop to break out.
* Added ability to update a specific subscription's payment method
In order to remove ambiguity we add the ability to update the payment
method for a specific subscription. This will remove room for errors as
we will not have to worry about if a subscription belong to the customer
or not.
no-issue
Fetching relations via the model returns a promise, and this was missing
the `await` keyword. We also need to `get` the subscription_id attribute
as we're working with models rather than subscription objects.
no issue
The logic to fetch member for a checkout session was incorrectly creating a new customer instead of finding an existing one, so the member's billing details was not getting updated.
no-issue
This refactors the members-api module so that it is easier to test going forward,
as well as easier to understand & navigate. The Stripe API no longer contains
storage code, this is all handled via the member repository. And we have dedicated
services for webhooks, and stripe plans initialisation.
