Cap-go
Allow any plan to have credits
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
When user buys it, it credits his account It credits his organization?
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.
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)