Allow any plan to have credits

[riderx]

Describe the bug/issue
Our current payment system has 2 things, monthly plan and Pay as you go.
Pay as you go is tricky because the user consumes and pay later, this had in the past a big problem as someone didn't pay.
Also, this doesn't scale well, and big clients don't take us as price doesn't decrease with usage.

So we need a second system to replace pay as you go and allow any plan to use it: credit.

One user can buy credit for MAU, Storage or bandwidth separately.

They can buy by 100, 1000, 10000 etc we have to be able to set different package for each, with different price, as many as we want.
When user buys it, it credits his account.
When a user goes above its plan, he starts to use credit if he has, or he is blocked to using Capgo.
We also need to alter how payment works to block by exact value who is limiting, if storage is the limit reached, the download should still work.

We will stop the current system of Pay as you go, where you pay at the end.

A front should be done to see current credits, the user should be able to buy one - time or recurrent credits.
Credits should be valid for 1 year.

We need to store the history of credit usage and display it month by month, with a one-year period max.

Credit count should be done 4 times a day, not at the exact second.

Email event should be done the same way we do for plan usage to allow use configure emails ( making the email is out of scope)

I suggest to first create a plan here and discuss this plan before starting coding, with milestone we can merge on the way, a big PR is not acceptable, as it's too big change

[WcaleNieWolny]

When user buys it, it credits his account
It credits his organization?

[WcaleNieWolny]

Let's start with a very small PR that will foster my understanding of the problem and allow me to develop a more robust roadmap in the short-term future.

In this issue, you mentioned, "We also need to alter how payment works to block by exact value who is limiting, if storage is the limit reached, the download should still work."

I am of the firm belief that we should start there.

[riderx]

yes that makes sense

[WcaleNieWolny]

I propose the following design for the backend:
capgo_tokens

id	sum	reason	org_id	created_at
0	100	Purchase	ca843e2c-7341-4505-867c-52360555323e	2025-01-21T04:50:00.906Z
1	-50	Increase MAU limit by 1000	ca843e2c-7341-4505-867c-52360555323e	2025-01-23T04:50:00.906Z
2	-20	Buy 10gb of storage	ca843e2c-7341-4505-867c-52360555323e	2025-01-24T12:50:00.906Z

capgo_token_giftcards:

id	total	giftcard	name	created_at
0	1000	447f04a80ccd4d0b9f8acd4065597f07	Betatest new credit system	2025-01-21T04:50:00.906Z
1	100	e9b9adfc956a41f6afa5ca05c5b336b4	Compensation for a bug	2025-01-23T04:50:00.906Z
2	25000	fa7e67754b7c4c039525c98cca3387b2	enterprise points deal	2025-01-24T12:50:00.906Z

There will be a get_total_capgo_tokens(org_id) postgres function that will count all the transactions from the previous year. The tables themselves (capgo_tokens and capgo_token_giftcards will NOT be accessible via RLS to the users)