Billing Center v2

[ignapas]

Overview

Second iteration of the Billing Center. After the first version has been tested and deployed, there are a number of possible improvements to the user experience and the overall look.

General improvements

• Amount of credits is shown for the wallet selected as in use.
• Placeholder text must be removed or made useful
  

Sections

The billing center is divided into four different main sections: Credit accoutns, Payment methods, Activity and Transactions

Wallets

The user has a personal wallet and the wallets that other users might have shared with him.
The user can only recharge his own personal wallet. Optionally, the user can enable the auto-recharge function for his personal wallet.

Wallet list (Credit Accounts section)

• Primary / secondary selection becomes Default / Not default. This is what determines which wallet is used by default when running a study.
  • The list of wallets gets a column header that says "Default Wallet / Account"
  • The switch becomes a radio button

Buy credits

Adds credits to the personal wallet.

Can be done in one or two steps, depending on whether the user has already saved a payment method. If a payment method exists and is selected, it will be charged after the user clicks on Buy credits. If not, there will be a second screen to enter credit card details and the option to save that payment method.

Select payment method

The payment method is selected by the user using a Select widget.

• If there are no saved payment methods
  • The widget is disabled
  • Above the widget there is a label "There are no saved payment methods yet"
  • The option "Enter card details in the next step" is selected
• If there are payment methods saved
  • The widget is enabled
  • A payment method is selected by default (preferably the one that was last used)
  • The option "Enter card details in the next step" is still available

Autorecharge

When the amount of credits of the personal wallet moves below a certain quantity, the system automatically recharges that wallet.

• Even if he is not allowed to edit it, this low threshold amount should be known by the user
• It is linked to a saved payment method. This needs to be made clear to the user. With no payment methods, autorecharge cannot work.

Activity & Transactions

Two different sections for tracking the usage of credits and the transactions adding credits to the user's wallet. Currently there are three related sections: Activity, Usage and Transactions: the will become only two. Transactions will list the USD payments where the user spends dollars for credits and Activity will list the usage of credits for computation time.

Both will have filtering capabilities and the option to download a report.

Transactions

• Lists USD transactions
  • Welcome package (free credits)
  • Buying credits
  • Refunds

This is only displayed for wallets owned by the user (or those where the user is made Accountant). A SelectBox is used to select the Wallet (as placeholder for when a user will be able to have multiple wallets).

Usage

Lists credit usage per wallet. If the wallet belongs to the user, all usage is listed. If not, only usage from the user is listed. Again, a SelectBox chooses the wallet (or "All wallets").

Payment methods

Lists all payment methods added by the user and allows to delete them. It also indicates if they are used for autorecharge.

Tasks for This is Sparta!

Preview Give feedback

1. Include date filters for Transactions and Usage
2. Export feature for Transactions and Usage
3. Refine table columns for Transactions and Usage
4. Autorecharge fetching state
5. "Currently in use" incoherence: Account get assigned to project and does not change
6. Saving column state in User Preferences
7. Hide shared wallets when list is empty
8. UI: Improvements on billing center tables #5284
   UX_improvements a:frontend +2
   
9. UI billing center: behaviour when payments service are unavailable #5283
   a:frontend bug +2
   

[elisabettai]

@ignapas, @jsaq007, I am adding here some feedback/bugs we got from the users. When you finish the implementation of the billing center v2, let's double check the following has changed. Also please let me know if I should write this feedback somewhere else

Show credit card name instead of uuid when autorecharge is enabled:

Credits account need a reload.

When you add another user to your wallet, the other user has to do a hard refresh to see it appearing. Maybe we can add a reload button?

See marker.io report for more info.

Usage

The usage table can use space better. For example, why it doesn't expand vertically? See more details here.

Move "Usage" somewhere else? I am not sure anymore this is relevant

See this feedback on marker.io. As far as I understand from this feedback, there should be an independent "Usage" window somewhere else? @ignapas, feel free to ask more details to the reporter on marker.io

[matusdrobuliak66]

Issue found:
When a user is in the Non-billable product, the frontend should behave a bit differently, the API is called without wallet_id as the wallet concept does not exist in non-billable products. Then the API returns the usage (without credits consumed) of that user:

[ignapas]

Hi @matusdrobuliak66,
I am now connecting date filters and ordering, I will write here everything I find so I don't forget.

• I don't see the filters and ordering parameters for payments. Is this missing? Not doing? Or just not yet on the Swagger specs?
• Ordering by credit_cost does not seem to work
• Shouldn't ordering be available at least for every column displayed in the front-end?
• NOTE: Payments endpoint does not have a wallet filter/parameter. This is not a problem for the moment.
• NOTE: Usage endpoint wallet parameter is optional. Also not a problem, but the front-end will always use it, there is no usage listing for all wallets.

[matusdrobuliak66]

Hi Ignacio, it would be best if we could meet in person, here are brief answers:

• I don't see the filters and ordering parameters for payments. Is this missing? Not doing? Or just not yet on the Swagger specs?

• Yes payments and usage have a bit different logic in the backend so I have focused on usage endpoint as I do not expect many payments, but if it is needed I can start to add it also there 👍

• Ordering by credit_cost does not seem to work

• good catch it is a bug, fix here: 🎨 Is922/adding filtering fields to usage endpoint #5277

• Shouldn't ordering be available at least for every column displayed in the front-end?

• yes valid point, added here 🎨 Is922/adding filtering fields to usage endpoint #5277

• NOTE: Payments endpoint does not have a wallet filter/parameter. This is not a problem for the moment.

• yes the same as above, we should discuss whether is needed right away, or not, based on that i will prioritize.

• NOTE: Usage endpoint wallet parameter is optional. Also not a problem, but the front-end will always use it, there is no usage listing for all wallets.

• I double checked and the behavior before was that when you are in an non-billable product where the concepts of wallet and credits don't exist, you use the same endpoint without specifying the wallet_id. The user gets his specific use. (Check UI of non-billable product for example in the production)

[ignapas]

@pcrespov
I found a critical issue with the paymentMethodAcknowledged socket.io event:
When using the fake completion (local env) I get

When in master (test gateway?) I get

The last one is correct. The first one forces the front-end to parse every response back to an object using JSON.parse while we should rely on the library to do this. It also adds an extra line of code basically everywhere and looks ugly.
To avoid this Python side, we should directly pass the dictionary to the emit method, without the use of json_dumps.
This is not a huge issue, the main issue here is the inconsistency between the fake completion and the test gateway. Still we should dedicate some time refactor so we can remove all the JSON.parse from the front-end (they are everywhere!).

EDIT: This is also the reason why the 'add payment method' window does not close in the deployments.

[pcrespov]

@pcrespov I found a critical issue with the paymentMethodAcknowledged ...
This is not a huge issue, ...

:-)

@ignapas OK i am working in a fix right now.
Q: are you sure the "stringified json" is returned by the fake and not by the real thing? i.e. you got it the other way around.

[ignapas]

@pcrespov I found a critical issue with the paymentMethodAcknowledged ...
This is not a huge issue, ...

:-)

@ignapas OK i am working in a fix right now. Q: are you sure the "stringified json" is returned by the fake and not by the real thing? i.e. you got it the other way around.

sending strings is not the huge issue. but the type inconsistency is kind of bad...
yes. in the deployments backend behaves good. the front end parses it as a string everytime, that is why only the fake works fine

[pcrespov]

sending strings is not the huge issue. but the type inconsistency is kind of bad...

@ignapas agreed. can you please also answer the question?

[pcrespov]

@ignapas @matusdrobuliak66 let's review what is missing here and close ASAP this issue.