org billing email, restrict plan downgrades, card expiry check #5312

pjain1 · 2024-07-18T17:10:21Z

No description provided.

admin/server/organizations.go

pjain1 · 2024-07-19T04:39:00Z

admin/server/organizations.go

+}
+
+func comparableInt(v *int) int {
+	if v == nil || *v < 0 {


if a quota is not set (nil) the we should use the default value instead of unlimited ? can just change the plan creation logic to use default value instead of nil in case a quota is not set

Not sure, but I think I'm fine with having unlimited when a quota is not explicitly set – it reduces user pain if we mess up, and should help in dev and testing. What do you think?

makes sense but current logic uses default value during org creation if any quota is not set and during plan change it uses the persisted quota in database if not present in plan. Should I change this logic then ?

begelundmuller · 2024-07-19T13:08:52Z

admin/billing/payment/stripe.go

+	// very basic check if the customer has a payment method and if it's a card then is not expired
+	for i.Next() {
+		hasPaymentMethod = true
+		pm := i.PaymentMethod()
+		if pm.Type == stripe.PaymentMethodTypeCard {
+			isCardValid = new(bool)
+			*isCardValid = int(pm.Card.ExpYear) > time.Now().Year() || (int(pm.Card.ExpYear) == time.Now().Year() && int(pm.Card.ExpMonth) >= int(time.Now().Month()))
+		}
+	}


Does Stripe have an API for this? There are other factors than just expiry, and Stripe might know about them (like probably they track cards they have detected to be blocked)

I could not find any such API but added specifically this check because Eric O mentioned that we want to show a banner if the card expires.

begelundmuller · 2024-07-19T13:10:27Z

admin/billing/payment/stripe.go

+			var isCardValid *bool
+			// very basic check if the customer has a payment method and if it's a card then is not expired
+			for it.Next() {
+				hasPaymentMethod = true
+				pm := it.PaymentMethod()
+				isCardValid = new(bool)
+				if pm.Type == stripe.PaymentMethodTypeCard {
+					*isCardValid = int(pm.Card.ExpYear) > time.Now().Year() || (int(pm.Card.ExpYear) == time.Now().Year() && int(pm.Card.ExpMonth) >= int(time.Now().Month()))
+				}
+			}


Since this is duplicated twice and non-trivial, can we pull it into a util func?

begelundmuller · 2024-07-19T13:12:35Z

admin/server/organizations.go

+	// don't allow plan downgrades, only superuser can downgrade
+	if planDowngrade(plan, org) && !claims.Superuser(ctx) {
+		return nil, status.Errorf(codes.FailedPrecondition, "plan downgrade not allowed")
+	}


Why do we not allow downgrades? What if someone doesn't use a bigger plan and wants to switch to a smaller one?

@nishantmonu51 suggested we should not allow downgrades, for this they should contact us. Downgrades can be tricky if they are already over some quotas.

I wonder if it would be better to let people downgrade, and then in the beginning just have a job that checks/alerts if they don't get within the lower quotas within a day or so. Then we can just contact or hibernate non-compliant projects without causing trouble for people who want to downgrade for legitimate reasons.

@nishantmonu51 any thoughts here ?

removed the restriction, just logging in case of downgrade

Yes, we intentionally wanted to keep the scope limited here and not allow downgrade, as downgrade would require checking if the quotas for the lower plan are met and only allow to downgrade. The expected flow here for a user would be to create a support ticket, FE team will manually verify the quotas and then downgrade directly in orb.

Other reasons for not allowing downgrade is for enterprise users who have signed a multi-year contract and we don't want them to downgrade unless explicitly approved. Since its not going to be a common case and in many such cases we want to have manual intervention. We do not allow downgrade at present.

begelundmuller · 2024-07-19T13:14:53Z

proto/rill/admin/v1/api.proto

+enum PaymentCardStatus {
+  PAYMENT_CARD_STATUS_UNSPECIFIED = 0;
+  PAYMENT_CARD_STATUS_OK = 1;
+  PAYMENT_CARD_STATUS_EXPIRED = 2;
 }


What is the goal of exposing this? Just wondering if we could just track whether they have a valid payment method or not, and direct them to the Stripe portal if they want more details?

As stated elsewhere, I'm also guessing there are many other conditions that could cause a card to be invalid than just expiry.

using the api we can just check if there exists a payment method or not for the customer, does explicitly say if its a valid or not.

The goal is Eric O mentioned that we want to show a banner if the card expires.

Okay, maybe not completely related, but do you think it would make sense to have generic billing_warning and billing_error fields on an org, and then show those in banners instead? Then we could populate billing_warning if it looks like the card will expire within the next 3 months or so, and set billing_error if we get a webhook from Stripe that tells us that a payment actually failed or a card has become invalid for some reason.

sure that makes sense, however we will need some background jobs to clear out these warnings/errors once they are resolved.

or we just rely on webhooks to clear these warnings like payment card updated for expired card warning or payment succeeded for payment failed error. Looks fragile though because webhook delivery may fail or our service may be unavailable at that point etc.

ok I see webhooks are retried upto 3 days by stripe but we may need async queue to process the webhooks internally and prevent processing duplicate webhooks

should webhook support be added in separate PR ?

Yeah we can add it in a separate PR, but I think we should do it sooner rather than later.

Webhooks should be very stable, as you say they are usually retried until ack'ed, but if you worry about inconsistencies you can also have a background job once per day or so that checks and syncs statuses in case a webhook was dropped.

Removed checking of card expiry, just keeping check of presence of a payment method so that we can disallow plan change if no payment is present. This is all internal and not exposed in any API so that once we have billing warnings and errors, will just make sure no billing errors present instead of this payment method check.

admin/database/database.go

org billing email, restrict plan downgrades, card expiry check

e1668cd

pjain1 requested a review from begelundmuller July 18, 2024 17:10

pjain1 added 2 commits July 18, 2024 22:41

Merge branch 'main' into self_serve_followups

ed67683

fix bool pointer

e3f97e5

pjain1 commented Jul 19, 2024

View reviewed changes

admin/server/organizations.go Show resolved Hide resolved

pjain1 commented Jul 19, 2024

View reviewed changes

pjain1 added 2 commits July 19, 2024 10:32

cli edit org email

94204ea

allow superuser to downgrade

77bd50e

begelundmuller requested changes Jul 19, 2024

View reviewed changes

pjain1 added 3 commits July 29, 2024 10:17

use bigger quota during repair

e41a8a8

review comments

0d5deea

merge with main

8e97a39

pjain1 requested a review from begelundmuller July 30, 2024 12:50

pjain1 added 3 commits July 31, 2024 02:58

allow plan downgrades by superusers only

d6fbe4b

don't delete stripe customer on org deletion

2039988

logging

3940c49

begelundmuller approved these changes Jul 31, 2024

View reviewed changes

pjain1 added 7 commits August 1, 2024 20:16

fix billing email corner cases

ef9b118

merge with main

96c09b2

merge with main

db98f55

add grace period to reporting

9120ced

change storage quota to 10Gb, allow -1 as quotas which means unlimited

df585e6

fix lint

bce249e

add missing update org params

de29f94

k-anshul requested changes Aug 9, 2024

View reviewed changes

admin/database/database.go Show resolved Hide resolved

k-anshul approved these changes Aug 12, 2024

View reviewed changes

pjain1 merged commit 2d4833f into main Aug 12, 2024
7 checks passed

pjain1 deleted the self_serve_followups branch August 12, 2024 11:50

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

org billing email, restrict plan downgrades, card expiry check #5312

org billing email, restrict plan downgrades, card expiry check #5312

pjain1 commented Jul 18, 2024

pjain1 Jul 19, 2024 •

edited

Loading

begelundmuller Jul 19, 2024

pjain1 Jul 19, 2024

begelundmuller Jul 19, 2024

pjain1 Jul 19, 2024

begelundmuller Jul 19, 2024

begelundmuller Jul 19, 2024

pjain1 Jul 19, 2024

begelundmuller Jul 19, 2024

pjain1 Jul 26, 2024

pjain1 Jul 30, 2024

nishantmonu51 Jul 30, 2024

begelundmuller Jul 19, 2024

pjain1 Jul 19, 2024

pjain1 Jul 19, 2024

begelundmuller Jul 19, 2024

pjain1 Jul 26, 2024

pjain1 Jul 26, 2024

pjain1 Jul 26, 2024

pjain1 Jul 26, 2024

begelundmuller Jul 26, 2024

pjain1 Jul 30, 2024

org billing email, restrict plan downgrades, card expiry check #5312

org billing email, restrict plan downgrades, card expiry check #5312

Conversation

pjain1 commented Jul 18, 2024

pjain1 Jul 19, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pjain1 Jul 19, 2024 •

edited

Loading