-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Synchronising stripe and studio API state - [DEV-4157] #561
Conversation
bb51721
to
4f32d08
Compare
Signed-off-by: jay-dee7 <[email protected]>
Signed-off-by: jay-dee7 <[email protected]>
subscriptions Signed-off-by: jay-dee7 <[email protected]>
…` event Signed-off-by: jay-dee7 <[email protected]>
5732a42
to
241f6e4
Compare
Signed-off-by: jay-dee7 <[email protected]>
241f6e4
to
3622762
Compare
Signed-off-by: jay-dee7 <[email protected]>
@jay-dee7 |
@DaevMithran we can't remove it. To implement |
Signed-off-by: jay-dee7 <[email protected]>
## [3.1.0-develop.1](3.0.1-develop.2...3.1.0-develop.1) (2024-07-31) ### Features * Synchronising stripe and studio API state - [DEV-4157] ([#561](#561)) ([f338db7](f338db7))
🎉 This PR is included in version 3.1.0-develop.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
## [3.1.0](3.0.0...3.1.0) (2024-08-05) ### Features * Switch logto role assignment to subscription webhook [DEV-4164] ([#565](#565)) ([0b93908](0b93908)) * Synchronising stripe and studio API state - [DEV-4157] ([#561](#561)) ([f338db7](f338db7)) ### Bug Fixes * Return proper response on auth setup [DEV-4146] ([#560](#560)) ([690d854](690d854)) * trigger stripe account creation on sign-in ([#559](#559)) ([d2fec93](d2fec93)) * Use `admin:subscription:get` auth guard for Stripe checkout session ([#564](#564)) ([fc631e4](fc631e4))
🎉 This PR is included in version 3.1.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
This PR makes few adjustments and breaks existing assumptions about the user journeys for Stripe and our API.
We now create a customer (Studio) when someone subscribes on Stripe but has never signed up for our platform. This helps with
Inbound Billing Journey
We still try to maintain consistency at runtime about 1-1 relationship between the
user
andcustomer
tables. Though it's quite risky since the underlying database does not guarantee the relation terms. We could end up creating multiple customers in some edge case as long as it's not implemented at the database layer. The first step for this should be marking thecustomer.email
as the primary or at least a unique column.Allow setting the
paymentProviderId
while creating new Customer entity records, it was optional before anyway and we only allow to create it optionally (to avoid having to perform a create + update operation)New endpoint -
GET /admin/checkout/session/:id
API to retrieve Stripe checkout session by IDWarning
The get Stripe checkout session endpoint is completely open at the source (API) this of course does require some thinking but the times when this endpoint becomes useful is mostly when user is not authenticated. One thing we could do is make thisauthenticated
and force a user login before performing any checks on client side.