[stripe] Create customers with attributionId

[easyCZ]

Description

Create customers (user/team) with an AttributionID instead of user/team ID. We cannot yet update the find queries to use this field as we have customers in Stripe without the attributionID property.

Once this has propagated enough, we can also kill the user/team specific methods and use the Attribution ID only.

Related Issue(s)

Fixes #

How to test

Release Notes

NONE

Documentation

Werft options:

• /werft with-preview

[easyCZ]

/werft run

👍 started the job as gitpod-build-mp-stripe-attribution-id.1
(with .werft/ from main)

[jankeromnes]

Nit: I think the only place where this userId metadata is used is a few lines above in findCustomerByUserId.

If you also update findCustomerByUserId to use the attributionId, then you can completely remove the now useless userId metadata. 👍

Suggested change

	// userId is deprecated, use attributionId where possible
	userId: user.id,

[jankeromnes]

Nit: Same as above -- the only place where the teamId metadata is used is in findCustomerByTeamId above. If you update this method, you can remove the now useless teamId metadata.

Suggested change

	// teamId is deprecated, use attributionId where possible
	teamId: team.id,

[easyCZ]

We cannot yet update the find queries to use this field as we have customers in Stripe without the attributionID property.

We cannot remove it yet, lookup queries would fail on existing customers.

[easyCZ]

The reason it stays on the create is consistency, we want to phase out teamId, but that doesn't mean we can stop setting it, due to existing queries.

[easyCZ]

/hold

[jankeromnes]

We cannot yet update the find queries to use this field as we have customers in Stripe without the attributionID property.

Actually yes, we can. The updated find queries may no longer find existing Stripe customers, and thus conclude that your team/user is not a customer yet. This is totally safe and allows you to create a new customer.

Also, in production, there is currently one single customer. I'll even go ahead and add the attributionId metadata to it, so that it can still be found by the new find queries.

EDIT: Done ✅

[easyCZ]

There's also the Usage component which performs these queries. Let's do it properly:

1. Set the new property additively
2. Ensure all staging + prod customers have this updated
3. Update the queries to use attribution ID
4. Remove team/User ID

[jankeromnes]

There's also the Usage component which performs these queries.

True, there are also 4 occurrences to fix in https://github.com/gitpod-io/gitpod/blob/main/components/usage/pkg/stripe/stripe.go

Fixing them shouldn't take too long. 😊

Let's do it properly:

1. Set the new property additively
2. Ensure all staging + prod customers have this updated
3. Update the queries to use attribution ID
4. Remove team/User ID

I don't see any benefit in doing this very slowly over multiple PRs/deployments.

Why take several days to do something we could do in just 5 minutes in one PR?

Reminder: There is just one customer in Stripe that matters, and its metadata is already up-to-date. We don't need a very slow & very safe migration path for one customer which is ourselves.

[andrew-farries]

Sounds like #12753 is relevant here.

This is where we start creating new Stripe customers for individual users. It currently sets userId: 1234-.... in the metadata for the new user.

[easyCZ]

There is just one customer in Stripe that matters

We want staging to work also.

The reason for doing it properly is to practice the mechanics. Sooner or later we will need to do this when UBP is released to real customers and we won't have as much room for error on this.

[easyCZ]

/unhold

[jankeromnes]

We want staging to work also.

Customers in staging don't matter. If queries can't find existing customers, it's just like the customers never existed, and teams can upgrade again with a fake credit card.

The reason for doing it properly is to practice the mechanics. Sooner or later we will need to do this when UBP is released to real customers and we won't have as much room for error on this.

Agreed, once UBP is released and deployed and massively used, we will need to migrate much more slowly and safely.

However, today it's not useful to slow ourselves down. In fact, the more days of work we save ourselves, the sooner we can release UBP.

[easyCZ]

I'll do it iteratively. If not for any other benefit than my own to practice this when it is needed for real. Thank you for the suggestion of an alternative approach!